安全
从安全的角度来看,Kubernetes 中包含如下图所示的潜在攻击面:

(图片来自《Kubernetes Security - Operating Kubernetes Clusters and Applications Safely》)
为了保证集群以及容器应用的安全,Kubernetes 提供了多种安全机制,限制容器的行为,减少容器和集群的攻击面,保证整个系统的安全性。
集群安全,比如组件(如 kube-apiserver、etcd、kubelet 等)只开放安全 API并开启 TLS 认证、开启 RBAC 等;
Security Context:限制容器的行为,包括 Capabilities、ReadOnlyRootFilesystem、Privileged、RunAsNonRoot、RunAsUser 以及 SELinuxOptions 等;
User Namespaces:通过隔离容器和主机的用户 ID,提供额外的安全隔离层(v1.33 默认启用);
Pod Security Policy:集群级的 Pod 安全策略,自动为集群内的 Pod 和 Volume 设置 Security Context;
Sysctls:允许容器设置内核参数,分为安全 Sysctls 和非安全 Sysctls;
AppArmor:限制应用的访问权限;
Network Policies:精细控制容器应用和集群中的网络访问;
Seccomp:Secure computing mode 的缩写,限制容器应用可执行的系统调用。
除此之外,推荐尽量使用较新版本的 Kubernetes,因为它们通常会包含常见安全问题的修复。你可以参考 kubernetes-announce 来查询最新的 Kubernetes 发布情况,也可以参考 cvedetails.com 查询 Kubernetes 各个版本的 CVE (Common Vulnerabilities and Exposures) 列表。
集群安全
Kubernetes 组件(如 kube-apiserver、etcd、kubelet 等)只开放安全 API 并开启 TLS 认证。
开启 RBAC 授权,赋予容器应用最小权限,并开启 NodeRestriction 准入控制(限制 Kubelet 权限)。
RBAC 规则过多或者无法满足实际需要时,推荐使用 Open Policy Agent (OPA) 配置更灵活的访问策略
开启 Secret 加密存储(Secret Encryption),并配置 etcd 的 TLS 认证;
禁止 Kubelet 的匿名访问和只读端口,开启 Kubelet 的证书轮替更新(Certificate Rotation)。
禁止默认 ServiceAccount 的 automountServiceAccountToken,并在需要时创建容器应用的专用 ServiceAccount。
禁止 Dashboard 的匿名访问,通过 RBAC 限制 Dashboard 的访问权限,并确保 Dashboard 仅可在内网访问(通过 kubectl proxy)。
定期运行 CIS Kubernetes Benchmark,确保集群的配置或更新符合最佳的安全实践(使用 kube-bench 和 kube-hunter)。
在多租户场景中,还可以使用 Kata Containers、gVisor 等对容器进程进行强隔离,或者使用 Istio、Linkerd 等对容器应用之间的通信也进行自动加密。
TLS 安全
为保障 TLS 安全,并避免 Zombie POODLE and GOLDENDOODLE Vulnerabilities,请为 TLS 1.2 禁止 CBC (Cipher Block Chaining) 模式。
你可以使用 https://www.ssllabs.com/ 来测试 TLS 的安全问题。
Security Context 和 Pod Security Policy
apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
name: restricted
annotations:
# Seccomp v1.11 使用 'runtime/default',而 v1.10 及更早版本使用 'docker/default'
seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'runtime/default'
seccomp.security.alpha.kubernetes.io/defaultProfileName: 'runtime/default'
apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default'
apparmor.security.beta.kubernetes.io/defaultProfileName: 'runtime/default'
spec:
privileged: false
# Required to prevent escalations to root.
allowPrivilegeEscalation: false
# This is redundant with non-root + disallow privilege escalation,
# but we can provide it for defense in depth.
requiredDropCapabilities:
- ALL
# Allow core volume types.
volumes:
- 'configMap'
- 'emptyDir'
- 'projected'
- 'secret'
- 'downwardAPI'
# Assume that persistentVolumes set up by the cluster admin are safe to use.
- 'persistentVolumeClaim'
hostNetwork: false
hostIPC: false
hostPID: false
runAsUser:
# Require the container to run without root privileges.
rule: 'MustRunAsNonRoot'
seLinux:
# This policy assumes the nodes are using AppArmor rather than SELinux.
rule: 'RunAsAny'
supplementalGroups:
rule: 'MustRunAs'
ranges:
# Forbid adding the root group.
- min: 1
max: 65535
fsGroup:
rule: 'MustRunAs'
ranges:
# Forbid adding the root group.
- min: 1
max: 65535
readOnlyRootFilesystem: false
完整参考见这里。
User Namespaces(用户命名空间)
User Namespaces 是 Kubernetes v1.33 中默认启用的重要安全特性,通过隔离容器内的用户和组 ID 与主机系统的用户和组 ID,提供了额外的安全隔离层。
安全最佳实践
高安全性工作负载:对于处理敏感数据或具有高安全要求的工作负载,建议启用用户命名空间:
apiVersion: v1
kind: Pod
metadata:
name: secure-workload
spec:
hostUsers: false # 启用用户命名空间
securityContext:
runAsNonRoot: true
runAsUser: 1000
fsGroup: 2000
containers:
- name: app
image: myapp:latest
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop:
- ALL
多租户环境:在多租户 Kubernetes 集群中,用户命名空间可以有效防止租户间的横向攻击:
apiVersion: v1
kind: Pod
metadata:
name: tenant-app
labels:
tenant: tenant-a
spec:
hostUsers: false
securityContext:
runAsUser: 1001
runAsGroup: 1001
fsGroup: 1001
containers:
- name: app
image: tenant-app:v1.0
securityContext:
runAsNonRoot: true
allowPrivilegeEscalation: false
传统应用迁移:对于需要以 root 身份运行的传统应用,用户命名空间允许在不牺牲安全性的情况下运行:
apiVersion: v1
kind: Pod
metadata:
name: legacy-app
spec:
hostUsers: false
containers:
- name: legacy
image: legacy-app:latest
securityContext:
runAsUser: 0 # 容器内 root,但映射到主机非特权用户
安全优势
容器逃逸防护:即使容器被攻破,攻击者获得的 root 权限也被限制在用户命名空间内
权限隔离:容器内的特权用户无法访问主机系统资源
文件系统保护:通过 idmap 挂载提供文件系统级别的用户 ID 隔离
横向移动防护:防止攻击者在获得一个容器的访问权限后影响其他容器或主机
注意事项
内核版本要求:需要 Linux 5.19+ 内核(推荐 6.3+)
容器运行时:需要支持用户命名空间的容器运行时(containerd 2.0+ 或 CRI-O)
卷限制:NFS 卷当前不支持用户命名空间
应用兼容性:大多数应用无需修改,但某些特权操作可能受限
部署建议
逐步推广:从非关键工作负载开始,逐步扩展到生产环境
测试验证:在启用前充分测试应用的兼容性
监控观察:部署后密切监控应用行为和性能指标
策略制定:为不同类型的工作负载制定用户命名空间使用策略
Supplemental Groups Policy(补充组策略)
从 Kubernetes v1.33 开始,supplementalGroupsPolicy
特性(Beta)提供了对容器补充组的精细控制,增强了安全性。
安全风险
默认情况下,Kubernetes 会将容器镜像中 /etc/group
定义的组信息与 Pod 指定的组信息合并,这可能带来安全风险:
隐式权限提升:容器可能获得未在 Pod 清单中声明的组权限
策略绕过:安全策略引擎无法检测这些隐式组
卷访问风险:意外的组成员身份可能导致对敏感卷的未授权访问
使用 Strict 策略
通过设置 supplementalGroupsPolicy: Strict
,可以确保只有明确指定的组被附加到容器进程:
apiVersion: v1
kind: Pod
metadata:
name: secure-pod
spec:
securityContext:
runAsUser: 1000
runAsGroup: 3000
supplementalGroups: [4000]
supplementalGroupsPolicy: Strict # 排除隐式组
containers:
- name: app
image: myapp:latest
securityContext:
allowPrivilegeEscalation: false
最佳实践
默认使用 Strict 策略:对于新部署的应用,建议默认使用 Strict 策略:
apiVersion: v1
kind: Pod
metadata:
name: production-app
spec:
securityContext:
supplementalGroupsPolicy: Strict
runAsNonRoot: true
runAsUser: 1000
runAsGroup: 1000
fsGroup: 2000
策略强制执行:通过准入控制器或 OPA 策略强制所有 Pod 使用 Strict 策略:
# OPA Rego 策略示例
deny[msg] {
input.kind == "Pod"
not input.spec.securityContext.supplementalGroupsPolicy
msg := "Pod must specify supplementalGroupsPolicy"
}
deny[msg] {
input.kind == "Pod"
input.spec.securityContext.supplementalGroupsPolicy != "Strict"
msg := "Pod must use supplementalGroupsPolicy: Strict"
}
审计现有工作负载:使用 Pod 状态中的用户信息审计现有工作负载的组成员身份:
# 查看容器的实际组成员身份
kubectl get pod <pod-name> -o jsonpath='{.status.containerStatuses[0].user.linux}'
逐步迁移策略:
阶段 1:审计并记录现有 Pod 的隐式组
阶段 2:在非生产环境测试 Strict 策略
阶段 3:为新应用默认启用 Strict 策略
阶段 4:逐步迁移现有应用到 Strict 策略
升级注意事项
如果您的集群已经在使用 supplementalGroupsPolicy: Strict
:
确保 CRI 运行时支持:
containerd v2.0+
CRI-O v1.31+
检查节点支持:
kubectl get nodes -o custom-columns=NAME:.metadata.name,SUPPORTED:.status.features.supplementalGroupsPolicy
处理不支持的节点:
升级 CRI 运行时
或使用节点选择器避免调度到不支持的节点:
apiVersion: v1
kind: Pod
metadata:
name: strict-policy-pod
spec:
nodeSelector:
feature.node.kubernetes.io/supplementalGroupsPolicy: "true"
securityContext:
supplementalGroupsPolicy: Strict
Sysctls
Sysctls 允许容器设置内核参数,分为安全 Sysctls 和非安全 Sysctls
安全 Sysctls:即设置后不影响其他 Pod 的内核选项,只作用在容器 namespace 中,默认开启。包括以下几种
kernel.shm_rmid_forced
net.ipv4.ip_local_port_range
net.ipv4.tcp_syncookies
非安全 Sysctls:即设置好有可能影响其他 Pod 和 Node 上其他服务的内核选项,默认禁止。如果使用,需要管理员在配置 kubelet 时开启,如
kubelet --experimental-allowed-unsafe-sysctls 'kernel.msg*,net.ipv4.route.min_pmtu'
Sysctls 在 v1.11 升级为 Beta 版,可以通过 PSP spec 直接设置,如
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: sysctl-psp
spec:
allowedUnsafeSysctls:
- kernel.msg*
forbiddenSysctls:
- kernel.shm_rmid_forced
而 v1.10 及更早版本则为 Alpha 阶段,需要通过 Pod annotation 设置,如:
apiVersion: v1
kind: Pod
metadata:
name: sysctl-example
annotations:
security.alpha.kubernetes.io/sysctls: kernel.shm_rmid_forced=1
security.alpha.kubernetes.io/unsafe-sysctls: net.ipv4.route.min_pmtu=1000,kernel.msgmax=1 2 3
spec:
...
AppArmor
AppArmor(Application Armor) 是 Linux 内核的一个安全模块,允许系统管理员将每个程序与一个安全配置文件关联,从而限制程序的功能。通过它你可以指定程序可以读、写或运行哪些文件,是否可以打开网络端口等。作为对传统 Unix 的自主访问控制模块的补充,AppArmor 提供了强制访问控制机制。
在使用 AppArmor 之前需要注意
Kubernetes 版本 >=v1.4
apiserver 和 kubelet 已开启 AppArmor 特性,
--feature-gates=AppArmor=true
已开启 apparmor 内核模块,通过
cat /sys/module/apparmor/parameters/enabled
查看仅支持 docker container runtime
AppArmor profile 已经加载到内核,通过
cat /sys/kernel/security/apparmor/profiles
查看
AppArmor 还在 alpha 阶段,需要通过 Pod annotation container.apparmor.security.beta.kubernetes.io/<container_name>
来设置。可选的值包括
runtime/default
: 使用 Container Runtime 的默认配置localhost/<profile_name>
: 使用已加载到内核的 AppArmor profile
$ sudo apparmor_parser -q <<EOF
#include <tunables/global>
profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
#include <abstractions/base>
file,
# Deny all file writes.
deny /** w,
}
EOF'
$ kubectl create -f /dev/stdin <<EOF
apiVersion: v1
kind: Pod
metadata:
name: hello-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"]
EOF
pod "hello-apparmor" created
$ kubectl exec hello-apparmor cat /proc/1/attr/current
k8s-apparmor-example-deny-write (enforce)
$ kubectl exec hello-apparmor touch /tmp/test
touch: /tmp/test: Permission denied
error: error executing remote command: command terminated with non-zero exit code: Error executing in Docker Container: 1
Seccomp
Seccomp 是 Secure computing mode 的缩写,它是 Linux 内核提供的一个操作,用于限制一个进程可以执行的系统调用.Seccomp 需要有一个配置文件来指明容器进程允许和禁止执行的系统调用。
在 Kubernetes 中,需要将 seccomp 配置文件放到 /var/lib/kubelet/seccomp
目录中(可以通过 kubelet 选项 --seccomp-profile-root
修改)。比如禁止 chmod 的格式为
$ cat /var/lib/kubelet/seccomp/chmod.json
{
"defaultAction": "SCMP_ACT_ALLOW",
"syscalls": [
{
"name": "chmod",
"action": "SCMP_ACT_ERRNO"
}
]
}
Seccomp 还在 alpha 阶段,需要通过 Pod annotation 设置,包括
security.alpha.kubernetes.io/seccomp/pod
:应用到该 Pod 的所有容器security.alpha.kubernetes.io/seccomp/container/<container name>
:应用到指定容器
而 value 有三个选项
runtime/default
: 使用 Container Runtime 的默认配置unconfined
: 允许所有系统调用localhost/<profile-name>
: 使用 Node 本地安装的 seccomp,需要放到/var/lib/kubelet/seccomp
目录中
比如使用刚才创建的 seccomp 配置:
apiVersion: v1
kind: Pod
metadata:
name: trustworthy-pod
annotations:
seccomp.security.alpha.kubernetes.io/pod: localhost/chmod
spec:
containers:
- name: trustworthy-container
image: sotrustworthy:latest
kube-bench
kube-bench 提供了一个简单的工具来检查 Kubernetes 的配置(包括 master 和 node)是否符合最佳的安全实践(基于 CIS Kubernetes Benchmark)。
推荐所有生产环境的 Kubernetes 集群定期运行 kube-bench,保证集群配置符合最佳的安全实践。
安装 kube-bench
:
$ docker run --rm -v `pwd`:/host aquasec/kube-bench:latest install
$ ./kube-bench <master|node>
当然,kube-bench 也可以直接在容器内运行,比如通常对 Master 和 Node 的检查命令分别为:
$ kubectl apply -f https://github.com/feiskyer/kubernetes-handbook/raw/master/examples/job-master.yaml
job.batch/kube-bench-master created
$ kubectl apply -f https://github.com/feiskyer/kubernetes-handbook/raw/master/examples/job-node.yaml
job.batch/kube-bench-node created
# Wait for a few seconds for the job to complete
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
kube-bench-master-k7jdd 0/1 Completed 0 2m15s
kube-bench-node-p9sl9 0/1 Completed 0 2m15s
# The results are held in the pod's logs
$ kubectl logs kube-bench-master-k7jdd
[INFO] 1 Master Node Security Configuration
[INFO] 1.1 API Server
...
镜像拉取认证安全(v1.33 新特性)
Service Account Token Integration for Kubelet Credential Providers
Kubernetes v1.33 引入了 Service Account Token Integration for Kubelet Credential Providers(Alpha 特性),这是一个重要的安全改进,允许使用 Pod 特定的服务账户令牌来获取镜像仓库凭证,从而消除了对长期有效的镜像拉取密钥的需求。
现有问题
目前,Kubernetes 管理员在处理私有容器镜像拉取时主要有两种选择:
存储在 Kubernetes API 中的镜像拉取密钥
这些密钥通常是长期有效的,因为很难轮换
必须显式附加到服务账户或 Pod
密钥泄露可能导致未授权的镜像访问
Kubelet 凭证提供程序
这些提供程序在节点级别动态获取凭证
在节点上运行的任何 Pod 都可以访问相同的凭证
没有按工作负载隔离,增加了安全风险
这两种方法都不符合最小权限和临时认证的原则,给 Kubernetes 留下了安全缺口。
解决方案
新的增强功能使 kubelet 凭证提供程序能够在获取镜像仓库凭证时使用工作负载身份。凭证提供程序可以使用服务账户令牌来请求与特定 Pod 身份绑定的短期凭证,而不是依赖长期有效的密钥。
这种方法提供了:
特定于工作负载的认证:镜像拉取凭证的范围限定为特定工作负载
临时凭证:令牌自动轮换,消除了长期有效密钥的风险
无缝集成:与现有的 Kubernetes 认证机制配合使用,符合云原生安全最佳实践
工作原理
凭证提供程序的服务账户令牌
Kubelet 为选择接收服务账户令牌进行镜像拉取的凭证提供程序生成短期、自动轮换的服务账户令牌
这些令牌符合 OIDC ID 令牌语义
令牌作为
CredentialProviderRequest
的一部分提供给凭证提供程序
镜像仓库认证流程
当 Pod 启动时,kubelet 从凭证提供程序请求凭证
如果凭证提供程序已选择加入,kubelet 为 Pod 生成服务账户令牌
服务账户令牌包含在
CredentialProviderRequest
中凭证提供程序使用此令牌进行身份验证,并从仓库(如 AWS ECR、GCP Artifact Registry、Azure ACR)交换临时镜像拉取凭证
kubelet 然后使用这些凭证代表 Pod 拉取镜像
优势
安全性:消除长期有效的镜像拉取密钥,减少攻击面
细粒度访问控制:凭证绑定到单个工作负载,而不是整个节点或集群
操作简化:管理员无需手动管理和轮换镜像拉取密钥
合规性改进:帮助组织满足禁止在集群中使用持久凭证的安全策略
如何启用
要尝试此功能:
确保运行 Kubernetes v1.33 或更高版本
在 kubelet 上启用
ServiceAccountTokenForKubeletCredentialProviders
特性门控kubelet --feature-gates=ServiceAccountTokenForKubeletCredentialProviders=true
确保凭证提供程序支持:修改或更新凭证提供程序以使用服务账户令牌进行身份验证
更新凭证提供程序配置:通过配置
tokenAttributes
字段,选择为凭证提供程序接收服务账户令牌部署 Pod:使用凭证提供程序从私有仓库拉取镜像
未来计划
对于 Kubernetes v1.34,预计此功能将升级为 Beta 版本,同时将专注于:
实施缓存机制以提高令牌生成的性能
为凭证提供程序提供更多灵活性,以决定返回给 kubelet 的仓库凭证如何缓存
使该功能与 Ensure Secret Pulled Images 配合工作
更多信息可以参考:
KEP-4412 跟踪进展
镜像拉取安全(v1.33 新特性)
Ensure Secret Pulled Images(确保私密镜像拉取安全)
Kubernetes v1.33 引入了 Ensure Secret Pulled Images(Alpha 特性),这是一个重要的安全改进,解决了容器镜像访问的潜在安全漏洞。
现有安全问题
在 v1.33 之前,Kubernetes 存在一个镜像访问安全漏洞:
当一个 Pod 使用私有镜像拉取凭证成功拉取镜像后,该镜像会存储在节点上
同一节点上的其他 Pod(即使没有相应的镜像拉取凭证)也能访问这些私有镜像
这违反了最小权限原则,可能导致敏感镜像的未授权访问
解决方案
新的 KubeletEnsureSecretPulledImages
特性门控启用后,Kubelet 会验证 Pod 的镜像拉取凭证:
凭证验证:即使镜像已存在于节点上,Kubelet 也会验证请求 Pod 的凭证
凭证匹配:只有使用相同凭证(或来自同一 Secret)的 Pod 才能重用已拉取的镜像
兼容性:支持所有镜像拉取策略(
IfNotPresent
、Never
、Always
)
工作原理
首次镜像拉取:
Pod 请求私有镜像
Kubelet 记录拉取意图
从 Pod 的 imagePullSecret 提取凭证
从镜像仓库拉取镜像
创建包含凭证详情的成功拉取记录
后续镜像请求:
Kubelet 检查新 Pod 的凭证
如果凭证与先前成功拉取的记录匹配,允许使用镜像
如果凭证不匹配,尝试新的镜像仓库拉取
如何启用
要启用此安全特性:
在 Kubelet 上启用特性门控:
kubelet --feature-gates=KubeletEnsureSecretPulledImages=true
配置 Pod 使用镜像拉取密钥:
apiVersion: v1 kind: Pod metadata: name: secure-private-image spec: containers: - name: app image: private-registry.example.com/myapp:v1.0 imagePullSecrets: - name: my-registry-secret
安全优势
访问控制增强:防止未授权 Pod 访问私有镜像
最小权限原则:确保只有具备适当凭证的 Pod 才能使用特定镜像
多租户安全:提高多租户环境中的镜像隔离性
合规性改进:帮助满足严格的安全合规要求
镜像安全
Clair
Clair 是 CoreOS 开源的容器安全工具,用来静态分析镜像中潜在的安全问题。推荐将 Clair 集成到 Devops 流程中,自动对所有镜像进行安全扫描。
安装 Clair 的方法为:
git clone https://github.com/coreos/clair
cd clair/contrib/helm
helm dependency update clair
helm install clair
Clair 项目本身只提供了 API,在实际使用中还需要一个客户端(或集成Clair的服务)配合使用。比如,使用 reg 的方法为
# Install
$ go get github.com/genuinetools/reg
# Vulnerability Reports
$ reg vulns --clair https://clair.j3ss.co r.j3ss.co/chrome
# Generating Static Website for a Registry
$ $ reg server --clair https://clair.j3ss.co
trivy
trivy 是 Aqua Security 开源的容器漏洞扫描工具。相对于 Clair 来说,使用起来更为简单,可以更方便集成到 CI 中。
# Install
sudo apt-get install wget apt-transport-https gnupg lsb-release
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo apt-key add -
echo deb https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main | sudo tee -a /etc/apt/sources.list.d/trivy.list
sudo apt-get update
sudo apt-get install -y trivy
# Image Scanning
trivy python:3.4-alpine
其他工具
其他镜像安全扫描工具还有:
安全工具
开源产品:
falco:容器运行时安全行为监控工具。
docker-bench-security:Docker 环境安全检查工具。
kube-hunter:Kubernetes 集群渗透测试工具。
商业产品
参考文档
最后更新于