Gérer les liaisons d'accès

Cette page explique comment gérer vos liaisons d'accès existantes, qui définissent comment les règles d'accès sont appliquées à vos groupes d'utilisateurs. Vous pouvez afficher, modifier et supprimer ces liaisons selon vos besoins. Les liaisons d'accès déterminent comment les niveaux d'accès et les contrôles de session sont appliqués à un groupe d'utilisateurs.

Pour savoir comment créer des liaisons d'accès et obtenir plus d'informations sur les niveaux d'accès et les contrôles de session, consultez Appliquer des règles à des groupes d'utilisateurs avec des liaisons d'accès.

Afficher les liaisons d'accès

Une fois que les liaisons d'accès sont créées pour un groupe d'utilisateurs, l'accès à la Google Cloud console et aux Google Cloud API est contrôlé basé sur le niveau d'accès associé.

Vous pouvez afficher les détails de la liaison d'accès que vous avez créée, la modifier ou la supprimer.

Console

  1. Dans la Google Cloud console, accédez à la page Access Context Manager.

    Accéder à Access Context Manager

  2. Si vous y êtes invité, sélectionnez un projet. La liste des liaisons d'accès s'affiche sur la page Access Context Manager.

gcloud

  • Pour afficher toutes les liaisons d'accès, exécutez la commande suivante :

      gcloud access-context-manager cloud-bindings list \
       --organization ORG_ID
    

    ORG_ID : ID de votre organisation. Si la propriété access-context-manager/organization n'a pas été définie, remplacez ORG_ID dans l'indicateur facultatif --organization par l'ID de l'organisation que vous avez utilisé lors de la création du rôle GcpAccessAdmin.

  • Pour afficher les détails d'une liaison d'accès, exécutez la commande suivante :

      gcloud access-context-manager cloud-bindings describe \
      --binding=BINDING_ID
    

    BINDING_ID est l'ID de la liaison d'accès ou l'identifiant complet de la liaison d'accès.

API

  • Afficher toutes les liaisons d'accès :

    Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :

    • ORG_ID est l'ID de l'organisation que vous avez utilisé lors de la création du rôle GcpAccessAdmin. Si la propriété access-context-manager/organization n'a pas été définie, remplacez ORG_ID dans l'indicateur facultatif --organization par l'ID de l'organisation que vous avez utilisé lors de la création du rôle GcpAccessAdmin.

    Méthode HTTP et URL :

    GET https://accesscontextmanager.googleapis.com/v1/organizations/ORG_ID/gcpUserAccessBindings

    Pour envoyer votre requête, choisissez l'une des options suivantes :

    curl

    Exécutez la commande suivante :

    curl -X GET \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    "https://accesscontextmanager.googleapis.com/v1/organizations/ORG_ID/gcpUserAccessBindings"

    PowerShell

    Exécutez la commande suivante :

    $cred = gcloud auth print-access-token
    $headers = @{ "Authorization" = "Bearer $cred" }

    Invoke-WebRequest `
    -Method GET `
    -Headers $headers `
    -Uri "https://accesscontextmanager.googleapis.com/v1/organizations/ORG_ID/gcpUserAccessBindings" | Select-Object -Expand Content

    Vous devriez recevoir une réponse JSON de ce type :

    
    {
      "name": string,
      "groupKey": string,
      "accessLevels": [
        string
      ]
      "dryRunAccessLevels": [
      string
      ]
    }
    
    

  • Afficher les détails d'une liaison d'accès :

    Méthode HTTP et URL :

    GET https://accesscontextmanager.googleapis.com/v1/BINDING_ID

    Pour envoyer votre requête, choisissez l'une des options suivantes :

    curl

    Exécutez la commande suivante :

    curl -X GET \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    "https://accesscontextmanager.googleapis.com/v1/BINDING_ID"

    PowerShell

    Exécutez la commande suivante :

    $cred = gcloud auth print-access-token
    $headers = @{ "Authorization" = "Bearer $cred" }

    Invoke-WebRequest `
    -Method GET `
    -Headers $headers `
    -Uri "https://accesscontextmanager.googleapis.com/v1/BINDING_ID" | Select-Object -Expand Content

    Vous devriez recevoir une réponse JSON de ce type :

    
    {
      "name": "organizations/427391306986/gcpUserAccessBindings/aAQS-YRSviv2hC12vZFUN3AZzvwa6KV2hJ89iMytB_nHUcT1l",
      "groupKey": "045jfvxd0ybeul8",
      "accessLevels": [
        "accessPolicies/305009197125/accessLevels/device_lock"
      ],
      "dryRunAccessLevels": [
        "accessPolicies/305009197125/accessLevels/another"
      ]
    }
    
    

Mettre à jour une liaison d'accès

Vous pouvez mettre à jour une liaison d'accès pour effectuer les opérations suivantes :

  • Ajouter, supprimer ou modifier les applications auxquelles une règle est appliquée.
  • Modifier les niveaux d'accès d'une application au sein d'un groupe d'utilisateurs.
  • Ajouter un niveau d'accès en mode test ou promouvoir un niveau existant en niveau actif.

Console

  1. Dans la Google Cloud console, accédez à la page Access Context Manager.

    Accéder à Access Context Manager

  2. Si vous y êtes invité, sélectionnez un projet.

  3. Sur la page Access Context Manager, sélectionnez une liaison d'accès, puis cliquez sur Modifier pour la mettre à jour.

Vous ne pouvez pas mettre à jour les liaisons d'accès avec des niveaux d'accès en mode test ou des contrôles de session dans la Google Cloud console.

gcloud

  1. Créez un fichier de liaison YAML.

    gcloud access-context-manager cloud-bindings update
      --binding ACCESS_BINDING
      --binding-file BINDING_FILE_PATH
    [  --level DEFAULT_ACCESS_LEVEL ]
    [  --dry-run-level DEFAULT_DRY_RUN_ACCESS_LEVEL           ]
    [  --session-length=DEFAULT_SESSION_LENGTH                ]
    [  --session-reauth-method=DEFAULT_SESSION_REAUTH_METHOD  ]
    

    Remplacez les éléments suivants :

    • ACCESS_BINDING est au format organizations/ORG_ID/gcpUserAccessBindings/ACCESS_BINDING_NAME.
    • BINDING_FILE_PATH : chemin d'accès au fichier YAML contenant le schéma de liaison d'accès. Le fichier de liaison n'est compatible qu'avec scopedAccessSettings.
    • DEFAULT_ACCESS_LEVEL : nom facultatif du niveau d'accès, au format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Remplacez POLICY_ID par l'ID de la règle d'accès et ACCESS_LEVEL_NAME par le nom du niveau d'accès.
    • DEFAULT_DRY_RUN_ACCESS_LEVEL_2 : nom facultatif du niveau d'accès au format `accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME`. Incluez cet indicateur pour appliquer le niveau d'accès en mode test spécifié à toutes les applications par défaut s'il n'est pas spécifié dans le fichier YAML.
    • DEFAULT_SESSION_LENGTH : durée de session facultative au format horaire, par exemple 15h pour 15 heures ou 2h pour deux heures.
    • DEFAULT_SESSION_REAUTH_METHOD : méthode facultative permettant d'inviter les utilisateurs à vérifier à nouveau leur identité. Elle doit être l'une des suivantes :
      • LOGIN: appliquer la connexion standard, qui peut inclure l'MFA ou d'autres facteurs définis par Workspace.
      • PASSWORD : n'exiger qu'un mot de passe, même si d'autres facteurs sont définis. Si les mots de passe sont gérés à l'aide d'un fournisseur d'identité externe, les utilisateurs sont redirigés vers le fournisseur d'identité. Si la session du fournisseur d'identité est active, les utilisateurs sont réauthentifiés de manière implicite. Si le fournisseur d'identité n'est pas actif, les utilisateurs doivent se connecter via le fournisseur d'identité.
      • SECURITY_KEY : exiger une clé de sécurité matérielle.

    Fonctionnement combiné des arguments --level et --binding-file

    • Si vous n'utilisez que --binding-file, seules les applications du fichier se voient appliquer les règles.
    • Si vous n'utilisez que --level, le niveau d'accès s'applique à toutes les applications.
    • Si vous utilisez les deux, les règles sont combinées. La valeur --level s'applique à toutes les applications, tandis que les règles du fichier YAML spécifié par --binding-file ne s'appliquent qu'aux applications telles qu'elles sont définies dans le fichier.

    Utiliser des contrôles de session

    • Pour définir des contrôles de session par défaut pour toutes les applications, utilisez --session-length et --session-reauth-method.
    • Si vous définissez également des contrôles de session dans le fichier YAML, ces contrôles de session remplacent les paramètres par défaut pour ces applications spécifiques.
    • Vous devez utiliser --session-length et --session-reauth-method ensemble.

    Pour supprimer un niveau d'accès par défaut ou un niveau d'accès en mode test par défaut, fournissez une chaîne vide, par exemple --level= ou --dry-run-level=. Lorsque ces arguments ne sont pas fournis, la commande update n'apporte aucune modification.

    Pour supprimer un contrôle de session, définissez --session-length=0.

API

  1. Créez un corps JSON.

    {
      "accessLevels": [
        "DEFAULT_ACCESS_LEVEL"
      ],
      "scopedAccessSettings": [
        {
          "scope": {
            "clientScope": {
              "restrictedClientApplication": {
                "clientId": "CLIENT_ID"
              }
            }
          },
          "activeSettings": {
            "accessLevels": [
              "ACCESS_LEVEL_A"
            ],
            "sessionSettings": [
              {
                "sessionLength": "SESSION_LENGTH",
                "sessionReauthMethod": "SESSION_REAUTH_METHOD",
                "sessionLengthEnabled": true
              }
            ]
        }
        },
        {
          "scope": {
            "clientScope": {
              "restrictedClientApplication": {
                "name": "CLIENT_NAME"
              }
            },
            "activeSettings": {
              "accessLevels": [
                "ACCESS_LEVEL_C"
              ]
            }
          }
        }
      ]
    }
    

    Remplacez les éléments suivants :

    • DEFAULT_ACCESS_LEVEL : nom facultatif du niveau d'accès, au format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Remplacez POLICY_ID par l'ID de la règle d'accès et ACCESS_LEVEL_NAME par le nom du niveau d'accès.
    • CLIENT_ID : ID client OAuth. Vous devez utiliser clientId lorsqu'une application contient sessionSettings.
    • ACCESS_LEVEL_A : nom du niveau d'accès au format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • SESSION_LENGTH : durée de la session au format ISO 8601, par exemple 30m pour 30 minutes ou 2h pour deux heures.
    • SESSION_REAUTH_METHOD : méthode facultative permettant d'inviter les utilisateurs à vérifier à nouveau leur identité. Elle doit être l'une des suivantes :

      • LOGIN: appliquer la connexion standard, qui peut inclure l'MFA ou d'autres facteurs définis par Workspace.
      • PASSWORD: n'exiger qu'un mot de passe, même si d'autres facteurs sont définis. Si les mots de passe sont gérés à l'aide d'un fournisseur d'identité externe, les utilisateurs sont redirigés vers le fournisseur d'identité. Si la session du fournisseur d'identité est active, les utilisateurs sont réauthentifiés de manière implicite. Si le fournisseur d'identité n'est pas actif, les utilisateurs doivent se connecter via le fournisseur d'identité.
      • SECURITY_KEY : exiger une clé de sécurité matérielle.
    • CLIENT_NAME : nom du client. Si l'application contient sessionSettings, vous ne pouvez pas utiliser le nom du client. Utilisez plutôt l'ID client OAuth.

    • ACCESS_LEVEL_C : nom du niveau d'accès au format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

  2. Envoyez la requête PATCH.

    PATCH https://accesscontextmanager.googleapis.com/v1/ACCESS_BINDING?fieldMask=FIELDMASK
    

    Remplacez les éléments suivants :

    • ACCESS_BINDING est au format organizations/ORG_ID/gcpUserAccessBindings/ACCESS_BINDING_NAME.
    • FIELD_MASK : liste obligatoire, séparée par des virgules, des champs que vous souhaitez mettre à jour. Cela indique à l'API les parties de la liaison d'accès à modifier.

    fieldMask doit contenir les clés JSON de premier niveau dans le corps de la requête que vous souhaitez mettre à jour, qui peuvent contenir accessLevels, dryRunAccessLevels et scopedAccessSettings.

    En cas de succès, vous devriez recevoir une représentation de l'objet JSON. En cas de problème, vous recevez un message d'erreur.

Supprimer des liaisons d'accès

Console

  1. Dans la Google Cloud console, accédez à la page Access Context Manager.

    Accéder à Access Context Manager

  2. Si vous y êtes invité, sélectionnez un projet.

  3. Sur la page Access Context Manager, sélectionnez une liaison d'accès, puis cliquez sur Supprimer.

gcloud

   gcloud access-context-manager cloud-bindings delete \
       --binding ACCESS_BINDING

Remplacez les éléments suivants :

  • ACCESS_BINDING est au format organizations/ORG_ID/gcpUserAccessBindings/ACCESS_BINDING_NAME.
  • ACCESS_BINDING_NAME est la chaîne unique renvoyée pour l'identifiant name lors de la création de la liaison d'accès.

API

Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :

  • ACCESS_BINDING_NAME est la chaîne unique renvoyée pour l'identifiant name lors de la création de la liaison d'accès.

Méthode HTTP et URL :

DELETE https://accesscontextmanager.googleapis.com/v1/ACCESS_BINDING_NAME

Pour envoyer votre requête, choisissez l'une des options suivantes :

curl

Exécutez la commande suivante :

curl -X DELETE \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
"https://accesscontextmanager.googleapis.com/v1/ACCESS_BINDING_NAME"

PowerShell

Exécutez la commande suivante :

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
-Method DELETE `
-Headers $headers `
-Uri "https://accesscontextmanager.googleapis.com/v1/ACCESS_BINDING_NAME" | Select-Object -Expand Content

Vous devriez recevoir un code d'état indiquant le succès de l'opération (2xx), ainsi qu'une réponse vide.