【k8s】pod和serviceaccount关系

概述

Pod 和 ServiceAccount 在 Kubernetes 中是密切相关的。具体来说，ServiceAccount 是 Kubernetes 中用于控制 Pod 与 API 服务器交互时的身份验证和授权的机制。

1. 主要联系点

1. Pod 使用 ServiceAccount 进行身份验证：

• 每个 Pod 在与 Kubernetes API 服务器交互时，都需要通过一个 ServiceAccount 来进行身份验证。默认情况下，如果你没有指定 Pod 使用哪个 ServiceAccount，Kubernetes 会自动将 Pod 绑定到命名空间中的默认 ServiceAccount（default）。

2. ServiceAccount 中的权限：

• ServiceAccount 本质上是一组权限，定义了 Pod 在与 Kubernetes API 服务器交互时可以执行哪些操作（例如，读取 ConfigMap、创建 Pods、列出服务等）。这些权限通过绑定到 Role 或 ClusterRole 来控制。
• RoleBinding 或 ClusterRoleBinding 是 Kubernetes 中的资源，它们将 ServiceAccount 与具体的权限集（Role 或 ClusterRole）绑定在一起。

3. 自动挂载凭据：

• 当 Pod 启动时，Kubernetes 会自动将与 ServiceAccount 相关联的凭据（通常是一个 JWT 令牌和 API 服务器的 CA 证书）挂载到 Pod 中的 /var/run/secrets/kubernetes.io/serviceaccount 目录下。
  这些凭据允许 Pod 内的应用程序通过 Kubernetes API 服务器进行身份验证，以执行有权限的操作。

4. 自定义 ServiceAccount：

• 如果你希望某个 Pod 具有特定的权限或访问受限的资源，可以为该 Pod 指定一个自定义的 ServiceAccount。例如，以下 YAML 定义了一个使用自定义 ServiceAccount 的 Pod：

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

在这个例子中，Pod my-pod 将使用 my-service-account 进行身份验证，而不是使用默认的 default ServiceAccount。

2. 典型用例：

1. 权限隔离：

通过为不同的应用或 Pod 配置不同的 ServiceAccount，你可以有效地隔离权限，确保每个 Pod 只能访问和操作特定的资源。

2. 安全性增强：

通过为 Pod 分配特定的 ServiceAccount，并将其权限最小化（例如，通过 Least Privilege 原则），你可以减少安全漏洞的风险，防止 Pod 过度访问集群中的资源。

3. Pod 与 API 服务器交互：

某些 Pod 需要与 Kubernetes API 服务器进行交互，例如监控应用、自动化任务等。你可以通过为这些 Pod 分配合适的 ServiceAccount 来确保它们具有必要的权限。

3. 总结：

Pod 和 ServiceAccount 的联系体现在权限管理和安全控制上。通过 ServiceAccount，你可以控制 Pod 如何与 Kubernetes API 服务器交互，授予它们执行任务所需的最小权限，从而增强集群的安全性和管理性。

4. serviceaccount详解

"containers": [
        "volumeMounts": [
                            {
                                "mountPath": "/var/run/secrets/kubernetes.io/serviceaccount",
                                "name": "kube-api-access-7r7ch",    //容器引用了一个volume
                                "readOnly": true
                            }
                        ]
............................
        "serviceAccount": "default",
        "serviceAccountName": "default",
.........................
       "volumes": [
            {
                "name": "kube-api-access-7r7ch",          //定义的volume
                "projected": {
                    "defaultMode": 420,
                    "sources": [                                 //
                        {
                            "serviceAccountToken": {
                                "expirationSeconds": 3607,
                                "path": "token"
                            }
                        },
                        {
                            "configMap": {
                                "items": [
                                    {
                                        "key": "ca.crt",
                                        "path": "ca.crt"
                                    }
                                ],
                                "name": "kube-root-ca.crt"
                            }
                        },
                        {
                            "downwardAPI": {
                                "items": [
                                    {
                                        "fieldRef": {
                                            "apiVersion": "v1",
                                            "fieldPath": "metadata.namespace"
                                        },
                                        "path": "namespace"
                                    }
                                ]
                            }

这个 JSON 片段描述了 Kubernetes 中一个 Pod 的 volume 配置，该 volume 名为 kube-api-access-58tmd，用于将与 ServiceAccount 相关的凭据和信息挂载到 Pod 中。具体来说，这段配置是将凭据和配置信息投射（projected）到容器内，以便 Pod 使用这些信息与 Kubernetes API 服务器进行交互。

具体解析：

1. Volume 名称 (name: “kube-api-access-58tmd”)：

kube-api-access-58tmd 是该 volume 的名称。这是 Kubernetes 自动生成的一个名称，可能会根据 Pod 的不同实例生成不同的名称。
projected 字段：

projected 是一种特殊的 volume 类型，允许你将多个资源（如 ServiceAccountToken、ConfigMap、DownwardAPI 等）的内容投射到一个单一的 volume 中。

2. defaultMode: 420：

这是这个 volume 内所有文件的默认权限设置，以八进制表示。420 表示权限 0644，即文件所有者可以读写，其他用户只能读取。

3. sources 数组：

这个数组包含了多个资源的定义，这些资源的内容将被投射到这个 volume 中。

4. sources 内的各个资源解释：

4.1) serviceAccountToken：

• expirationSeconds: 3607：
  这个字段指定了生成的 ServiceAccountToken 的有效期，以秒为单位。3607 秒大约等于 1 小时 1 秒。这意味着这个令牌将在 1 小时后过期。
• path: “token”：
  指定了该令牌在 volume 中的存储路径。这个令牌将被保存为 token 文件。

4.2) configMap：

• name: “kube-root-ca.crt”：
  这个字段表示 ConfigMap 的名称为 kube-root-ca.crt。这个 ConfigMap 通常包含 Kubernetes API 服务器的根证书。
• items：
  • key: “ca.crt”：ca.crt 是 ConfigMap 中的键名，表示证书的内容。
  • path: “ca.crt”：指定了 ca.crt 文件在 volume 中的存储路径。这个证书文件将被保存为 ca.crt。

4.3) downwardAPI：

• DownwardAPI 是 Kubernetes 中的一种机制，用于将 Pod 的元数据（如名称、命名空间、标签等）投射到容器中。
• fieldRef：
  • apiVersion: “v1”：指定使用 Kubernetes API 的版本。
  • fieldPath: “metadata.namespace”：指定要投射的字段是 Pod 所在的命名空间。
• path: “namespace”：指定了命名空间信息在 volume 中的存储路径。这个信息将被保存为 namespace 文件。

这个 volume 配置将多个资源投射到 Pod 中，包括 ServiceAccount 的访问令牌、API 服务器的根证书以及 Pod 的命名空间信息。这些资源通常被挂载到 Pod 的容器内，使得应用程序能够安全地与 Kubernetes API 服务器进行交互。例如，应用可以使用令牌来验证自身身份，用证书来验证服务器的身份，或者根据命名空间信息进行逻辑处理。