ServiceAccount & User & Group

🧩 ServiceAccount

ServiceAccount 是 Kubernetes 中为 Pod 提供身份的对象，它相当于 Pod 的“工牌”，让 Pod 在集群中能够以某个身份访问 API Server，并使用 RBAC 权限。

---

🧩 ServiceAccount 的作用

• 身份标识
  👉 每个 Pod 默认都会绑定一个 ServiceAccount，用来标识它在集群中的身份。
• 权限控制
  👉 结合 RBAC，决定 Pod 能访问哪些资源。
• 安全通信
  👉 Pod 通过 ServiceAccount 获取 Token，用来安全地调用 API Server。
• 自动挂载
  👉 Kubernetes 会自动把 ServiceAccount 的 Token 挂载到 Pod 的 /var/run/secrets/kubernetes.io/serviceaccount 路径。

---

📌 类比理解

• ServiceAccount = 工牌
  • 每个员工（Pod）上班时都要佩戴工牌（ServiceAccount）。
  • 工牌上有身份信息和权限范围，决定员工能进入哪些部门（命名空间）、能做哪些事情（操作资源）。
  • 没有工牌，员工无法在公司（集群）里自由行动。

---

📝 示例配置

创建一个 ServiceAccount：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-serviceaccount
  namespace: dev-team

在 Pod 中使用 ServiceAccount：

apiVersion: v1
kind: Pod
metadata:
  name: sa-demo
spec:
  serviceAccountName: my-serviceaccount
  containers:
  - name: demo
    image: alpine
    command: ["sleep", "3600"]

👉 这个 Pod 会使用 my-serviceaccount 的身份运行。

---

⚠️ 注意事项

• 默认 ServiceAccount：如果不指定，Pod 会使用命名空间的 default ServiceAccount。
• 安全性：建议为不同应用创建独立的 ServiceAccount，并结合 RBAC 授予最小权限。
• 不可跨命名空间：ServiceAccount 只能在所属命名空间中使用。

---

💡 总结

• ServiceAccount 是 Kubernetes 的 工牌系统。
• 它为 Pod 提供身份和权限，结合 RBAC 实现安全访问控制。
• 默认每个 Pod 都有工牌，但生产环境通常需要自定义和精细化管理。

---

🧩 User

在 Kubernetes 中，User 和 ServiceAccount 都代表身份，但它们的用途和管理方式有明显区别。

---

🧩 User 的作用

• 外部身份
  👉 User 通常是集群外部的实体，比如开发者、管理员。
• 认证方式
  👉 通过证书、OAuth、OIDC、LDAP 等外部系统认证。
• 生命周期管理
  👉 Kubernetes 本身不存储或管理 User 对象，它依赖外部身份系统。
• 典型场景
  👉 开发者用 kubectl 登录集群时，就是以 User 身份访问。

---

📌 类比理解

• User = 外部员工
  • 外部员工（开发者/管理员）通过门禁系统（认证）进入公司（集群）。
  • 公司本身不管理这些员工的档案，而是依赖外部人事系统。
• ServiceAccount = 内部工牌
  • 内部工人（Pod）上班时必须佩戴工牌（ServiceAccount）。
  • 工牌由公司（Kubernetes）自己发放，并决定工人能进入哪些部门（命名空间）、能做哪些事（操作资源）。

---

💡 总结

• User 是外部身份，供人类或外部系统使用，Kubernetes 不直接管理。
• ServiceAccount 是内部身份，供 Pod 使用，由 Kubernetes 自动管理。
• 两者结合 RBAC，构成完整的权限控制体系。

---

🧩 Group

Group 是 Kubernetes RBAC 中的一种身份集合，它把多个用户归类在一起，方便统一分配权限。与 User 和 ServiceAccount 相比，Group 更像是一个“用户组”，而不是单个身份。

---

🧩 Group 的作用

• 批量授权
  👉 可以一次性给整个组分配权限，而不是逐个用户绑定。
• 简化管理
  👉 当有很多用户需要相同权限时，用 Group 管理更高效。
• 外部系统支持
  👉 Kubernetes 本身不存储 Group 信息，它依赖外部身份系统（如 LDAP、OIDC、企业认证系统）来定义和管理。

---

📌 类比理解

• Group = 部门员工名单
  • User 是单个员工，ServiceAccount 是 Pod 的工牌。
  • Group 就是部门的员工名单，把一群人归在一起。
  • 管理员只需要给部门分配权限，部门里的所有员工就自动拥有这些权限。

---

📝 使用示例

在 RoleBinding 或 ClusterRoleBinding 中，可以指定 Group 作为主体：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: dev-team-binding
subjects:
- kind: Group
  name: dev-team
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

👉 这里的 dev-team Group 中的所有用户都会获得 pod-reader 的权限。

---

📝 对比表

身份类型	范围	管理方式	典型用途
User	外部单个用户	外部系统管理	开发者/管理员使用 kubectl
ServiceAccount	集群内部对象	Kubernetes 自动管理	Pod 在集群中访问 API Server
Group	外部用户集合	外部系统管理	批量分配权限给一组用户

---

💡 总结

• Group 是用户集合，用于批量分配权限。
• Kubernetes 不直接管理 Group，而是依赖外部身份系统。
• 在 RBAC 中，Group 常与 RoleBinding 或 ClusterRoleBinding 配合使用。