基于Kubernetes ServiceAccount身份体系的密钥管理系统-Vault/Conjur

前言

想象1个袜子乱穿的场景：

预发布（Dev/Staging）环境的Pod，意外拿到了生产环境（Prod）的 Redis、AK/SK 或制品库密钥，请求瞬间打进生产系统，引发数据污染甚至服务雪崩。

在Kubernetes环境中，需要管理的敏感信息越来越多：

GitLab/GitHub Token
Docker/Harbor登录凭证
制品库账号
云厂商AK/SK
数据库、Redis 等基础设施密钥

这些秘钥一旦泄露，或者被用错环境，带来的后果往往是生产级故障。

两份完全相同的Deployment.yaml部署至不同命名空间，依托Vault Kubernetes认证按命名空间(Namespace)绑定角色与密钥策略，准生产环境Pod即便知晓密钥路径也无法获取生产环境密钥。

一、Kubernetes权限

K8s采用RBAC权限模型，进行K8s资源的权限管理，RBAC就是先把权限打包成角色，再把角色发给人/人群/系统。

RBAC的设计原则是最小权限原则：每个Subject只获取完成任务所需的最少权限，避免滥用Role。

ServiceAccount决定你是谁，RBAC决定你能干什么？

RBAC组成

RBAC（基于角色的访问控制）主要由三类核心对象组成：

Role / ClusterRole：权限集合
RoleBinding / ClusterRoleBinding：绑定权限集合到Subject
Subject：人/人群/系统

RBAC 概念	Django / Web	Kubernetes
主体（Subject）	User	User / ServiceAccount
角色（Role）	Role 表	Role / ClusterRole
权限（Permission）	Permission 表	rule（verbs + resources）
绑定关系	UserRole	RoleBinding / ClusterRoleBinding
校验位置	代码里	API Server

Subject（权限承载者）

Subject指的是权限的接收者，可分为以下3类：

User：人类用户
Group：用户组
ServiceAccount：Kubernetes 内的系统身份（通常用于 Pod）

本质：Role/ClusterRole 是钥匙，Subject 是持钥者，RoleBinding是钥匙发放单。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app1-sa    # SA 名称
  namespace: dev   # 所在 Namespace
#--------------
apiVersion: v1
kind: Pod
metadata:
  name: app1
  namespace: dev
spec:
  serviceAccountName: app1-sa   # 指定 SA
  containers:
  - name: app1-container
    image: nginx

查看当前Pod使用的SA

$ winpty kubectl.exe exec -it shouwang-7d98479d99-qp99j -n ops-dev -- //bin/sh
/app # cat /var/run/secrets/kubernetes.io/serviceaccount/token
eyJhbGciOiJSUzI1NiIsImtpZCI6InlYUEQ0NXdSRVllVkVKSzE5dHJNY3l2Umxvd3FPZ1NwSmFQR0lPSENBVTAifQ.eyJhdWQiOlsiaHR0cHM6Ly9rdWJlcm5ldGVzLmRlZmF1bHQuc3ZjIl0sImV4cCI6MTc5OTI5MDM1OSwiaWF0IjoxNzY3NzU0MzU5LCJpc3MiOiJodHRwczovL2t1YmVybmV0ZXMuZGVmYXVsdC5zdmMiLCJqdGkiOiJhODc3MzE4Zi1iZTYxLTRjMWQtOWRhZS0yMTBiMmZiNzIyNjkiLCJrdWJlcm5ldGVzLmlvIjp7Im5hbWVzcGFjZSI6Im9
wcy1kZXYiLCJub2RlIjp7Im5hbWUiOiJhcC1ub3J0aGVhc3QtMS4xMC4xMjcuMC4xMzUiLCJ1aWQiOiI1ODI5ZDFhNy0zMGQ5LTQzZTMtYjUyMC02Y2MxNjI2Zjg0MDkifSwicG9kIjp7Im5hbWUiOiJzaG91d2FuZy03ZDk4NDc5ZDk5LXFwOTlqIiwidWlkIjoiOTZkMjE3NzUtMGU1OC00YTVkLTlhZjUtNGQ4ZDNmYjQ4NzM0In0sInNlcnZpY2VhY2NvdW50Ijp7Im5hbWUiOiJkZWZhdWx0IiwidWlkIjoiNTY5OGZlMDItODg5Ny00MzM0LThmNDctMTEzZDNhO
DhkNmZiIn0sIndhcm5hZnRlciI6MTc2Nzc1Nzk2Nn0sIm5iZiI6MTc2Nzc1NDM1OSwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50Om9wcy1kZXY6ZGVmYXVsdCJ9.gWyPAg_39ZsqT9ZyClKH6LnS-okoFJaqXoGkG_wfz4Y7sfKbhTof4652OJV9hYy4r4uW3jxKsMQY2PfsJA0wvbmALtYE9vp8YAiEtMoeHyyjGzGp_1AMgdzrYyhCytSEC2T7hd6qQAffd3C9NJHFkP6p6EvMxSlvegfJvFRr_5ffneb4L4Gz6ICcyxs3CATmHt1K-ZJYVyAhk60q6WFGcKXL3P
aStgrZCj0GAnwzuRHTtCK_JhJkKIHEclLueEVjZ_4-52tSWH5TF6jwwIHwF5QEATvMWlUNtoUZehlC5Tzae41cFs77O2LLr64WdYeJUOLGHuffW6_XptxJqoYnMg

View Code

Role/ClusterRole（权限集合）

Role：在1个Namespace内定义的一组权限（对资源的操作权限，如 Pod、ConfigMap等）。

ClusterRole：跨Namespace或全局权限的集合，可用于集群级别的资源。

本质：把一组具体操作（verbs）打包成角色，便于统一管理。

示例

kind: Role
metadata:
  name: pod-reader
  namespace: dev
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

RoleBinding/ClusterRoleBinding（权限绑定）

RoleBinding：把Role赋予指定的用户/用户组/ServiceAccount，在单个Namespace 内生效。

ClusterRoleBinding：把ClusterRole赋给用户/用户组/ServiceAccount，在集群全局生效。

本质：把权限集合真正授予谁，实现授权。

示例

kind: RoleBinding
metadata:
  name: read-pods
  namespace: dev
subjects:
- kind: ServiceAccount
  name: app1-sa
  namespace: dev
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

二、Vault秘钥管理系统

Vault密钥管理平台充分复用 Kubernetes 内置身份认证能力，统一管控业务凭据，根治密钥无序分发、违规复用这类高发且影响严重的安全隐患。

1.namespace命名即环境规范

ops-dev
ops-prod
ops-test

2.客户端

对于需要长期运行的客户端服务，通常将客户端作为Pod的Sidecar部署，以持续刷新和注入短期凭证；

而对于1次性访问的场景，可以采用InitContainer部署客户端。（DevOps 系统通常只需一次性部署，因此适合使用 Init Container 方式。）

每次访问秘钥管理系统时，客户端会先读取本地挂载的/var/run/secrets/kubernetes.io/serviceaccount/token再用PodSAToken请求秘钥管理系统获取短期凭证。

3.Vault工作流程

业务Pod ----[POST /v1/auth/kubernetes/login, {role, pod-sa-jwt}]----> Vault
                                                                     │
Vault  ─────[使用vault-sa凭证，创建TokenReview]────> K8S APIServer
Vault  <────[返回JWT归属ns与sa名称]───────────────── K8S APIServer
                                                                     │
Vault 核对role绑定sa/namespace规则，校验通过下发Vault Client Token
业务Pod <----------------[返回Vault Client Token]------------------- Vault
                                                                     │
业务Pod ----[携带X-Vault-Token 请求KV接口]--------------------------> Vault
Vault 校验Vault Policy权限，返回存储的用户名密码
业务Pod <-----------------[密钥信息]-------------------------------- Vault

参考

posted on 2026-01-06 09:12 运维体系建设之路阅读(33) 评论(0) 收藏举报

刷新页面返回顶部