Тип бэкенда: gcs

Сохраняет состояние в виде объекта с настраиваемым префиксом в предварительно созданном бакете Google Cloud Storage (GCS). Бакет должен существовать до настройки бэкенда.

Этот бэкенд поддерживает блокировку состояния.

Пример конфигурации​

terraform {
  backend "gcs" {
    bucket  = "tf-state-prod"
    prefix  = "tofu/state"
  }
}

Конфигурация источника данных​

data "terraform_remote_state" "foo" {
  backend = "gcs"
  config = {
    bucket  = "tofu-state"
    prefix  = "prod"
  }
}

resource "local_file" "foo" {
  content  = data.terraform_remote_state.foo.outputs.greeting
  filename = "${path.module}/outputs.txt"
}

Аутентификация​

Изменения IAM для бакетов применяются с задержкой, и для их вступления в силу может потребоваться несколько минут. До завершения этого процесса OpenTofu будет возвращать ошибки 403.

Запуск OpenTofu на рабочей станции.​

Если вы используете OpenTofu на рабочей станции, необходимо установить Google Cloud SDK и пройти аутентификацию с помощью учетных данных пользователя по умолчанию для приложений.

Пользовательские ADC имеют срок действия; их можно обновить, выполнив gcloud auth application-default login.

Запуск OpenTofu в Google Cloud​

Если вы запускаете OpenTofu в Google Cloud, можно настроить экземпляр или кластер на использование сервисного аккаунта Google. Это позволит OpenTofu проходить аутентификацию в Google Cloud без добавления отдельного файла учетных данных или аутентификации. Убедитесь, что для ВМ/кластера задана область действия cloud-platform.

Запуск OpenTofu за пределами Google Cloud​

Если вы запускаете OpenTofu за пределами Google Cloud, создайте ключ сервисного аккаунта и задайте для переменной среды GOOGLE_APPLICATION_CREDENTIALS путь к этому ключу. OpenTofu будет использовать этот ключ для аутентификации.

Имперсонация сервисных аккаунтов​

OpenTofu может выполнять имперсонацию сервисного аккаунта Google, как описано здесь. Необходимо предоставить действительные учетные данные, как описано в предыдущем разделе; соответствующая учетная запись должна иметь роль roles/iam.serviceAccountTokenCreator для сервисного аккаунта, от имени которого выполняется имперсонация.

Шифрование​

Предоставленные клиентом ключи шифрования​

Чтобы начать работу, следуйте этому руководству: Использование предоставленных клиентом ключей шифрования

Если вы хотите удалить предоставленные клиентом ключи из конфигурации бэкенда или заменить их другими, OpenTofu не сможет автоматически выполнить миграцию состояния — потребуется вмешательство вручную. Это необходимо, поскольку Google не хранит предоставленные клиентом ключи шифрования, поэтому их нужно указывать в каждом запросе к API Cloud Storage (см. раздел «Предоставленные клиентом ключи шифрования»). При миграции состояния конфигурация бэкенда теряет сведения о старом ключе, и OpenTofu не может использовать его в процессе миграции.

Управляемые клиентом ключи шифрования (Cloud KMS)​

Чтобы начать работу, следуйте этому руководству: Использование управляемых клиентом ключей шифрования

Если вы хотите удалить управляемые клиентом ключи из конфигурации бэкенда или заменить их другими, OpenTofu может выполнить миграцию состояния без вмешательства вручную. Это возможно, поскольку GCP хранит управляемые клиентом ключи шифрования, и они доступны в процессе миграции состояния. Однако изменения вступят в силу не полностью, пока после миграции состояния не будет выполнена первая операция записи в файл состояния. При первой операции записи после миграции файл расшифровывается старым ключом, а затем записывается с использованием нового метода шифрования. Этот метод эквивалентен операции rewrite, описанной в разделе о предоставленных клиентом ключах шифрования. Учитывая важность первой записи состояния после миграции, не удаляйте старые ключи KMS, пока не будут обновлены все файлы состояния, зашифрованные с их помощью.

Для чтения файлов из бакетов GCS управляемые клиентом ключи не нужно передавать в запросах, поскольку расшифровка выполняется автоматически в GCS. Это означает, что при использовании terraform_remote_state источника данных для доступа к состоянию, зашифрованному с помощью KMS, указывать ключ KMS в объекте config источника данных не нужно.

Переменные конфигурации​

Поддерживаются следующие параметры конфигурации:

• bucket — (Обязательный) Имя бакета GCS. Это имя должно быть уникальным в глобальном масштабе. Дополнительную информацию см. в разделе «Рекомендации по именованию бакетов».
• credentials / GOOGLE_BACKEND_CREDENTIALS / GOOGLE_CREDENTIALS — (Необязательный) Локальный путь к учетным данным аккаунта Google Cloud Platform в формате JSON. Если он не задан, используется путь к учетным данным Google Application Default Credentials. Указанные учетные данные должны иметь роль Storage Object Admin для бакета. Предупреждение: если вы также используете провайдер Google Cloud Platform, он тоже будет использовать переменную среды GOOGLE_CREDENTIALS.
• impersonate_service_account / GOOGLE_BACKEND_IMPERSONATE_SERVICE_ACCOUNT / GOOGLE_IMPERSONATE_SERVICE_ACCOUNT — (Необязательный) Сервисный аккаунт, от имени которого выполняется доступ к бакету состояния. Для успешной имперсонации у вас должна быть роль roles/iam.serviceAccountTokenCreator для этого аккаунта. Если используется цепочка делегирования, ее можно указать с помощью поля impersonate_service_account_delegates.
• impersonate_service_account_delegates — (Необязательный) Цепочка делегирования для имперсонации сервисного аккаунта, как описано здесь.
• access_token — (Необязательный) Временный [токен доступа OAuth 2.0], полученный от сервера авторизации Google, то есть токен Authorization: Bearer, используемый для аутентификации HTTP-запросов к API GCP. Это альтернатива credentials. Если указаны оба параметра, access_token будет иметь приоритет над полем credentials.
• prefix — (Необязательный) Префикс GCS внутри бакета. Именованные состояния рабочих пространств хранятся в объекте с именем <prefix>/<name>.tfstate.
• encryption_key / GOOGLE_ENCRYPTION_KEY — (Необязательный) Ключ шифрования длиной 32 байта в кодировке base64, предоставленный клиентом и используемый при чтении файлов состояния из бакета и записи в него. Дополнительную информацию см. в разделе «Предоставленные клиентом ключи шифрования».
• kms_encryption_key / GOOGLE_KMS_ENCRYPTION_KEY — (Необязательный) Ключ Cloud KMS («управляемый клиентом ключ шифрования»), используемый при чтении файлов состояния из бакета и записи в него. Формат должен быть projects/{{project}}/locations/{{location}}/keyRings/{{keyRing}}/cryptoKeys/{{name}}. Дополнительную информацию, в том числе о требованиях IAM, см. в разделе «Управляемые клиентом ключи шифрования».
• storage_custom_endpoint / GOOGLE_BACKEND_STORAGE_CUSTOM_ENDPOINT / GOOGLE_STORAGE_CUSTOM_ENDPOINT — (Необязательный) URL, состоящий из трех частей: протокола, DNS-имени, указывающего на конечную точку Private Service Connect, и пути к API Cloud Storage (/storage/v1/b, см. здесь). Можно использовать DNS-имя, автоматически созданное Service Directory, или пользовательское DNS-имя. Например, если вы создадите конечную точку с именем xyz и захотите использовать автоматически созданное DNS-имя, задайте для поля значение https://storage-xyz.p.googleapis.com/storage/v1/b. Инструкции по созданию конечной точки Private Service Connect с помощью OpenTofu см. в этом руководстве.
• universe_domain / GOOGLE_BACKEND_UNIVERSE_DOMAIN / GOOGLE_CLOUD_UNIVERSE_DOMAIN — (Необязательный) Домен конечной точки Private Service Connect. В большинстве случаев здесь указывается корневой домен значения, заданного в storage_custom_endpoint. Это указывает SDK GCP разрешать запросы к суверенному облаку с учетными данными, уже созданными для этой облачной вселенной.