Kubernetes为我们提供了一套很好的软件安全原则，但我们仍然需要理解并实施它们。随着 Kubernetes 集群规模的增大，攻击数量也会慢慢增加，因此尽可能多地了解阻止攻击的最佳实践非常重要。
即使在使用托管的 Kubernetes 服务时，仍然有些安全需要用户来处理。云供应商通常负责管理和保护 Kubernetes 集群的控制平面（API 服务器、调度程序、etcd、控制器），客户负责保护数据平面（节点、入口、网络、服务网格等）。
本文，基于我在minikube和Linux Vagrant 项目的经验，分享了6个Kubernetes 安全最佳实践，应该对你会有所帮助，无论你是使用开源 Kubernetes，还是使用来自 Oracle、Azure、AWS 或其他云提供商之类的托管 Kubernetes 服务。
1. 使用基于角色的访问控制 (RBAC)
基于角色的访问控制 (RBAC) ，可以控制谁可以访问 Kubernetes API 以及他们拥有哪些权限。RBAC 通常在 Kubernetes 中默认启用。但是，如果你使用的是旧版本的 Kubernetes并且之前没有启用它，则应检查 RBAC 设置以确保它们已启用。
要记住的另一件事是，仅仅启用 RBAC 是不够的。你还应该管理授权策略并正确使用它们。使用 RBAC 将用户和组，限制为他们可能需要的操作和任务。始终遵循最小权限原则，以确保用户和 Kubernetes 服务帐户具有所需的最小权限集。确保不要授予集群范围的权限，除非绝对必要，否则不要向任何人授予集群管理员权限。 有关更多信息，请参阅官方 Kubernetes RBAC 文档。
对于使用云服务创建和管理的 Kubernetes 集群，供应商可能会提供身份和访问管理 服务。此处的文档 提供了更多详细信息。如果你需要多个因素来验证身份，则多因素身份验证 (MFA)是增强对 Kubernetes API 进行身份验证的安全性的另一种选择。
2. Secret应该是机密的
Secret包含敏感数据，例如密码、令牌或 SSH 密钥。Kubernetes secrets 使用密钥、密码、令牌等，帮助实现了Pod初始化的安全。当 Pod 启动时，它通常需要访问其secrets。每当创建服务帐户时，都会自动生成存储其授权令牌的 Kubernetes secrets。在master节点上，Secret对象以非加密的格式存储于etcd中，因此管理员必须加以精心管控以确保敏感数据的机密性，必须确保etcd集群节点间以及与APIserver的安全通信，etcd服务的访问授权，还包括用户访问APIServer时的授权，因为拥有创建pod资源的用户都可以使用Secret资源并能够通过pod中的容器访问其数据。
当攻击者尝试获得对 etcd 的读取访问权限时，加密提供了额外的防御级别。同时，确保用户和API服务器之间以及从API服务器到kubelets，使用SSL / TLS保护的通信，这很有必要，具体原因参考 Kubernetes文档。推荐的做法是为secrets 或凭证设置较短的生命周期，以使攻击者更难使用它们。为证书设置较短的生命周期并自动轮换是一种很好的做法。
要注意的另一件事是，请求访问 Kubernetes 集群secrets的第三方系统。在这种情况下，请仔细检查请求的 RBAC 权限和访问权限，否则你可能会损害集群的安全。
3. Kubernetes API 使用私有端点
Kubernetes 集群管理员和运维人员可以将集群的 Kubernetes API 端点配置为私有或公共子网的一部分。在私有集群中，控制平面内的 API 服务器（端点）有一个私有 IP 地址，这使得主节点无法从公共互联网访问。除了私有工作节点之外，你还应该确保将 Kubernetes API 端点配置为私有端点。如果你需要创建不使用或公开任何公共 IP 并且不允许流量进出公共互联网的完全私有的集群，可以使用安全访问控制列表或使用网络安全设置控制对集群 API 端点的网络访问。
4. 保护节点和 Pod
Node： Kubernetes 节点是一个工作节点，通常是可以在 Linux 操作系统 (OS) 上运行的 VM 或物理机。节点上运行的服务包括容器运行时、kubelet 和 kube-proxy。加固和保护节点上运行的操作系统很重要，这也是云提供商和 Kubernetes 管理员的责任。
例如，Oracle Kubernetes Engine 节点使用安全加强的 Linux 镜像。安全补丁应由 Kubernetes 管理员定期应用到在这些节点上运行的 Linux 镜像上，或者使用提供商的自动升级功能。对节点使用互联网安全中心 (CIS) Kubernetes 基准测试也是另一个很好的做法。
除了操作系统安全之外，还建议节点位于专用网络上并且不能从 Internet 访问。如果需要，可以配置网关以访问集群网络之外的其他服务。节点上的网络端口访问应通过网络访问列表进行控制。还建议限制对节点的SSH访问。
Pod： 一个 Pod 包含运行在节点上一个或多个容器的，并且可以使用共享或专用的存储。默认情况下，对哪些节点可以运行 Pod 没有限制。使用 网络策略为集群内的 pod 定义通信规则。网络策略由网络插件实现。
为了获得最佳网络安全状态，请使用网络策略组合来保护 pod 级网络通信和安全列表来保护主机级网络通信。Kubernetes中的 pod 安全上下文有助于定义 pod 或容器的权限和访问控制设置。Pod 安全策略允许客户控制Pod 运行时的执行属性，例如将容器作为特权容器运行的能力、主机文件系统的使用、网络和端口。默认情况下，可以在集群中的任何节点上调度 Pod。Kubernetes 提供了多种方式来控制 pod 到节点的分配，例如用于控制Pod调度到节点的策略 和 基于污点驱逐Pod的策略。
5. 降低容器安全风险
应用程序被打包为容器镜像，通常是Docker镜像。容器镜像存储并从容器镜像仓库中提取，并在 pod 内实例化为运行时容器。在开发过程之初，当你使用源代码和库为应用程序构建容器镜像时，安全性必须成为设计原则。
在你的 CI/CD 工具中以及在容器镜像的整个构建、存储和部署过程中实施安全实践。包括，安全地存储容器镜像、扫描这些镜像的安全漏洞以及管理容器的运行时安全性。作为 DevSecOps 周期的一部分，自动对可能用于构建应用程序的第三方库进行漏洞扫描是一个好主意。
在构建 Docker 镜像和容器时，使用体积小的操作系统镜像，并确保运行应用程序的用户具有运行容器内进程所需的最低操作系统权限级别。要记住的另一件重要事情是定期对源镜像应用安全更新，然后将它们重新部署更新。使用Docker私有镜像仓库时，具备适当的访问控制和策略也很重要。建议对容器镜像进行签名并维护对容器内容的信任。
6. 审计、日志记录和监控必不可少
审计、日志记录和监控是重要的安全方面，可以帮助改善集群的安全状况，这不容忽视。Kubernetes 审计日志，是对 Kubernetes API 服务器的每次调用的详细描述。这些审计日志提供有关集群中发生的事情的有用信息，甚至可用于审计、合规性和安全性分析。Kubernetes 审计 记录包括捕获完整活动序列的安全记录，可以帮助检测异常行为和对敏感资源的访问。
建议启用审计日志并将审计日志保存在存储库中，以便在发生泄露时进行分析。Kubernetes 还提供基于集群的 日志记录 ，以将容器活动记录到日志记录系统中。可以使用在每个节点上运行的Fluentd等代理将 Kubernetes 集群中每个容器的标准输出和标准错误输出采集到Elasticsearch等工具中， 并使用 Kibana 进行查看。最后，使用Prometheus、 Grafana或 Jaeger 等工具监控集群的容器、Pod、应用程序、服务和其他组件等。
译文链接: https://thenewstack.io/6-kubernetes-security-best-practices/
