Kubernetes IAM 与 RBAC 为 DevOps 与 SRE

I’m happy to help translate the article, but I need the actual text you’d like translated. Could you please paste the content (or the portion you want translated) here? Once I have the text, I’ll provide a Simplified Chinese translation while preserving the formatting, markdown, and any code blocks or URLs.

理解 Kubernetes 中的身份（初学者级别）

身份验证 vs 授权

• Authentication – 你是谁？
• Authorization – 你能做什么？

Kubernetes 将这些职责分离：身份验证用于验证身份，而授权用于确定权限。

Kubernetes 中的身份类型

Kubernetes 识别三种身份类型：

1. Users – 人类操作员或外部系统。
2. Groups – 用户的逻辑集合。
3. ServiceAccounts – 在 Pod 内运行的工作负载的身份。

用户、组和 ServiceAccount（初学者 → 中级）

用户（人类）

用户代表在集群外部操作的人（例如，通过 kubectl）。

注意： Kubernetes 并未提供内置的 create user 命令；用户通常在集群外部管理（例如，通过证书或外部身份提供者）。

组

组是用户的逻辑集合，用于简化权限分配。

ServiceAccount

ServiceAccount（SA）是集群内部工作负载的身份。
典型的使用者包括 cert‑manager 和 prometheus‑operator 等运营组件。

关键原则： 人类 ≠ 工作负载。

实践中的身份验证（中级）

实践：创建用户（证书认证）

# Step 1: Generate a private key
openssl genrsa -out devuser.key 2048

# Step 2: Generate a CSR
openssl req -new -key devuser.key -out devuser.csr \
  -subj "/CN=devuser/O=dev-team"

# Step 3: Sign the certificate (using the cluster’s CA)
openssl x509 -req -in devuser.csr \
  -CA /etc/kubernetes/pki/ca.crt \
  -CAkey /etc/kubernetes/pki/ca.key \
  -CAcreateserial -out devuser.crt -days 365

# Step 4: Add the user to your kubeconfig
kubectl config set-credentials devuser \
  --client-certificate=devuser.crt \
  --client-key=devuser.key

# Step 5: Create a context for the new user
kubectl config set-context devctx \
  --cluster=kubernetes \
  --user=devuser

测试访问

kubectl --context=devctx get pods
# Expected output:
# Error from server (Forbidden): pods is forbidden

使用 RBAC 的授权（中级）

RBAC 基础

RBAC（基于角色的访问控制）通过将 主体（用户、组、服务账号）绑定到定义了允许的 资源 和 动词 的 角色，来回答“你能做什么？”的问题。

• 资源示例： pods、deployments、nodes
• 动词示例： get、list、watch、create、delete

实际 RBAC 配置

创建一个 Role（命名空间范围）

# role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: dev
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

kubectl apply -f role.yaml
# role.rbac.authorization.k8s.io/pod-reader created

将 Role 绑定到用户

# rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-dev-pods
  namespace: dev
subjects:
- kind: User
  name: devuser
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

kubectl apply -f rolebinding.yaml
# rolebinding.rbac.authorization.k8s.io/read-dev-pods created

测试授权

# Should succeed (read‑only access to pods in dev)
kubectl --context=devctx get pods -n dev

# Should fail (no cluster‑scope permission)
kubectl --context=devctx get nodes
# Output:
# Error: User "devuser" cannot list resource "nodes" at cluster scope

集群级别访问（高级）

创建 ClusterRole

# clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-reader
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

kubectl apply -f clusterrole.yaml
# clusterrole.rbac.authorization.k8s.io/node-reader created

将 ClusterRole 绑定到 ServiceAccount

# clusterrolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: node-reader-binding
subjects:
- kind: ServiceAccount
  name: prometheus-sa
  namespace: monitoring
roleRef:
  kind: ClusterRole
  name: node-reader
  apiGroup: rbac.authorization.k8s.io

kubectl apply -f clusterrolebinding.yaml
# clusterrolebinding.rbac.authorization.k8s.io/node-reader-binding created

验证访问

kubectl auth can-i list nodes --as=system:serviceaccount:monitoring:prometheus-sa
# Output: yes

Deployment 中的 ServiceAccount

将 ServiceAccount 附加到 Deployment（摘录）：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus
  namespace: monitoring
spec:
  template:
    spec:
      serviceAccountName: prometheus-sa
      containers:
      - name: prometheus
        image: prom/prometheus:latest

您可以在 pod 中验证已挂载的凭证：

kubectl exec -it prometheus-xxxx -n monitoring -- ls /var/run/secrets/kubernetes.io/serviceaccount
# Output:
# ca.crt  token  namespace

实际 DevOps/SRE 场景（专家级）

云 IAM 集成（专家级）

Kubernetes 本身不提供企业级 IAM。云服务提供商提供的集成可以将外部身份映射到 Kubernetes RBAC：

• Amazon EKS – IAM 角色用于服务账户（IRSA）
• Azure AKS – Azure AD 集成
• Google GKE – GCP IAM 绑定

这些桥接让您能够利用现有的云 IAM 策略来访问集群。

反模式（真实世界的错误）

• 将 cluster‑admin 权限授予应用程序使用的服务账户。

• 对人类用户使用静态证书且不进行轮换。

• 权限过大的 RoleBindings（例如，对 * 资源使用 * 动作）。

• 在同一组中混合人类身份和工作负载身份。

• 使用 SSO/OIDC 进行人工身份验证。

• 优先使用 短期令牌 和 证书轮换。

• 在 Role/ClusterRole 定义中遵循 最小权限原则。

• 将 命名空间范围 和 集群范围 的权限分离。

• 定期审计 RBAC 绑定（kubectl get rolebindings,clusterrolebindings）。

• 在 RBAC 之外，利用 Pod Security Standards 和 NetworkPolicies。

结论

通过本指南，你现在应该了解：

• Kubernetes 认证的工作原理（证书、OIDC 等）
• 用户、组和服务账户之间的区别
• RBAC 理论、角色创建以及绑定机制
• 命名空间范围 vs. 集群范围的权限
• 实际的 YAML 清单和命令行工作流
• 真实场景下的 DevOps/SRE 身份案例和云 IAM 集成
• 常见反模式和企业级最佳实践

这种思维模型是生产级 SRE 和平台工程师用来运行安全、可维护的 Kubernetes 集群的依据。