Limiter l'utilisation des comptes de service

Resource Manager fournit des contraintes pouvant être utilisées dans les règles d'administration pour limiter l'utilisation des comptes de service Cloud Identity and Access Management.

La plupart de ces contraintes déterminent si des comptes de service et d'autres ressources peuvent être créés ou configurés de manière spécifique. Ces contraintes ne sont pas rétroactives. Elles n'affectent pas les comptes de service créés et configurés précédemment.

Avant de commencer

Vous devez être autorisé à modifier les règles d'administration pour définir des contraintes. Par exemple, le rôle orgpolicy.policyAdmin est autorisé à définir des contraintes de règle d'administration. Consultez la page Utiliser des contraintes pour en savoir plus sur la gestion des règles au niveau de l'organisation.

Contraintes booléennes

Les contraintes suivantes sont des types de contrainte booléenne, définies sur "true" ou "false".

Désactiver les attributions automatiques de rôles pour les comptes de service par défaut

Certains services Google Cloud créent automatiquement des comptes de service par défaut. Lorsqu'un compte de service par défaut est créé, le rôle Éditeur (roles/editor) lui est automatiquement attribué sur votre projet.

Pour renforcer la sécurité, nous vous recommandons vivement de désactiver l'attribution automatique des rôles. Pour ce faire, vous pouvez utiliser la contrainte booléenne iam.automaticIamGrantsForDefaultServiceAccounts.

<ph type="x-smartling-placeholder">

</ph> Remarque: Si votre organisation a été créée le 3 mai 2024 ou après, est appliquée par défaut.

Désactiver la création de comptes de service

Vous pouvez utiliser la contrainte booléenne iam.disableServiceAccountCreation pour désactiver la création de comptes de service. Cela vous permet de centraliser la gestion des comptes de service sans restreindre les autres autorisations détenues par vos développeurs pour les projets.

Si vous appliquez cette contrainte dans un projet, certains services Google Cloud ne peuvent pas créer automatiquement de comptes de service par défaut. Par conséquent, si le projet exécute des charges de travail nécessitant d'emprunter l'identité d'un compte de service, il est possible que le projet ne contienne pas de compte de service utilisable par la charge de travail. Pour résoudre ce problème, vous pouvez activer l'emprunt d'identité des comptes de service entre les projets. Lorsque vous activez cette fonctionnalité, vous pouvez créer des comptes de service dans un projet centralisé, puis associer ces comptes de service à des ressources situées dans d'autres projets.

Pour en savoir plus sur l'organisation des comptes de service, consultez Où créer des comptes de service ?

Désactiver la création de clés de compte de service

Vous pouvez utiliser la contrainte booléenne iam.disableServiceAccountKeyCreation pour désactiver la création de clés de compte de service externes. Cela vous permet de contrôler l'utilisation des identifiants à long terme non gérés pour les comptes de service. Lorsque cette contrainte est définie, les identifiants gérés par l'utilisateur ne peuvent pas être créés pour les comptes de service dans les projets affectés par la contrainte.

<ph type="x-smartling-placeholder">

</ph> Remarque: Si votre organisation a été créée le 3 mai 2024 ou après, est appliquée par défaut.

Désactiver l'importation de clé de compte de service

Vous pouvez utiliser la contrainte booléenne iam.disableServiceAccountKeyUpload pour désactiver l'importation de clés publiques externes dans des comptes de service. Lorsque cette contrainte est définie, les utilisateurs ne peuvent pas importer de clés publiques dans les comptes de service de projets affectés par la contrainte.

<ph type="x-smartling-placeholder">

</ph> Remarque: Si votre organisation a été créée le 3 mai 2024 ou après, est appliquée par défaut.

Désactiver l'association de comptes de service à des ressources situées dans d'autres projets

Chaque compte de service est situé dans un projet. Vous pouvez utiliser la contrainte booléenne iam.disableCrossProjectServiceAccountUsage pour empêcher que les comptes de service d'un projet soient associés à des ressources d'autres projets.

Si vous souhaitez autoriser l'utilisation des comptes de service entre plusieurs projets, consultez la page Activer l'emprunt d'identité des comptes de service entre les projets.

Restreindre la suppression des privilèges de projet lorsque des comptes de service sont utilisés entre plusieurs projets

Lorsque vous autorisez l'association de comptes de service d'un projet à des ressources d'autres projets, Cloud IAM ajoute un privilège de projet qui vous empêche de supprimer le projet. Par défaut, toute personne disposant de l'autorisation resourcemanager.projects.updateLiens sur le projet peut supprimer le privilège.

Si vous appliquez la contrainte booléenne iam.restrictCrossProjectServiceAccountLienRemoval, les comptes principaux ne peuvent supprimer le privilège que s'ils disposent de l'autorisation resourcemanager.projects.updateLiens sur l'organisation.

Nous vous recommandons d'appliquer cette contrainte si l'un de vos projets autorise l'emprunt d'identité des comptes de service entre les projets.

Désactiver la création de clusters Workload Identity

Vous pouvez utiliser la contrainte booléenne iam.disableWorkloadIdentityClusterCreation pour exiger que la fonctionnalité Workload Identity de tous les nouveaux clusters Google Kubernetes Engine soit désactivée au moment de leur création. Si vous souhaitez contrôler étroitement l'accès au compte de service dans votre organisation, vous souhaiterez peut-être désactiver Workload Identity en plus de la création de comptes de service et de clés de compte de service.

Les clusters GKE existants pour lesquels Workload Identity est activé ne seront pas affectés et continueront de fonctionner normalement.

Appliquer une contrainte booléenne

Console

Pour définir une règle d'administration qui applique une contrainte permettant de restreindre l'utilisation du compte de service, procédez comme suit :

1. Dans la console Google Cloud, accédez à la page Règles d'administration.

   Accéder à la page Règles d'administration

2. Dans le sélecteur de projet, choisissez l'organisation pour laquelle vous souhaitez limiter l'utilisation des comptes de service.

3. Cliquez sur l'une des contraintes booléennes d'utilisation des comptes de service répertoriées dans cette .

4. Cliquez sur Gérer la règle.

5. Sous Applicable à, sélectionnez Remplacer les règles parentes.

6. Cliquez sur Ajouter une règle.

7. Sous Application, sélectionnez Activé.

8. Pour appliquer la règle, cliquez sur Définir la règle.

gcloud

Les règles peuvent être définies via la Google Cloud CLI.

Pour restreindre l'utilisation du compte de service, exécutez la commande suivante :

gcloud resource-manager org-policies enable-enforce \
    --organization 'ORGANIZATION_ID' \
    BOOLEAN_CONSTRAINT

Où BOOLEAN_CONSTRAINT est la contrainte booléenne que vous souhaitez appliquer.

Pour désactiver l'application forcée, la même commande peut être émise avec

disable-enforce

.

Pour en savoir plus sur l'utilisation de contraintes dans les règles d'administration, consultez la page Utiliser des contraintes.

Exemple de stratégie avec une contrainte booléenne

L'extrait de code suivant présente une règle d'administration qui applique la contrainte booléenne iam.disableServiceAccountCreation, qui empêche la création de comptes de service :

name: organizations/012345678901/policies/iam.disableServiceAccountCreation
spec:
  rules:
  - enforce: true

Contraintes de liste

Les contraintes suivantes sont des types contrainte de liste, définies sur une liste de valeurs.

Prolonger la durée de vie des jetons d'accès OAuth 2.0

Vous pouvez créer un jeton d'accès OAuth 2.0 qui fournit des identifiants éphémères pour un compte de service. Par défaut, la durée de vie maximale d'un jeton d'accès est de 1 heure, soit 3 600 secondes. Toutefois, vous pouvez prolonger la durée de vie maximale à 12 heures. Pour ce faire, identifiez les comptes de service qui ont besoin de jetons d'accès à durée de vie prolongée, puis ajoutez ces comptes de service à une règle d'administration qui comprend la contrainte de liste constraints/iam.allowServiceAccountCredentialLifetimeExtension.

Limiter la durée de vie des clés de compte de service

Une clé de compte de service vous permet une requête en tant que compte de service. Par défaut, les clés de compte de service n'expire jamais. Vous pouvez modifier cette valeur par défaut en définissant un délai d'expiration clés récemment créées dans votre projet, dossier ou organisation.

Attention :Dans certains scénarios, si vous définissez un délai d'expiration pour les clés de compte de service, vous risquez de provoquer une interruption de production ou de désactiver des charges de travail critiques. Avant de définir un délai d'expiration, vérifiez les délais d'expiration pour les clés gérées par l'utilisateur ; Vérifiez que la définition d'un délai d'expiration est adaptée à votre cas d'utilisation.

Pour définir un délai d'expiration, utilisez l'constraints/iam.serviceAccountKeyExpiryHours pour spécifier le nombre d'heures pendant lesquelles une clé nouvellement créée est valide. Passé ce délai, la clé du compte de service expire et vous pouvez ne l'utilisent plus.

Cette contrainte de liste accepte les valeurs ALLOW suivantes : il n'accepte pas Valeurs DENY. Nous vous recommandons d'utiliser le délai d'expiration le plus court a besoin:

• 1h: 1 heure
• 8h: 8 heures
• 24h: 24 heures (1 jour)
• 168h: 168 heures (7 jours)
• 336h: 336 heures (14 jours)
• 720h: 720 heures (30 jours)
• 1440h: 1 440 heures (60 jours)
• 2160h: 2 160 heures (90 jours)

Impossible de fusionner la contrainte constraints/iam.serviceAccountKeyExpiryHours avec une stratégie parente. Pour appliquer cette contrainte, vous devez soit remplacer qui héritent de la stratégie parente.

Spécifier les fournisseurs d'identité externes autorisés

Si vous utilisez la fédération d'identité de charge de travail qui permet aux identités externes d'accéder aux ressources Google Cloud, vous pouvez spécifier les fournisseurs d'identité externes autorisés. Par défaut, tous les fournisseurs sont autorisés. Pour définir une limite, utilisez la contrainte de liste constraints/iam.workloadIdentityPoolProviders afin de spécifier des URI pour les fournisseurs autorisés, en utilisant les formats suivants :

• Amazon Web Services (AWS) : https://sts.amazonaws.com

  Pour limiter les comptes AWS autorisés, utilisez la contrainte de liste constraints/iam.workloadIdentityPoolAwsAccounts décrite sur cette page.

• Microsoft Azure : https://sts.windows.net/azure-tenant-id

• Autres fournisseurs d'identité compatibles avec OpenID Connect (OIDC) : utilisez l'URI d'émetteur de votre fournisseur d'identité.

Spécifier les comptes AWS autorisés

Si vous utilisez la fédération d'identité de charge de travail qui permet aux identités externes d'accéder aux ressources Google Cloud, vous pouvez spécifier les comptes AWS autorisés à accéder à vos ressources. Par défaut, les charges de travail de n'importe quel compte AWS sont autorisées à accéder à vos ressources Google Cloud. Pour limiter les comptes AWS autorisés, utilisez la contrainte de liste constraints/iam.workloadIdentityPoolAwsAccounts pour spécifier une liste d'ID de comptes autorisés.

Désactiver automatiquement les clés de compte de service exposées

Google Cloud détecte parfois qu'une clé de compte de service particulière a été exposés, par exemple, il peut détecter une clé dans un dépôt public. À spécifier ce que Google Cloud fait avec ces clés, utilisez le Contrainte de liste iam.serviceAccountKeyExposureResponse.

Important :Google Cloud ne garantit pas la détection exposées des clés. Pour minimiser l'exposition des clés et l'effet des clés exposées, procédez comme suit : les bonnes pratiques de gestion des comptes de service clés.

Cette contrainte de liste accepte les valeurs ALLOW suivantes : il n'accepte pas Valeurs DENY.

• DISABLE_KEY: si Google Cloud détecte une clé divulguée, il désactiver automatiquement la clé. Il crée également un événement Cloud Audit Logs et envoie une notification concernant la clé divulguée aux propriétaires du projet et aux administrateurs des contacts.

  Remarque :À compter du 16 juin 2024, si vous ne définissez pas de valeur pour cette contrainte, Google Cloud adoptera par défaut le comportement décrit pour DISABLE_KEY.

• WAIT_FOR_ABUSE: Google Cloud ne désactivera pas les clés exposées de manière proactive. Toutefois, Google Cloud peut toujours désactiver les clés divulguées si elles sont utilisées d'une manière qui nuit à la plate-forme. Que le groupe exposé est désactivée, Google Cloud crée un événement Cloud Audit Logs et envoie une notification concernant la clé divulguée aux propriétaires du projet et aux administrateurs des contacts.

Les événements Cloud Audit Logs sont créés lorsque Google Cloud détecte un une clé divulguée ou désactive une clé.

• Lorsque Google Cloud détecte la fuite d'une clé, un abus se produit dans les journaux d'événements d'utilisation abusive.

• Lorsque Google Cloud désactive une clé, les journaux d'audit contiennent l'option de désactivation action par compte principal [e-mail].

Nous vous recommandons vivement de définir cette contrainte sur DISABLE_KEY. Paramètre cette contrainte à WAIT_FOR_ABUSE augmente le risque de fuite de clés mal utilisés.

Si vous décidez de définir la contrainte sur WAIT_FOR_ABUSE, nous vous recommandons vous vous abonnez aux événements Cloud Audit Logs, vérifiez vos coordonnées de sécurité, dans les contacts essentiels, et assurez-vous que vos contacts de sécurité répondent aux notifications dans les meilleurs délais.

Impossible de fusionner la contrainte iam.serviceAccountKeyExposureResponse avec un une stratégie parente. Pour appliquer cette contrainte, vous devez remplacer la stratégie parente.

Définir une contrainte de liste

Console

Pour définir une règle d'administration contenant une contrainte de liste, procédez comme suit :

1. Dans la console Google Cloud, accédez à la page Règles d'administration.

   Accéder à la page Règles d'administration

2. Dans le sélecteur de projet, choisissez la ressource pour laquelle vous souhaitez pour définir la règle d'administration.

3. Sur la page Règles d'administration, sélectionnez une contrainte dans la liste. La page Détails de la règle correspondant à cette contrainte s'affiche.

4. Pour mettre à jour la règle d'administration pour cette ressource, cliquez sur Gérer la règle

5. Sous Application des règles, sélectionnez une option d'application :

   • Pour fusionner et évaluer vos règles d'administration ensemble, sélectionnez Fusionner avec le parent. Pour en savoir plus sur l'héritage et les la hiérarchie des ressources, consultez Comprendre l'évaluation hiérarchique
   • Pour remplacer les règles héritées d'une ressource parente, sélectionnez Remplacer.

6. Cliquez sur Ajouter une règle.

7. Sous Valeurs de règles, sélectionnez Personnalisé.

8. Sous Type de règle, sélectionnez Autoriser.

9. Sous Valeurs personnalisées, saisissez la première valeur de la contrainte de liste.

   1. Si vous souhaitez ajouter d'autres valeurs, cliquez sur Ajouter une valeur pour créer plusieurs lignes et ajouter une valeur à chaque ligne.

10. Lorsque vous avez terminé d'ajouter des valeurs, cliquez sur OK.

11. Pour appliquer la règle, cliquez sur Définir la règle.

gcloud

Les règles peuvent être définies via la Google Cloud CLI:

gcloud resource-manager org-policies allow \
    CONSTRAINT_NAME \
    VALUE_1 [VALUE_N ...] \
    --organization=ORGANIZATION_ID \

Remplacez les valeurs suivantes :

• CONSTRAINT_NAME : nom de la contrainte de liste. Exemple : constraints/iam.allowServiceAccountCredentialLifetimeExtension.
• VALUE_1, VALUE_N... : valeurs de la contrainte de liste.

Pour en savoir plus sur l'utilisation de contraintes dans les règles d'administration, consultez la page Utiliser des contraintes.

Exemple de stratégie avec une contrainte de liste

L'extrait de code suivant présente une règle d'administration appliquant la contrainte de liste iam.allowServiceAccountCredentialLifetimeExtension, qui prolonge la durée de vie maximale des jetons d'accès OAuth 2.0 pour les comptes de service répertoriés :

name: organizations/012345678901/policies/iam.allowServiceAccountCredentialLifetimeExtension
spec:
  rules:
  - values:
      allowedValues:
      - SERVICE_ACCOUNT_ADDRESS

Messages d'erreur

Désactiver la création de comptes de service

Si la contrainte iam.disableServiceAccountCreation est appliquée, la création de compte de service échoue et l'erreur suivante s'affiche :

FAILED_PRECONDITION: Service account creation is not allowed on this project.

Désactiver la création de clés de compte de service

Si la contrainte iam.disableServiceAccountKeyCreation est appliquée, la création de compte de service échoue et l'erreur suivante s'affiche :

FAILED_PRECONDITION: Key creation is not allowed on this service account.

Désactiver la création de clusters Workload Identity

Si iam.disableWorkloadIdentityClusterCreation est appliqué, la création d'un cluster GKE pour lequel Workload Identity est activé échoue, avec l'erreur suivante :

FAILED_PRECONDITION: Workload Identity is disabled by the organization
policy constraints/iam.disableWorkloadIdentityClusterCreation. Contact your
administrator to enable this feature.

Résoudre les problèmes connus

Comptes de service par défaut

L'application de la contrainte iam.disableServiceAccountCreation empêche la création de comptes de service dans ce projet. Cette limitation concerne également les services Google Cloud qui, lorsqu'ils sont activés, créent automatiquement des comptes de service par défaut dans le projet, tels que :

• Compute Engine
• GKE
• App Engine
• Dataflow

Si la contrainte iam.disableServiceAccountCreation est appliquée, toute tentative d'activation de ces services échoue, car leurs comptes de service par défaut ne peuvent pas être créés.

Pour remédier à ce problème :

1. Supprimez temporairement la contrainte iam.disableServiceAccountCreation.
2. Activez les services souhaités.
3. Créez tout autre compte de service souhaité.
4. Réappliquez la contrainte.