借助3款K8S原生控件，保护你的云原生应用

随着越来越多的企业开始采用容器技术，他们正在面临一个重大挑战——如何保护容器应用程序的安全？比起存储、网络和监控，安全常常是一个被积压已久的问题。再加上需要对员工进行Kubernetes相关的培训，对安全问题的关注已经远远滞后了。事实上，The New Stack发布的一项调查显示，近50%的Kubernetes用户表示，安全是他们尚未解决的首要问题。

在本文中，我们将深入了解Kubernetes所面临的安全威胁并展示保护集群的最佳实践，然后提供一些有用的工具以帮助开发人员维护集群安全。这些工具包括：

• Rancher Kubernetes Engine(RKE)，以实现声明式部署
• KubeLinter，用于以开发者为中心的安全检查
• StackRox，在构建、部署和运行时执行安全策略

工具介绍

Rancher Kubernetes Engine(RKE)

RKE是一个经过CNCF认证的Kubernetes发行版，可以在Docker容器内完整运行。它通过移除大多数的主机依赖项并提供一个部署、升级和回滚的稳定路径，解决了Kubernetes安装过于复杂的问题。RKE使用声明式YAML文件来配置和创建Kubernetes环境。这可以实现可重现的本地或远程环境。

KubeLinter

KubeLinter是一个静态的分析工具，它可以查看Kubernetes YAML文件以确保声明的应用程序配置坚持最佳实践。KubeLinter是StackRox首个开源工具，用于从命令行实现安全检查以及作为CI流程的一部分。KubeLinter是一个二进制文件，它接收YAML文件的路径，并对它们进行一系列的检查。管理员和开发人员可以创建自己的策略来执行，从而实现更快、更自动化的部署。

StackRox

StackRox Kubernetes安全平台通过构建、部署和运行时保护重要的应用程序。StackRox部署在您的基础设施中，并于您的DevOps工具和工作流程集成，以提供无摩擦的安全性和合规性。StackRox Policy Engine包含了数百个内置控制，以执行DevOps和安全最佳实践、CIS基准和NIST等行业标准、容器和Kubernetes运行时安全的配置管理。StackRox对您的工作负载进行剖析，使您能够对工作负载的安全性做出明智的决定。

组合使用

RKE、KubeLinter和StackRox使您能够部署可重现的安全集群、可视化配置文件和访问安全漏洞，并创建声明式安全策略。接下来，我们来谈谈这些应用程序如何共同应对安全威胁。

评估安全风险

我们先来关注一下Kubernetes的攻击载体。微软最近发布了一个基于MITRE ATT&CK框架的Kubernetes攻击矩阵：

https://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/

该框架针对Kubernetes进行了调整，并基于真实世界的观察和案例。幸运的是，存在一些策略可以缓解所有不同的问题。首先，我们可以从hardening我们的Kubernetes控制平面开始。之后，我们将把重点转移到保护我们运行的容器工作负载的安全上。

控制平面Hardening

Kubernetes控制平面包括以下组件：

• Kubernetes API Server
• kube-scheduler
• kube-controller-manager
• etcd (如果适用)
• cloud-controller-manager (如果适用)

etcd将可能在控制平面节点上，但是它也可以为高可用用例提供一个远程环境。cloud-controller-manager也安装在提供程序实例中。

Kubernetes API Server

Kubernetes REST API server是control-plane的核心组件。该server处理REST API的调用，这些调用包含不同组件和用户之间的所有通信。该依赖项使得保障API Server的安全成为人们最关心的问题。在此前的K8S版本中，只要升级到较新的版本就可以修复一些特定的漏洞。然而，你也可以控制以下hardening任务：

• 启用基于角色控制访问（RBAC）
• 确保所有API流量是TLS加密的
• 启用审计日志
• 为所有K8S API客户端设置身份验证

借助诸如RKE等开发工具，可以很轻松地设置这种声明式格式的集群。以下是一个默认的RKE config.yml.file代码段。从中可以看到，我们能够默认启用审计日志、TLS（在Kubernetes组件之间）以及RBAC。

 1. kube-api:
   
 2.  image: ""
  
 3. extra_args: {}
    
 4. extra_binds: []
   
 5. extra_env: []
    
 6. win_extra_args: {}
   
 7. win_extra_binds: []
   
 8. win_extra_env: []
    
 9. service_cluster_ip_range: 10.43.0.0/16
   
 10. service_node_port_range: ""
   
 11. pod_security_policy: false
   
 12. always_pull_images: false
   
 13. secrets_encryption_config: null
   
 14. audit_log: null
   
 15. admission_configuration: null
   
 16. event_rate_limit: null
 17. …
 18. authentication:
  
 19. strategy: x509
  
 20. sans: []
 
 21. webhook: null
 22. …
 23. authorization:
  
 24. mode: rbac
 
 25. options: {}

为所有的K8S API客户端设置身份验证是当前面临的挑战。我们需要应用一个零信任的模型到运行在我们集群中的工作负载上。

kube-scheduler

Kubernetes的默认scheduler是可插拔的。因此你可以构建你的scheduler或者为不同的工作负载设置多个scheduler。不管哪种实现方式，都需要保证安全。以下这些任务可以确保它是安全的：

• 设置与API Server通信的安全端口
• 确保scheduler以最低要求的权限运行（RBAC）
• 限制kube-scheduler pod规范和kubeconfig文件的文件权限

通过RKE，我们可以通过验证默认的scheduler地址(设置为127.0.0.1)来保证其与API server的连接。另外，通过确保根用户拥有scheduler YAML文件来限制文件权限。

stat -c %U:%G /etc/kubernetes/manifests/kube-scheduler.yaml

kube-controller-manager

Kubernetes系统调节器，即kube-controller-manager，是一个使用核心控制循环调节系统的守护进程。保护controller的安全，需要采取与scheduler类似的策略：

• 设置一个与API Server通信的安全端口
• 确保scheduler以最低所需权限运行（RBAC）
• 限制kube-controller-manager pod规范和kubeconfig文件的文件权限

和scheduler一样，我们可以确保通信使用本地地址（而不是不安全的loopback接口），并确保根用户拥有controller YAML文件。

stat -c %U:%G /etc/kubernetes/manifests/kube-controller-manager.yaml

etcd

控制平面的最后一个核心组件是它的键值存储，etcd。所有的Kubernetes对象都位于etcd中，这意味着你所有的配置文件和密钥都存储在这里。最好的做法是使用单独的密钥管理解决方案（如Hashicorp Vault或云提供商的密钥管理服务）来加密密钥或管理密钥信息。当你管理数据库时，需要记住以下关键因素：

• 限制对数据库的读/写访问
• 加密

我们希望将manifest的任何更新或更改限制在允许访问的服务上。使用RBAC控制与零信任模型相结合将可以帮助你入门。最后，使用etcd加密可能很麻烦。基于此，Rancher有一个独特的方法，即在初始集群配置中生产密钥。Kubernetes有类似的策略，尽管带有密钥的文件也需要安全。企业的安全要求将决定你在何处以及如何保护敏感信息。

Cloud-controller-manager

对于云提供商而言，云的cloud-controller-manager是独一无二的，同时它对于需要集群与提供程序API通信的发行版来说也是独有的。与云提供商一起使用时，管理员将无法访问其集群的主节点，因此将无法运行此前提到的hardening步骤。

使用Kubernetes原生控件保护工作负载安全

既然我们的控制平面的安全已经得到保障，那么是时候研究一下我们在Kubernetes中运行的应用程序了。与此前的部分类似，让我们把安全拆分为以下几个部分：

• 容器镜像安全
• 运行时
• 持久化
• 网络
• 基于角色的访问控制（RBAC）

在以下部分，我们将深入探讨每个部分的各种注意事项。

容器镜像安全

在使用容器之前对其进行管理是采用容器的第一个障碍。首先，我们需要考虑：

• 基本镜像的选择
• 更新频率
• 非必要软件
• 可访问的构建/CI工具

最重要的是选择安全的基础镜像，限制不必要的包并保障镜像仓库安全。现在，大部分镜像仓库都有内置的镜像扫描工具，可以轻松地确保安全。StackRox Kubernetes安全平台可以在与底层基础操作系统（OS）镜像分离的镜像层中自动执行可用于启动容器并识别安全问题（包括漏洞和有问题的程序包）的镜像。

如果你想了解更多，可以访问以下链接查看相关文章：

https://www.stackrox.com/post/2020/04/container-image-security-beyond-vulnerability-scanning/

Runtime

运行时安全跨越不同的Kubernetes功能，核心目标是确保我们的工作负载是安全的。Pod安全策略具备以下能力保护容器安全：

• Linux功能
• 容器的SELinux上下文
• 主机网络和端口的使用情况
• 主机文件系统的使用
• 容器的用户和groupID

请记住应用于系统的零信任方法，应该在其中设置功能，以便容器具有运行时起作用所需的最低功能。为了更好地实现可视化，StackRox的风险剖析会自动识别哪些容器中包含对攻击者有用的工具，包括bash。它还会对可疑工具的使用发出告警，并监控、检测和警告有关运行时活动，如在容器内执行异常或意外的进程。

持久化

在Kubernetes中运行有状态的工作负载会创建一个后门进入你的容器。通过附加存储并可能将可执行文件或信息提供给不应访问的容器，遭受攻击的可能性会大大增加。Kubernetes的最佳实践可以确保有状态工作负载以所需的最小特权运行。其他注意事项包括：

• 使用命名空间作为存储的自然边界
• 没有特权容器
• 使用Pod安全策略限制Pod volume访问

StackRox通过提供动态策略驱动的准入控制作为StackRox平台的一部分，帮助缓解这些威胁。这使企业能够自动执行安全策略，包括在将容器部署到Kubernetes集群之前对主机挂载的限制及其可写性。

网络访问

由于缺乏对容器的可见性，网络访问在Kubernetes中是一个艰难的挑战。默认情况下，网络策略是禁用的，每个pod都可以到达Kubernetes网络上的其他pod。如果没有这个默认值，新人会很难上手。随着企业的成熟，除了我们认为必要的流量之外，我们应该努力锁定所有流量。这可以使用由命名空间配置的网络策略来完成，同时关注以下几点也很重要：

• 使用命名空间作为网络策略的自然边界
• 在每个命名空间中启用默认的拒绝策略
• 使用特定于每个 pod 所需流量的网络策略

网络策略的重大挑战之一是可视化。StackRox通过监控pod之间的活动网络流量，自动生成和配置网络策略，将通信限制在应用程序组件运行所需的范围内，从而帮助防止网络映射。

基于角色的访问控制（RBAC）

RBAC是保护集群安全的核心。Kubernetes的RBAC权限是相加的，因此，RBAC唯一的漏洞是管理员或用户授予可利用的权限。我们遇到的最常见的问题是用户在不该有的时候拥有集群管理员权限。幸运的是，有很多RBAC最佳实践可以帮助减少此类问题：

• 对不同类型的工作负载使用不同的服务账户，并应用最小权限原则。
• 定期审核您的集群的RBAC配置。
• 对不同类型的工作负载使用不同的服务账户，并应用最小权限原则。
• 避免集群管理员的过度使用

RKE集群在集群设置时使用RBAC作为默认的身份验证选项。StackRox通过帮助企业根据最小权限原则（the least privilege principle）限制Kubernetes RBAC权限来扩展这个默认选项。我们监控集群RBAC设置的用户和服务账户，并识别集群上权限过大的账户。

总 结

独自解决Kubernetes安全问题是很有挑战性的。在企业中，安全问题很有可能会阻碍DevOps，导致在追求交付时放弃安全原则。但实际上，不一定如此。通过主动识别威胁并制定合理的政策，我们进一步将安全左移（shift left）。我们可以评估我们的时间需要用在哪里，避免用额外的工作量拖累DevOps团队。