Esta página foi traduzida pela API Cloud Translation.

Ativar chaves de criptografia gerenciadas pelo cliente para o Secret Manager

Por padrão, o Secret Manager criptografa o conteúdo do cliente em repouso. O Secret Manager processa a criptografia para você sem que você precise fazer nada. Essa opção é chamada de Criptografia padrão do Google.

Se você quiser controlar suas chaves de criptografia, use chaves de criptografia gerenciadas pelo cliente (CMEKs) no Cloud KMS com serviços integrados a CMEKs, incluindo o Secret Manager. O uso de chaves do Cloud KMS permite controlar o nível de proteção, o local, a programação de rotação, as permissões de uso e acesso e os limites criptográficos. O uso do Cloud KMS também permite a você monitorar o uso de chaves, visualizar registros de auditoria e controlar ciclos de vida importantes. Em vez de o Google ser proprietário e gerente de chaves de criptografia de chaves (KEKs) simétricas que protegem seus dados, você controla e gerencia essas chaves no Cloud KMS.

Depois de configurar os recursos com CMEKs, a experiência de acesso aos recursos do Secret Manager é semelhante à criptografia padrão do Google. Para mais informações sobre suas opções de criptografia, consulte Chaves de criptografia gerenciadas pelo cliente (CMEK).

O Secret Manager fornece ferramentas para armazenar, gerenciar e acessar dados sensíveis nos seus aplicativos.

CMEK com o Cloud KMS Autokey

É possível criar CMEKs manualmente para proteger seus recursos do Secret Manager ou usar o Autokey do Cloud KMS. Com o Autokey, keyrings e chaves são gerados sob demanda como parte da criação de recursos no Secret Manager. Os agentes de serviço que usam as chaves para operações de criptografia e descriptografia são criados se ainda não existirem e receberem os papéis necessários do Identity and Access Management (IAM). Para mais informações, consulte Visão geral das autokeys.

O Secret Manager é compatível apenas com o Autokey do Cloud KMS ao criar recursos usando o Terraform ou a API REST.

Para saber como usar CMEKs criadas manualmente para proteger seus recursos do Secret Manager, consulte CMEK com replicação automática e CMEK com replicação gerenciada pelo usuário nesta página.

Para saber como usar as CMEKs criadas pelo Autokey do Cloud KMS para proteger seus recursos do Secret Manager, consulte Usar o Autokey com recursos do Secret Manager.

Como o CMEK funciona no Secret Manager

Antes de gravar uma versão do secret no armazenamento permanente em um determinado local, o Secret Manager criptografa os dados com uma chave de criptografia de dados (DEK) exclusiva. Essa DEK é criptografada com uma chave específica de réplica, chamada chave de criptografia de chaves (KEK) que pertence ao serviço Secret Manager.

Ao usar o CMEK para o Secret Manager, a KEK é chamada de chave CMEK, que é uma chave simétrica gerenciada no Cloud KMS. A chave CMEK precisa estar no mesmo local do Google Cloud que a réplica da versão secreta que ela criptografa. Também é possível usar uma chave do Cloud EKM na política CMEK para criptografia e descriptografia.

Este guia explica como configurar o Secret Manager para usar a CMEK. Para mais informações gerais sobre a CMEK, incluindo como quando e por que ativar, consulte a documentação do Cloud Key Management Service.

Limitações

A CMEK está disponível apenas na API v1 do Secret Manager e na Google Cloud CLI.

Antes de começar

É possível armazenar todos os recursos no mesmo projeto ou armazenar segredos e chaves em projetos separados. Leia Separação de tarefas do Cloud KMS para entender melhor essa decisão.

Conclua os pré-requisitos a seguir para configurar o Secret Manager e o Cloud KMS:

Secret Manager:
- Crie ou use um projeto atual para armazenar os recursos do Secret Manager.
- Se necessário, conclua as etapas na seção Como configurar o Secret Manager do guia de início rápido do Secret Manager.
Cloud KMS:
- Crie ou use um projeto atual para armazenar os recursos do Cloud KMS.
- Se necessário, ative a API Cloud KMS.

Defina as variáveis a seguir para os IDs dos projetos do Secret Manager e do Cloud KMS.

This is an editable variable. Set it to your Secret Manager project ID and the
value will be used in all commands on this page.
SM_PROJECT_ID

This is an editable variable. Set it to your Cloud KMS project ID and the value
will be used in all commands on this page.
KMS_PROJECT_ID

Faça a autenticação no Google Cloud:

gcloud

Para usar o Secret Manager na linha de comando, primeiro instale ou faça upgrade para a versão 378.0.0 ou mais recente da Google Cloud CLI. No Compute Engine ou no GKE, você precisa fazer a autenticação com o escopo do cloud-platform.

gcloud auth login

Como criar uma identidade de agente de serviço

Você precisa criar uma identidade de agente de serviço para cada projeto que exige chaves de criptografia gerenciadas pelo cliente.

Para criar uma identidade de serviço com a Google Cloud CLI, execute o seguinte comando:

gcloud

gcloud beta services identity create \
    --service "secretmanager.googleapis.com" \
    --project "SM_PROJECT_ID"

Que vai retornar um nome de identidade de serviço no seguinte formato:

service-PROJECT_NUMBER@gcp-sa-secretmanager.iam.gserviceaccount.com

Salve o nome da identidade do serviço:

The following variable is editable. Click on it to update the value, and it will
be reflected throughout this documentation page.

SM_SERVICE_IDENTITY

Você vai conceder a essa identidade de serviço acesso às chaves CMEK do Cloud KMS usadas para criptografar e descriptografar seus secrets.

CMEK com replicação automática

Esta seção aborda os segredos configurados por uma política de replicação automática.

Para chaves secretas que usam a política de replicação automática, a chave CMEK precisa estar localizada na multirregião global do Cloud KMS. Se você estiver usando uma chave do Cloud EKM, não será possível configurar o segredo para usar a replicação automática, porque as chaves do Cloud EKM não estão disponíveis na região global. Para saber mais sobre o uso de chaves do Cloud EKM, consulte Adicionar uma chave do Cloud EKM a uma política de CMEK.

Crie uma chave simétrica do Cloud KMS na região do Cloud KMS global ou use uma chave existente. Este exemplo cria um novo keyring chamado secret-manager-cmek e, em seguida, uma nova chave chamada my-cmek-key.

gcloud

gcloud kms keyrings create "secret-manager-cmek" \
    --project "KMS_PROJECT_ID" \
    --location "global"

gcloud kms keys create "my-cmek-key" \
    --project "KMS_PROJECT_ID" \
    --location "global" \
    --keyring "secret-manager-cmek" \
    --purpose "encryption"

Conceda à identidade do serviço o acesso ao Secret Manager para criptografar e descriptografar usando a chave CMEK. Esse comando concede o papel de criptografador/descriptografador do Cloud KMS (roles/cloudkms.cryptoKeyEncrypterDecrypter) na chave my-cmek-key do Cloud KMS à identidade de serviço.

gcloud

gcloud kms keys add-iam-policy-binding "my-cmek-key" \
    --project "KMS_PROJECT_ID" \
    --location "global" \
    --keyring "secret-manager-cmek" \
    --member "serviceAccount:SM_SERVICE_IDENTITY" \
    --role "roles/cloudkms.cryptoKeyEncrypterDecrypter"

Crie um secret com replicação automática. O nome do recurso da chave CMEK é armazenado como metadados no secret.

gcloud

gcloud secrets create "SECRET_ID" \
    --replication-policy "automatic" \
    --kms-key-name "projects/KMS_PROJECT_ID/locations/global/keyRings/secret-manager-cmek/cryptoKeys/my-cmek-key" \
    --project "SM_PROJECT_ID"

API

Esses exemplos usam curl para demonstrar o uso da API. É possível gerar tokens de acesso com o gcloud auth print-access-token. No Compute Engine ou no GKE, você precisa fazer a autenticação com o escopo do cloud-platform.

Defina o valor de replication.automatic.customerManagedEncryption.kmsKeyName como o nome do recurso da chave CMEK.

curl "https://secretmanager.googleapis.com/v1/projects/${SM_PROJECT_ID}/secrets?secretId=SECRET_ID" \
    --request "POST" \
    --header "Content-Type: application/json" \
    --header "Authorization: Bearer ACCESS_TOKEN" \
    --data-binary @- <<EOF
{
  "replication":{
    "automatic":{
      "customerManagedEncryption":{
        "kmsKeyName": "projects/KMS_PROJECT_ID/locations/global/keyRings/secret-manager-cmek/cryptoKeys/my-cmek-key"
      }
    }
  }
}
EOF

Agora, sempre que uma versão do secret é criada nesse secret, o payload dessa versão é automaticamente criptografado usando a chave antes de ser gravado no armazenamento permanente, desde que a identidade do serviço tenha acesso à chave CMEK. Se a identidade do serviço perder o acesso ou se a chave ficar indisponível, uma tentativa de criar uma nova versão do secret ou acessar uma versão atual vai retornar um erro.

Adicione uma nova versão do secret. Não é necessário especificar o nome do recurso da chave do Cloud KMS. Ele é lido nos metadados do segredo.

gcloud

echo -n "SECRET_DATA" | gcloud secrets versions add "SECRET_ID" \
    --project "SM_PROJECT_ID" \
    --data-file -

A versão do secret é criada, mesmo que o autor da chamada não tenha acesso direto para usar a chave CMEK. A identidade de serviço do Secret Manager, e não o autor da chamada, é responsável por criptografar e descriptografar secrets ao lê-los ou gravá-los.

Da mesma forma, você não precisa de acesso direto à chave CMEK para acessar o secret. A identidade do serviço acessa a chave e criptografa ou descriptografa o segredo em seu nome.

Acesse a versão do secret que você acabou de criar:

gcloud

gcloud secrets versions access "latest" \
    --project "SM_PROJECT_ID" \
    --secret "SECRET_ID"

Atualizar a configuração do CMEK

Crie uma nova chave simétrica do KMS na multirregião do Cloud KMS global.

gcloud

gcloud kms keys create "my-other-key" \
    --project "KMS_PROJECT_ID" \
    --location "global" \
    --keyring "secret-manager-cmek" \
    --purpose "encryption"

Conceda à identidade do serviço o acesso ao Secret Manager para criptografar e descriptografar usando a nova chave CMEK. Esse comando concede o papel de criptografador / descriptografador do Cloud KMS (roles/cloudkms.cryptoKeyEncrypterDecrypter) na chave my-other-key do Cloud KMS à identidade de serviço.

gcloud

gcloud kms keys add-iam-policy-binding "my-other-key" \
    --project "KMS_PROJECT_ID" \
    --location "global" \
    --keyring "secret-manager-cmek" \
    --member "serviceAccount:SM_SERVICE_IDENTITY" \
    --role "roles/cloudkms.cryptoKeyEncrypterDecrypter"

Para modificar a configuração do CMEK em um secret, atualize a replicação no secret com os novos nomes de recursos da chave do Cloud KMS.

gcloud

gcloud secrets replication update "SECRET_ID" \
    --set-kms-key "projects/KMS_PROJECT_ID/locations/global/keyRings/secret-manager-cmek/cryptoKeys/my-other-key" \
    --project "SM_PROJECT_ID"

API

curl "https://secretmanager.googleapis.com/v1/projects/${SM_PROJECT_ID}/secrets/SECRET_ID?updateMask=replication" \
    --request "PATCH" \
    --header "Authorization: Bearer ACCESS_TOKEN" \
    --header "Content-Type: application/json" \
    --data-binary @- <<EOF
{
  "replication": {
    "automatic":{
      "customerManagedEncryption":{
        "kmsKeyName": "projects/KMS_PROJECT_ID/locations/global/keyRings/secret-manager-cmek/cryptoKeys/my-other-key"
      }
    }
  }
}
EOF

CMEK com replicação gerenciada pelo usuário

Esta seção aborda secrets configurados com uma política de replicação gerenciada pelo usuário. Com uma política de replicação gerenciada pelo usuário, você controla o local do Google Cloud em que o secret é armazenado. Os secrets podem ser acessados em todos os locais do Google Cloud.

Os secrets com uma política de replicação gerenciada pelo usuário precisam usar chaves do Cloud KMS que mapeiam exatamente os locais em que as versões do secret são armazenadas. Os exemplos deste guia armazenam um segredo em dois locais separados: us-east1 e us-central1. As solicitações para acessar o secret são encaminhadas para um desses locais.

Em cada uma das duas regiões, crie um keyring e uma chave do Cloud KMS com a finalidade de criptografia ou use uma chave existente. Este exemplo cria um novo keyring chamado "secret-manager-cmek" e, em seguida, uma chave chamada "my-cmek-key" em cada região.

gcloud

gcloud kms keyrings create "secret-manager-cmek" \
    --project "KMS_PROJECT_ID" \
    --location "us-east1"

gcloud kms keys create "my-cmek-key" \
    --project "KMS_PROJECT_ID" \
    --location "us-east1" \
    --keyring "secret-manager-cmek" \
    --purpose "encryption"

gcloud kms keyrings create "secret-manager-cmek" \
    --project "KMS_PROJECT_ID" \
    --location "us-central1"

gcloud kms keys create "my-cmek-key" \
    --project "KMS_PROJECT_ID" \
    --location "us-central1" \
    --keyring "secret-manager-cmek" \
    --purpose "encryption"

Conceda à identidade do serviço do Secret Manager a permissão para criptografar e descriptografar usando a chave CMEK. Para isso, conceda o papel de criptografador/descriptografador do Cloud KMS (roles/cloudkms.cryptoKeyEncrypterDecrypter) para cada chave CMEK individualmente ou para todas as chaves no projeto.

gcloud

gcloud kms keys add-iam-policy-binding "my-cmek-key" \
    --project "KMS_PROJECT_ID" \
    --location "us-east1" \
    --keyring "secret-manager-cmek" \
    --member "serviceAccount:SM_SERVICE_IDENTITY" \
    --role "roles/cloudkms.cryptoKeyEncrypterDecrypter"

gcloud kms keys add-iam-policy-binding "my-cmek-key" \
    --project "KMS_PROJECT_ID" \
    --location "us-central1" \
    --keyring "secret-manager-cmek" \
    --member "serviceAccount:SM_SERVICE_IDENTITY" \
    --role "roles/cloudkms.cryptoKeyEncrypterDecrypter"

Crie um secret ativado para CMEK com replicação gerenciada pelo usuário. O nome do recurso da chave CMEK é armazenado como metadados no secret.

gcloud

cat <<EOF > ./replication-policy.json
{
  "userManaged":{
    "replicas":[
      {
        "location":"us-east1",
        "customerManagedEncryption":{
          "kmsKeyName":"projects/KMS_PROJECT_ID/locations/us-east1/keyRings/secret-manager-cmek/cryptoKeys/my-cmek-key"
        }
      },
      {
        "location":"us-central1",
        "customerManagedEncryption":{
          "kmsKeyName":"projects/KMS_PROJECT_ID/locations/us-central1/keyRings/secret-manager-cmek/cryptoKeys/my-cmek-key"
        }
      }
    ]
  }
}
EOF

gcloud secrets create "my-ummr-secret" \
    --replication-policy-file ./replication-policy.json \
    --project "SM_PROJECT_ID"

API

Defina o valor de replication.userManaged.replicas.customerManagedEncryption.kmsKeyName como os nomes dos recursos das chaves CMEK.

curl "https://secretmanager.googleapis.com/v1/projects/SM_PROJECT_ID/secrets?secretId=my-ummr-secret" \
--request "POST" \
--header "Content-Type: application/json" \
--header "Authorization: Bearer ACCESS_TOKEN" \
--data-binary @- <<EOF
{
  "replication":{
    "userManaged":{
      "replicas":[
        {
          "location":"us-east1",
          "customerManagedEncryption":{
            "kmsKeyName":"projects/KMS_PROJECT_ID/locations/us-east1/keyRings/secret-manager-cmek/cryptoKeys/my-cmek-key"
          }
        },
        {
          "location":"us-central1",
          "customerManagedEncryption":{
            "kmsKeyName":"projects/KMS_PROJECT_ID/locations/us-central1/keyRings/secret-manager-cmek/cryptoKeys/my-cmek-key"
          }
        }
      ]
    }
  }
}
EOF

Adicione uma nova versão do secret. Não é necessário especificar o nome do recurso da chave do Cloud KMS. Ele é lido nos metadados do segredo.

gcloud

echo -n "SECRET_DATA" | gcloud secrets versions add "my-ummr-secret" \
    --project "SM_PROJECT_ID" \
    --data-file -

A versão do secret é criada, mesmo que o autor da chamada não tenha acesso direto para usar a chave CMEK. A identidade do serviço do Secret Manager, e não o autor da chamada, é responsável por criptografar e descriptografar secrets ao lê-los ou gravá-los.

Da mesma forma, você não precisa de acesso direto à chave CMEK para acessar o secret. A identidade do serviço acessa a chave e criptografa ou descriptografa o segredo em seu nome.

Acesse a versão do secret que você acabou de criar.

gcloud

gcloud secrets versions access "latest" \
    --project "SM_PROJECT_ID" \
    --secret "my-ummr-secret"

Atualizar a configuração do CMEK

Crie duas novas chaves simétricas do KMS nas mesmas regiões do segredo.

gcloud

gcloud kms keys create "my-other-key" \
    --project "KMS_PROJECT_ID" \
    --location "us-east1" \
    --keyring "secret-manager-cmek" \
    --purpose "encryption"

gcloud kms keys create "my-other-key" \
    --project "KMS_PROJECT_ID" \
    --location "us-central1" \
    --keyring "secret-manager-cmek" \
    --purpose "encryption"

Conceda à identidade de serviço o acesso ao Secret Manager para criptografar e descriptografar usando as novas chaves CMEK. Esse comando concede o papel de criptografador / descriptografador do Cloud KMS (roles/cloudkms.cryptoKeyEncrypterDecrypter) nas chaves do Cloud KMS my-other-key à identidade de serviço.

gcloud

gcloud kms keys add-iam-policy-binding "my-other-key" \
    --project "KMS_PROJECT_ID" \
    --location "us-east1" \
    --keyring "secret-manager-cmek" \
    --member "serviceAccount:SM_SERVICE_IDENTITY" \
    --role "roles/cloudkms.cryptoKeyEncrypterDecrypter"

gcloud kms keys add-iam-policy-binding "my-other-key" \
    --project "KMS_PROJECT_ID" \
    --location "us-central1" \
    --keyring "secret-manager-cmek" \
    --member "serviceAccount:SM_SERVICE_IDENTITY" \
    --role "roles/cloudkms.cryptoKeyEncrypterDecrypter"

Para modificar a configuração do CMEK em um secret, atualize a replicação no secret com os novos nomes de recursos da chave do Cloud KMS.

gcloud

gcloud secrets replication update "my-ummr-secret" \
    --set-kms-key "projects/KMS_PROJECT_ID/locations/us-east1/keyRings/secret-manager-cmek/cryptoKeys/my-other-key" \
    --location us-east1 \
    --project "SM_PROJECT_ID"

gcloud secrets replication update "my-ummr-secret" \
    --set-kms-key "projects/KMS_PROJECT_ID/locations/us-central1/keyRings/secret-manager-cmek/cryptoKeys/my-other-key" \
    --location us-central1 \
    --project "SM_PROJECT_ID"

Para atualizar várias chaves em um secret simultaneamente, é possível receber e definir a política de replicação por um arquivo.

gcloud

gcloud secrets replication get "my-ummr-secret" \
    --project "SM_PROJECT_ID" \
    --format=json > ./replication-policy.json

Atualize o arquivo para refletir a configuração CMEK desejada no editor de sua preferência. Em seguida, defina a nova política:

gcloud secrets replication set "my-ummr-secret" \
    --replication-policy-file ./replication-policy.json \
    --project "SM_PROJECT_ID"

API

curl "https://secretmanager.googleapis.com/v1/projects/${SM_PROJECT_ID}/secrets/my-ummr-secret?updateMask=replication" \
    --request "PATCH" \
    --header "Authorization: Bearer ACCESS_TOKEN" \
    --header "Content-Type: application/json" \
    --data-binary @- <<EOF
{
  "replication":{
    "userManaged":{
      "replicas":[
        {
          "location":"us-east1",
          "customerManagedEncryption":{
            "kmsKeyName":"projects/KMS_PROJECT_ID/locations/us-east1/keyRings/secret-manager-cmek/cryptoKeys/my-other-key"
          }
        },
        {
          "location":"us-central1",
          "customerManagedEncryption":{
            "kmsKeyName":"projects/KMS_PROJECT_ID/locations/us-central1/keyRings/secret-manager-cmek/cryptoKeys/my-other-key"
          }
        }]
      }
    }
  }
EOF

Conferir a configuração do CMEK da versão do secret

Para inspecionar os metadados de uma versão do secret, incluindo se ela está ativada para o CMEK e o nome do recurso da versão da chave CMEK, acesse os metadados dela.

gcloud

gcloud secrets versions describe "latest" \
    --secret "SECRET_ID" \
    --project "SM_PROJECT_ID"

API

curl "https://secretmanager.googleapis.com/v1/projects/SM_PROJECT_ID/secrets/SECRET_ID/versions/latest" \
    --request "GET" \
    --header "Authorization: Bearer ACCESS_TOKEN" \
    --header "Content-Type: application/json"

Isso retorna o nome completo do recurso do Cloud KMS da versão da chave usada para criptografar a versão secreta.

{
  "name": "projects/PROJECT_NUMBER/secrets/SECRET_ID/versions/1",
  "createTime": "2021-07-...",
  "state": "ENABLED",
  "replicationStatus": {
    "automatic": {
      "customerManagedEncryption": {
        "kmsKeyVersionName": "projects/KMS_PROJECT_ID/locations/global/keyRings/secret-manager-cmek/cryptoKeys/my-cmek-key/cryptoKeyVersions/1"
      }
    }
  }
}

Adicionar uma chave do Cloud EKM a uma política de CMEK

Esta seção aborda a adição de uma chave do Cloud EKM a uma política do CMEK. Essas etapas permitem que uma chave do Cloud EKM seja usada para criptografar ou descriptografar segredos.

Como o Cloud EKM não oferece suporte à multirregião global, as chaves do Cloud EKM só podem ser usadas com segredos configurados para a replicação gerenciada pelo usuário.

Crie uma chave simétrica na região do Cloud KMS us-central1 (ou qualquer região, exceto global). Este exemplo cria um novo keyring chamado secret-manager-cmek-ekm e, em seguida, uma nova chave chamada my-ekm-key no keyring.

gcloud

Crie um novo keyring:

gcloud kms keyrings create "secret-manager-cmek-ekm" \
  --project "KMS_PROJECT_ID" \
  --location "us-central1"

Crie uma chave nesse keyring:

gcloud kms keys create "my-ekm-key" \
  --keyring "secret-manager-cmek-ekm" \
  --location "us-central1" \
  --purpose "encryption" \
  --protection-level "external" \
  --skip-initial-version-creation \
  --default-algorithm "external-symmetric-encryption"

Em seguida, crie uma nova versão de my-ekm-key usando o URI externo da chave. Para mais informações sobre URIs externos para chaves do Cloud EKM, consulte Criar uma chave externa.

gcloud

gcloud kms keys versions create \
  --key "my-ekm-key" \
  --keyring "secret-manager-cmek-ekm" \
  --location "us-central1" \
  --external-key-uri EXTERNAL_KEY_URI \
  --primary

Conceda à identidade do serviço o acesso ao Secret Manager para criptografar e descriptografar usando a chave externa. Esse comando concede o papel de criptografador / descriptografador do Cloud KMS (roles/cloudkms.cryptoKeyEncrypterDecrypter) em my-ekm-key à identidade do serviço.

gcloud

gcloud kms keys add-iam-policy-binding "my-ekm-key" \
  --project "KMS_PROJECT_ID" \
  --location "us-central1" \
  --keyring "secret-manager-cmek-ekm" \
  --member "serviceAccount:SM_SERVICE_IDENTITY" \
  --role "roles/cloudkms.cryptoKeyEncrypterDecrypter"

Crie um secret ativado para CMEK que use uma chave do Cloud EKM.

gcloud

cat <<EOF > ./replication-policy.json
{
  "userManaged":{
    "replicas":[
      {
        "location":"us-central1",
        "customerManagedEncryption":{
          "kmsKeyName":"projects/KMS_PROJECT_ID/locations/us-central1/keyRings/secret-manager-cmek-ekm/cryptoKeys/my-ekm-key"
        }
      }
    ]
  }
}
EOF

gcloud secrets create "my-ekm-secret" \
    --replication-policy-file ./replication-policy.json \
    --project "SM_PROJECT_ID"

Agora, sempre que uma versão do secret é criada em my-ekm-secret, o payload dessa versão é criptografado automaticamente usando a chave do Cloud EKM antes de ser gravado no armazenamento permanente, desde que a identidade do serviço tenha acesso à chave. Se a identidade do serviço perder o acesso ou se a chave ficar indisponível, uma tentativa de criar uma nova versão do secret ou acessar uma versão atual vai retornar um erro.

Adicione uma nova versão do secret. O nome do recurso da chave é lido dos metadados do segredo.

gcloud

echo -n "SECRET_DATA" | gcloud secrets versions add "my-ekm-secret" \
    --project "SM_PROJECT_ID" \
    --data-file -

A versão do secret é criada, mesmo que o autor da chamada não tenha acesso direto para usar a chave. A identidade de serviço do Secret Manager, e não o autor da chamada, é responsável por criptografar e descriptografar secrets ao lê-los ou gravá-los.

Acesse a versão do secret que você acabou de criar. É aqui que a identidade do serviço acessa a chave e criptografa ou descriptografa o segredo em seu nome.

gcloud

gcloud secrets versions access "latest" \
  --project "SM_PROJECT_ID" \
  --secret "my-ekm-secret"

Desativar a CMEK

Atualize a política de replicação para remover a configuração de CMEK de um secret.

gcloud

gcloud secrets replication update "SECRET_ID" --remove-cmek \
    --project "SM_PROJECT_ID"

API

curl "https://secretmanager.googleapis.com/v1/projects/${SM_PROJECT_ID}/secrets/SECRET_ID?updateMask=replication" \
    --request "PATCH" \
    --header "Authorization: Bearer ACCESS_TOKEN" \
    --header "Content-Type: application/json" \
    --data-binary @- <<EOF
{
  "replication":{
    "automatic":{}
  }
}
EOF

A seguir

Saiba mais sobre o CMEK.