用403锁定了我的terraform状态文件；如何识别执行terraform init的帐户？

Question

TL;DR :如何为terraform操作(如terraform init )指定用户帐户/电子邮件？我如何知道在默认情况下使用的是哪一封电子邮件？

详情：

我在gcp bucket中有一个terraform远程状态，不幸的是，我在某种程度上被封锁了；来自terraform操作，而不是组织。

我使用服务帐户模拟测试了通过gcloud和gsutil进行的访问，它们似乎能够通过以下方式读写状态桶。

gsutil -i "terraform-admin@<project-id>.iam.gserviceaccount.com" cp test-file.txt gs://<state-bucket-id>/terraform.tfstate/test-file.txt

我还验证了，iam.serviceAccountTokenCreator角色很好地归因于用户帐户，即假定的模拟高级管理服务帐户。

当我尝试做terraform init时，我得到：

│ Error: Failed to get existing workspaces: querying Cloud Storage failed: Get "https://storage.googleapis.com/storage/v1/b/<project-bucket-state-for-workspace>/o?alt=json&delimiter=%2F&pageToken=&prefix=terraform.tfstate%2F&prettyPrint=false&projection=full&versions=false": impersonate: status code 403: {
│   "error": {
│     "code": 403,
│     "message": "The caller does not have permission",
│     "status": "PERMISSION_DENIED"
│   }
│ }

我还尝试通过gcloud auth login对用户管理帐户进行身份验证，但仍然会遇到相同的错误。这一定意味着terraform没有使用正确的帐户/电子邮件来执行init。

编辑:通过export TF_LOGS=TRACE在客户端启用日志

2022-11-21T01:40:23.350+0100 [INFO]  Terraform version: 1.3.4
2022-11-21T01:40:23.351+0100 [DEBUG] using github.com/hashicorp/go-tfe v1.9.0
2022-11-21T01:40:23.351+0100 [DEBUG] using github.com/hashicorp/hcl/v2 v2.14.1
2022-11-21T01:40:23.351+0100 [DEBUG] using github.com/hashicorp/terraform-config-inspect v0.0.0-20210209133302-4fd17a0faac2
2022-11-21T01:40:23.351+0100 [DEBUG] using github.com/hashicorp/terraform-svchost v0.0.0-20200729002733-f050f53b9734
2022-11-21T01:40:23.351+0100 [DEBUG] using github.com/zclconf/go-cty v1.12.0
2022-11-21T01:40:23.351+0100 [INFO]  Go runtime version: go1.19.3
2022-11-21T01:40:23.351+0100 [INFO]  CLI args: []string{"terraform", "init"}
2022-11-21T01:40:23.351+0100 [TRACE] Stdout is a terminal of width 156
2022-11-21T01:40:23.351+0100 [TRACE] Stderr is a terminal of width 156
2022-11-21T01:40:23.351+0100 [TRACE] Stdin is a terminal
2022-11-21T01:40:23.351+0100 [DEBUG] Attempting to open CLI config file: /home/<user>/.terraformrc
2022-11-21T01:40:23.351+0100 [DEBUG] File doesn't exist, but doesn't need to. Ignoring.
2022-11-21T01:40:23.351+0100 [DEBUG] ignoring non-existing provider search directory terraform.d/plugins
2022-11-21T01:40:23.351+0100 [DEBUG] ignoring non-existing provider search directory /home/<user>/.terraform.d/plugins
2022-11-21T01:40:23.351+0100 [DEBUG] ignoring non-existing provider search directory /home/<user>/.local/share/terraform/plugins
2022-11-21T01:40:23.351+0100 [DEBUG] ignoring non-existing provider search directory /usr/local/share/terraform/plugins
2022-11-21T01:40:23.351+0100 [DEBUG] ignoring non-existing provider search directory /usr/share/terraform/plugins
2022-11-21T01:40:23.351+0100 [DEBUG] ignoring non-existing provider search directory /var/lib/snapd/desktop/terraform/plugins
2022-11-21T01:40:23.351+0100 [INFO]  CLI command args: []string{"init"}
Initializing modules...
2022-11-21T01:40:23.358+0100 [TRACE] ModuleInstaller: installing child modules for . into .terraform/modules
2022-11-21T01:40:23.363+0100 [DEBUG] Module installer: begin dev-omni-orchestrator-instance
2022-11-21T01:40:23.367+0100 [TRACE] ModuleInstaller: Module installer: dev-omni-orchestrator-instance <nil> already installed in ../modules/omni-orchestrator
2022-11-21T01:40:23.367+0100 [DEBUG] Module installer: begin gcs-infra-genesis-state-buckets
2022-11-21T01:40:23.370+0100 [TRACE] ModuleInstaller: Module installer: gcs-<terraform-project>-state-buckets 3.4.0 already installed in .terraform/modules/gcs-<terraform-project>-state-buckets
2022-11-21T01:40:23.370+0100 [TRACE] modsdir: writing modules manifest to .terraform/modules/modules.json

Initializing the backend...
2022-11-21T01:40:23.382+0100 [TRACE] Meta.Backend: built configuration for "gcs" backend with hash value <V1>
2022-11-21T01:40:23.382+0100 [TRACE] Meta.Backend: backend has not previously been initialized in this working directory
2022-11-21T01:40:23.382+0100 [DEBUG] New state was assigned lineage "<V2>"
2022-11-21T01:40:23.382+0100 [TRACE] Meta.Backend: moving from default local state only to "gcs" backend
2022-11-21T01:40:23.382+0100 [DEBUG] checking for provisioner in "."
2022-11-21T01:40:23.384+0100 [DEBUG] checking for provisioner in "/usr/bin"
2022-11-21T01:40:23.384+0100 [TRACE] backend/local: state manager for workspace "default" will:
 - read initial snapshot from terraform.tfstate
 - write new snapshots to terraform.tfstate
 - create any backup at terraform.tfstate.backup
2022-11-21T01:40:23.384+0100 [TRACE] statemgr.Filesystem: reading initial snapshot from terraform.tfstate
2022-11-21T01:40:23.384+0100 [TRACE] statemgr.Filesystem: snapshot file has nil snapshot, but that's okay
2022-11-21T01:40:23.384+0100 [TRACE] statemgr.Filesystem: read nil snapshot
2022-11-21T01:40:23.384+0100 [TRACE] Meta.Backend: ignoring local "default" workspace because its state is empty
2022-11-21T01:40:23.385+0100 [DEBUG] New state was assigned lineage "<V3>"
╷
│ Error: Failed to get existing workspaces: querying Cloud Storage failed: Get "https://storage.googleapis.com/storage/v1/b/<terraform-project>-terraform-state/o?alt=json&delimiter=%2F&pageToken=&prefix=terraform.tfstate%2F&prettyPrint=false&projection=full&versions=false": impersonate: status code 403: {
│   "error": {
│     "code": 403,
│     "message": "The caller does not have permission",
│     "status": "PERMISSION_DENIED"
│   }
│ }
│

Answer 1

答案是：

gcloud auth application-default login

确保您的所有凭据都是冗余设置，按照gcloud的任意、文档错误的规则设置。

以下是我为回答不同用途而使用的几个方法：

gcloud auth login
gcloud auth application-default login
gcloud auth login --no-browser
gcloud config configurations create <...>

我已经在使用指向gcloud auth list的right帐户检查身份验证状态，但这还不够。我很少在堆积如山中表达沮丧或情绪，但这是相当糟糕的。

This post帮了忙。