Тип бэкенда: 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 без необходимости встраивать отдельный файл учетных данных или аутентификации. Убедитесь, что для VM/кластера задана область действия cloud-platform.

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

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

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

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

Шифрование​

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

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

Если вы хотите удалить предоставляемые клиентом ключи из конфигурации бэкенда или заменить их другими, OpenTofu не сможет автоматически перенести состояние — потребуется выполнить действия вручную. Это необходимо, поскольку Google не хранит предоставляемые клиентом ключи шифрования, поэтому их нужно передавать с каждым запросом к Cloud Storage API (см. раздел Предоставляемые клиентом ключи шифрования). При переносе состояния сведения о старом ключе удаляются из конфигурации бэкенда, и 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 разрешать запросы к суверенному облаку с учетными данными, уже созданными для этого облачного домена.