K8s Service Account 基础：容器内身份认证 - 智猿学院-IT界的百科全书

K8s Service Account 基础：容器内身份认证 – 容器的“通行证”与“身份证”

大家好，欢迎来到今天的“容器身份大揭秘”讲座！我是你们的老朋友，容器界的探险家——阿凯。今天，我们要聊聊 Kubernetes (K8s) 中一个非常重要，但又常常被新手忽略的概念：Service Account（服务账号）。

想象一下，你开着一辆炫酷的容器跑车，想要访问 K8s 这个巨大的游乐园里的各种资源，比如数据库、消息队列、甚至是其他的容器。如果没有“通行证”和“身份证”，游乐园管理员可不会轻易让你进去！Service Account，就是 K8s 赋予容器的身份凭证，让它们能够安全可靠地访问集群内的资源。

1. 容器跑车也要“身份认证”？

你可能会觉得奇怪，容器不就是一个个独立的进程吗？它们怎么还需要身份认证呢？

答案很简单：在云原生世界里，容器不仅仅是运行代码的地方，它们还承担着与其他服务交互的重任。想象一下，一个负责处理用户请求的容器，需要访问数据库来获取用户信息。如果没有身份认证，谁都能冒充它去访问数据库，那岂不是乱套了？

因此，我们需要一种机制，让容器能够证明自己的身份，并获得访问特定资源的权限。Service Account 就是为此而生的。

2. 什么是 Service Account？它长什么样？

Service Account 本质上就是一个 K8s 对象，它包含以下几个关键组成部分：

Token (令牌): 这是 Service Account 最重要的部分，相当于容器的“通行证”。它是一个 JWT (JSON Web Token)，包含了容器的身份信息和权限声明。容器会通过这个 Token 向 K8s API Server 证明自己的身份。
Secret (密钥): 默认情况下，每个 Service Account 都会关联一个 Secret 对象。这个 Secret 对象里就包含着 Token。
Namespace (命名空间): Service Account 属于特定的命名空间，这意味着它的权限范围也仅限于该命名空间。

你可以通过以下命令查看 Service Account 的详细信息：

kubectl get serviceaccount <service-account-name> -n <namespace> -o yaml

例如：

kubectl get serviceaccount default -n default -o yaml

你会看到类似这样的输出：

apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: "2023-10-27T02:00:00Z"
  name: default
  namespace: default
  resourceVersion: "12345"
  uid: a1b2c3d4-e5f6-7890-1234-567890abcdef
secrets:
- name: default-token-xxxxx

这里 secrets 字段指向的就是关联的 Secret 对象，它包含了 Token。

3. 默认的 “无名小卒”：Default Service Account

K8s 默认会为每个命名空间创建一个名为 default 的 Service Account。如果你在创建 Pod 的时候没有指定 Service Account，那么 Pod 就会自动使用 default Service Account。

这就像游乐园里给所有游客都发了一张“体验卡”，可以免费体验一些基础项目。但是，这张“体验卡”的权限非常有限，只能访问一些基本的 K8s API 资源。

注意: 默认 Service Account 的权限通常不应该被滥用。我们应该根据容器的实际需求，创建具有特定权限的 Service Account。

4. 创建你的专属“VIP通行证”：自定义 Service Account

为了更精细地控制容器的访问权限，我们需要创建自定义的 Service Account。这就像为你的容器跑车定制一张专属的“VIP通行证”，让它可以畅通无阻地访问特定的资源。

创建 Service Account 非常简单，只需要一个简单的 YAML 文件：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: my-namespace

然后使用 kubectl apply 命令创建：

kubectl apply -f service-account.yaml

这就创建了一个名为 my-app-sa 的 Service Account，它属于 my-namespace 命名空间。

5. 如何让容器使用自定义 Service Account？

创建了 Service Account 之后，我们需要告诉 Pod 使用它。这也很简单，只需要在 Pod 的 YAML 文件中指定 serviceAccountName 字段：

apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
  namespace: my-namespace
spec:
  serviceAccountName: my-app-sa
  containers:
  - name: my-app-container
    image: my-app-image

这样，my-app-pod 里的容器就会使用 my-app-sa 这个 Service Account。

6. Token 的“秘密通道”：容器如何获取 Token？

容器如何获取 Token 呢？K8s 会自动将 Token 以文件的形式挂载到容器的 /var/run/secrets/kubernetes.io/serviceaccount/ 目录下。

这个目录下有两个文件：

token: 包含 JWT Token，容器可以使用它来认证自己的身份。
ca.crt: 包含 K8s API Server 的 CA 证书，容器可以使用它来验证 API Server 的身份。

容器可以通过读取这些文件来获取 Token 和 CA 证书。例如，在容器内部可以使用以下命令读取 Token：

cat /var/run/secrets/kubernetes.io/serviceaccount/token

7. 权限管理的大杀器：RBAC (Role-Based Access Control)

有了 Service Account，我们还需要给它赋予相应的权限，才能让容器访问特定的资源。这就要用到 K8s 的 RBAC (Role-Based Access Control) 机制。

RBAC 就像游乐园里的“权限管理系统”，它可以根据用户的角色，分配不同的访问权限。

RBAC 主要包含以下几个概念：

Role (角色): 定义了一组权限的集合。例如，一个 Role 可以允许读取 Pods，但禁止创建 Pods。
ClusterRole (集群角色): 与 Role 类似，但是作用于整个集群，而不是单个命名空间。
RoleBinding (角色绑定): 将 Role 绑定到特定的用户、组或 Service Account。
ClusterRoleBinding (集群角色绑定): 将 ClusterRole 绑定到特定的用户、组或 Service Account。

我们可以通过创建 Role 和 RoleBinding 来给 Service Account 赋予权限。例如，以下 YAML 文件定义了一个允许读取 Pods 的 Role，并将它绑定到 my-app-sa Service Account：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: my-namespace
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: my-namespace
subjects:
- kind: ServiceAccount
  name: my-app-sa
  namespace: my-namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: pod-reader

这样，使用 my-app-sa Service Account 的容器就可以读取 my-namespace 命名空间下的 Pods 了。

8. “权限最小化”原则：安全第一！

在 RBAC 权限管理中，务必遵循“权限最小化”原则。这意味着只给 Service Account 赋予它需要的最小权限。

这就像游乐园管理员只给游客发放他们需要的项目体验券，而不是把所有项目的体验券都一股脑地塞给他们。

滥用权限会导致安全风险，攻击者可能会利用具有过多权限的 Service Account 来入侵你的集群。

9. 超越基础：Service Account 的高级应用

除了基本的身份认证和权限管理，Service Account 还有一些高级应用：

外部身份认证集成: Service Account 可以与外部身份认证系统集成，例如 AWS IAM Roles for Service Accounts (IRSA) 和 Azure AD Pod Identity。这可以让容器使用云平台的身份凭证来访问云服务。
Webhook Token Authentication: K8s 允许你配置一个 Webhook，用于验证 Service Account 的 Token。这可以让你自定义 Token 的验证逻辑。
Token 自动轮换: 为了提高安全性，K8s 支持自动轮换 Service Account 的 Token。

10. 常见问题与排错

在使用 Service Account 的过程中，可能会遇到一些问题：

容器无法访问 API Server: 检查容器是否正确挂载了 Token 和 CA 证书，以及网络是否连通。
容器没有足够的权限: 检查 Role 和 RoleBinding 的配置是否正确，以及 Service Account 是否被正确绑定。
Token 验证失败: 检查 Token 是否过期，以及 API Server 的配置是否正确。

遇到问题时，可以查看 K8s API Server 的日志，以及容器的日志，来获取更多的信息。

11. 总结：Service Account 是容器安全的基石

Service Account 是 K8s 中容器身份认证和权限管理的基础。它就像容器的“通行证”和“身份证”，让容器能够安全可靠地访问集群内的资源。

通过创建自定义的 Service Account，并结合 RBAC 机制，我们可以实现精细化的权限控制，保障集群的安全。

希望今天的讲座能够帮助大家更好地理解 Service Account 的概念和用法。记住，安全第一！🎉

表格总结:

特性	描述	重要性
ServiceAccount	K8s 对象，代表容器的身份，包含 Token 和 Secret。	高
Token	容器的“通行证”，用于向 API Server 证明身份。	高
RBAC	基于角色的访问控制，用于管理 Service Account 的权限。	高
Role	定义一组权限的集合。	中
RoleBinding	将 Role 绑定到 Service Account。	中
权限最小化原则	只给 Service Account 赋予它需要的最小权限，避免安全风险。	高
外部身份认证集成	Service Account 可以与外部身份认证系统集成，例如 AWS IAM Roles for Service Accounts (IRSA) 和 Azure AD Pod Identity，让容器使用云平台的身份凭证来访问云服务。	中

记住，在容器的世界里，安全永远是第一位的！ 🛡️