随着越来越多的企业开始采纳容器技术，他们正在面临一个重大挑战——如何爱护容器应用程序的平安？比起存储、网络和监控，平安经常是一个被积压已久的问题。再加上须要对员工进行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团队。