借助 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。

  kube-api:    image: ""    extra_args: {}    extra_binds: []    extra_env: []    win_extra_args: {}    win_extra_binds: []    win_extra_env: []    service_cluster_ip_range: 10.43.0.0/16    service_node_port_range: ""    pod_security_policy: false    always_pull_images: false    secrets_encryption_config: null    audit_log: null    admission_configuration: null    event_rate_limit: null…authentication:  strategy: x509  sans: []  webhook: null…authorization:  mode: rbac  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 团队。

本文转载自：RancherLabs（ID：RancherLabs）

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