Jerarquía de permisos de IAM en Apigee Spaces

Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Esta página se aplica a Apigee y Apigee híbrido .

Ver la documentación de Apigee Edge .

Esta página describe cómo se aplican las jerarquías de permisos de Administración de identidad y acceso (IAM) a los recursos de API de Apigee (proxies de API, flujos compartidos y productos de API) y sus elementos secundarios cuando se utilizan Apigee Spaces.

Interacción de IAM con Apigee Spaces

En general, las políticas de IAM que rigen el acceso a los recursos se heredan a través de Google Cloud Jerarquía de recursos . Las políticas de IAM específicas que se aplican a un recurso determinado incluyen las dos siguientes:

• Cualquier política aplicada directamente al recurso
• Cualquier política que el recurso herede de sus ancestros

Jerarquía de recursos y permisos en Apigee

En Apigee, la parte superior de la jerarquía de recursos es el recurso de la organización . Los recursos secundarios de una organización incluyen proxies de API , flujos compartidos y productos de API . Al usar Apigee sin espacios, los permisos se aplican a... Google Cloud Proyecto, que se correlaciona directamente con el recurso de la organización de Apigee. Como resultado, las políticas de IAM que rigen el acceso a un proxy de API, flujo compartido o producto de API determinado incluyen cualquier política heredada de la organización, además de cualquier política aplicada directamente al recurso específico.

Jerarquía de recursos y permisos con Spaces

Al usar Apigee con Spaces, el recurso Space se añade a la jerarquía. Imagine un escenario donde una organización de Apigee tiene tres proxies de API: proxy-a , proxy-b y proxy-c . En este ejemplo, proxy-b y proxy-c están asociados con space-red y space-blue , respectivamente. Al asociar un recurso de API con un Space, el atributo space se establece en el recurso.

Cuando realiza una llamada a la API para obtener los detalles de proxy-c , su punto final de API refleja la jerarquía de recursos real, donde el proxy de API es un elemento secundario de la organización con un atributo Space , como se muestra en el siguiente ejemplo:

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

Aunque la ruta a un recurso de API asociado a un espacio permanece igual, la jerarquía efectiva de permisos de IAM cambia. En nuestro ejemplo, las comprobaciones de permisos de IAM se comportarán como si el recurso de API fuera un elemento secundario del espacio. Como resultado, las políticas de IAM que se aplican al recurso de API incluyen las heredadas del espacio, además de las que se aplican directamente a él, como se muestra en la siguiente figura:

Comprobaciones de políticas de IAM para recursos espaciales

Como se mencionó en una sección anterior, cuando los proxies de API, los flujos compartidos y los productos de API se asocian a un espacio, se tratan como recursos secundarios del espacio durante las comprobaciones de políticas de IAM. Esta jerarquía de recursos efectiva se aplica a todos los recursos secundarios de los proxies de API, los flujos compartidos y los productos de API.

Por ejemplo, los atributos de producto de API son recursos secundarios de un producto de API. Para listar todos los atributos del producto de API product-a en la organización de Apigee org1 , asociada al espacio de Apigee space-blue , la ruta del recurso es GET organizations/org1/apiproduct/product-a/attributes . Sin embargo, la ruta que se verifica para los permisos de IAM es organizations/org1/ spaces/space-blue /apiproduct/product-a/attributes .

Comprobaciones de políticas de IAM para implementaciones

El recurso Entorno no está asociado con Espacios. Sin embargo, se han actualizado algunas API existentes para permitir un acceso preciso a las implementaciones y sesiones de depuración para proxies de API y flujos compartidos.

A continuación se describen los cambios en las comprobaciones de permisos de IAM para las siguientes operaciones de implementación en recursos de un espacio:

Comprobaciones de permisos para sesiones de depuración

Si un proxy de API está asociado con un espacio, las comprobaciones de permisos de IAM para las sesiones de depuración del proxy han cambiado, como se describe en la siguiente tabla: