Cette page a été traduite par l'API Cloud Translation.

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 modifier 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

Pour utiliser Secret Manager avec la ligne de commande, commencez par Installez la Google Cloud CLI ou passez à la version 378.0.0 ou ultérieure. Sur Compute Engine ou GKE, vous devez vous authentifier avec le champ d'application cloud-platform.

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

API

Ces exemples utilisent curl pour illustrer l'utilisation de l'API. Vous pouvez générer des jetons d'accès avec gcloud auth print-access-token. Sur Compute Engine ou GKE, vous devez vous authentifier avec le champ d'application 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

Créez un secret arrivant à expiration en définissant une durée:

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

Mettre à jour la date d'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

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

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

gcloud

Pour utiliser Secret Manager avec la ligne de commande, commencez par installer ou mettre à niveau Google Cloud CLI vers la version 378.0.0 ou une version ultérieure. Sur Compute Engine ou GKE, vous devez vous authentifier avec le champ d'application cloud-platform.

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

Supprimer l'expiration d'un secret

gcloud

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

API

L'inclusion de expire_time ou de ttl dans updateMask tout en ne leur fournissant pas de valeurs supprimera l'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 le Secret ressource sur à des intervalles spécifiques menant à l'expiration d'un secret.

Durée des journaux	Type d'événement secret
30 jours avant l'expiration.	`EXPIRES_IN_30_DAYS`
sept jours avant l'expiration.	`EXPIRES_IN_7_DAYS`
1 jour avant l'expiration	`EXPIRES_IN_1_DAY`
six heures avant l'expiration	`EXPIRES_IN_6_HOURS`
1 heure avant l'expiration	`EXPIRES_IN_1_HOUR`
à l'expiration	`EXPIRED`

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 des secrets.
Découvrez comment activer les clés de chiffrement gérées par le client (CMEK) pour Secret Manager.