Kubernetes安全加固的一些实用建议

目录前言集群设置和加固准则如下：网络和资源策略RBAC和服务账户系统加固供应链安全监控、日志和运行时安全总结

前言

随着更多的组织开始拥抱云原生技术，Kubernetes已成为容器编排领域的行业标准。向 Kubernetes转变的这股潮流，很大程度上简化了容器化应用程序的部署、扩展和管理，并实现了自动化，为传统的单体式系统提供了胜于传统管理协议的众多优势。

然而，管理大规模的Kubernetes带来了一系列独特挑战，包括加固集群、保护供应链以及运行时检测威胁。本文结合云原生计算基金会（CNCF）、美国国家安全局（NSA）以及网络安全和基础设施安全局（CISA）的诸多最佳实践，整理出Kubernetes安全加固的6个建议，帮助组织降低风险。

集群设置和加固

保护Kubernetes环境从加固集群开始。对于使用托管Kubernetes服务（比如GKE、EKS或AKS）的用户而言，由相应的云提供商管理主节点安全，并为集群实施各种默认安全设置。GKE Autopilot采取了额外措施，实施GKE加固准则和GCP安全最佳实践。但即使对于GKE Standard或EKS/AKS用户而言，云提供商也有一套准则，以保护用户对Kubernetes API服务器的访问、对云资源的容器访问以及Kubernetes升级。

准则如下：

GKE加固指南

EKS安全最佳实践指南

AKS集群安全

至于自我管理的Kubernetes集群（比如kube-adm或kops），kube-bench可用于测试集群是否符合CIS Kubernetes Benchmark中规定的安全准则。主要的建议包括：加密存储在静态etcd中的机密信息、使用TLS证书保护控制平面通信以及开启审计日志功能。

网络和资源策略

默认情况下，Kubernetes允许从任何pod到同一集群中另一个pod的通信。虽然这对于发现服务而言很理想，但没有提供网络分离，不法分子或中招的系统可以无限制地访问所有资源。如果团队使用命名空间作为Kubernetes内部多租户的主要手段，这就成为非常严重的问题。

为了控制pod、命名空间和外部端点之间的流量，应使用支持NetworkPolicy API的CNI插件（比如Calico、Flannel或针对特定云的CNI），用于网络隔离。遵照零信任模型，最佳实践是实施默认一概拒绝的策略，阻止所有出入流量，除非另一项策略特别允许。

除了网络策略外，Kubernetes还提供两个资源级别的策略：LimitRange和ResourceQuotas。LimitRanges可用于限制单个资源的使用（如每个pod最多有2个CPU），而ResourceQuota控制聚合资源的使用（如在dev命名空间中总共有20个CPU）。

RBAC和服务账户

强大的网络和资源策略到位后，下一步是强制执行RBAC授权以限制访问。Kubernetes管理员可以对用户和用户组强制执行RBAC以访问集群，以及限制服务访问集群内外的资源（如云托管的数据库）。另外，企业使用创建时挂载到每个pod的默认服务账户时须谨慎。pod可能被授予过大的权限，这取决于授予默认服务账户的权限。如果不需要与Kubernetes服务进行任何特定的通信，将automountServiceAccountToken设置为false，以防止挂载。

系统加固

鉴于集群已安全，下一步是尽量缩小系统的攻击面。这适用于节点上运行的操作系统以及容器上的内核。选择为运行容器而优化的专用操作系统，如AWS Bottlerocket或GKE COS，而不是选择通用的Linux节点。接下来，充分利用Linux内核安全功能，如SELinux、AppArmor（自1.4起是测试版）及/或seccomp（自1.19起是稳定版）。AppArmor为Linux用户或用户组定义了将程序限制于一组有限资源的权限。一旦定义了AppArmor配置文件，带有AppArmor标注的pod将强制执行这些规则。

apiVersion:

这是一个AD广告，想出现在这里吗？点击我！

这是一个AD广告，想出现在这里吗？点击我！

这是一个AD广告，想出现在这里吗？点击我！

这是一个AD广告，想出现在这里吗？点击我！

这是一个AD广告，想出现在这里吗？点击我！

这是一个AD广告，想出现在这里吗？点击我！