在 Kubernetes 集群中，容器镜像的拉取是 Pod 启动的关键步骤。当镜像存储在私有仓库（如 Docker Hub 私有库、Harbor、AWS ECR 等）时，Kubernetes 需要提供认证凭据才能访问。若认证配置错误，会导致 ErrImagePull 或 ImagePullBackOff 等错误。镜像拉取认证的核心目标是：

1. 安全性：确保只有授权的 Pod 可以拉取私有镜像。
2. 灵活性：支持多环境、多仓库的凭据管理。
3. 可维护性：避免硬编码凭据，降低运维复杂度。

核心概念:

• imagePullSecrets：Kubernetes 中用于存储镜像仓库认证凭据的 Secret 对象，通过名称引用到 Pod 或 ServiceAccount。

• docker-registry 类型 Secret：专门用于存储 Docker 镜像仓库认证信息的 Secret，包含 docker-server、docker-username、docker-password 等字段。

• ServiceAccount：Kubernetes 中的身份抽象，可关联 imagePullSecrets，使所有使用该 ServiceAccount 的 Pod 自动继承凭据。

下面将列举镜像拉取认证的 8 种方式:

1、宿主机预配置认证

在 Node 宿主机上直接配置 Docker 或 Containerd 的认证文件（如 ~/.docker/config.json）。

~/.docker/config.json 中 auth 字段是经过 base64 编码的认证信息（base64 解码后为 username:password ）。

适用场景：开发测试环境、单节点环境。

操作步骤：

1. 登录镜像仓库生成配置文件：

   docker login registry.example.com -u <username> -p <password>
   

2. 将生成的 ~/.docker/config.json 复制到所有节点的相同路径。

优点：简单快速，无需 Kubernetes 配置。

缺点：难以维护，不适用于大规模集群；凭据明文存储在节点上，安全性低。

2、通过 ServiceAccount 绑定 imagePullSecrets

将镜像拉取凭据 Secret 关联到 ServiceAccount，所有使用该 ServiceAccount 的 Pod 自动继承认证。

操作步骤：

1. 创建 docker-registry Secret：

   kubectl create secret docker-registry my-secret \
     --docker-server=registry.example.com \
     --docker-username=admin \
     --docker-password=pass123
   

2. 创建或修改 ServiceAccount：

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: my-sa
   imagePullSecrets:
     - name: my-secret  # 关键配置
   

3. 在 Pod/Deployment 中指定 ServiceAccount：

   spec:
     serviceAccountName: my-sa
     containers:
       - name: app
         image: registry.example.com/my-app:v1
   

适用场景：统一管理多个 Pod 的凭据，减少重复配置。

优点：集中化管理，适合团队协作。

缺点：需提前创建 Secret，且所有关联 Pod 使用相同凭据。

3、在 Deployment 中直接配置 imagePullSecrets

在 Pod 模板中直接引用 Secret，仅对当前工作负载生效。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deploy
spec:
  template:
    spec:
      imagePullSecrets:
        - name: my-secret  # 直接引用 Secret
      containers:
        - name: app
          image: registry.example.com/my-app:v1

适用场景：个别 Pod 需要独立凭据（如访问特定仓库）。

优点：灵活，不影响其他 Pod。

缺点：配置冗余，维护成本高。

4、第三方 Secret 管理工具（Vault / External Secrets Operator）

通过工具动态同步外部密钥库中的凭据到 Secret。

以 External Secrets Operator 为例：

1. 部署 Operator：

   helm install external-secrets external-secrets/external-secrets
   

2. 配置 Vault 连接：

   apiVersion: external-secrets.io/v1beta1
   kind: SecretStore
   metadata:
     name: vault-backend
   spec:
     provider:
       vault:
         server: "http://vault:8200"
         path: "secret"
         auth:
           tokenSecretRef:
             name: vault-token
             key: token
   

3. 创建 ExternalSecret 资源：

   apiVersion: external-secrets.io/v1beta1
   kind: ExternalSecret
   metadata:
     name: registry-cred
   spec:
     refreshInterval: 1h
     secretStoreRef:
       name: vault-backend
     target:
       name: my-secret  # 生成的 Kubernetes Secret 名称
     data:
       - secretKey: docker-username
         remoteRef:
           key: registry-creds
           property: username
       - secretKey: docker-password
         remoteRef:
           key: registry-creds
           property: password
   

适用场景：企业级密钥管理，需集中化、审计能力。

优点：避免 Secret 泄露，支持动态更新。

缺点：需维护额外组件。

5、云厂商动态凭证（AWS ECR / GCP GCR）

利用云平台 IAM 角色或服务账号动态生成临时凭证，无需手动管理 Secret。

5.1 AWS ECR 示例

1. 为 Node 附加 IAM 角色：

   确保 Node 的 IAM 角色附加 AmazonEC2ContainerRegistryReadOnly 策略。

2. 配置 kubelet 自动使用 IAM 凭证：

   EKS 集群默认支持，节点自动获得 ECR 拉取权限。

5.2 GCP GCR 示例（Workload Identity）

1. 启用 Workload Identity：

   gcloud container clusters update <cluster-name> \
     --workload-pool=<project-id>.svc.id.goog
   

2. 绑定 Kubernetes SA 到 GCP SA：

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: my-sa
     annotations:
       iam.gke.io/gcp-service-account: "my-gcp-sa@<project-id>.iam.gserviceaccount.com"
   

适用场景：云原生环境，需高安全性、自动凭证轮转。

优点：无静态 Secret，自动凭证更新。

缺点：仅限特定云平台。

6、Pod 身份绑定（Workload Identity）

Pod 直接绑定云平台 IAM 身份，如: Azure AD Pod Identity。

Azure 示例：

1. 创建 Azure Identity：

   az identity create -g <resource-group> -n <identity-name>
   

2. 部署 Azure Pod Identity 组件：

   helm install aad-pod-identity aad-pod-identity/aad-pod-identity
   

3. 绑定 Identity 到 Pod：

   apiVersion: v1
   kind: Pod
   metadata:
     name: my-pod
     labels:
       aadpodidbinding: my-identity
   spec:
     containers:
       - name: app
         image: myregistry.azurecr.io/my-app:v1
   

适用场景：需要细粒度云平台权限控制的场景。

优点：无需 Secret，直接集成云 IAM。

缺点：依赖云平台支持。

7、Admission Webhook 自动注入 Secret

通过自定义 Webhook 在 Pod 创建时动态注入 imagePullSecrets。

实现步骤：

1. 开发 Webhook：

   监听 Pod 创建事件，根据镜像地址匹配预定义规则，注入对应 Secret。

2. 注册 Webhook：

   配置 Kubernetes API Server 调用该 Webhook。

示例规则：若镜像地址包含 registry.example.com，自动注入 Secret example-secret。

适用场景：复杂多仓库环境，需自动化凭据管理。

优点：减少人工配置。

缺点：开发维护成本高。

8、镜像仓库匿名访问

直接拉取公开镜像，无需认证。

image: nginx:latest  # Docker Hub 公开镜像

适用场景：使用公共镜像，如开源中间件。

注意：可能受仓库速率限制（如 Docker Hub 匿名用户限速）。

9、方案对比与选型建议

10、总结与最佳实践

10.1 核心原则

1. 最小权限：仅授予 Pod 访问所需镜像仓库的权限。

2. 自动化管理：优先使用动态凭证或第三方工具，避免硬编码凭据。

3. 环境适配：根据基础设施（如云平台、本地集群）选择合适方案。

10.2 推荐实践

• 云原生环境：

  • AWS EKS → 使用节点 IAM 角色或 IRSA（IAM Roles for Service Accounts）。

  • GCP GKE → 启用 Workload Identity。

• 混合/本地环境：

  • 使用 External Secrets Operator + Vault 管理凭据。

  • 通过 ServiceAccount 统一绑定 imagePullSecrets。

• 开发测试环境：

  • 简化流程，可直接在 Deployment 中配置 Secret。

通过合理选择镜像拉取认证方案，可以显著提升 Kubernetes 集群的安全性和运维效率。