Hiérarchie des autorisations IAM dans Apigee Spaces

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Cette page s'applique à Apigee et à Apigee hybrid.

Consultez la documentation d' Apigee Edge.

Cette page explique comment les hiérarchies d'autorisations IAM (Identity and Access Management) sont appliquées aux ressources d'API Apigee (proxys d'API, flux partagés et produits d'API) et à leurs enfants lorsque vous utilisez Apigee Spaces.

Interaction d'IAM avec Apigee Spaces

En général, les stratégies IAM régissant l'accès aux ressources sont héritées via la hiérarchie des ressources Google Cloud . Les stratégies IAM spécifiques qui s'appliquent à une ressource donnée incluent les éléments suivants:

• Toutes les stratégies appliquées directement à la ressource
• Toutes les stratégies que la ressource hérite de ses ancêtres

Hiérarchie des ressources et des autorisations dans Apigee

Dans Apigee, la ressource organisation se trouve au sommet de la hiérarchie des ressources. Les ressources enfants d'une organisation incluent les proxys d'API, les flux partagés et les produits d'API. Lorsque vous utilisez Apigee sans Spaces, les autorisations sont appliquées au projet Google Cloud , qui est directement associé à la ressource de l'organisation Apigee. Par conséquent, les règles IAM qui régissent l'accès à un proxy d'API, à un flux partagé ou à un produit d'API donnés incluent toutes les règles héritées de l'organisation, en plus de toutes les règles appliquées directement à la ressource spécifique.

Hiérarchie des ressources et des autorisations avec des espaces

Lorsque vous utilisez Apigee avec Spaces, la ressource Space est ajoutée à la hiérarchie. Imaginons qu'une organisation Apigee dispose de trois proxys d'API, proxy-a, proxy-b et proxy-c. Dans cet exemple, proxy-b et proxy-c sont associés à space-red et space-blue, respectivement. Lorsque vous associez une ressource d'API à un espace, l'attribut space est défini sur la ressource.

Lorsque vous effectuez un appel d'API pour obtenir les détails de proxy-c, votre point de terminaison d'API reflète la hiérarchie des ressources réelles, où le proxy d'API est un enfant de l'organisation avec un attribut "Space", comme illustré dans l'exemple suivant:

curl -X GET -H "Authorization: Bearer $TOKEN" "https://apigee.googleapis.com/v1/organizations/org1/apis/proxy-c"
{
  "metaData": {
    "createdAt": "1725665197737",
    "lastModifiedAt": "1725665462105",
    "subType": "Proxy"
  },
  "name": "proxy-c",
  "revision": [
    "1"
  ],
  "apiProxyType": "PROGRAMMABLE",
  "space": "space-blue"
}

Bien que le chemin d'accès à une ressource API associée à un espace reste le même, la hiérarchie des autorisations IAM effective change. Dans notre exemple, les vérifications des autorisations IAM se comportent comme si la ressource API était un enfant de l'espace. Par conséquent, les stratégies IAM qui s'appliquent à la ressource API incluent celles héritées de l'espace, en plus de toute stratégie appliquée directement à l'espace, comme illustré dans la figure suivante:

La stratégie IAM vérifie les ressources Space

Comme indiqué dans une section précédente, lorsque des proxys d'API, des flux partagés et des produits d'API sont associés à un espace, ils sont traités comme des ressources enfants de l'espace lors des vérifications des règles IAM. Cette hiérarchie des ressources effective s'applique à tous les sous-enfants des proxys d'API, des flux partagés et des produits d'API.

Par exemple, les attributs de produit d'API sont des ressources enfants d'un produit d'API. Pour lister tous les attributs du produit d'API product-a dans l'organisation Apigee org1, qui est associée à l'espace Apigee space-blue, le chemin d'accès aux ressources réel est GET organizations/org1/apiproduct/product-a/attributes. Toutefois, le chemin d'accès vérifié pour les autorisations IAM est organizations/org1/spaces/space-blue/apiproduct/product-a/attributes.

Vérifications des stratégies IAM pour les déploiements

La ressource Environment n'est pas associée à Spaces. Toutefois, certaines API existantes ont été mises à jour pour permettre un accès précis aux déploiements et aux sessions de débogage pour les proxys d'API et les flux partagés.

Les modifications apportées aux vérifications des autorisations IAM pour les opérations de déploiement suivantes sur les ressources d'un espace sont décrites ci-dessous:

Vérifications des autorisations pour les sessions de débogage

Si un proxy d'API est associé à un espace, les vérifications d'autorisation IAM pour les sessions de débogage du proxy ont changé, comme décrit dans le tableau suivant: