Spec-Zone.ru › OpenTofu 1.10

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

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

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

Предупреждение

Настоятельно рекомендуется включить версионирование объектов в бакете 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 для учетной записи, имперсонация которой выполняется.

Шифрование​

Предупреждение

Бережно храните ключи шифрования: данные состояния, зашифрованные утерянным или удаленным ключом, восстановить невозможно. Если вы используете предоставленные клиентом ключи шифрования, необходимо обеспечить их безопасное хранение и не допустить их утраты. Нельзя удалять управляемые клиентом ключи шифрования в Cloud KMS, используемые для шифрования состояния. Однако если вы случайно удалили ключ, в течение некоторого времени его можно восстановить.

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

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

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

Важно

Чтобы перенести состояние с использованием предоставленных клиентом ключей шифрования или изменить ключ, используемый бэкендом, необходимо выполнить операцию перезаписи (интерфейс командной строки gsutil) или cp (интерфейс командной строки gcloud), чтобы удалить старый предоставленный клиентом ключ шифрования из файла состояния. После удаления шифрования вы сможете успешно выполнить tofu init -migrate-state с новой конфигурацией бэкенда.

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

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

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

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

Важно

Чтобы использовать управляемые клиентом ключи шифрования, создайте ключ и предоставьте служебному агенту GCS вашего проекта разрешение на его использование, назначив предопределенную роль Cloud KMS CryptoKey Encrypter/Decrypter.

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

Предупреждение

Рекомендуем использовать переменные среды для передачи учетных данных и других конфиденциальных данных. Если вы используете -backend-config или указываете эти значения непосредственно в конфигурации, OpenTofu включает их и в подкаталог .terraform, и в файлы плана. Подробности см. в разделе «Учетные данные и конфиденциальные данные».

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

  • bucket — (Обязательный) Имя бакета GCS. Это имя должно быть уникальным во всем мире. Дополнительные сведения см. в разделе «Рекомендации по именованию бакетов».
  • credentials / GOOGLE_BACKEND_CREDENTIALS / GOOGLE_CREDENTIALS — (Необязательный) Локальный путь к учетным данным аккаунта Google Cloud Platform в формате JSON. Если параметр не задан, используется путь к учетным данным приложения Google по умолчанию. Указанные учетные данные должны иметь роль 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 — (Необязательный) Ключ шифрования, предоставленный клиентом, в кодировке base64, длиной 32 байта; используется при чтении файлов состояния из бакета и записи в него. Дополнительные сведения см. в разделе «Предоставленные клиентом ключи шифрования».
  • 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 см. в этом руководстве.

Copyright (c) The OpenTofu Authors
Copyright (c) 2014 HashiCorp, Inc.
Mozilla Public License, version 2.0
https://opentofu.org/docs/v1.10/language/settings/backends/gcs/

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API