安全是 Kubernetes 生产化部署的核心议题。默认情况下，K8s 集群中的用户和 ServiceAccount 拥有一定的权限，但若不加限制，任何 Pod 都可能访问 API Server，甚至越权操作。本文详细讲解基于角色的访问控制（RBAC）、ServiceAccount 的用途，以及 Pod 安全标准（Pod Security Standards）和 Pod Security Admission（PSA）。通过这些机制，你可以实现细粒度的权限隔离和安全加固。
一、Kubernetes 安全体系概览
Kubernetes 安全分为三个层面：
集群访问安全：认证（Authentication）、授权（Authorization）、准入控制（Admission Control）。
Pod 内部安全：容器运行用户、权限提升、安全上下文。
网络策略：限制 Pod 之间通信（后续文章介绍）。
本文聚焦于认证与授权（RBAC + ServiceAccount）以及 Pod 安全策略（PSA）。
二、认证（Authentication）与授权（Authorization）简介
认证：确认请求者的身份，包括：客户端证书、Bearer Token（ServiceAccount）、用户名/密码（基础认证，已废弃）、OpenID Connect 等。
授权：决定请求者是否有权执行某个操作。K8s 支持多种授权模式：RBAC、ABAC（已过时）、Webhook、Node 授权。
生产环境几乎都使用 RBAC（基于角色的访问控制）。
三、RBAC 核心概念
RBAC 通过四个资源对象实现：
3.1 一个简单的 Role 示例
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""] # 核心 API 组
resources: ["pods"] # 资源类型
verbs: ["get", "list", "watch"] # 允许的操作3.2 RoleBinding 绑定到用户
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
- kind: User
name: alice # 用户名（由外部认证提供）
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io3.3 ClusterRole 与 ClusterRoleBinding
ClusterRole 可用于跨命名空间管理，例如查看所有 Pod：
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: pod-reader-cluster
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: read-all-pods
subjects:
- kind: User
name: alice
roleRef:
kind: ClusterRole
name: pod-reader-cluster
apiGroup: rbac.authorization.k8s.io四、ServiceAccount：Pod 的身份标识
ServiceAccount 是 Kubernetes 为 Pod 中的进程提供的身份。Pod 可以使用该身份与 API Server 交互。每个命名空间会默认创建一个名为 default 的 ServiceAccount，并自动挂载 token 到 /var/run/secrets/kubernetes.io/serviceaccount。
4.1 创建自定义 ServiceAccount
bash
kubectl create sa my-sa -n my-ns
4.2 在 Pod 中使用 ServiceAccount
yaml
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
serviceAccountName: my-sa
containers:
- name: app
image: nginxPod 运行后，可以通过挂载的 token 调用 API Server（需要相应的 RBAC 授权）。
4.3 为 ServiceAccount 授权
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: my-ns
name: sa-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
namespace: my-ns
name: sa-reader-binding
subjects:
- kind: ServiceAccount
name: my-sa
namespace: my-ns
roleRef:
kind: Role
name: sa-reader
apiGroup: rbac.authorization.k8s.io4.4 禁止 ServiceAccount 自动挂载
默认情况下，每个 Pod 都会挂载默认 ServiceAccount 的 token。若不希望 Pod 拥有 API 访问权限，可以禁用自动挂载：
yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: no-token-sa
automountServiceAccountToken: false或在 Pod 级别设置 automountServiceAccountToken: false。
五、Pod 安全标准（Pod Security Standards）
Pod Security Standards 定义了三种安全策略，用于限制 Pod 的行为（如运行用户、特权容器、卷类型等）。
六、Pod Security Admission（PSA）
Pod Security Admission 是 K8s 1.22+ 引入的准入控制器，用于在命名空间级别强制执行 Pod 安全标准。它是 PodSecurityPolicy（已废弃）的替代方案。
6.1 为命名空间设置安全策略
通过给命名空间打标签来声明策略：
bash
# 设置默认策略为 baseline，并拒绝违反 restricted 策略的 Pod
kubectl label ns default pod-security.kubernetes.io/enforce=baseline
kubectl label ns default pod-security.kubernetes.io/enforce-version=latest
kubectl label ns default pod-security.kubernetes.io/warn=restricted
kubectl label ns default pod-security.kubernetes.io/warn-version=latestenforce：违反策略时拒绝 Pod 创建。
audit：记录违反事件但不拒绝。
warn：触发告警信息。
6.2 测试 Pod 是否符合策略
如果一个 Pod 违反了 restricted 策略，但命名空间只设置了 warn=restricted，则创建 Pod 时会显示警告，但 Pod 仍能创建。可以逐步提升策略等级。
6.3 豁免与例外
通过 Pod 的 metadata.annotations 可以临时绕过某些检查：
yaml
metadata:
annotations:
pod-security.kubernetes.io/exempt: "true"但生产环境不建议普遍使用。
七、安全上下文（SecurityContext）
SecurityContext 是在 Pod 或容器级别配置安全选项（如运行用户、特权、只读根文件系统等）。
7.1 容器级别配置
yaml
apiVersion: v1
kind: Pod
spec:
containers:
- name: myapp
image: myapp
securityContext:
runAsUser: 1000
runAsGroup: 3000
readOnlyRootFilesystem: true
allowPrivilegeEscalation: false
capabilities:
drop: ["ALL"]
add: ["NET_ADMIN"]runAsNonRoot: true：强制容器不以 root 运行。
privileged: false：禁止特权容器。
capabilities：控制 Linux Capabilities，遵循最小权限原则。
7.2 Pod 级别配置
Pod 级别配置会被容器继承（除非容器覆盖）：
yaml
spec:
securityContext:
runAsUser: 1000
fsGroup: 2000 # 卷文件的属组八、实战：为部署提供最小权限 ServiceAccount
创建命名空间 secure-ns。
创建 ServiceAccount my-app-sa。
创建 Role 只允许 get、list pods。
绑定该 Role 到 ServiceAccount。
在 Deployment 中使用该 ServiceAccount。
yaml
# 创建命名空间
kubectl create ns secure-ns
# 创建 ServiceAccount
kubectl create sa my-app-sa -n secure-ns
# 创建 Role 和 RoleBinding
cat <<EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: secure-ns
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
namespace: secure-ns
name: my-app-binding
subjects:
- kind: ServiceAccount
name: my-app-sa
namespace: secure-ns
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
EOF
# 部署应用
kubectl run test-pod --image=busybox -n secure-ns --overrides='{"spec":{"serviceAccountName":"my-app-sa"}}' --command sleep 3600进入 Pod 测试 API 访问：
bash
kubectl exec -it test-pod -n secure-ns -- sh
# 安装 curl 并访问 API Server
apk add curl
TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
curl -k -H "Authorization: Bearer $TOKEN" https://kubernetes.default/api/v1/namespaces/secure-ns/pods由于只授权了 get/list pods，无法创建或删除资源。
九、最佳实践
禁用 default ServiceAccount 的自动挂载：为每个命名空间配置 automountServiceAccountToken: false。
使用最小权限原则：只授予必要的 API 操作。
为生产环境命名空间开启 Pod Security Admission：至少设置为 baseline。
避免使用 privileged 容器，除非绝对必要（如网络插件）。
设置容器的 securityContext：runAsNonRoot: true，readOnlyRootFilesystem: true。
定期审计 RBAC 权限：使用工具如 rbac-lookup、kubectl-who-can。
十、小结
RBAC 和 ServiceAccount 构成了 Kubernetes 的授权基础，通过细粒度的角色绑定，可以严格限制 Pod 和用户的操作范围。Pod Security Admission 则保证了 Pod 自身配置的安全性，防止危险配置（如特权容器）进入集群。结合 SecurityContext，你能够建立一个纵深防御的容器环境。