随着更多的组织开始拥抱云原生技术,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: v1

kind: Pod

metadata:

name: apparmor

annotations:

container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-deny-write

spec:

containers:

- name: hello

image: busybox

command: [ "sh", "-c", "echo "Hello AppArmor!" && sleep 1h" ]

另一方面,Seccomp限制容器的系统调用。只要底层Kubernetes节点上有seccomp配置文件可用,就可以在securityContext这部分定义seccomp配置文件。

apiVersion: v1

kind: Pod

metadata:

name: audit-pod

labels:

app: audit-pod

spec:

securityContext:

seccompProfile:

type: Localhost

localhostProfile: profiles/audit.json

containers:

- name: test-container

image: hashicorp/http-echo:0.2.3

args:

- "-text=just made some syscalls!"

即使没有seccomp配置文件,用户仍然可以限制容器免受各种权限提升攻击。在安全上下文中,Kubernetes允许配置容器是否可以以特权或root身份来运行,或者将权限升级到root。用户还可以限制hostPID、hostIPC、hostNetwork和hostPaths。所有这些设置都可以通过Pod Security Policy(v1.21中已被弃用)或使用其他开源工具(比如K-Rail、Kyverno和OPA/Gatekeeper)来执行。

最后,如果需要额外的安全保证,可以配置自定义的RuntimeClass,以便充分利用硬件虚拟化(如gVisor或Kata)。在节点层面定义RuntimeClass,并在pod定义部分指定它。

apiVersion: node.k8s.io/v1 # RuntimeClass is defined in the node.k8s.io API group

kind: RuntimeClass

metadata:

name: myclass # The name the RuntimeClass will be referenced by

# RuntimeClass is a non-namespaced resource

handler: myconfiguration # The name of the corresponding CRI configuration

---

apiVersion: v1

kind: Pod

metadata:

name: mypod

spec:

runtimeClassName: myclass供应链安全

即使集群和系统安全,为保证整个应用程序的端到端安全,也必须考虑到供应链。若是内部开发的应用程序,请遵循创建容器的最佳实践,即使用最小基础镜像以减小攻击面、固定软件包版本,并使用多阶段构建以创建小镜像。此外,定义容器运行所需的非root用户,或使用podman构建无root容器,以限制root访问。

下一步,使用开源工具(如Trivy、Clair或Anchore)或者商用工具扫描所有镜像,以查找漏洞。一些工具还允许对镜像进行签名和验证签名,以确保容器在构建和上传过程中未被篡改。最后,定义Kubernetes可以使用ImagePolicyWebhook或上面提到的任何策略执行工具从中提取镜像的白名单注册表。

监控、日志和运行时安全

至此,我们有了一个供应链严加保护的安全集群,可以生成干净的、经过验证的镜像,有限的访问权限。然而环境是动态的,安全团队需能够响应运行环境中的事件。首先,将readOnlyRootFilesystem设置为true,并将tmp日志文件存储到emptyDir,以此确保容器在运行时不变。除了典型的应用程序监控(如Prometheus/Grafana)或日志(如EFK)存储外,还可以使用Falco或Sysdig来分析系统调用进程和Kubernetes API日志。

这两种工具都可以在运行时解析来自内核的Linux系统调用,并在违反规则时触发警报。示例规则包括:权限提升时发出警报,已知目录上检测到读/写事件时发出警报,或调用shell时发出警报。最后,将Kubernetes API审计日志与现有日志聚合和警报工具整合起来,以监控集群中的所有活动。这包括API请求历史记录、性能指标、部署、资源消耗、操作系统调用和网络流量。

结语

由于云原生系统很复杂,需要采用多层方法来保护Kubernetes环境。建议Kubernetes做好云原生安全的4C:云、集群、容器和代码。首先,加固集群,并遵循云安全最佳实践;其次,严加保护容器,减小攻击面,限制访问,并确保运行时不变;再次,保护供应链,分析代码和容器以查找漏洞。最后,监控运行时的所有活动,将防御机制融入Kubernetes内运行的每一层软件中。

参考链接:https://dzone.com/articles/kubernetes-security-guide-high-level-k8s-hardening

关键词: 建议 Kubernetes