随着更多的组织开始拥抱云原生技术，KubeRnetes已成为容器编排领域的行业标准。向 KubeRnetes转变的这股潮流，很大程度上简化了容器化应用程序的部署、扩展和管理，并实现了自动化，为传统的单体式系统提供了胜于传统管理协议的众多优势。
然而，管理大规模的KubeRnetes带来了一系列独特挑战，包括加固集群、保护供应链以及运行时检测威胁。本文结合云原生计算基金会(CNCF)、美国国家安全局(NSA)以及网络安全和基础设施安全局(CISA)的诸多最佳实践，整理出KubeRnetes安全加固的6个建议，帮助组织降低风险。
集群设置和加固
保护KubeRnetes环境从加固集群开始。对于使用托管KubeRnetes服务的用户而言，由相应的云提供商管理主节点安全，并为集群实施各种默认安全设置。GKE Autopilot采取了额外措施，实施GKE加固准则和GCP安全最佳实践。但即使对于GKE Standard或EKS/AKS用户而言，云提供商也有一套准则，以保护用户对KubeRnetes API服务器的访问、对云资源的容器访问以及KubeRnetes升级。
准则如下：
GKE加固指南
EKS安全最佳实践指南
AKS集群安全
至于自我管理的KubeRnetes集群，kube-bench可用于测试集群是否符合CIS KubeRnetes Benchmark中规定的安全准则。主要的建议包括：加密存储在静态etcd中的机密信息、使用tls证书保护控制平面通信以及开启审计日志功能。
网络和资源策略
默认情况下，KubeRnetes允许从任何pod到同一集群中另一个pod的通信。为了控制pod、命名空间和外部端点之间的流量，应使用支持NetworkPolicy API的CNI插件，用于网络隔离。遵照零信任模型，最佳实践是实施默认一概拒绝的策略，阻止所有出入流量，除非另一项策略特别允许。
除了网络策略外，KubeRnetes还提供两个资源级别的策略：LimitRange和ResourceQuotas。LimitRanges可用于限制单个资源的使用，而ResourceQuota控制聚合资源的使用。
RBAC和服务帐户
强大的网络和资源策略到位后，下一步是强制执行RBAC授权以限制访问。KubeRnetes管理员可以对用户和用户组强制执行RBAC以访问集群，以及限制服务访问集群内外的资源。另外，企业使用创建时挂载到每个pod的默认服务帐户时须谨慎。如果不需要与KubeRnetes服务进行任何特定的通信，将automountServiceAccountToken设置为False，以防止挂载。
系统加固
鉴于集群已安全，下一步是尽量缩小系统的攻击面。选择为运行容器而优化的专用操作系统，如AWS BottleRocket或GKE COS，而不是选择通用的linux节点。接下来，充分利用linux内核安全功能，如SELinux、AppArmor及/或Seccomp。AppArmor为linux用户或用户组定义了将程序限制于一组有限资源的权限。一旦定义了AppArmor配置文件，带有AppArmor标注的pod将强制执行这些规则。
另一方面，Seccomp限制容器的系统调用。只要底层KubeRnetes节点上有Seccomp配置文件可用，就可以在securitycontext这部分定义Seccomp配置文件。
即使没有Seccomp配置文件，用户仍然可以限制容器免受各种权限提升攻击。在安全上下文中，KubeRnetes允许配置容器是否可以以特权或Root身份来运行，或者将权限升级到Root。用户还可以限制hostPID、hostIPC、hostNetwork和hostPaths。所有这些设置都可以通过Pod security Policy或使用其他开源工具来执行。
供应链安全
即使集群和系统安全，为保证整个应用程序的端到端安全，也必须考虑到供应链。若是内部开发的应用程序，请遵循创建容器的最佳实践，即使用最小基础镜像以减小攻击面、固定软件包版本，并使用多阶段构建以创建小镜像。此外，定义容器运行所需的非Root用户，或使用Podman构建无Root容器，以限制Root访问。
下一步，使用开源工具或商用工具扫描所有镜像，以查找漏洞。一些工具还允许对镜像进行签名和验证签名，以确保容器在构建和上传过程中未被篡改。最后，定义KubeRnetes可以使用imagePolicyWebhook或上面提到的任何策略执行工具从中提取镜像的白名单注册表。
监控、日志和运行时安全
至此，我们有了一个供应链严加保护的安全集群，可以生成干净的、经过验证的镜像，有限的访问权限。然而环境是动态的，安全团队需能够响应运行环境中的事件。首先，将ReadOnlyRootfilesystem设置为true，并将tmp日志文件存储到emptyDir，以此确保容器在运行时不变。除了典型的应用程序监控或日志存储外，还可以使用Falco或Sysdig来分析系统调用进程和KubeRnetes API日志。
这两种工具都可以在运行时解析来自内核的linux系统调用，并在违反规则时触发警报。示例规则包括：权限提升时发出警报，已知目录上检测到读/写事件时发出警报，或调用Shell时发出警报。最后，将KubeRnetes API审计日志与现有日志聚合和警报工具整合起来，以监控集群中的所有活动。这包括API请求历史记录、性能指标、部署、资源消耗、操作系统调用和网络流量。
结语
由于云原生系统很复杂，需要采用多层方法来保护KubeRnetes环境。建议KubeRnetes做好云原生安全的4C：云、集群、容器和代码。首先，加固集群，并遵循云安全最佳实践;其次，严加保护容器，减小攻击面，限制访问，并确保运行时不变;再次，保护供应链，分析代码和容器以查找漏洞。最后，监控运行时的所有活动，将防御机制融入KubeRnetes内运行的每一层软件中。