关于后端:借助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 团队。