Réduction des champs d'application des autorisations pour les identifiants éphémères

Cette page explique comment réduire les champs d'application ou restreindre les autorisations de Cloud Identity and Access Management (Cloud IAM) que peuvent utiliser les identifiants éphémères.

Pour réduire les champs d'application des autorisations, vous définissez une limite d'accès aux identifiants qui spécifie les ressources auxquelles les identifiants éphémères peuvent accéder, ainsi qu'une limite supérieure des autorisations disponibles pour chaque ressource. Vous pouvez ensuite créer des identifiants éphémères, puis les remplacer par des identifiants qui respectent les limites d'accès aux identifiants.

L'exemple suivant illustre une simple limite d'accès aux identifiants. Elle s'applique au bucket Cloud Storage example-bucket et définit la limite supérieure des autorisations incluses dans le rôle Lecteur des objets de l'espace de stockage (roles/storage.objectViewer) :

{
      "accessBoundaryRules": [
        {
          "availablePermissions": [
            "inRole:roles/storage.objectViewer"
          ],
          "availableResource": "//storage.googleapis.com/projects/_/buckets/example-bucket"
        }
      ]
    }

Si vous souhaitez octroyer aux membres un ensemble distinct d'autorisations pour chaque session, l'utilisation des limites d'accès aux identifiants peut s'avérer plus efficace que la création de nombreux comptes et l'octroi d'un ensemble différent de rôles à chaque compte de service. Par exemple, si l'un de vos clients doit accéder aux données Cloud Storage que vous contrôlez, vous pouvez créer un compte de service pouvant accéder à chaque bucket Cloud Storage que vous possédez, puis appliquer une limite d'accès aux identifiants qui autorise uniquement l'accès au bucket contenant les données de votre client.

Avant de commencer

Avant d'utiliser les limites d'accès aux identifiants, assurez-vous que vous remplissez les conditions suivantes :

  • Vous devez réduire les champs d'application des autorisations pour Cloud Storage uniquement, et non pour les autres services Google Cloud.

    Si vous devez réduire les champs d'application des autorisations pour d'autres services Google Cloud, vous pouvez créer plusieurs comptes de service et attribuer un ensemble de rôles différent à chaque compte de service.

  • Vous devez réduire les champs d'application des autorisations au niveau du bucket, et non au niveau de l'objet.

  • Vous utilisez un accès uniforme au niveau du bucket pour gérer l'accès à vos ressources Cloud Storage.

  • Vous pouvez utiliser les jetons d'accès OAuth 2.0 pour l'authentification. Les autres types d'identifiants éphémères ne sont pas compatibles avec les limites d'accès aux identifiants.

Création d'informations d'identification éphémères aux champs d'application limités

Pour créer un jeton d'accès OAuth 2.0 avec des autorisations aux champs d'application limités, procédez comme suit :

  1. Attribuez les rôles Cloud IAM appropriés à un compte utilisateur ou un compte de service.
  2. Définissez une limite d'accès aux identifiants qui définit une limite supérieure des autorisations disponibles pour l'utilisateur ou le compte de service.
  3. Créez un jeton d'accès OAuth 2.0 pour l'utilisateur ou le compte de service.
  4. Remplacez le jeton d'accès OAuth 2.0 par un nouveau jeton respectant les limites d'accès aux identifiants.

Vous pouvez ensuite utiliser le nouveau jeton d'accès OAuth 2.0 aux champs d'application limités pour authentifier les requêtes dans Cloud Storage.

Attribuer des rôles Cloud IAM

Une limite d'accès aux identifiants définit une limite supérieure des autorisations disponibles pour une ressource. Cette limite peut soustraire les autorisations d'un membre, mais elle ne peut pas ajouter d'autorisations que le membre n'a pas déjà.

Par conséquent, vous devez attribuer des rôles au membre qui fournit les autorisations nécessaires : dans un bucket Cloud Storage ou sur une ressource de niveau supérieur, comme le projet.

Supposons, par exemple, que vous ayez besoin de créer des identifiants éphémères aux champs d'application limités permettant à un compte de service de créer des objets dans un bucket :

  • Vous devez au moins octroyer un rôle au compte de service qui inclut l'autorisation storage.objects.create, par exemple le rôle Créateur des objets de l'espace de stockage (roles/storage.objectCreator). La limite d'accès aux identifiants doit également inclure cette autorisation.
  • Vous pouvez également accorder un rôle qui inclut davantage d'autorisations, telles que le rôle d'administrateur d'objets de stockage (roles/storage.objectAdmin). Le compte de service ne peut utiliser que les autorisations qui apparaissent à la fois dans l'attribution de rôle et dans les limites d'accès aux identifiants.

Définition d'une limite d'accès aux identifiants

Une limite d'accès aux identifiants est un objet JSON qui contient une liste de règles d'accès aux limites. Chaque règle contient les informations suivantes :

  • La ressource à laquelle s'applique la règle
  • La limite supérieure des autorisations disponibles pour cette ressource

Si vous appliquez une limite d'accès aux identifiants à un identifiant éphémère, celui-ci ne peut accéder qu'aux ressources comprises dans la limite. Aucune autorisation n'est disponible pour les autres ressources.

Une limite d'accès aux identifiants peut contenir jusqu'à 10 règles de limite d'accès. Vous ne pouvez appliquer qu'une seule limite d'accès aux identifiants à chaque identifiant éphémère.

Une limite d'accès aux identifiants contient les champs suivants :

Champs
accessBoundaryRules[]

object

Liste des règles d'accès à appliquer aux identifiants éphémères.
accessBoundaryRules[].availablePermissions[]

string

Liste qui définit la limite supérieure des autorisations disponibles pour la ressource.

Chaque valeur correspond à l'identifiant d'un rôle prédéfini ou d'un rôle personnalisé Cloud IAM, avec le préfixe inRole:. Par exemple, inRole:roles/storage.objectViewer. Seules les autorisations associées à ces rôles seront disponibles.

accessBoundaryRules[].availableResource

string

Nom complet de la ressource du bucket Cloud Storage auquel la règle s'applique. Utilisez le format //storage.googleapis.com/projects/_/buckets/[BUCKET_NAME].

L'exemple suivant illustre une limite d'accès aux identifiants qui inclut des règles pour plusieurs ressources :

  • Le bucket Cloud Storage example-bucket-1. Pour ce bucket, seules les autorisations du rôle "Lecteur des objets de l'espace de stockage" (roles/storage.objectViewer) sont disponibles.
  • Le bucket Cloud Storage example-bucket-2. Pour ce bucket, seules les autorisations du rôle "Créateur des objets de l'espace de stockage" (roles/storage.objectCreator) sont disponibles.
{
      "accessBoundaryRules": [
        {
          "availablePermissions": [
            "inRole:roles/storage.objectViewer"
          ],
          "availableResource": "//storage.googleapis.com/projects/_/buckets/example-bucket-1"
        },
        {
          "availablePermissions": [
            "inRole:roles/storage.objectCreator"
          ],
          "availableResource": "//storage.googleapis.com/projects/_/buckets/example-bucket-2"
        }
      ]
    }

Créez un fichier JSON qui définit la limite d'accès aux identifiants. Vous utiliserez ce fichier dans une prochaine étape.

Créer un jeton d'accès OAuth 2.0

Avant de créer des identifiants éphémères aux champs d'application limités, vous devez créer un jeton d'accès OAuth 2.0 standard. Vous pouvez ensuite remplacer les identifiants standards par des identifiants aux champs d'application limités. Lorsque vous créez le jeton d'accès, utilisez le champ d'application OAuth 2.0 https://www.googleapis.com/auth/cloud-platform.

Pour créer un jeton d'accès pour un compte de service, vous pouvez terminer le flux OAuth 2.0 de serveur à serveur, ou utilisez l'API Credit Account Credentials pour générer un jeton d'accès OAuth 2.0.

Pour créer un jeton d'accès pour un utilisateur, consultez la section Obtention des jetons d'accès OAuth 2.0. Vous pouvez également utiliser OAuth 2.0 Playground pour créer un jeton d'accès pour votre propre compte Google.

Échanger les jetons d'accès OAuth 2.0.

Après avoir créé un jeton d'accès OAuth 2.0, vous pouvez le remplacer par un nouveau jeton qui respecte la limite d'accès aux identifiants. Vous échangez le jeton d'accès via le service de jeton de sécurité, qui fait partie de Identity Platform.

Pour échanger le jeton d'accès, utilisez la méthode HTTP et l'URL suivantes :

POST https://securetoken.googleapis.com/v2beta1/token

Définissez l'en-tête Content-Type de la requête sur application/x-www-form-urlencoded. Spécifiez les champs suivants dans le corps de la requête :

Champs
access_boundary

string

La limite d'accès aux identifiants encodée en pourcentage.
grant_type

string

Utilisez la valeur urn:ietf:params:oauth:grant-type:token-exchange.
requested_token_type

string

Utilisez la valeur urn:ietf:params:oauth:token-type:access_token.
subject_token

string

Le jeton d'accès OAuth 2.0 que vous souhaitez échanger.
subject_token_type

string

Utilisez la valeur urn:ietf:params:oauth:token-type:access_token.

La réponse est un objet JSON qui contient les champs suivants :

Champs
access_token

string

Un nouveau jeton d'accès OAuth 2.0 qui respecte les limites d'accès aux identifiants.
expires_in

number

Le délai avant expiration du nouveau jeton d'accès, exprimé en secondes.

Ce champ n'est présent que si le jeton d'accès d'origine représente un compte de service. Lorsque ce champ est absent, le nouveau jeton d'accès expire en même temps que le jeton d'accès d'origine.

issued_token_type

string

Contient la valeur urn:ietf:params:oauth:token-type:access_token.

token_type

string

Contient la valeur Bearer.

Par exemple, si la limite d'accès aux identifiants est stockée dans le fichier ./access-boundary.json, vous pouvez utiliser la commande suivante curl pour échanger le jeton d'accès. Remplacez [ORIGINAL_TOKEN] par le jeton d'accès d'origine :

curl -H "Content-Type:application/x-www-form-urlencoded" \
        -X POST \
        https://securetoken.googleapis.com/v2beta1/token \
        -d "grant_type=urn:ietf:params:oauth:grant-type:token-exchange&subject_token_type=urn:ietf:params:oauth:token-type:access_token&requested_token_type=urn:ietf:params:oauth:token-type:access_token&subject_token=[ORIGINAL_TOKEN]" \
        --data-urlencode "access_boundary=$(cat ./access-boundary.json)"

La réponse est similaire à l'exemple suivant :

{
      "access_token": "ya29.dr.AbCDeFg-123456...",
      "issued_token_type": "urn:ietf:params:oauth:token-type:access_token",
      "token_type": "Bearer",
      "expires_in": 3600
    }

Étape suivante