Kubernetes通过YAML创建GCP服务账号Secret认证失败排查

算力阿峰

2026-8-29

问题1：通过secret.yaml创建Secret的方式是否正确

该配置语法可通过Kubernetes校验，但不符合Tekton对接GCP服务的认证要求，存在3处核心配置错误，直接导致认证不生效：

Secret类型拼写错误：配置中写的kubernetes.io/opaque为错误写法，Kubernetes内置通用密钥类型为大小写敏感的Opaque，小写写法会被识别为自定义类型，可能引发密钥挂载、读取异常。
密钥存储键名不符合GCP工具链默认规则：你将服务账号JSON内容存储在gcs-config键下，而GCP SDK、gcloud CLI、Tekton官方GCP类Task默认查找的是GOOGLE_APPLICATION_CREDENTIALS环境变量指向的JSON密钥文件，常规对接需将键名设为service-account.json，自定义键名若未额外配置路径映射，运行时根本无法定位到密钥文件。
Secret与ServiceAccount绑定错配：查看PipelineRun配置，build阶段（即访问Artifact Registry的阶段）使用的服务账号是gcp-service-account，但你将gcp-secret绑定到了仅给代码克隆阶段用的git-service-account上，build任务运行时根本不会挂载这份GCP密钥，这是认证失效的核心原因。

修正后的Secret配置参考：

apiVersion: v1
kind: Secret
metadata:
  name: gcp-secret
  namespace: tekton-pipelines
type: Opaque
stringData:
  service-account.json: |
     {
      "type": "service_account",
      "project_id": "fetebird-350310",
      "private_key_id": "5566b5e81ce3cb9530659be6c70e07a36dcbd581",
      "private_key": "-----BEGIN PRIVATE KEY-----\nMIIEvww2VjXHj9/7gQ8ZWs/OaQKBgQDDHqb2rG4b5wGMDeeW\nuNTofm7xfC9yAHBm4Rug6hXpYSy36LUrpe0agZqzcLpH2G4xTarQyx76sPXVCpGc\nyFAQ6Jvj1kqM2pHJlGg+L1kX1mZ96jOyyZ2mxPV3r837q90w4CqT2rLKTF9VgWre\nSD6P7h2JbJ46Xzu4Mp72wSxSCg==\n-----END PRIVATE KEY-----\n",
      "client_email": "ssss@ssss-350310.iam.gserviceaccount.com",
      "client_id": "sssssssss",
      "auth_uri": "https://accounts.google.com/o/oauth2/auth",
      "token_uri": "https://oauth2.googleapis.com/token",
      "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
      "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/fetebird%40fetebird-350310.iam.gserviceaccount.com"
    }

对应需要修正ServiceAccount配置，将GCP密钥绑定到build任务实际使用的账号上：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: gcp-service-account
  namespace: tekton-pipelines
secrets:
  - name: gcp-secret

问题2：私有Artifact Registry访问权限异常排查方案

公开仓库可正常运行、私有仓库报权限错误，说明流水线任务逻辑本身无问题，故障根源是运行时未加载有效GCP凭证、或凭证权限不匹配，按以下步骤逐次排查：

先确认ServiceAccount绑定关系正确：执行kubectl describe serviceaccount gcp-service-account -n tekton-pipelines，检查返回结果的Secrets列表中是否存在gcp-secret，排除绑定错配问题。
确认密钥正确挂载到Task运行环境：
- 若使用Tekton官方的镜像推拉类Task，需显式配置环境变量GOOGLE_APPLICATION_CREDENTIALS=/var/run/secrets/kubernetes.io/serviceaccount/service-account.json，同时将Secret中的密钥文件挂载到对应路径。
- 若使用自定义构建镜像，可进入Task运行的Pod，先执行echo $GOOGLE_APPLICATION_CREDENTIALS确认路径存在，再执行gcloud auth activate-service-account --key-file=$GOOGLE_APPLICATION_CREDENTIALS手动激活凭证，通过以下命令测试Artifact Registry连通性：
```
gcloud artifacts docker images list <你的Artifact Registry仓库全路径>
```
  如果该命令返回403，说明凭证加载环节无问题，故障在权限侧；如果提示找不到密钥文件，说明挂载路径或环境变量配置错误。
核对IAM权限配置：
- 不要仅检查项目级权限，需进入Artifact Registry对应仓库的IAM配置页，确认密钥内client_email对应的服务账号，已被授予对应权限：拉取镜像需roles/artifactregistry.reader角色，推送镜像需roles/artifactregistry.writer角色。
- 确认服务账号未被禁用、密钥未被轮换作废，排除账号本身状态异常。
本地验证密钥有效性：将你上传到Secret的服务账号JSON文件下载到本地，执行gcloud auth activate-service-account --key-file=<本地密钥文件路径>后，尝试访问私有Artifact Registry，如果本地同样报403，说明密钥本身无效，直接在GCP控制台重新生成服务账号密钥，替换Secret内容即可。

生产环境建议使用GKE Workload Identity实现Kubernetes服务账号与GCP服务账号的免密钥对接，不需要手动管理长期访问密钥，可避免明文密钥泄露、密钥过期轮换等问题。

内容的提问来源于stack exchange，提问作者San Jaisy