Définir une date d'expiration pour un secret

Cette rubrique explique comment définir une date d'expiration pour un secret dans Secret Manager. Cet article explique également comment mettre à jour ou supprimer la date d'expiration définie pour un secret.

Présentation

Par défaut, les secrets stockés dans Secret Manager existent jusqu'à ce qu'un utilisateur les supprime. Si un secret ne doit être stocké que pendant une durée limitée et connue, vous pouvez lui associer un délai d'expiration. Au moment de l'expiration du délai configuré d'un secret, il est automatiquement supprimé.

Si vous n'avez pas d'exigences concernant la suppression du secret, envisagez d'utiliser les conditions IAM ou l'état Désactivé de la version pour révoquer l'accès de manière sécurisée.

Vous pouvez saisir une date d'expiration sous la forme d'un code temporel ou d'une durée. Lorsque des métadonnées d'un secret sont récupérées, l'expiration est toujours renvoyée sous forme d'horodatage, quelle que soit la façon dont elle a été fournie.

Un délai d'expiration peut être ajouté, mis à jour ou supprimé d'un secret à tout moment.

Limites

• L'expiration des secrets n'est disponible que dans l'API v1 de Secret Manager et dans l'outil de ligne de commande gcloud.

• Le délai d'expiration d'un secret ne peut pas être situé à moins de 60 secondes ni à plus de 100 ans.

Utiliser des secrets arrivant à expiration en toute sécurité

Lorsqu'un secret expire dans Secret Manager, il est supprimé de manière irréversible. Le meilleur moyen de détecter les secrets arrivant à expiration consiste à utiliser les conditions IAM pour supprimer les autorisations des comptes qui utilisent le secret avant son expiration.

Pour ce faire, lorsque vous accordez des autorisations sur un secret, associez une condition temporelle à la liaison. La liaison doit expirer après que le secret ne doit plus être utilisé, mais suffisamment tôt pour que les autorisations supprimées soient observées avant l'expiration du secret. Si les workflows qui étaient supposés ne plus utiliser le secret s'interrompent après qu'une autorisation est révoquée, il est possible d'ajouter à nouveau l'autorisation pour limiter rapidement les risques. Si davantage de temps est nécessaire, l'expiration du secret peut être mise à jour, voire supprimée.

Par exemple, supposons qu'un compte de service soit censé accéder à un secret tous les jours sur une période de 30 jours. Le délai d'expiration du secret peut ensuite être défini sur 60 jours à compter de sa création, et une liaison IAM conditionnelle peut être utilisée pour accorder au compte de service le rôle Accesseur de secrets pendant 45 jours. Si le compte de service tente d'accéder au secret au bout de 45 jours, une erreur "Autorisation refusée" est renvoyée et les workflows nécessitant le secret sont interrompus. Un administrateur peut ensuite attribuer de nouveau le rôle "Accesseur de secrets" au compte de service pour limiter rapidement les frais d'investigation, car le secret lui-même n'a pas été supprimé pendant 15 jours supplémentaires.

En outre, il est possible de créer des alertes basées sur l'avertissement de journaux des secrets qui expirent bientôt. Consultez la section Journalisation des délais d'expiration pour plus d'informations.

Spécifier des codes temporels et des durées

• Les valeurs d'horodatage doivent être au format RFC 3339, par exemple 2100-01-01T09:00:00-05:00.

• Les valeurs de durée doivent être mises en forme en tant que nombre de secondes, en incluant le suffixe "s", par exemple 86400s.

Créer un secret arrivant à expiration

Créez un secret arrivant à expiration à l'aide d'un code temporel:

gcloud secrets create "SECRET_ID" \
    --replication-policy "automatic" \
    --expire-time "TIMESTAMP"

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

Créez un secret avec une date d'expiration à l'aide d'une durée:

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

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

Mettre à jour l'expiration d'un secret

Un nouveau délai d'expiration peut être appliqué à tout secret, qu'il en possède déjà un ou non. Chaque secret ne peut être associé qu'à un seul délai d'expiration à la fois. La mise à jour de la date d'expiration d'un secret comportant déjà un délai remplacera son délai d'expiration existant.

Pour mettre à jour la date d'expiration d'un secret à l'aide d'un code temporel:

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

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

Pour mettre à jour l'expiration d'un secret à l'aide d'une durée:

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

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

Supprimer l'expiration d'un secret

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

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 '{}'

Journalisation des délais d'expiration

Les journaux d'audit Cloud ne sont pas générés lorsqu'un secret expire automatiquement. À la place, Secret Manager écrit les journaux dans la ressource Secret de Secret Manager à des intervalles spécifiques menant à l'expiration du secret.

Consultez le guide de démarrage rapide de Logging pour savoir comment afficher ces journaux. Vous pouvez créer des métriques basées sur les journaux et les utiliser pour créer des alertes pour les expirations à venir.

Étape suivante

• Découvrez comment configurer des calendriers de rotation pour les secrets.
• Découvrez comment activer les clés de chiffrement gérées par le client (CMEK) pour Secret Manager.