身份、RBAC 与安全基线¶

访问 Kubernetes API 要经过认证、鉴权和准入控制：先确认“你是谁”，再判断“能做什么”，最后由 Admission Policy/Webhook 检查或修改请求。网络访问、容器权限和 Secret 保护则属于其他安全层，不能只依赖 RBAC。

请求 → Authentication → Authorization（RBAC）→ Admission → API 对象写入 etcd

User 与 ServiceAccount¶

身份	用途	来源
User/Group	人员和外部自动化系统	证书、OIDC、Webhook 等外部认证
ServiceAccount	Pod 和集群内自动化身份	Kubernetes Namespaced 对象

Pod 未指定时使用 Namespace 的 default ServiceAccount。应用不需要访问 Kubernetes API 时应禁用自动挂载 Token：

spec:
  automountServiceAccountToken: false

需要 API 权限的应用创建专用 ServiceAccount，不共享高权限账户。

RBAC 对象¶

对象	范围	作用
Role	Namespace	定义某 Namespace 内的权限
ClusterRole	集群	定义集群级或可复用权限
RoleBinding	Namespace	在一个 Namespace 内绑定 Role/ClusterRole
ClusterRoleBinding	集群	在全集群绑定 ClusterRole，风险较高

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-reader
  namespace: order
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: config-reader
  namespace: order
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: app-read-config
  namespace: order
subjects:
  - kind: ServiceAccount
    name: app-reader
    namespace: order
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: config-reader

权限检查¶

kubectl auth can-i get pods -n order
kubectl auth can-i --list -n order
kubectl auth can-i list configmaps -n order \
  --as system:serviceaccount:order:app-reader

能创建 Pod/Deployment 的用户通常可以让 Pod 挂载该 Namespace 的 Secret、使用其他 ServiceAccount 或访问宿主资源，因此“只能创建工作负载”仍是高权限。尽量在 Namespace 级用 RoleBinding，不随意授予 cluster-admin、通配符资源或通配符动词。

Pod Security¶

Pod Security Admission 可按 Namespace 执行 privileged、baseline、restricted 等安全标准。业务容器通常应：

securityContext:
  runAsNonRoot: true
  seccompProfile:
    type: RuntimeDefault
containers:
  - name: app
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]

落地前确认应用写目录、端口和系统调用需求。禁止特权容器、Host Network/PID/IPC、HostPath 和额外 Capability，除非有经过审核的基础组件场景。

Secret 安全¶

Kubernetes Secret 的 Base64 只是编码。生产应启用 etcd 静态加密、RBAC 最小权限、审计日志和外部密钥方案。允许 list/watch secrets 也能读取内容，不只是 get。

Secret 不以明文提交 Git。
不打印完整 Pod 环境或 Secret YAML 到 CI 日志。
优先短期、可轮换凭据。
按应用拆分 Secret，不使用全 Namespace 通用大 Secret。
证书和 Token 到期需要监控。

镜像与供应链¶

仅允许可信 Registry，镜像用版本/digest。
CI 扫描镜像和依赖漏洞，保留 SBOM/签名与 Git SHA。
限制 imagePullSecrets 读取范围并定期轮换。
通过准入策略阻止 latest、特权容器、无资源限制等违规 Manifest。

审计清单¶

kubectl get role,rolebinding -A
kubectl get clusterrolebinding
kubectl get serviceaccount -A
kubectl auth can-i --list --as <identity> -n <namespace>
kubectl get namespaces --show-labels

常见风险¶

风险	说明
ClusterRoleBinding 过多	权限扩散到所有 Namespace
默认 ServiceAccount 被授权	未指定身份的任意 Pod 继承权限
可创建特权 Pod	可能进一步获得 Node/集群权限
Secret 广泛 list/watch	等效读取大量敏感信息
Argo CD/CI 使用 cluster-admin	单个仓库或 Runner 泄露影响全集群

官方参考：RBAC Good Practices、Security Checklist。