View a markdown version of this page

Creare un ruolo per la federazione OpenID Connect (console) - AWS Identity and Access Management
Prerequisiti per la creazione di un ruolo per OIDCCreazione di un ruolo per OIDCConfigurazione di un ruolo per il provider di GitHub identità OIDC

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Creare un ruolo per la federazione OpenID Connect (console)

Puoi utilizzare i provider di identità federati OpenID Connect (OIDC) invece di creare AWS Identity and Access Management utenti nel tuo. Account AWS Con un provider di identità (IdP), puoi gestire le tue identità utente all'esterno AWS e concedere a queste identità utente esterne le autorizzazioni per accedere alle risorse del tuo account. AWS Per ulteriori informazioni sulla federazione e, vedere. IdPs Fornitori di identità e federazione in AWS

Prerequisiti per la creazione di un ruolo per OIDC

Prima di poter creare un ruolo per la federazione OIDC, devi completare i seguenti passaggi obbligatori.

Per prepararsi alla creazione di un ruolo per la federazione OIDC

  1. Registrati con uno o più servizi che offrono l'identità OIDC federata. Se stai creando un'app che richiede l'accesso alle tue AWS risorse, configura anche l'app con le informazioni del provider. Al momento della registrazione, il gestore fornisce un ID applicazione o destinatario univoco per l'app. Provider diversi utilizzano una terminologia diversa per questo processo. Questa guida utilizza il termineconfigurare per il processo di identificazione dell'applicazione con il provider. È possibile configurare più app con ogni provider o più provider con una sola app. Consulta le informazioni sull'utilizzo degli IdP specificate di seguito:

  2. Dopo aver ricevuto le informazioni richieste dall'IdP, crea un IdP in IAM. Per ulteriori informazioni, consulta Creare un provider di identità OpenID Connect (OIDC) in IAM.

    Importante

    Se utilizzi un IdP OIDC di Google, Facebook o Amazon Cognito, non occorre creare un IdP IAM separato nella Console di gestione AWS. Questi provider di identità OIDC sono già integrati AWS e sono disponibili per l'uso. Ignora questa fase e vai alla fase successiva per creare nuovi ruoli utilizzando l'IdP.

  3. Prepara le politiche per il ruolo che assumeranno gli IdP-authenticated utenti. Come qualsiasi altro ruolo, anche il ruolo per un'app per dispositivi mobili include due policy. Una è la policy di affidabilità, che specifica chi può assumere il ruolo. L'altra è la policy di autorizzazione, che specifica le operazioni e le risorse AWS a cui l'app per dispositivi mobili può accedere o meno.

    Per il web IdPs, ti consigliamo di utilizzare Amazon Cognito per gestire le identità. In tal caso, si utilizza una policy di attendibilità simile all'esempio seguente.

    JSON
    {
    "Version":"2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Principal": {"Federated": "cognito-identity.amazonaws.com"},
        "Action": "sts:AssumeRoleWithWebIdentity",
        "Condition": {
            "StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east-2:12345678-abcd-abcd-abcd-123456"},
            "ForAnyValue:StringLike": {"cognito-identity.amazonaws.com:amr": "unauthenticated"}
        }
    }
}

    Sostituisci us-east-2:12345678-abcd-abcd-abcd-123456 con l'ID del pool di identità che ti ha assegnato Amazon Cognito.

    Nella configurazione manuale di un IdP OIDC, al momento della creazione della policy di attendibilità occorre utilizzare tre valori che garantiscono che solo l'app in questione possa assumere quel ruolo:

    • Per l'elemento Action, si utilizza l'operazione sts:AssumeRoleWithWebIdentity.

    • Per l'elemento Principal, usa la stringa {"Federated":providerUrl/providerArn}.

      • Per alcuni OIDC comuni IdPs, è un URL. providerUrl Gli esempi seguenti includono metodi per specificare il principio per alcuni comuni: IdPs

        "Principal":{"Federated":"cognito-identity.amazonaws.com"}

        "Principal":{"Federated":"www.amazon.com"}

        "Principal":{"Federated":"graph.facebook.com"}

        "Principal":{"Federated":"accounts.google.com"}

      • Per gli altri gestori OIDC, utilizza il nome della risorsa Amazon (ARN) dell'IdP OIDC creato in Passo 2, come nell'esempio seguente:

        "Principal":{"Federated":"arn:aws:iam::123456789012:oidc-provider/server.example.com"}

    • Per l'elemento Condition, si utilizza una condizione StringEquals per limitare le autorizzazioni. È necessario testare l'ID del pool di identità per Amazon Cognito o l'ID app per altri provider. L'ID del pool di identità dovrebbe corrispondere all'ID app che hai ricevuto durante la configurazione dell'app con l'IdP. Questa corrispondenza tra gli ID assicura che la richiesta provenga dalla tua app.

      Nota

      I ruoli IAM per i pool di identità di Amazon Cognito si affidano al principale del servizio cognito-identity.amazonaws.com per assumere il ruolo. I ruoli di questo tipo devono contenere almeno una chiave di condizione per limitare i principali che possono assumere il ruolo.

      Considerazioni aggiuntive si applicano ai pool di identità di Amazon Cognito che assumono ruoli IAM su più account. Le policy di attendibilità di questi ruoli devono accettare il principale del servizio cognito-identity.amazonaws.com e devono contenere la chiave di condizione aud per limitare l'assunzione di ruoli agli utenti dei pool di identità previsti. Una policy che considera attendibili i pool di identità di Amazon Cognito senza questa condizione comporta il rischio che un utente proveniente da un pool di identità non intenzionale possa assumere il ruolo. Per ulteriori informazioni, consulta Policy di attendibilità per i ruoli IAM nell'autenticazione di base (classica) nella Guida per gli sviluppatori di Amazon Cognito.

      Crea un elemento condizione simile agli esempi seguenti, a seconda dell'IdP in uso:

      "Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}}

      "Condition": {"StringEquals": {"www.amazon.com:app_id": "amzn1.application-oa2-123456"}}

      "Condition": {"StringEquals": {"graph.facebook.com:app_id": "111222333444555"}}

      "Condition": {"StringEquals": {"accounts.google.com:aud": "66677788899900pro0"}}

      Per i provider OIDC, si utilizza l'URL completo del provider di identità OIDC con la chiave di contesto aud, come nell'esempio seguente:

      "Condition": {"StringEquals": {"server.example.com:aud": "appid_from_oidc_idp"}}

    Nota

    I valori per il principale nella policy di attendibilità per il ruolo sono specifici dell'IdP. Un ruolo per OIDC può specificare solo un principale. Pertanto, se l'app per dispositivi mobili consente agli utenti di effettuare l'accesso da più di un IdP, devi creare un ruolo separato per ogni IdP da supportare. Crea policy di attendibilità separate per ogni IdP.

    Se un utente utilizza un'app per dispositivi mobili per accedere da Login with Amazon, si applica la policy di attendibilità di esempio riportata di seguito. Nell'esempio, amzn1.application-oa2-123456 rappresenta l'ID dell'app che Amazon assegna quando hai configurato l'app utilizzando Login with Amazon.

    JSON
    {
      "Version":"2012-10-17",
      "Statement": [{
          "Sid": "RoleForLoginWithAmazon",
          "Effect": "Allow",
          "Principal": {"Federated": "www.amazon.com"},
          "Action": "sts:AssumeRoleWithWebIdentity",
          "Condition": {"StringEquals": {"www.amazon.com:app_id": "amzn1.application-oa2-123456"}}
      }]
  }

    Se un utente utilizza un'app per dispositivi mobili per accedere da Facebook, si applica la policy di attendibilità di esempio riportata di seguito. In questo esempio, 111222333444555 rappresenta l'ID dell'app assegnato da Facebook.

    JSON
    {
      "Version":"2012-10-17",
      "Statement": [{
          "Sid": "RoleForFacebook",
          "Effect": "Allow",
          "Principal": {"Federated": "graph.facebook.com"},
          "Action": "sts:AssumeRoleWithWebIdentity",
          "Condition": {"StringEquals": {"graph.facebook.com:app_id": "111222333444555"}}
      }]
  }

    Se un utente utilizza un'app per dispositivi mobili per accedere da Google, si applica la policy di attendibilità di esempio riportata di seguito. In questo esempio, 666777888999000 rappresenta l'ID dell'app assegnato da Google.

    JSON
    {
      "Version":"2012-10-17",
      "Statement": [{
          "Sid": "RoleForGoogle",
          "Effect": "Allow",
          "Principal": {"Federated": "accounts.google.com"},
          "Action": "sts:AssumeRoleWithWebIdentity",
          "Condition": {"StringEquals": {"accounts.google.com:aud": "666777888999000"}}
      }]
  }

    Se un utente utilizza un'app per dispositivi mobili per accedere da Amazon Cognito, si applica la policy di attendibilità di esempio riportata di seguito. In questo esempio, us-east:12345678-ffff-ffff-ffff-123456 rappresenta l'ID del pool di identità assegnato da Amazon Cognito.

    JSON
    {
      "Version":"2012-10-17",
      "Statement": [{
          "Sid": "RoleForCognito",
          "Effect": "Allow",
          "Principal": {"Federated": "cognito-identity.amazonaws.com"},
          "Action": "sts:AssumeRoleWithWebIdentity",
          "Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}}
      }]
  }

Creazione di un ruolo per OIDC

Una volta completati i prerequisiti, puoi creare il ruolo in IAM. Per i provider di identità condivisi OpenID Connect (OIDC) riconosciuti (IdPs), IAM richiede una valutazione esplicita di dichiarazioni specifiche in JSON Web Tokens (JWT), note come controlli dei provider di identità. Per ulteriori informazioni su quali OIDC dispongono dei controlli relativi ai provider di identità, consulta. IdPs Identity-provider controlli per provider OIDC condivisi

Nella procedura seguente viene descritto come creare il ruolo per la federazione OIDC nella Console di gestione AWS. Per creare un ruolo dall' AWS API AWS CLI or, consulta le procedure in. Creazione di un ruolo per un provider di identità di terze parti

Importante

Se utilizzi Amazon Cognito, utilizza la console di Amazon Cognito per configurare i ruoli. In caso contrario, usa la console IAM per creare un ruolo per la federazione OIDC.

Per creare un ruolo IAM per la federazione OIDC

  1. Accedi Console di gestione AWS e apri la console IAM all'indirizzo https://console.aws.amazon.com/iam/.

  2. Nel riquadro di navigazione, scegli Ruoli, quindi Crea ruolo.

  3. Scegli Identità Web come tipo di entità attendibile e seleziona Avanti.

  4. Per Identity provider (Gestore dell'identità digitale [IdP]), scegli l'IdP per il ruolo:

    • Se vuoi creare un ruolo per un singolo IdP Web, scegli Login with Amazon, Facebook o Google.

      Nota

      Devi creare un ruolo separato per ogni IdP che intendi supportare.

    • Se vuoi creare un ruolo per uno scenario avanzato per Amazon Cognito, scegli Amazon Cognito.

      Nota

      Devi creare manualmente un ruolo da utilizzare con Amazon Cognito solo quando operi in uno scenario avanzato. In caso contrario, i ruoli possono essere creati da Amazon Cognito. Per ulteriori informazioni su Amazon Cognito, consulta la pagina Provider di identità esterni di pool di identità (identità federate) nella Guida per gli sviluppatori di Amazon Cognito.

    • Se desideri creare un ruolo per GitHub Actions, devi iniziare aggiungendo il provider GitHub OIDC a IAM. Dopo aver aggiunto il provider GitHub OIDC a IAM, scegli token.actions.githubusercontent.com.

      Nota

      Per informazioni su come configurare il provider OIDC di AWS to trust come identità federata, consulta GitHub Docs - Configuring OpenID Connect in Amazon Web Services. GitHub Per informazioni sulle best practice per limitare l'accesso ai ruoli associati all'IAM IdP per, consulta questa pagina. GitHub Configurazione di un ruolo per il provider di GitHub identità OIDC

    • Se desideri creare un ruolo per HashiCorp Cloud Platform (HCP) Terraform, devi iniziare aggiungendo il provider OIDC Terraform a IAM. Dopo aver aggiunto il provider OIDC Terraform a IAM, scegli app.terraform.io.

      Importante

      I ruoli IAM per il provider OIDC Terraform HashiCorp Cloud Platform (HCP) devono valutare la chiave di condizione IAM, nella policy di fiducia dei ruoli. app.terraform.io:sub Questa chiave di condizione limita le organizzazioni, i progetti, gli spazi di lavoro o le fasi di esecuzione di HCP Terraform in grado di assumere il ruolo. Senza questa chiave condizionale, la tua politica di fiducia garantisce l'accesso al tuo ruolo e alle tue AWS risorse da identità esterne alla tua organizzazione, il che non è in linea con il principio del privilegio minimo.

      Se imposti o modifichi una politica di fiducia dei ruoli per un ruolo associato al provider HCP Terraform OIDC nel tuo AWS account, ma non valuti la chiave di condizione IAM, riceverai un errore. app.terraform.io:sub Inoltre, AWS STS negherà le richieste di autorizzazione se la policy di attendibilità del ruolo non valuta questa chiave di condizione.

  5. Le informazioni richieste variano in base al provider OIDC scelto.

    • Inserisci l'identificatore per l'applicazione. L'etichetta relativa all'identificatore cambia in base al gestore scelto:

      • Se vuoi creare un ruolo per Login with Amazon, inserisci l'ID app nella casella Application ID (ID applicazione).

      • Se vuoi creare un ruolo per Facebook, inserisci l'ID app nella casella Application ID (ID applicazione).

      • Se vuoi creare un ruolo per Google, inserisci il nome del destinatario nella casella Audience (Destinatario).

      • Se vuoi creare un ruolo per Amazon Cognito, inserisci l'ID del pool di identità che hai creato per le applicazioni Amazon Cognito nella casella Identity Pool ID (ID pool di identità).

    • Se desideri creare un ruolo per GitHub Actions, inserisci i seguenti dettagli:

      • Per Pubblico, scegli sts.amazonaws.com.

      • Per GitHub l'organizzazione, inserisci il nome GitHub dell'organizzazione. Il nome GitHub dell'organizzazione è obbligatorio e deve essere alfanumerico, compresi i trattini (-). Non puoi usare caratteri jolly (* e?) nel nome dell' GitHub organizzazione.

      • (Facoltativo) Per il GitHub repository, inserisci il nome del GitHub repository. Se non specifichi un valore, viene utilizzato un carattere jolly (*) per impostazione predefinita.

      • (Facoltativo) Per la GitHub filiale, inserisci il nome della GitHub filiale. Se non specifichi un valore, viene utilizzato un carattere jolly (*) per impostazione predefinita.

    • Se desideri creare un ruolo per HashiCorp Cloud Platform (HCP) Terraform, inserisci i seguenti dettagli:

      • Per Pubblico, scegli aws.workload.identity.

      • Per Organizzazione, inserisci il nome dell'organizzazione. È possibile specificare un carattere jolly (*) per tutte le organizzazioni.

      • Per Progetto, inserisci il nome del progetto. È possibile specificare un carattere jolly (*) per tutti i progetti.

      • In Spazio di lavoro, immetti un nome per lo spazio di lavoro. È possibile specificare un carattere jolly (*) per tutti gli spazi di lavoro.

      • Per Fase di esecuzione, inserisci il nome della fase di esecuzione. È possibile specificare un carattere jolly (*) per tutte le fasi di esecuzione.

  6. (Facoltativo) In Condizione (facoltativo) scegli Aggiungi condizioneper creare condizioni aggiuntive che devono essere soddisfatte prima che gli utenti dell'applicazione possano utilizzare le autorizzazioni concesse dal ruolo. Ad esempio, puoi aggiungere una condizione che conceda l'accesso alle AWS risorse solo per un ID utente IAM specifico. Puoi anche aggiungere condizioni alla policy di attendibilità dopo la creazione del ruolo. Per ulteriori informazioni, consulta Aggiornamento di una policy di attendibilità del ruolo.

  7. Verifica le informazioni su OIDC, quindi seleziona Successivo.

  8. IAM include un elenco delle policy AWS gestite e gestite dal cliente nel tuo account. Seleziona la policy delle autorizzazioni da utilizzare o scegli Create policy (Crea policy) per aprire una nuova scheda del browser e creare una nuova policy da zero. Per ulteriori informazioni, consulta Creazione di policy IAM. Una volta creata la policy, chiudere la scheda e tornare alla scheda originale. Seleziona la casella di controllo accanto alle policy di autorizzazione che si desidera abbiano gli utenti OIDC. È anche possibile non selezionare le policy ora e collegarle al ruolo in un secondo momento. Per default, un ruolo non dispone di autorizzazioni.

  9. (Facoltativo) Impostare un limite delle autorizzazioni. Questa è una caratteristica avanzata.

    Apri la sezione Permissions boundary (Limite delle autorizzazioni) e scegli Use a permissions boundary to control the maximum role permissions (Usa un limite delle autorizzazioni per controllare il numero massimo di autorizzazioni del ruolo). Selezionare la policy da utilizzare per il limite delle autorizzazioni.

  10. Scegli Next (Successivo).

  11. In Role name, (Nome ruolo), inserisci un nome. I nomi dei ruoli devono essere univoci all'interno del tuo Account AWS. Non fanno distinzione tra maiuscole e minuscole. Ad esempio, non è possibile creare ruoli denominati sia PRODROLE sia prodrole. Poiché altre AWS risorse potrebbero fare riferimento al ruolo, non puoi modificare il nome del ruolo dopo averlo creato.

  12. (Facoltativo) In Description (Descrizione), inserisci una descrizione per il nuovo ruolo.

  13. Per modificare i casi d'uso e le autorizzazioni per il ruolo, scegli Edit (Modifica) nelle sezioni Step 1: Select trusted entities (Fase 1: seleziona le entità attendibili) o Step 2: Add permissions (Fase 2: aggiungi autorizzazioni).

  14. (Facoltativo) Per aggiungere metadati al ruolo, collegare i tag come coppie chiave-valore. Per ulteriori informazioni sull'utilizzo dei tag in IAM, consultare Tag per AWS Identity and Access Management le risorse.

  15. Rivedere il ruolo e scegliere Crea ruolo.

Configurazione di un ruolo per il provider di GitHub identità OIDC

Se lo utilizzi GitHub come provider di identità (IdP) OpenID Connect (OIDC), la procedura migliore è limitare le entità che possono assumere il ruolo associato all'IdP IAM. Quando includi una dichiarazione di condizione nella policy di fiducia, puoi limitare il ruolo a un' GitHuborganizzazione, un repository o una filiale specifici. Puoi usare la chiave di condizione token.actions.githubusercontent.com:sub con operatori di condizione delle stringhe per limitare l'accesso. Si consiglia di limitare la condizione a un insieme specifico di repository o filiali all'interno dell'organizzazione GitHub . Per informazioni su come configurare l'OIDC AWS GitHub di trust come identità federata, consulta GitHub Docs - Configuring OpenID Connect in Amazon Web Services.

Se utilizzi GitHub gli ambienti nei flussi di lavoro in azione o nelle politiche OIDC, ti consigliamo vivamente di aggiungere regole di protezione all'ambiente per una maggiore sicurezza. Utilizza i rami e i tag di implementazione per limitare i rami e i tag che possono essere implementati nell'ambiente. Per ulteriori informazioni sulla configurazione degli ambienti con regole di protezione, consulta i rami e i tag di distribuzione nell' GitHubarticolo Using environment for deployment.

Quando GitHub l'IdP OIDC è il Principal affidabile per il tuo ruolo, IAM controlla la condizione della politica di attendibilità del ruolo per verificare che la chiave di condizione token.actions.githubusercontent.com:sub sia presente e che il suo valore non sia solo un carattere jolly (* e?) o null. IAM esegue questo controllo quando la policy di attendibilità viene creata o aggiornata. Se la chiave di condizione token.actions.githubusercontent.com:sub non è presente o il valore della chiave non soddisfa i criteri di valore indicati, la richiesta avrà esito negativo e restituirà un errore.

Importante

Se non limiti la chiave condizionale a un'organizzazione o token.actions.githubusercontent.com:sub a un repository specifico, GitHub le azioni provenienti da organizzazioni o repository al di fuori del tuo controllo possono assumere i ruoli associati all' GitHub IdP IAM nel tuo account. AWS

Il seguente esempio di politica di fiducia limita l'accesso all' GitHub organizzazione, al repository e alla filiale definiti. Il token.actions.githubusercontent.com:sub valore della chiave di condizione nell'esempio seguente è il formato predefinito del valore dell'oggetto documentato da. GitHub

JSON
{
  "Version":"2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::012345678910:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
          "token.actions.githubusercontent.com:sub": "repo:GitHubOrg/GitHubRepo:ref:refs/heads/GitHubBranch"
        }
      }
    }
  ]
}

La seguente condizione di esempio limita l'accesso all' GitHub organizzazione e al repository definiti, ma concede l'accesso a qualsiasi filiale all'interno del repository.

"Condition": {
  "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
  },
  "StringLike": {    
    "token.actions.githubusercontent.com:sub": "repo:GitHubOrg/GitHubRepo:*"
  }
}

La seguente condizione di esempio limita l'accesso a qualsiasi repository o filiale all'interno dell'organizzazione definita. GitHub Si consiglia di limitare la chiave condizionale token.actions.githubusercontent.com:sub a un valore specifico che limiti l'accesso alle GitHub azioni dall'interno GitHub dell'organizzazione.

"Condition": {
  "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
  },
  "StringLike": {    
    "token.actions.githubusercontent.com:sub": "repo:GitHubOrg/*"
  }
}

Per ulteriori informazioni sulle chiavi di federazione OIDC disponibili per i controlli delle condizioni nelle policy, consulta Chiavi disponibili per AWS Federazione OIDC.