Définir une date d'expiration pour un secret

Cet article explique comment définir une date d'expiration pour un secret dans Secret Manager. Cette rubrique 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 un délai d'expiration sous forme de code temporel ou de durée. Lorsque les métadonnées d'un secret sont récupérées, le délai d'expiration est toujours renvoyé sous forme d'horodatage, quelle que soit la façon dont il a été fourni.

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 de manière sécurisée

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 dans la ligne de commande, commencez par installer la version 378.0.0 ou une version ultérieure de la Google Cloud CLI, ou la mettre à niveau vers la version 378.0.0. 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 à l'aide d'une durée:

gcloud

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

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

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": {}},
  "ttl": "DURATION"
}
EOF

Mettre à jour le délai 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.

Mettez à jour le délai d'expiration d'un secret à l'aide d'un code temporel:

gcloud

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

gcloud secrets update "SECRET_ID" \
    --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/SECRET_ID?updateMask=expire_time" \
    --request "PATCH" \
    --header "Content-Type: application/json" \
    --header "Authorization: Bearer ACCESS_TOKEN" \
    --data-binary @- <<EOF
{
  "expire_time": "TIMESTAMP"
}
EOF

Mettez à jour le délai d'expiration d'un secret à l'aide d'une durée:

gcloud

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

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

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/SECRET_ID?updateMask=ttl" \
    --request "PATCH" \
    --header "Content-Type: application/json" \
    --header "Authorization: Bearer ACCESS_TOKEN" \
    --data-binary @- <<EOF
{
  "ttl": "DURATION"
}
EOF

Supprimer la date d'expiration d'un secret

gcloud

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

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

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.

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 sur la ressource Secret Secret Manager à des intervalles spécifiques jusqu'à 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.

Étapes suivantes