Neste tópico, mostramos como definir a data de validade de 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.
O prazo de validade pode ser inserido no formato de carimbo de data/hora ou duração Quando os metadados do secret são recuperados, a expiração é sempre retornados 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 com segurança 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.
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 prestes a expirar
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
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 validade de um secret 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 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, o Secret Manager grava registros no Secret Manager Secret
recurso em
intervalos específicos que levam à expiração de um 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 saber mais sobre como visualizar esses registros. É possível criar com base em registros métricas e usá-las para criar alertas para as próximas datas de expiração.
A seguir
- Saiba como configurar programações de rotação de secrets.
- Saiba como ativar chaves de criptografia gerenciadas pelo cliente (CMEK) para o Secret Manager.