Gerarchia delle autorizzazioni IAM in Apigee Spaces

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Questa pagina si applica ad Apigee e Apigee hybrid.

Visualizza la documentazione di Apigee Edge.

Questa pagina descrive come le gerarchie di autorizzazione di Identity and Access Management (IAM) vengono applicate alle risorse API Apigee (proxy API, flussi condivisi e prodotti API) e ai relativi elementi secondari quando utilizzi Apigee Spaces.

Interazione di IAM con Apigee Spaces

In generale, i criteri IAM che regolano l'accesso alle risorse vengono ereditati tramite la Google Cloud gerarchia delle risorse. I criteri IAM specifici che si applicano a una determinata risorsa includono entrambi i seguenti elementi:

• Eventuali criteri applicati direttamente alla risorsa
• Eventuali criteri ereditati dalla risorsa dai suoi antenati

Gerarchia delle risorse e delle autorizzazioni in Apigee

In Apigee, la parte superiore della gerarchia delle risorse è la risorsa organizzazione. Le risorse secondarie di un'organizzazione includono proxy API, flussi condivisi e prodotti API. Quando utilizzi Apigee senza Spaces, le autorizzazioni vengono applicate al Google Cloud progetto, che è direttamente correlato alla risorsa dell'organizzazione Apigee. Di conseguenza, i criteri IAM che regolano l'accesso a un determinato proxy API, flusso condiviso o prodotto API includono tutti i criteri ereditati dall'organizzazione, oltre a eventuali criteri applicati direttamente alla risorsa specifica.

Gerarchia delle risorse e delle autorizzazioni con gli spazi

Quando utilizzi Apigee con gli spazi, la risorsa Spazio viene aggiunta alla gerarchia. Considera uno scenario in cui un'organizzazione Apigee ha tre proxy API, proxy-a, proxy-b e proxy-c. In questo esempio, proxy-b e proxy-c sono associati rispettivamente a space-red e space-blue. Quando associ una risorsa API a uno spazio, l'attributo space viene impostato sulla risorsa.

Quando effettui una chiamata API per ottenere i dettagli di proxy-c, l'endpoint dell'API riflette la gerarchia delle risorse effettiva, in cui il proxy API è un elemento secondario dell'organizzazione con un attributo Spazio, come mostrato nell'esempio seguente:

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

Sebbene il percorso a una risorsa API associata a uno spazio rimanga invariato, la gerarchia delle autorizzazioni IAM effettiva cambia. Nel nostro scenario di esempio, i controlli delle autorizzazioni IAM si comporteranno come se la risorsa API fosse un elemento secondario dello spazio. Di conseguenza, i criteri IAM che si applicano alla risorsa API includono quelli ereditati dallo spazio, oltre a eventuali criteri applicati direttamente allo spazio, come mostrato nella figura seguente:

Controlli dei criteri IAM per le risorse Space

Come indicato in una sezione precedente, quando i proxy API, i flussi condivisi e i prodotti API sono associati a uno spazio, vengono trattati come risorse secondarie dello spazio durante i controlli dei criteri IAM. Questa gerarchia delle risorse efficace si applica a tutti i sottoelementi secondari di proxy API, flussi condivisi e prodotti API.

Ad esempio, gli attributi del prodotto API sono risorse secondarie di un prodotto API. Per elencare tutti gli attributi del prodotto API product-a nell'organizzazione Apigee org1, associata allo spazio Apigee space-blue, il percorso della risorsa effettivo è GET organizations/org1/apiproduct/product-a/attributes. Tuttavia, il percorso controllato per le autorizzazioni IAM è organizations/org1/spaces/space-blue/apiproduct/product-a/attributes.

Controlli dei criteri IAM per i deployment

La risorsa Environment non è associata a Spaces. Tuttavia, alcune API esistenti sono state aggiornate per consentire l'accesso granulare ai deployment e alle sessioni di debug per i proxy API e i flussi condivisi.

Di seguito sono descritte le modifiche ai controlli delle autorizzazioni IAM per le seguenti operazioni di deployment sulle risorse in uno spazio:

Controlli delle autorizzazioni per le sessioni di debug

Se a uno spazio è associato un proxy API, i controlli delle autorizzazioni IAM per le sessioni di debug del proxy sono cambiati, come descritto nella tabella seguente: