Definir a data de validade de um secret

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

Informações gerais

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.

Insira um prazo de validade como um carimbo de data/hora ou uma duração. Quando os metadados do secret são recuperados, a expiração é sempre retornada como um carimbo de data/hora, independentemente de como eles foram fornecidos.

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.

Use chaves secretas expiradas com segurança

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.

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 temporário

Crie um secret temporário 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 temporário usando uma duração:

gcloud

gcloud secrets create "SECRET_ID" \
    --replication-policy "automatic" \
    --ttl "DURATION"

API

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 validade 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.

Use um carimbo de data/hora para atualizar a validade de um secret:

gcloud

gcloud secrets update "SECRET_ID" \
    --expire-time "TIMESTAMP"

API

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 validade de um secret usando uma duração:

gcloud

gcloud secrets update "SECRET_ID" \
    --ttl "DURATION"

API

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

gcloud secrets update "SECRET_ID" \
    --remove-expiration

API

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, o Secret Manager 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 ver esses registros. É possível criar métricas com base em registros e usá-las para criar alertas para as próximas expiras.

A seguir

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