目录前言集群设置和加固准则如下:网络和资源策略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:
暂无评论内容