Kubernetes 安全不是安装一个扫描工具就结束，而是一条从身份到运行时的防线。可以按“谁在访问、允许做什么、对象能否进入集群、工作负载如何运行、事后怎样追踪”五个问题来设计。
## 1. 认证：先确认“你是谁”
API Server 是集群控制入口。管理员、普通用户、ServiceAccount 和自动化程序都应使用独立身份，避免多人共用 kubeconfig。生产环境应设置明确的凭证生命周期，离职或角色变更时及时撤销权限。
Pod 内程序优先使用专用 ServiceAccount；不需要访问 Kubernetes API 的工作负载，建议设置：
```yaml
spec:
automountServiceAccountToken: false
```
这样可以减少令牌被容器内进程读取后的风险。
## 2. 授权：RBAC 坚持最小权限
RBAC 的核心对象包括 Role、ClusterRole、RoleBinding 和 ClusterRoleBinding。Role 只作用于命名空间，ClusterRole 可描述集群级资源或被多个命名空间复用。
实践建议：
- 优先使用 RoleBinding，确实需要跨命名空间或集群资源时再用 ClusterRoleBinding。
- 避免通配符 *，不要把日常账号直接绑定到 cluster-admin。
- 分开“查看”“发布”“运维”“安全审计”等职责。
- 注意创建 Pod 的权限可能间接获得 Secret、ServiceAccount 或节点能力。
- 定期使用 kubectl auth can-i 验证实际权限。
示例：只允许读取 default 命名空间中的 Pod：
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
namespace: default
name: read-pods
subjects:
- kind: ServiceAccount
name: observer
namespace: default
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: pod-reader
```
## 3. 准入控制：在对象落库前把关
认证和授权通过后，请求还会经过准入控制。Pod Security Admission 可以基于命名空间标签应用三种标准：
- Privileged：几乎不限制，适合受控的系统组件。
- Baseline：阻止常见的高风险配置。
- Restricted：更严格，适合大多数普通业务。
建议先用 warn 和 audit 观察，再逐步启用 enforce，避免一次性阻断现有应用：
```bash
kubectl label namespace app \
pod-security.kubernetes.io/warn=restricted \
pod-security.kubernetes.io/audit=restricted \
pod-security.kubernetes.io/enforce=baseline
```
原 PodSecurityPolicy 已从 Kubernetes v1.25 移除，新集群应采用 Pod Security Admission，或按治理需求选择策略引擎。
## 4. 工作负载防护：缩小容器权限
安全的 SecurityContext 通常包含：非 root 用户、禁止提权、只读根文件系统、删除不必要 capabilities，并使用 RuntimeDefault seccomp：
```yaml
securityContext:
runAsNonRoot: true
seccompProfile:
type: RuntimeDefault
containers:
- name: app
image: example/app:1.0.0
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]
```
应尽量避免 privileged、hostPID、hostNetwork、hostPath 和直接挂载容器运行时 socket。若业务确实需要，最好放到专用节点并配合额外审计。
## 5. 网络、Secret 与镜像
- 使用 NetworkPolicy 实现命名空间内外的最小通信。
- Secret 不是天然加密的保险箱，应开启 etcd 静态加密并限制读取权限。
- 镜像使用不可变版本或摘要，扫描漏洞并记录来源。
- 入口启用 TLS，管理面不要直接暴露到公网。
## 6. 落地顺序
1. 盘点所有身份、kubeconfig 与 ServiceAccount。
2. 清理 cluster-admin、通配符和长期不用的绑定。
3. 为新命名空间启用 Pod Security 的 warn/audit。
4. 给 Deployment 增加 SecurityContext 与资源限制。
5. 建立 NetworkPolicy、镜像扫描和审计日志。
6. 定期演练凭证泄露、节点失陷和误删后的响应。
安全配置必须先在测试环境验证；生产变更保留回滚方案，并持续观察被拒绝的请求。
## 参考资料
- https://kubernetes.io/docs/reference/access-authn-authz/rbac/
- https://kubernetes.io/docs/concepts/security/rbac-good-practices/
- https://kubernetes.io/docs/concepts/security/pod-security-standards/
- https://kubernetes.io/docs/concepts/security/pod-security-admission/
- https://kubernetes.io/docs/concepts/security/service-accounts/