Kubernetes 中的 Service Account 与 Pod Identity：高级认证授权

好的，各位观众，各位朋友，欢迎来到今天的“K8s魔法课堂”！我是你们的魔法师，今天我们要一起探索K8s世界里一个非常酷炫的主题——Service Account与Pod Identity，以及它们如何玩转高级认证授权。

系好安全带，因为接下来的旅程可不是纸上谈兵，而是要深入到K8s的“灵魂深处”去一探究竟。准备好了吗？Let’s go! 🚀

一、开场白：谁动了我的“奶酪”？（认证与授权的重要性）

想象一下，你是一家“美味奶酪公司”的CEO，你的奶酪配方是公司的核心机密，价值连城。 你肯定不会随便把配方给任何人，对吧？ 你会给你的员工分配不同的权限，比如：

• 奶酪大师： 可以查看和修改配方，负责生产最美味的奶酪。
• 销售经理： 只能查看配方，用于更好地向客户介绍奶酪的特点。
• 清洁阿姨： 只能打扫卫生，没有权限接触配方。

这就是认证和授权的意义！

• 认证 (Authentication)： 确认“你是谁？” 就像门卫检查你的身份证，确定你是公司员工。
• 授权 (Authorization)： 确认“你能做什么？” 就像根据你的职位，决定你能访问哪些资源。

在K8s的世界里，Pod就像我们奶酪公司的员工，它们需要访问各种资源，比如数据库、API等等。如果没有认证和授权，任何Pod都可以随意访问任何资源，那K8s集群岂不是乱套了？ 就像你家的门钥匙被所有人复制了一样！ 😱

二、Service Account：Pod的“身份证”

那么，K8s是如何给Pod发“身份证”的呢？ 这就要请出我们的主角之一——Service Account。

Service Account是K8s为Pod提供身份认证的一种机制。 简单来说，它就像Pod的“通行证”，让Pod可以安全地访问集群内的资源。

1. Service Account 的本质：

Service Account其实就是一个K8s对象，它包含以下关键信息：

• Token： 一串加密的字符串，就像你的“数字签名”，用于证明你的身份。
• Namespace： Service Account所属的命名空间，就像你的“部门”，用于隔离不同的服务。
• 关联的Secret： Secret 存储着Token，Pod 通过挂载 Secret 来获取 Token。

2. Service Account 的创建与使用：

K8s会自动为每个Namespace创建一个名为default的Service Account。 你也可以手动创建自定义的Service Account。

例子：创建一个名为my-app的Service Account：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app
  namespace: my-namespace # 命名空间，可替换

执行kubectl apply -f my-app-sa.yaml 就可以创建了。

3. Pod 如何使用 Service Account？

当创建一个Pod时，如果没有指定Service Account，K8s会自动将default Service Account分配给该Pod。

如果你想让Pod使用自定义的Service Account，可以在Pod的定义文件中指定：

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  namespace: my-namespace # 命名空间，可替换
spec:
  serviceAccountName: my-app # 指定使用 my-app Service Account
  containers:
  - name: my-container
    image: busybox
    command: ['sleep', '3600']

4. Service Account 的“魔法”：

• 自动挂载 Token： K8s会自动将Service Account的Token挂载到Pod的文件系统中，通常是/var/run/secrets/kubernetes.io/serviceaccount/token。
• 环境变量： K8s也会设置一些环境变量，比如KUBERNETES_SERVICE_HOST和KUBERNETES_SERVICE_PORT，方便Pod访问K8s API Server。

三、RBAC：权限管理的“守护神”

有了Service Account，Pod就有了“身份证”，但有了身份证还不够，还需要知道Pod有什么权限，这就是RBAC (Role-Based Access Control) 的作用。

RBAC是K8s的权限管理机制，它基于角色 (Role) 来控制Pod对资源的访问权限。

1. RBAC 的核心概念：

• Role： 定义了一组权限，比如“可以读取Pod”、“可以创建Deployment”等等。
• ClusterRole： 类似于Role，但作用于整个集群，而不是单个Namespace。
• RoleBinding： 将Role绑定到Service Account或User，赋予其相应的权限。
• ClusterRoleBinding： 将ClusterRole绑定到Service Account或User，赋予其在整个集群内的权限。

2. RBAC 的工作原理：

1. 创建一个Role或ClusterRole，定义一组权限。
2. 创建一个RoleBinding或ClusterRoleBinding，将Role或ClusterRole绑定到Service Account。
3. 当Pod使用该Service Account访问资源时，K8s会检查该Service Account是否具有相应的权限。

3. RBAC 的例子：

例子：创建一个Role，允许my-namespace命名空间中的Pod读取Pod：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: my-namespace # 命名空间，可替换
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

例子：创建一个RoleBinding，将pod-reader Role绑定到my-app Service Account：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: my-namespace # 命名空间，可替换
subjects:
- kind: ServiceAccount
  name: my-app
  namespace: my-namespace # 命名空间，可替换
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

执行kubectl apply -f pod-reader-role.yaml 和 kubectl apply -f read-pods-rolebinding.yaml 就可以创建了。

四、Service Account 的局限性：身份的“伪装者”？

Service Account虽然很强大，但它也有一些局限性：

• Token 的生命周期： Service Account的Token是长期有效的，如果Token泄露，可能会导致安全问题。
• 权限管理的复杂性： RBAC的配置比较繁琐，容易出错。
• 难以管理外部资源： Service Account主要用于访问K8s集群内的资源，难以管理外部资源，比如云服务商的数据库、消息队列等等。

想象一下，如果你的身份证被别人捡到了，那个人就可以冒充你做很多事情，这可不是闹着玩的！ 😱

五、Pod Identity：真正的身份认证！

为了解决Service Account的局限性，Pod Identity应运而生。

Pod Identity是一种更安全的身份认证机制，它可以让Pod拥有更精细的权限控制，并且可以方便地管理外部资源。

1. Pod Identity 的原理：

Pod Identity的核心思想是：为Pod分配一个唯一的身份，并将其与云服务商的身份认证机制集成。

简单来说，就是让Pod拥有一个“云身份证”，可以直接向云服务商证明自己的身份。

2. Pod Identity 的实现方式：

不同的云服务商有不同的Pod Identity实现方式，比如：

• AWS IAM Roles for Service Accounts (IRSA)： 将Service Account与AWS IAM Role关联，Pod可以通过STS (Security Token Service) 获取临时的AWS凭证。
• Azure AD Pod Identity： 将Service Account与Azure AD Managed Identity关联，Pod可以通过Azure Instance Metadata Service 获取Azure AD Token。
• GCP Workload Identity： 将Service Account与GCP Service Account关联，Pod可以通过GCP Metadata Server 获取GCP Token。

3. Pod Identity 的优势：

• 临时凭证： Pod Identity使用临时凭证，凭证过期后会自动更新，大大提高了安全性。
• 精细的权限控制： 可以为每个Pod分配不同的权限，避免权限过度授予。
• 方便管理外部资源： 可以直接使用云服务商的身份认证机制，方便管理外部资源。

4. Pod Identity 的例子 (以 AWS IRSA 为例)：

1. 创建一个 IAM Role，定义 Pod 需要访问的 AWS 资源权限。 比如，允许访问 S3 Bucket。
2. 创建一个 OIDC Provider，用于验证 K8s 集群的身份。
3. 创建一个 IAM Policy，允许 Service Account Assume IAM Role。
4. 将 IAM Role 与 Service Account 关联。 可以使用 Kubernetes annotations 来实现。
5. Pod 使用 Service Account，自动获取 AWS 临时凭证。

六、Service Account 与 Pod Identity 的“爱恨情仇”：如何选择？

Service Account和Pod Identity都是K8s的身份认证机制，它们各有优缺点。那么，我们应该如何选择呢？

特性	Service Account	Pod Identity
凭证类型	长期有效 Token	临时凭证
安全性	较低，Token泄露风险	较高，凭证过期自动更新
权限管理	RBAC，配置繁琐	与云服务商集成，更精细的权限控制
外部资源管理	难以管理	方便管理
适用场景	集群内部资源访问	需要访问外部资源，对安全性要求较高的场景
部署复杂度	简单	较复杂，需要配置 OIDC Provider 等

总结：

• 如果你的应用只需要访问K8s集群内部的资源，并且对安全性要求不高，那么Service Account是一个不错的选择。
• 如果你的应用需要访问外部资源，并且对安全性要求很高，那么Pod Identity是更好的选择。

当然，你也可以将Service Account和Pod Identity结合使用，比如：

• 使用Service Account访问K8s集群内部的资源。
• 使用Pod Identity访问外部资源。

七、安全最佳实践：让你的K8s集群固若金汤！

最后，我们来总结一些K8s安全最佳实践：

• 最小权限原则： 只授予Pod需要的最小权限，避免权限过度授予。
• 定期审计： 定期审计RBAC配置，确保权限设置正确。
• 使用Pod Identity： 尽可能使用Pod Identity，提高安全性。
• Token 轮换： 定期轮换Service Account的Token，防止Token泄露。
• 网络策略： 使用网络策略限制Pod之间的网络流量，防止恶意攻击。
• 镜像安全： 使用安全可靠的镜像，避免使用存在漏洞的镜像。
• 漏洞扫描： 定期扫描K8s集群中的漏洞，及时修复。

八、结语：K8s安全，任重道远！

K8s安全是一个复杂而重要的课题，需要我们不断学习和实践。 希望今天的课程能帮助大家更好地理解Service Account和Pod Identity，以及如何使用它们来保护你的K8s集群。

记住，安全无小事！ 让我们一起努力，打造一个更安全、更可靠的K8s世界！ 🚀

感谢大家的收听！ 我们下期再见！ 👋