IAM permission hierarchy in Apigee Spaces

Stay organized with collections Save and categorize content based on your preferences.

This page applies to Apigee and Apigee hybrid.

View Apigee Edge documentation.

This page describes how Identity and Access Management (IAM) permission hierarchies are applied to Apigee API resources (API proxies, shared flows, and API products) and their children when using Apigee Spaces.

IAM interaction with Apigee Spaces

In general, IAM policies governing access to resources are inherited through the Google Cloud resource hierarchy. The specific IAM policies that apply to a given resource include both of the following:

• Any policies directly applied to the resource
• Any policies the resource inherits from its ancestors

Resource and permission hierarchy in Apigee

In Apigee, the top of the resource hierarchy is the organization resource. Child resources of an organization include API proxies, shared flows, and API products. When you use Apigee without Spaces, permissions are applied to the Google Cloud project, which correlates directly with the Apigee organization resource. As a result, the IAM policies governing access to a given API proxy, shared flow, or API product include any policies inherited from the organization, in addition to any policies directly applied to the specific resource.

Resource and permission hierarchy with Spaces

When you use Apigee with Spaces, the Space resource is added to the hierarchy. Consider a scenario where an Apigee organization has three API proxies, proxy-a, proxy-b, and proxy-c. In this example, proxy-b and proxy-c are associated with space-red and space-blue, respectively. When you associate an API resource with a Space, the space attribute is set on the resource.

When you make an API call to get the details of proxy-c, your API endpoint reflects the actual resource hierarchy, where the API proxy is a child of the organization with a Space attribute, as shown in the following example:

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"
}

Although the path to an API resource associated with a Space remains the same, the effective IAM permission hierarchy changes. In our example scenario, the IAM permission checks will behave as though the API resource is a child of the Space. As a result, the IAM policies that apply to the API resource include those policies inherited from the Space, in addition to any policies directly applied to the Space, as shown in the following figure:

IAM policy checks for Space resources

As noted in a previous section, when API proxies, shared flows, and API products are associated with a Space, they are treated as child resources of the Space during IAM policy checks. This effective resource hierarchy applies to all sub-children of API proxies, shared flows, and API products.

For example, API Product attributes are child resources of an API product. To list all attributes of the API product product-a in the Apigee organization org1, which is associated with the Apigee space space-blue, the actual resource path is GET organizations/org1/apiproduct/product-a/attributes. However, the path that is checked for IAM permissions is organizations/org1/spaces/space-blue/apiproduct/product-a/attributes.

IAM policy checks for deployments

The Environment resource is not associated with Spaces. However, some existing APIs have been updated to enable fine-grained access to deployments and debug sessions for API proxies and shared flows.

Changes to IAM permission checks for the following deployment operations on resources in a Space are described below:

Permission checks for debug sessions

If an API proxy is associated with a Space, the IAM permission checks for the proxy's debug sessions have changed, as described in the following table: