Comme tout compte principal, un compte de service peut s'authentifier auprès de Google, obtenir un jeton d'accès OAuth 2.0 et appeler les API Google. Toutefois, ce processus fonctionne différemment pour les comptes de service et pour les utilisateurs.
Les comptes de service s'authentifient en effectuant l'une des opérations suivantes :
- Obtenir des identifiants éphémères
- Utiliser une clé de compte de service pour signer un jeton Web JSON (JWT) et l'échanger contre un jeton d'accès
Identifiants de compte de service à court terme
Le moyen le plus sécurisé de s'authentifier en tant que compte de service consiste à obtenir des identifiants éphémères pour le compte de service sous la forme d'un jeton d'accès OAuth 2.0. Par défaut, ces jetons expirent au bout d'une heure.
Les identifiants de compte de service éphémères sont utiles pour les scénarios dans lesquels vous devez accorder un accès limité aux ressources des comptes de service de confiance. Ils présentent également moins de risques que les identifiants longue durée, tels que les clés de compte de service.
Dans la plupart des cas, ces identifiants sont obtenus automatiquement. Vous n'avez pas besoin de les créer ni de les gérer vous-même. Voici quelques exemples :
- Si vous exécutez une commande Google Cloud CLI et incluez l'option
--impersonate-service-account, gcloud CLI crée des identifiants éphémères pour le compte de service et exécute la commande avec ces identifiants. Si vous associez un compte de service à une instance de machine virtuelle (VM) Compute Engine, les charges de travail de cette instance peuvent utiliser les bibliothèques clientes Cloud pour accéder aux services Google Cloud. Les bibliothèques clientes Cloud utilisent les identifiants par défaut de l'application pour obtenir des identifiants éphémères pour le compte de service.
Pour en savoir plus sur ce processus, consultez la page Authentifier des applications à l'aide des identifiants du compte de service.
Si vous avez configuré la fédération d'identité de charge de travail, les bibliothèques clientes Cloud peuvent utiliser les identifiants de votre fournisseur d'identité pour générer des identifiants de compte de service éphémères.
Vous pouvez également utiliser l'API Service Account Credentials pour créer manuellement des identifiants éphémères. Par exemple, vous pouvez créer un service qui fournit aux utilisateurs des identifiants de compte de service éphémères pour leur permettre d'accéder temporairement aux ressources Google Cloud.
L'API Service Account Credentials peut créer les types d'identifiants suivants :
- Jetons d'accès OAuth 2.0
- Jetons d'identification OpenID Connect (OIDC)
- Jetons Web JSON (JWT) autosignés
- Blobs binaires autosignés
Pour plus d'informations, consultez la page Créer des identifiants de compte de service éphémères.
Interpréter les journaux d'audit
Les journaux d'audit Cloud vous aident à répondre à des questions telles que "Qui a fait quoi, où et quand ?" pour vos ressources Google Cloud.
Lorsque vous utilisez des identifiants éphémères pour usurper l'identité d'un compte de service, la plupart des services Google Cloud créent des entrées de journal indiquant les identités suivantes :
- Compte de service dont l'identité est empruntée par les identifiants éphémères
- Identité ayant créé les identifiants éphémères
Vous pouvez utiliser ces entrées de journal pour identifier le compte principal qui a créé les identifiants éphémères, ainsi que le compte de service dont l'identité a été empruntée.
Pour obtenir des exemples d'entrées de journal d'audit indiquant l'usurpation d'identité d'un compte de service, consultez la section Usurper l'identité d'un compte de service pour accéder à Google Cloud.
Auto-emprunt d'identité
L'auto-emprunt d'identité se produit lorsque vous utilisez les identifiants d'un compte de service pour générer un nouvel identifiant pour le compte de service.
L'API Service Account Credentials interdit les types d'auto-emprunt d'identité suivants :
Utiliser un identifiant éphémère pour un compte de service afin de générer un nouveau jeton d'accès pour le compte de service.
Les jetons Web JSON (JWT, JSON Web Tokens) autosignés font exception à cette règle. Vous pouvez utiliser un jeton JWT autosigné pour un compte de service afin de générer un nouveau jeton d'accès pour le compte de service.
Utiliser un identifiant éphémère pour un compte de service afin de signer un objet binaire (blob) ou un jeton JWT pouvant être utilisé pour appeler les API suivantes :
Google Cloud interdit ce type d'auto-emprunt d'identité, car il permet aux utilisateurs malveillants d'actualiser indéfiniment des jetons volés.
Si vous essayez d'utiliser l'auto-emprunt d'identité de l'une des manières interdites, vous pouvez rencontrer l'erreur suivante :
FAILED_PRECONDITION: You can't create a token for the same service account that you used to authenticate the request.
Si vous rencontrez cette erreur, essayez d'utiliser d'autres identifiants pour générer les nouveaux identifiants éphémères pour votre compte de service, par exemple les identifiants de l'utilisateur final ou ceux d'un autre compte de service.
Clés de compte de service
Chaque compte de service est associé à une paire de clés RSA publique/privée. L'API Service Account Credentials utilise cette paire de clés interne pour créer des identifiants de compte de service éphémères, et pour signer des blobs et des jetons Web JSON (JWT). Cette paire de clés est appelée paire de clés gérée par Google.
Vous pouvez également créer plusieurs paires de clés RSA publiques/privées, appelées paires de clés gérées par l'utilisateur, et utiliser la clé privée pour vous authentifier auprès des API Google. Cette clé privée est appelée clé de compte de service.
Paires de clés gérées par Google
Les paires de clés gérées par Google sont utilisées par l'API Service Account Credentials ainsi que par les services Google Cloud tels qu'App Engine et Compute Engine pour générer des identifiants de courte durée pour les comptes de service.
Les clés gérées par Google qui sont activement utilisées pour la signature sont régulièrement alternées conformément aux bonnes pratiques de sécurité. Le processus de rotation est probabiliste. L'utilisation de la nouvelle clé augmentera et diminuera progressivement au cours de la durée de vie de la clé.
La clé privée d'une paire de clés gérée par Google est toujours conservée à titre de caution et vous ne pouvez jamais y accéder directement.
La clé publique d'une paire de clés gérée par Google est accessible au public. Ainsi, quiconque peut valider les signatures créées avec la clé privée. Vous pouvez accéder à la clé publique dans différents formats :
- Certificat X.509 :
https://www.googleapis.com/service_accounts/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL - Clé Web JSON (JWK) :
https://www.googleapis.com/service_accounts/v1/jwk/SERVICE_ACCOUNT_EMAIL - Format brut :
https://www.googleapis.com/service_accounts/v1/metadata/raw/SERVICE_ACCOUNT_EMAIL
Si vous téléchargez et mettez en cache la clé publique, nous vous recommandons de la mettre en cache pendant 24 heures maximum afin de vous assurer que vous disposez toujours de la clé actuelle. Quelle que soit la date à laquelle vous avez récupéré la clé publique, celle-ci reste valide pendant au moins 24 heures après sa récupération.
Paires de clés gérées par l'utilisateur
Vous pouvez créer des paires de clés gérées par l'utilisateur pour un compte de service, puis vous authentifier avec les API Google à l'aide de la clé privée de chaque paire de clés. Cette clé privée est appelée clé de compte de service.
Les bibliothèques clientes Cloud peuvent utiliser des clés de compte de service pour obtenir automatiquement un jeton d'accès OAuth 2.0. Vous pouvez également utiliser une clé de compte de service pour signer manuellement un jeton JWT, puis demander un jeton d'accès à l'aide du jeton JWT signé. Pour plus d'informations, consultez la page Utiliser OAuth 2.0 pour les applications de serveur à serveur.
Chaque compte de service peut comporter jusqu'à 10 clés de compte de service. Google ne stocke que la partie publique d'une paire de clés gérée par l'utilisateur.
Il existe plusieurs façons de créer une paire de clés gérée par l'utilisateur pour un compte de service :
- Utilisez l'API Cloud IAM pour créer automatiquement une paire de clés gérées par l'utilisateur. Google génère une paire de clés publique/privée ; stocke uniquement la clé publique ; et vous renvoie la clé privée.
- Créez vous-même une paire de clés gérée par l'utilisateur, puis importez uniquement la clé publique. Google ne voit jamais la clé privée.
Les clés gérées par l'utilisateur constituent des identifiants extrêmement puissants. Pour limiter l'utilisation de clés gérées par l'utilisateur, vous pouvez appliquer les contraintes liées aux règles d'administration suivantes à une organisation, un projet ou un dossier :
constraints/iam.disableServiceAccountKeyCreation: empêche les comptes principaux de créer des clés de compte de service gérées par l'utilisateur.constraints/iam.disableServiceAccountKeyUpload: empêche les comptes principaux d'importer une clé publique pour un compte de service.
Si vous appliquez ces contraintes parce que vous utilisez la fédération d'identité de charge de travail, envisagez d'utiliser les contraintes de règles d'administration pour la fédération d'identité de charge de travail afin de spécifier quels fournisseurs d'identité sont autorisés.
Délais d'expiration des clés gérées par l'utilisateur
Par défaut, lorsque vous créez une clé de compte de service gérée par l'utilisateur, la clé n'expire jamais. Vous pouvez modifier cette valeur par défaut en définissant un délai d'expiration pour toutes les clés nouvellement créées dans votre projet, dossier ou organisation. Un délai d'expiration spécifie le nombre d'heures pendant lesquelles une clé nouvellement créée est valide.
Utilisez des délais d'expiration lorsque vous avez besoin d'un accès temporaire à un système nécessitant une clé de compte de service. Par exemple, utilisez les délais d'expiration lorsque vous effectuez les opérations suivantes :
- Développement du code dans un environnement hors production pour une application qui ne peut s'authentifier qu'avec des clés de compte de service
- Utiliser un outil tiers ne pouvant s'authentifier qu'avec les clés de compte de service
Évitez d'utiliser les délais d'expiration dans les scénarios suivants :
- Charges de travail de production. En production, une clé de compte de service arrivée à expiration peut entraîner une panne accidentelle. Utilisez plutôt des clés qui n'expirent pas et gérez leur cycle de vie avec la rotation des clés.
- Charges de travail hors production nécessitant un accès permanent, telles qu'un pipeline d'intégration continue (CI).
- Systèmes de rotation des clés qui empêchent l'utilisation d'une clé après un certain temps. Pour en savoir plus sur les stratégies de rotation des clés recommandées, consultez la page Rotation des clés de compte de service.
Pour éviter les pannes, nous vous recommandons de ne pas définir de délai d'expiration, sauf si la contrainte de règle d'administration constraints/iam.disableServiceAccountKeyCreation est appliquée pendant une période prolongée. Lorsque vous définissez un délai d'expiration, vous devez également cesser d'appliquer la contrainte constraints/iam.disableServiceAccountKeyCreation. Pour en savoir plus sur cette contrainte, consultez la section Limiter la durée de vie des clés de compte de service.
Pour définir un délai d'expiration, procédez comme suit :
- Identifiez le projet, le dossier ou l'organisation dans lequel vous souhaitez définir un délai d'expiration pour les clés de compte de service.
- Ajoutez une règle d'administration qui applique la contrainte
constraints/iam.serviceAccountKeyExpiryHours. Après l'application de cette contrainte dans votre projet, dossier ou organisation, le délai d'expiration s'applique à toutes les clés de compte de service nouvellement créées dans cette ressource parente. Les clés existantes ne sont pas concernées.
Les délais d'expiration sont mesurés en heures. Nous vous recommandons d'utiliser des délais d'expiration courts, par exemple 8 heures, 24 heures (un jour) ou 168 heures (sept jours). Des délais d'expiration courts permettent de vous assurer que votre équipe dispose d'un processus bien éprouvé de mise à jour des clés. Commencez par le délai d'expiration le plus court qui répond à vos besoins et augmentez-le uniquement si cela devient nécessaire.