Cette page explique comment utiliser les limites d'accès aux identifiants pour créer un jeton d'accès OAuth 2.0 avec des autorisations Cloud Storage à champ d'application limité.
Pour créer un jeton avec des autorisations à champ d'application limité, procédez comme suit :
- Attribuez les rôles IAM appropriés à un utilisateur ou à un compte de service.
- Définissez une limite d'accès aux identifiants qui définit la limite supérieure des autorisations disponibles pour l'utilisateur ou le compte de service.
- Créez un jeton d'accès OAuth 2.0 pour l'utilisateur ou le compte de service.
- Échangez le jeton d'accès OAuth 2.0 contre un nouveau jeton respectant la limite d'accès aux identifiants.
Vous pouvez ensuite utiliser le nouveau jeton d'accès OAuth 2.0 à champ d'application limité pour authentifier les requêtes dans Cloud Storage.
Avant de commencer
Avant d'utiliser les limites d'accès aux identifiants, assurez-vous de remplir les conditions suivantes :
Vous devez réduire le champ d'application des autorisations pour Cloud Storage uniquement, et non pour les autres servicesGoogle Cloud .
Si vous devez réduire le champ d'application des autorisations associées à 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 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.
En outre, vous devez activer les API nécessaires :
-
Enable the IAM and Security Token Service APIs.
Roles required to enable APIs
To enable APIs, you need the Service Usage Admin IAM role (
roles/serviceusage.serviceUsageAdmin
), which contains theserviceusage.services.enable
permission. Learn how to grant roles.
Attribuer des rôles IAM
Une limite d'accès aux identifiants définit la limite supérieure des autorisations disponibles pour une ressource. Cette limite peut retirer des autorisations à un compte principal, mais ne peut pas ajouter d'autorisations que le compte principal ne possède pas déjà.
Par conséquent, vous devez attribuer au compte principal des rôles qui fournissent 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 à champ d'application limité, permettant à un compte de service de créer des objets dans un bucket :
- Vous devez au moins octroyer au compte de service un rôle comprenant l'autorisation
storage.objects.create
, par exemple le rôle Créateur d'objets Storage (roles/storage.objectCreator
). La limite d'accès aux identifiants doit également inclure cette autorisation. - Vous pouvez également attribuer un rôle comprenant davantage d'autorisations, tel que le rôle Administrateur d'objets Storage (
roles/storage.objectAdmin
). Le compte de service ne peut utiliser que les autorisations qui apparaissent à la fois dans le rôle attribué et dans la limite d'accès aux identifiants.
Pour en savoir plus sur les rôles prédéfinis pour Cloud Storage, consultez la page Rôles Cloud Storage.
Définir la limite d'accès aux identifiants
Une limite d'accès aux identifiants est un objet qui contient une liste de règles de limite d'accès. Les règles sont constituées de paramètres qui spécifient la limite supérieure des autorisations disponibles pour l'utilisateur ou le compte de service. Pour définir une limite d'accès aux identifiants, créez un objet JSON qui liste les règles de limite d'accès et leurs paramètres.
Voici un exemple de limite d'accès aux identifiants :
{
"accessBoundary": {
"accessBoundaryRules": [
{
"availablePermissions": [
"inRole:ROLE_ID"
],
"availableResource": "//storage.googleapis.com/projects/_/buckets/BUCKET_NAME"
"availabilityCondition": {
"expression" : "CONDITION"
}
]
}
}
Remplacez les éléments suivants :
ROLE_ID
: ID d'un rôle prédéfini ou personnalisé qui définit la limite supérieure des autorisations disponibles pour la ressource. Exemple :roles/storage.objectViewer
Pour spécifier plusieurs rôles, ajoutez une ligne avec un préfixeinRole:
suivi de l'ID du rôle. Seules les autorisations associées aux rôles spécifiés sont disponibles.BUCKET_NAME
: nom du bucket Cloud Storage auquel s'applique la règle.CONDITION
: facultatif. Expression de condition qui spécifie les objets Cloud Storage pour lesquels des autorisations sont disponibles. Par exemple, la condition suivante rend disponibles les autorisations pour les objets dont le nom commence parcustomer-a
:resource.name.startsWith('projects/_/buckets/example-bucket/objects/customer-a')
Pour savoir comment créer et personnaliser des limites d'accès aux identifiants, consultez Composants d'une limite d'accès aux identifiants.
Pour obtenir des exemples de cas d'utilisation potentiels des limites d'accès aux identifiants, consultez Exemples de limites d'accès aux identifiants.
Créer un jeton d'accès OAuth 2.0
Avant de créer un identifiant éphémère à champ d'application limité, vous devez créer un jeton d'accès OAuth 2.0 standard. Vous pouvez ensuite échanger l'identifiant standard contre un identifiant à champ d'application limité. 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 mettre en œuvre le flux OAuth 2.0 de serveur à serveur ou utiliser l'API Service 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 page Obtenir 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 le jeton d'accès OAuth 2.0
Une fois le jeton d'accès OAuth 2.0 créé, vous pouvez l'échanger contre un nouveau jeton à champ d'application limité respectant la limite d'accès aux identifiants. Ce processus implique généralement un agent de service de jetons et un consommateur de jetons:
L'agent de service de jetons est chargé de définir les limites d'accès aux identifiants et d'échanger un jeton d'accès contre un jeton à champ d'application limité.
L'agent de service de jetons peut utiliser une bibliothèque d'authentification compatible pour échanger automatiquement des jetons d'accès ou appeler le service de jetons de sécurité pour échanger des jetons manuellement.
Le consommateur de jetons demande un jeton d'accès à champ d'application limité à l'agent de service de jetons, puis utilise ce jeton pour effectuer une autre action.
Le consommateur de jetons peut utiliser une bibliothèque d'authentification compatible pour actualiser automatiquement les jetons d'accès avant leur expiration. Il peut également actualiser les jetons manuellement, ou encore autoriser l'expiration des jetons sans les actualiser.
Il existe deux façons d'échanger le jeton d'accès contre un jeton à champ d'application limité :
Échange de jetons côté client (recommandé) : les clients obtiennent des éléments cryptographiques à partir du serveur de l'API Security Token Service. Les éléments cryptographiques permettent aux clients de générer des jetons à champ d'application limité avec différentes règles de limites d'accès aux identifiants de manière indépendante côté client pendant une durée définie (par exemple, une heure). Cette approche réduit la latence et améliore l'efficacité, en particulier pour les clients qui doivent mettre à jour fréquemment les règles de limites d'accès aux identifiants. Il est également plus efficace pour les applications qui doivent générer de nombreux jetons uniques à portée limitée. Il s'agit de l'approche recommandée, car elle offre de meilleures performances, une meilleure évolutivité et une meilleure compatibilité avec les futures fonctionnalités.
Échange de jetons côté serveur : les clients demandent un nouveau jeton à champ d'application limité au serveur de l'API Security Token Service chaque fois qu'une règle de périmètre d'accès aux identifiants change. Cette approche est simple, mais nécessite un aller-retour vers le serveur de l'API Security Token Service pour chaque demande de jeton à portée réduite. Cette approche n'est recommandée que pour les clients qui ont besoin d'une bibliothèque cliente qui ne prend pas en charge l'échange de jetons côté client, en raison de l'aller-retour vers l'API Security Token Service pour chaque demande de jeton à portée réduite.
Échange de jetons côté client
Si vous créez l'agent de service de jetons et le consommateur de jetons dans le langage suivant, vous pouvez utiliser la bibliothèque d'authentification de Google pour échanger et actualiser automatiquement les jetons à l'aide de l'approche côté client.
Java
Pour Java, vous pouvez échanger et actualiser automatiquement des jetons avec la version 1.32.1 ou une version ultérieure de l'artefact com.google.auth:google-auth-library-cab-token-generator
.
Pour vérifier la version de votre artefact, exécutez la commande Maven suivante dans le répertoire de votre application :
mvn dependency:list -DincludeArtifactIds=google-auth-library-cab-token-generator
L'exemple suivant montre comment un agent de service de jetons peut générer des jetons à champ d'application limité :
L'exemple suivant montre comment un consommateur de jetons peut utiliser un gestionnaire d'actualisation pour obtenir et actualiser automatiquement les jetons à champ d'application limité :
Échange de jetons côté serveur
Cette section décrit les méthodes suivantes que vous pouvez utiliser pour échanger des jetons via l'approche côté service :
- Échanger et actualiser automatiquement le jeton d'accès
- Échanger et actualiser manuellement le jeton d'accès
Échanger et actualiser automatiquement le jeton d'accès à l'aide d'une approche côté serveur
Si vous créez l'agent de service de jetons et le consommateur de jetons dans l'un des langages suivants, vous pouvez utiliser la bibliothèque d'authentification de Google pour échanger et actualiser automatiquement les jetons à l'aide de l'approche de génération de jetons côté serveur :
Go
Pour Go, vous pouvez échanger et actualiser automatiquement des jetons avec la version v0.0.0-20210819190943-2bc19b11175f ou une version ultérieure du package golang.org/x/oauth2
.
Pour vérifier la version de votre package, exécutez la commande suivante dans le répertoire de votre application :
go list -m golang.org/x/oauth2
L'exemple suivant montre comment un agent de service de jetons peut générer des jetons à champ d'application limité :
L'exemple suivant montre comment un consommateur de jetons peut utiliser un gestionnaire d'actualisation pour obtenir et actualiser automatiquement les jetons à champ d'application limité :
Java
Pour Java, vous pouvez échanger et actualiser automatiquement des jetons avec la version 1.1.0 ou une version ultérieure de l'artefact com.google.auth:google-auth-library-oauth2-http
.
Pour vérifier la version de votre artefact, exécutez la commande Maven suivante dans le répertoire de votre application :
mvn dependency:list -DincludeArtifactIds=google-auth-library-oauth2-http
L'exemple suivant montre comment un agent de service de jetons peut générer des jetons à champ d'application limité :
L'exemple suivant montre comment un consommateur de jetons peut utiliser un gestionnaire d'actualisation pour obtenir et actualiser automatiquement les jetons à champ d'application limité :
Node.js
Pour Node.js, vous pouvez échanger et actualiser automatiquement des jetons avec la version 7.9.0 ou une version ultérieure du package google-auth-library
.
Pour vérifier la version de votre package, exécutez la commande suivante dans le répertoire de votre application :
npm list google-auth-library
L'exemple suivant montre comment un agent de service de jetons peut générer des jetons à champ d'application limité :
L'exemple suivant montre comment un consommateur de jetons peut fournir un gestionnaire d'actualisation qui obtient et actualise automatiquement les jetons à champ d'application limité :
Python
Pour Python, vous pouvez échanger et actualiser automatiquement des jetons avec la version 2.0.0 ou une version ultérieure du package google-auth
.
Pour vérifier la version de votre package, exécutez la commande suivante dans l'environnement où le package est installé :
pip show google-auth
L'exemple suivant montre comment un agent de service de jetons peut générer des jetons à champ d'application limité :
L'exemple suivant montre comment un consommateur de jetons peut fournir un gestionnaire d'actualisation qui obtient et actualise automatiquement les jetons à champ d'application limité :
Échanger et actualiser manuellement le jeton d'accès
Un agent de service de jetons peut utiliser l'API Security Token Service pour échanger un jeton d'accès contre un jeton d'accès à champ d'application limité. Il peut ensuite fournir le jeton à champ d'application limité à un consommateur de jetons.
Pour échanger le jeton d'accès, utilisez la méthode HTTP et l'URL suivantes :
POST https://sts.googleapis.com/v1/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 | |
---|---|
grant_type |
Utilisez la valeur |
options |
Limite d'accès aux identifiants au format JSON, encodée avec le encodage-pourcent. |
requested_token_type |
Utilisez la valeur |
subject_token |
Jeton d'accès OAuth 2.0 que vous souhaitez échanger. |
subject_token_type |
Utilisez la valeur |
La réponse est un objet JSON qui contient les champs suivants :
Champs | |
---|---|
access_token |
Jeton d'accès OAuth 2.0 à champ d'application limité respectant la limite d'accès aux identifiants. |
expires_in |
: délai avant expiration du nouveau jeton d'accès à champ d'application limité, exprimé en secondes. Ce champ n'est inclus que si le jeton d'accès d'origine représente un compte de service. Lorsque ce champ n'est pas inclus, le délai avant expiration du jeton à champ d'application limité est le même que celui du jeton d'accès d'origine. |
issued_token_type |
Contient la valeur |
token_type |
Contient la valeur |
Par exemple, si une limite d'accès aux identifiants au format JSON est stockée dans le fichier ./access-boundary.json
, vous pouvez utiliser la commande curl
suivante 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://sts.googleapis.com/v1/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 "options=$(cat ./access-boundary.json)"
La réponse est semblable à 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
}
Lorsqu'un consommateur de jetons demande un jeton à champ d'application limité, l'agent de service de jetons répond avec le jeton à champ d'application limité et le nombre de secondes avant expiration. Si le jeton a expiré, le serveur rejette la requête. Pour actualiser le jeton à champ d'application limité, le consommateur peut demander un jeton à champ d'application limité à l'agent avant l'expiration du jeton existant.
Étapes suivantes
- Apprenez-en plus sur le contrôle des accès pour Cloud Storage.
- Créez un identifiant de compte de service éphémère.
- Créez un jeton d'accès OAuth 2.0 pour un compte de service à l'aide de l'une des méthodes suivantes :
- Créez un jeton d'accès OAuth 2.0 pour un utilisateur.
- Consultez les autorisations de chaque rôle prédéfini.
- Apprenez-en plus sur les rôles personnalisés.