Questa pagina è stata tradotta dall'API Cloud Translation.

Panoramica dell'autenticazione delle 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.

Utilizza controllo dell'accesso basato su IAM

Questa sezione descrive il processo end-to-end per configurare l'autenticazione basata su IAM e autorizzazione, come vengono valutate le richieste una volta configurato l'accesso e come revocare l'accesso per i consumatori di API che in precedenza avevano accesso.

Aggiungi gestione degli accessi

Per configurare la gestione degli accessi 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.
  
  oppure
2. Utilizza l'azione SetIamPolicy per concedere il ruolo o l'autorizzazione al consumer dell'API principio di Google Cloud in un particolare deployment o iterativamente 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: aggiungi il ruolo o l'autorizzazione in i deployment dei flussi condivisi non creano un controllo dei criteri VerificationIAM sui flussi condivisi. applica il le autorizzazioni solo per i proxy. Per i proxy che chiamano flussi condivisi, le autorizzazioni devono essere applicati 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 valore generato il token deve avere l'ambito di autenticazione https://www.googleapis.com/auth/cloud-platform.

Operazioni amministrative

Questa sezione elenca le azioni eseguite dagli amministratori API (producer API) durante la gestione delle autorizzazioni basate su IAM.

La documentazione relativa alle operazioni basate su API utilizzate durante la gestione dell'accesso basato su IAM è disponibile nel organizations.environments e organizations.environments.deployments documentazione di riferimento dell'API e includono SetIamPolicy, GetIamPolicy, TestIamPermissions e Operazioni di GetDeployment.

Questa tabella mappa le operazioni alle autorizzazioni richieste:

Operazione di amministrazione	Azione	È necessaria l'autorizzazione IAM	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	Imposta accesso chiamata per consumer API in un determinato deployment 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 necessaria	N/D

^* Il progetto Google Cloud è il progetto utilizzato per il provisioning di Apigee. Apigee le autorizzazioni a livello di ambiente siano impostate nell'ambiente setIAMPolicy.

Controllo dell'accesso al runtime

Quando il consumatore dell'API tenta di accedere a un'API con controllo 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 è stato concesso l'accesso per singoli deployment utilizzando setIamPolicy, rimuovi il ruolo o l'autorizzazione dai deployment 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, per alcune chiamate potrebbero verificarsi latenze di completamento di circa 50 ms. Ad esempio, nel In asia-east2 specifica, la latenza media può raggiungere i 50 ms e il completamento delle chiamate potrebbe richiedere circa 100 ms.

Tieni presente che questi valori relativi alla 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 richieste, dopo solo la gestione del traffico criteri.
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 richiamato (apigee.deployments.invoke) a livello di ambiente non trasmette l'accesso invo a tutti i deployment API nell'ambiente.
Le condizioni IAM non sono supportate nella risorsa di deployment e non possono essere utilizzate per controllare richiamare l'accesso. Consulta: Aggiunta di condizioni IAM Apigee ai criteri per ulteriori informazioni.
Controllo dell'accesso basato su IAM supporta un massimo di 1500 associazioni di ruoli all'interno di un singolo criterio e altre limitazioni. Consulta Quote e limiti di IAM.
Il controllo dell'accesso basato su IAM è soggetto a tempi di propagazione IAM.
Tentativo di gestire altre operazioni di apigee.deployments, ad esempio apigee.deployments.delete tramite setIAMPolicy a livello di deployment, non verrà efficace, ma non restituirà 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.
L'autenticazione e l'autorizzazione basate su IAM non sono al momento disponibili in modalità ibrida.

Esempi

Questa sezione fornisce esempi per la concessione e la revoca dell'accesso alle API basato su IAM. Questi tutti gli 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. Il $Project negli esempi è il valore 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'

Concedere e revocare 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 vedere una risposta positiva 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 essere simile al seguente. Tieni presente che potresti visualizzare anche altre associazioni.

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

Per rimuovere l'associazione:

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 se fornisci un payload vuoto si 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 nei casi in cui l'accesso deve continuare per altri utenti, specifica chi deve continuare per avere accesso nel payload, come si farebbe durante l’impostazione dell’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.