Como criar e gerenciar secrets expirados

Neste tópico, discutimos a compatibilidade com secrets expirados no Secret Manager.

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.

Ao inserir uma expiração, ela pode ser expressa como carimbo de data/hora ou duração. Ao recuperar metadados secretos, a expiração será 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.

Como usar secrets expirados 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.

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

Como criar um secret expirado

Para criar um secret expirado usando uma execução de carimbo de data/hora:

gcloud

Para usar o Secret Manager na linha de comando, primeiro instale ou faça upgrade para a versão 338.0.0 ou posterior do SDK do Cloud. 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

Para criar um secret expirado usando uma execução de duração:

gcloud

Para usar o Secret Manager na linha de comando, primeiro instale ou faça upgrade para a versão 338.0.0 ou posterior do SDK do Cloud. 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

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

Para atualizar a expiração de um secret usando uma execução de carimbo de data/hora:

gcloud

Para usar o Secret Manager na linha de comando, primeiro instale ou faça upgrade para a versão 338.0.0 ou posterior do SDK do Cloud. 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

Para atualizar a expiração de um secret usando uma execução de duração:

gcloud

Para usar o Secret Manager na linha de comando, primeiro instale ou faça upgrade para a versão 338.0.0 ou posterior do SDK do Cloud. 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

Como remover a expiração de um secret

Para remover a execução do vencimento de um secret:

gcloud

Para usar o Secret Manager na linha de comando, primeiro instale ou faça upgrade para a versão 338.0.0 ou posterior do SDK do Cloud. 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