Questa pagina è stata tradotta dall'API Cloud Translation.

Panoramica dell'autenticazione API basata su IAM

Questa pagina si applica ad Apigee, ma non ad Apigee hybrid.

Apigee supporta l'autenticazione e l'autorizzazione basate su IAM per i proxy API. Con questa soluzione, l'accesso per richiamare un'API si basa su diversi fattori, tra cui se il flusso di richiesta include il regolamento VerifyIAM e se il consumatore dell'API dispone del ruolo o delle autorizzazioni IAM di Google Cloud necessarie per richiamare le API Apigee. L'autorizzazione può essere concessa per qualsiasi principale Google Cloud e non è limitata ai singoli utenti.

Utilizzare controllo dell'accesso basato su IAM

Questa sezione descrive la procedura end-to-end per la configurazione dell'autenticazione e dell'autorizzazione basate su IAM, la modalità di valutazione delle richieste una volta configurato l'accesso e come revocare l'accesso per i consumer dell'API che hanno avuto accesso in precedenza.

Aggiungere la gestione dell'accesso

Per configurare la gestione dell'accesso per un proxy API:

Aggiungi il criterio VerifyIAM al proxy o ai proxy API Apigee nell'ambito del flusso di richiesta.
L'amministratore Cloud del progetto Apigee:
1. Concede il ruolo IAM deploymentInvoker (o un ruolo personalizzato con l'autorizzazione IAM apigee.deployments.invoke) all'entità Google Cloud del consumatore dell'API a livello di progetto. In questo modo, il consumer dell'API può invocare tutte le API ospitate nell'organizzazione Apigee associata.
  
  o
2. Utilizza l'azione SetIamPolicy per concedere il ruolo o l'autorizzazione all'entità Google Cloud del consumatore dell'API in un determinato deployment o in modo iterativo in più deployment. Utilizza l'operazione di elenco sulla risorsa di deployment per visualizzare tutti i deployment all'interno di un ambiente, inclusi i proxy API e i flussi condivisi. Il nome del deployment è il nome del proxy API o del flusso condiviso.
  Nota: l'aggiunta del ruolo o dell'autorizzazione ai deployment dei flussi condivisi non crea un controllo delle norme VerifyIAM sui flussi condivisi. Applica le autorizzazioni solo ai proxy. Per i proxy che richiamano i flussi condivisi, le autorizzazioni devono essere applicate ai proxy. Con la catena di proxy, concedi l'autorizzazione al proxy con il criterio; l'autorizzazione non è richiesta sugli altri proxy della catena.
Chiedi al consumatore dell'API di generare un token di accesso, che verrà passato all'interno della richiesta dell'API Apigee per il controllo delle autorizzazioni. Il token generato deve avere l'ambito di autorizzazione https://www.googleapis.com/auth/cloud-platform.

Operazioni di amministrazione

Questa sezione elenca le azioni intraprese dagli amministratori dell'API (produttori di API) durante la gestione delle autorizzazioni basate su IAM.

La documentazione per le operazioni basate su API utilizzate per gestire l'accesso basato su IAM è disponibile nella documentazione di riferimento dell'API organizations.environments e organizations.environments.deployments e include le operazioni SetIamPolicy, GetIamPolicy, TestIamPermissions e GetDeployment.

Questa tabella mappa le operazioni alle autorizzazioni richieste:

Operazione di amministrazione	Azione	Autorizzazione IAM necessaria	Risorsa IAM per cui è necessaria l'autorizzazione^*
GetDeployment	Recuperare le informazioni per un deployment in un ambiente Apigee	apigee.deployments.get	Progetto Google Cloud o ambiente Apigee
ListDeployments	Elenco dei deployment in un ambiente Apigee	apigee.deployments.list	Progetto o ambiente Apigee
SetIamPolicy	Impostare l'accesso invocazione per i consumer dell'API in un determinato deployment dell'API	apigee.deployments.setIamPolicy	Progetto Google Cloud o ambiente Apigee
GetIamPolicy	Recupera l'insieme di impostazioni di accesso all'invocazione per un deployment dell'API	apigee.deployments.getIamPolicy	Progetto Google Cloud o ambiente Apigee
TestIamPermissions	Controlla se l'utente che chiama questa API dispone dell'autorizzazione indicata nel payload	Nessuna autorizzazione IAM richiesta	N/D

^* Il progetto Google Cloud è il progetto utilizzato per eseguire il provisioning di Apigee. Le autorizzazioni a livello di ambiente Apigee vengono impostate nell'ambiente utilizzando setIAMPolicy.

Controllo dell'accesso in runtime

Quando il consumatore dell'API tenta di accedere a un'API con controllo dell'accesso dell'accesso basato su IAM, viene eseguito un controllo per verificare se dispone del token di accesso necessario e del ruolo o dell'autorizzazione appropriati a livello di progetto o di implementazione. In questo caso, può continuare ad accedere al proxy. In caso contrario, vengono bloccati.

Rimuovi accesso

Per rimuovere l'accesso a livello di progetto: per rimuovere l'accesso per un consumer API gestito a livello di progetto, l'amministratore di Cloud per il progetto Apigee revoca il ruolo IAM deploymentInvoker (o il ruolo personalizzato con l'autorizzazione IAM apigee.deployments.invoke) dall'entità Google Cloud del consumer API per il progetto Google Cloud.

Se l'accesso è stato concesso per singoli implementazioni utilizzando setIamPolicy, rimuovi il ruolo o l'autorizzazione dalle implementazioni utilizzando un'altra operazione setIamPolicy.

Caratteristiche e limitazioni del controllo dell'accesso basato su IAM

Tieni presente queste caratteristiche e limitazioni quando utilizzi l'autenticazione e l'autorizzazione basate su IAM:

In genere, l'esecuzione delle norme con VerifyIAM richiede circa 10 millisecondi. Tuttavia, alcune chiamate potrebbero presentare latenze di completamento di circa 50 ms. Ad esempio, nella regione asia-east2 in particolare, la latenza media può aumentare fino a 50 ms e alcune chiamate potrebbero richiedere circa 100 ms per essere completate.

Tieni presente che questi valori di latenza non sono garantiti.
L'inclusione del criterio VerifyIAM per un proxy è solo un controllo di verifica/non verifica; i ruoli e le autorizzazioni specifici del consumatore dell'API non vengono considerati nelle fasi successive del flusso di richiesta o risposta.
Poiché un controllo dell'autorizzazione viene eseguito solo al momento dell'esecuzione del criterio VerifyIAM, VerifyIAM deve essere il primo criterio nel flusso di richiesta, dopo solo i criteri di gestione del traffico.
Se la convalida delle autorizzazioni va a buon fine o se il produttore dell'API ha contrassegnato il criterio VerifyIAM per continuare in caso di errore, il flusso di richieste continua a eseguire gli altri criteri, se presenti, fino a raggiungere il server di destinazione. Se il controllo delle autorizzazioni non va a buon fine e il produttore dell'API non ha contrassegnato il criterio per continuare in caso di errore, l'utente riceve un messaggio di errore.
L'aggiunta dell'accesso invocazione (apigee.deployments.invoke) a livello di ambiente non consente di trasmettere l'accesso invocazione a tutti i deployment dell'API all'interno dell'ambiente.
Le condizioni IAM non sono supportate nella risorsa di deployment e non possono essere utilizzate per controllare l'accesso all'invoke. Per ulteriori informazioni, consulta Aggiunta di condizioni IAM di Apigee ai criteri.
Controllo dell'accesso basato su IAM supporta al massimo 1500 associazioni di ruolo all'interno di un singolo criterio e altre limitazioni. Consulta Quote e limiti di IAM.
Controllo dell'accesso basato su IAM è soggetto a tempi di propagazione IAM.
Il tentativo di gestire altre operazioni apigee.deployments, ad esempio apigee.deployments.delete tramite setIAMPolicy a livello di deployment, non sarà efficace, ma non restituirà nemmeno un errore. Solo apigee.deployements.invoke è efficace.
L'accesso a un deployment viene eliminato quando il proxy corrispondente viene ritirato dall'ambiente o eliminato. L'accesso deve essere aggiunto di nuovo al nuovo deployment.
Al momento, l'autenticazione e l'autorizzazione basate su IAM non sono disponibili in modalità ibrida.

Esempi

Questa sezione fornisce esempi per la concessione e la revoca dell'accesso alle API basato su IAM. Questi esempi presuppongono che VerifyIAM sia già stato aggiunto al proxy API appropriato.

In questi esempi, utilizza la console Cloud o gcloud (mostrato) per gestire i ruoli o le autorizzazioni sul principale Google Cloud del consumatore dell'API. $Project negli esempi è il progetto Google Cloud.

Concedi e revoca l'accesso degli utenti per richiamare tutte le API in un'organizzazione Apigee

Per aggiungere l'accesso, aggiungi il ruolo deploymentInvoker:

gcloud projects add-iam-policy-binding {$Project} --member={$user} --role='roles/apigee.deploymentInvoker'

Per revocare l'accesso, rimuovi il ruolo deploymentInvoker:

gcloud projects remove-iam-policy-binding {$Project} --member={$user} --role='roles/apigee.deploymentInvoker'

Concedi e revoca l'accesso degli utenti a implementazioni specifiche all'interno di un ambiente

Per aggiungere il ruolo invocatore di un utente a un deployment specifico:

curl 'https://apigee.googleapis.com/v1/organizations/{org}/environments/{env}/deployments/{api}:setIamPolicy' \
    --header 'Authorization: Bearer $TOKEN ' \
    --header 'Content-Type: application/json' \
    --data '{"policy":{"bindings":[{"members":["user:$user"],"role":"roles/apigee.deploymentInvoker"}]}}'

Una risposta di successo dovrebbe avere il seguente aspetto:

  {
    "version": 1,
    "etag": "BwYT8i40Vwo=",
    "bindings": [
      {
        "role": "roles/apigee.deploymentInvoker",
        "members": [
          "user:$user"
        ]
      }
    ]
  }

(Facoltativo) Per verificare che l'oggetto criterio che hai aggiunto sia stato mantenuto correttamente:

curl 'https://apigee.googleapis.com/v1/organizations/{org}/environments/{env}/deployments/{api}:getIamPolicy' \
  --header 'Authorization: Bearer $TOKEN'

Dovresti visualizzare una risposta di successo come quella mostrata sopra.

Per consentire all'utente di verificare se è in grado di accedere al deployment specificato (se l'autorizzazione apigee.deployments.invoke è impostata per l'utente specificato in un deployment specificato), chiedi all'utente di inviare questa richiesta utilizzando il token di accesso generato in precedenza:

curl 'https://apigee.googleapis.com/v1/organizations/{org}/environments/{env}/deployments/{api}:testIamPermissions' \
  --header 'Authorization: Bearer $TOKEN' \
  --header 'Content-Type: application/json' \
  --header 'Accept: application/json' \
  --data '{"permissions":["apigee.deployments.invoke"]}'

La risposta deve includere l'autorizzazione apigee.deployments.invoke per l'utente.

Per revocare l'accesso a un deployment specifico, rimuovi il ruolo deploymentInvoker. Innanzitutto, recupera l'oggetto criterio attualmente associato al deployment:

curl 'https://apigee.googleapis.com/v1/organizations/{org}/environments/{env}/deployments/{api}:getIamPolicy' \
  --header 'Authorization: Bearer $TOKEN'

La risposta di successo dovrebbe avere il seguente aspetto. Tieni presente che potresti visualizzare anche altre associazioni.

{
  "version": 1,
  "etag": "BwYT8i40Vwo=",
  "bindings": [
      {
        "role": "roles/apigee.deploymentInvoker",
        "members": [
          "user:$user"
        ]
      }
    ]
  }

Per rimuovere il binding:

curl 'https://apigee.googleapis.com/v1/organizations/{org}/environments/{env}/deployments/{api}:setIamPolicy' \
  --header 'Authorization: Bearer $TOKEN' \
  --header 'Content-Type: application/json' \
  --data '{}'

Tieni presente che fornire un payload vuoto rimuove l'accesso per tutti gli utenti, ma è appropriato in questo esempio perché abbiamo un solo utente con accesso. Quando rimuovi l'accesso utente in una situazione in cui l'accesso deve continuare per altri utenti, specifica nel payload gli utenti che devono continuare ad avere accesso, come faresti quando imposti l'accesso iniziale per questi utenti.

Per verificare che il vincolo sia stato rimosso, assicurati che l'autorizzazione apigee.deployments.invoke non esista per l'utente nel deployment:

curl 'https://apigee.googleapis.com/v1/organizations/{org}/environments/{env}/deployments/{api}:testIamPermissions' \
  --header 'Authorization: Bearer $USER_TOKEN' \
  --header 'Content-Type: application/json' \
  --header 'Accept: application/json' \
  --data '{"permissions":["apigee.deployments.invoke"]}'

Se nessun utente dispone dell'autorizzazione, dovrebbe essere restituito un output vuoto.