Definir uma data de validade para um secret

Neste tópico, mostramos como definir uma data de validade para um secret no Secret Manager. O tópico também descreve como atualizar ou remover a data de validade definida para um secret.

Visão geral

Por padrão, os secrets armazenados no Secret Manager existem até que um usuário os exclua. É possível anexar um prazo de validade a uma senha que possa ser armazenada apenas por um período limitado e conhecido. No prazo de validade configurado de um secret, ele é excluído automaticamente.

Se você não tiver requisitos para excluir a chave secreta, use as condições do IAM ou o estado da versão desativada para revogar o acesso com segurança.

Aviso: no momento da expiração, o secret e todas as versões dele são excluídas de forma irreversível. Consulte Como usar secrets com segurança para mais informações.

Você pode inserir um tempo de expiração como um carimbo de data/hora ou uma duração. Quando os metadados secretos são recuperados, a expiração é sempre retornada como um carimbo de data/hora, independentemente de como foi fornecido.

Uma validade pode ser adicionada, atualizada ou removida a qualquer momento.

Limitações

• A expiração do secret só está disponível na API v1 do Secret Manager e na ferramenta de linha de comando gcloud.

• A expiração de um secret não pode estar a menos de 60 segundos ou a mais de 100 anos de distância.

Usar com segurança os secrets expirados

Quando um secret expira no Secret Manager, ele é excluído permanentemente. A melhor maneira de detectar secrets de breve a expirar é usando Condições de IAM para remover as permissões das contas que usam o secret antes da expiração.

Para fazer isso, ao conceder permissões em um secret, anexe uma condição baseada em tempo à vinculação. É necessário que a vinculação expire depois que o secret não for mais usado, mas o suficiente para que as permissões removidas sejam vistas antes que o secret expire. Se você considerar que os fluxos de trabalho não usarão mais o intervalo secreto depois que as permissões forem revogadas, será possível adicionar as permissões novamente para atenuá-las rapidamente. Se for necessário mais tempo, a validade do secret poderá ser atualizada ou até mesmo removida.

Por exemplo, suponha que uma conta de serviço precise acessar um secret diariamente durante um período de 30 dias. A expiração do secret pode ser definida como 60 dias a partir da criação, e uma vinculação de IAM condicional pode ser usada para conceder à conta de serviço o papel de acessador secreto por 45 dias. Se a conta de serviço tentar acessar o secret após 45 dias, um erro de permissão negada será retornado e os fluxos de trabalho que exigem o secret serão interrompidos. Um administrador pode conceder o papel de acessador do Secret novamente à conta de serviço para mitigar rapidamente durante a investigação, já que o secret não seria excluído por mais 15 dias.

Cuidado: se uma conta receber permissões no nível do projeto, ela manterá essas permissões em todos os secrets, independentemente das permissões específicas do secret, de modo que as condições do IAM sejam não é suficiente para detectar secrets expirados. Defina permissões por secret ao usar secrets expirados.

Além disso, é possível criar alertas com base em avisos de registros de secrets que expiram em breve. Consulte Registro de expiração para mais informações.

Especificar carimbos de data/hora e durações

• Os valores de carimbo de data/hora precisam ser formatados como RFC 3339, por exemplo, 2100-01-01T09:00:00-05:00.

• Os valores de duração precisam ser formatados como o número de segundos, incluindo o sufixo "s", por exemplo, 86400s.

Criar um secret com data de validade

Crie um secret com data de validade usando um carimbo de data/hora:

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 secrets create "SECRET_ID" \
    --replication-policy "automatic" \
    --expire-time "TIMESTAMP"

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.

curl "https://secretmanager.googleapis.com/v1/projects/PROJECT_ID/secrets?secretId=SECRET_ID" \
    --request "POST" \
    --header "Content-Type: application/json" \
    --header "Authorization: Bearer ACCESS_TOKEN" \
    --data-binary @- <<EOF
{
  "replication": {"automatic": {}},
  "expire_time": "TIMESTAMP"
}
EOF

Crie um secret com data de validade usando uma duração:

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 secrets create "SECRET_ID" \
    --replication-policy "automatic" \
    --ttl "DURATION"

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.

curl "https://secretmanager.googleapis.com/v1/projects/PROJECT_ID/secrets?secretId=SECRET_ID" \
    --request "POST" \
    --header "Content-Type: application/json" \
    --header "Authorization: Bearer ACCESS_TOKEN" \
    --data-binary @- <<EOF
{
  "replication": {"automatic": {}},
  "ttl": "DURATION"
}
EOF

Atualizar a expiração de um secret

Qualquer secret pode ter uma nova expiração aplicada a ela, independentemente de já ter uma. Cada secret só pode ter uma validade configurada por vez. Atualizar a validade de um secret que já tenha um substituirá a validade atual.

Atualize a expiração de um secret usando um carimbo de data/hora:

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 secrets update "SECRET_ID" \
    --expire-time "TIMESTAMP"

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.

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

Atualize a expiração de um secret usando uma duração:

Atenção: a duração representa o tempo decorrido entre a atualização e a expiração. Ele não representa o ttl total do secret desde a criação.

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 secrets update "SECRET_ID" \
    --ttl "DURATION"

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.

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

Remover a expiração de um secret

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 secrets update "SECRET_ID" \
    --remove-expiration

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.

Incluir expire_time ou ttl no updateMask e fornecer valores para nenhum deles removerá a validade.

curl "https://secretmanager.googleapis.com/v1/projects/PROJECT_ID/secrets/SECRET_ID?updateMask=ttl" \
    --request "PATCH" \
    --header "Content-Type: application/json" \
    --header "Authorization: Bearer ACCESS_TOKEN" \
    --data-binary '{}'

Geração de registros de expiração

Os registros de auditoria do Cloud não são produzidos quando um secret expira automaticamente. Em vez disso, ele grava registros no recurso Secret do Secret Manager em intervalos específicos que levam à expiração do secret.

Tempo do registro	Tipo de evento secreto
30 dias antes da expiração	EXPIRES_IN_30_DAYS
Sete dias antes da expiração	EXPIRES_IN_7_DAYS
1 dia antes da expiração	EXPIRES_IN_1_DAY
Seis horas antes da expiração	EXPIRES_IN_6_HOURS
1 hora antes da expiração	EXPIRES_IN_1_HOUR
na expiração	EXPIRED

Consulte o Guia de início rápido do Logging para informações sobre como visualizar esses registros. É possível criar métricas com base em registros e usá-las para criar alertas de datas de expiração futuras.

A seguir

• Saiba como configurar programações de rotação para segredos.
• Saiba como ativar as chaves de criptografia gerenciadas pelo cliente (CMEK) no Secret Manager.