一、为什么需要工作负载身份管理
在Kubernetes集群中，Pod经常需要访问云服务API（比如AWS S3、Google Cloud Storage或Azure Blob Storage）。直接在这些Pod里硬编码访问密钥（Access Key）或服务账号密钥文件，就像把家门钥匙贴在门口——非常不安全。一旦密钥泄露，黑客就能轻松访问你的云资源。
工作负载身份管理（Workload Identity）的核心思想是：让Pod动态获取临时、最小权限的访问凭证，而不是长期有效的密钥。这样即使凭证被截获，风险也大大降低。
二、主流云厂商的解决方案
1. AWS的IRSA（IAM Roles for Service Accounts）
IRSA允许你将IAM角色直接绑定到Kubernetes的Service Account上。当Pod使用这个Service Account时，会自动获得对应IAM角色的权限。
技术栈：AWS EKS + IRSA
# 1. 创建IAM角色（假设角色ARN为arn:aws:iam::123456789012:role/s3-reader）
# 2. 创建Kubernetes Service Account并注解IAM角色
apiVersion: v1
kind: ServiceAccount
metadata:
name: my-app-sa
annotations:
eks.amazonaws.com/role-arn: "arn:aws:iam::123456789012:role/s3-reader"
# 3. 在Pod中引用这个Service Account
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
serviceAccountName: my-app-sa # 关键配置
containers:
- name: my-container
image: my-app-image
注释：
eks.amazonaws.com/role-arn注解告诉EKS这个Service Account关联的IAM角色。- Pod启动后，AWS SDK会自动从实例元数据服务获取临时凭证。
2. Google Cloud的Workload Identity
GCP的方案类似，但需要通过Google Service Account（GSA）和Kubernetes Service Account（KSA）绑定实现。
技术栈：Google GKE + Workload Identity
# 1. 启用Workload Identity
gcloud container clusters update my-cluster \
--workload-pool=my-project.svc.id.goog
# 2. 创建Kubernetes Service Account
apiVersion: v1
kind: ServiceAccount
metadata:
name: my-app-sa
annotations:
iam.gke.io/gcp-service-account: "my-gsa@my-project.iam.gserviceaccount.com"
# 3. 在Pod中使用
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
serviceAccountName: my-app-sa
containers:
- name: my-container
image: my-app-image
注释：
iam.gke.io/gcp-service-account注解将KSA与GSA绑定。- Pod内调用Google Cloud API时会自动使用GSA权限。
三、开源工具推荐
如果你用的是多云环境或非主流云平台，可以考虑这些工具：
1. Vault Agent Sidecar
HashiCorp Vault能动态生成数据库密码、云API密钥等敏感信息。通过Sidecar模式注入到Pod中：
技术栈：HashiCorp Vault + Kubernetes
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
template:
spec:
serviceAccountName: vault-auth
containers:
- name: my-app
image: my-app-image
- name: vault-agent
image: vault:latest
args: ["agent", "-config=/etc/vault/config.hcl"]
volumeMounts:
- name: vault-config
mountPath: /etc/vault
volumes:
- name: vault-config
configMap:
name: vault-config
注释：
- Vault Agent以Sidecar形式运行，通过Kubernetes Auth方法获取令牌。
- 应用容器通过共享卷或HTTP API从Vault Agent获取凭证。
2. SPIFFE/SPIRE
SPIFFE是通用身份标准，SPIRE是其实现。它为每个工作负载颁发唯一身份证书：
技术栈：SPIRE + Kubernetes
# SPIRE Server部署（简化版）
apiVersion: apps/v1
kind: Deployment
metadata:
name: spire-server
spec:
template:
spec:
containers:
- name: spire-server
image: spire-server:latest
args: ["-config", "/run/spire/config/server.conf"]
# 注册Pod工作负载
apiVersion: spire.spiffe.io/v1alpha1
kind: ClusterSPIFFEID
metadata:
name: example
spec:
spiffeIDTemplate: "spiffe://example.org/ns/{{.PodMeta.Namespace}}/sa/{{.PodSpec.ServiceAccountName}}"
podSelector:
matchLabels:
app: my-app
注释：
- SPIRE Server负责颁发SVID（SPIFFE Verifiable Identity Document）。
- 应用容器通过Unix域套接字获取证书，用于mTLS通信。
四、最佳实践与避坑指南
1. 权限最小化原则
无论使用哪种方案，始终遵循最小权限原则。例如：
- 只给Pod访问特定S3桶的权限，而不是整个AWS S3服务。
- 使用条件限制（如IP范围、时间窗口）进一步约束权限。
2. 审计与轮换
- 启用云平台的审计日志（如AWS CloudTrail、GCP Audit Logs）。
- 设置凭证自动轮换（Vault和SPIRE都支持）。
3. 常见问题
- IRSA在Fargate上的限制：AWS Fargate Pod需要额外配置才能使用IRSA。
- GKE Workload Identity的域名冲突：如果集群域名与GCP项目域名冲突，需要手动调整。
五、总结
工作负载身份管理不是“可有可无”的功能，而是现代云原生架构的安全基石。根据你的云平台选择原生方案（如IRSA、Workload Identity），或通过Vault、SPIRE等工具实现统一管理。记住：临时、最小权限的凭证永远是安全的第一道防线。
评论