Configura la federazione delle identità per i carichi di lavoro con Active Directory

Questa guida descrive come utilizzare la federazione delle identità per i carichi di lavoro per consentire ai carichi di lavoro di utilizzare le credenziali di Active Directory per l'autenticazione in Google Cloud.

Se esegui carichi di lavoro Windows Server in un ambiente Active Directory, questi potrebbero avere accesso alle credenziali di Active Directory. Ad esempio:

  • È possibile che un servizio Windows sia configurato per l'accesso come utente del dominio.
  • Un'applicazione IIS potrebbe essere configurata per l'esecuzione come account di servizio gestito di gruppo (gMSA).

Utilizzando la federazione delle identità per i carichi di lavoro in combinazione con Active Directory Federation Services (ADFS), puoi consentire a questi carichi di lavoro di scambiare le proprie credenziali Kerberos di Active Directory per credenziali Google Cloud a breve durata. I carichi di lavoro possono utilizzare queste credenziali di breve durata per accedere alle API Google Cloud.

Lo scambio delle credenziali di Active Directory con le credenziali Google Cloud di breve durata funziona connettendo due scambi di token:

  1. Un carico di lavoro utilizza OpenID Connect (OIDC), SAML-POST o WS-Trust per richiedere un token OIDC o un'asserzione SAML da AD FS. Per l'autenticazione in AD FS, il carico di lavoro utilizza l'autenticazione Windows integrata (IWA) e le credenziali di Active Directory esistenti.
  2. Il carico di lavoro utilizza quindi la federazione delle identità per i carichi di lavoro per scambiare il token OIDC o l'asserzione SAML con un token di Security Token Service e, facoltativamente, per rubare l'identità di un account di servizio Google Cloud.

Questo articolo spiega come automatizzare questo processo in un modo che non richieda modifiche alla tua applicazione utilizzando Workload Authenticator per Windows.

Prepara AD FS

Dovrai eseguire questi passaggi una sola volta.

Seleziona un protocollo

Il modo per preparare AD FS dipende dal protocollo che vuoi utilizzare:

  • SAML: puoi consentire ai carichi di lavoro di utilizzare SAML o WS-Trust per ottenere le asserzioni SAML.

    Per utilizzare SAML o WS-Trust, devi creare una parte coinvolta in AD FS e configurare un pool di identità per i carichi di lavoro in modo che le asserzioni emesse per tale parte coinvolta siano attendibili.

    Un carico di lavoro può utilizzare il proprio utente di Active Directory per l'autenticazione ad AD FS utilizzando l'associazione SAML-POST o WS-Trust. AD FS emette quindi un'asserzione SAML contenente informazioni sull'utente di Active Directory del carico di lavoro e informazioni aggiuntive come le iscrizioni ai gruppi.

    L'utilizzo di SAML o WS-Trust richiede AD FS 3.0, AD FS per Windows Server 2016 o una versione più recente di AD FS.

  • OIDC: puoi consentire ai carichi di lavoro di usare OIDC per ottenere i token OIDC.

    Per utilizzare OIDC, devi creare un client OIDC (applicazione nativa) e una risorsa OIDC (API web) in AD FS. Puoi quindi configurare un pool di identità per i carichi di lavoro in modo da considerare attendibili i token di accesso emessi per l'API web.

    Un carico di lavoro può utilizzare il proprio utente di Active Directory e la concessione di OAuth client_credentials per eseguire l'autenticazione in AD FS. AD FS emette quindi un token di accesso, ma nessun token ID.

    Il token di accesso contiene informazioni sull'applicazione client OIDC, ma non sull'utente Active Directory del carico di lavoro o sulle sue iscrizioni ai gruppi.

    Poiché i token di accesso non contengono informazioni sull'utente di Active Directory, l'utilizzo di OIDC può essere meno flessibile rispetto all'uso di SAML o WS-Trust.

    L'utilizzo di OIDC richiede AD FS per Windows Server 2016 o una versione successiva di AD FS.

Per l'accesso, l'IdP deve fornire le informazioni di autenticazione firmate: gli IdP OIDC devono fornire un JWT e le risposte dell'IdP SAML devono essere firmate.

Prerequisiti IWA

Questa sezione descrive i prerequisiti IWA necessari per utilizzare questa guida.

Se non hai mai utilizzato IWA con AD FS, assicurati di soddisfare i seguenti prerequisiti:

Registra il carico di lavoro

Per registrare il carico di lavoro in AD FS:

OIDC

Per consentire ai carichi di lavoro di utilizzare OIDC, sono necessarie due registrazioni di applicazioni in AD FS:

  • Una registrazione di un'applicazione di tipo applicazione nativa o applicazione server.

  • Una registrazione di un'applicazione di tipo API web che corrisponde a un provider di pool di identità per i carichi di lavoro su Google Cloud.

Registrazione dell'applicazione client

Crea un'applicazione client che rappresenti il carico di lavoro. Se hai più carichi di lavoro che richiedono l'accesso a Google Cloud, potrebbe essere necessario creare più applicazioni client.

Per registrare un'applicazione client in AD FS:

  1. Apri lo snapshot MMC di AD FS e vai a Gruppi di applicazioni.
  2. Fai clic su Aggiungi gruppo di applicazioni.
  3. Nella pagina Ti diamo il benvenuto, procedi nel seguente modo:

    1. Nel campo di testo, inserisci un nome per il cliente.
    2. Seleziona Applicazione server.
    3. Tocca Avanti.
  4. Nella pagina Applicazione server, procedi nel seguente modo:

    1. Nel campo di testo , inserisci un identificatore client (ID client) e un URI di reindirizzamento.

      Se prevedi di utilizzare solo il tipo di autorizzazione client_credentials, l'URI di reindirizzamento non verrà utilizzato e puoi utilizzare un URI come http://localhost/.

    2. Tocca Avanti.

  5. Nella pagina Configura credenziali applicazione, segui questi passaggi:

    1. Scegli la modalità di autenticazione del client. Per utilizzare IWA, imposta Autenticazione integrata di Windows su abilitata.
    2. Seleziona l'utente del dominio per cui è configurata l'applicazione per l'esecuzione dell'applicazione.
    3. Tocca Avanti.
  6. Nella pagina Riepilogo, esamina le impostazioni e fai clic su Avanti.

  7. Fai clic su Chiudi per chiudere la finestra di dialogo.

Creazione di un'applicazione API web per il pool di identità per i carichi di lavoro

Crea un'altra registrazione dell'applicazione di tipo API web. Questa applicazione corrisponde a un provider di pool di identità per i carichi di lavoro. La utilizzi per configurare una relazione di attendibilità con Google Cloud.

Per creare l'applicazione in AD FS:

  1. Apri lo snapshot MMC di AD FS e vai a Gruppi di applicazioni.
  2. Fai clic su Aggiungi gruppo di applicazioni.
  3. Nella pagina di benvenuto, inserisci un nome, ad esempio Workload Identity Federation (test environment), e seleziona API web. Quindi, fai clic su Avanti.
  4. Nella pagina Configura API web, inserisci un identificatore della parte richiedente per l'API web.

    Anziché definire un identificatore della parte attendibile, puoi utilizzare il seguente URI come identificatore della parte attendibile:

    https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_POOL_ID/providers/PROVIDER_ID
    

    Sostituisci quanto segue:

    • PROJECT_NUMBER: il numero di progetto del progetto Google Cloud che utilizzi per creare il pool di identità per i carichi di lavoro.
    • WORKLOAD_POOL_ID: un ID a tua scelta che identifica il pool di identità per i carichi di lavoro. Devi utilizzare lo stesso ID durante la creazione del pool di identità per i carichi di lavoro in un secondo momento.
    • PROVIDER_ID: un ID a tua scelta che identifica il provider del pool di identità per i carichi di lavoro. Devi utilizzare lo stesso ID quando crei il provider del pool di identità per i carichi di lavoro in un secondo momento.

    La formattazione dell'URI in questo modo garantisce che l'identificatore della parte richiedente identifichi in modo univoco un provider di pool di identità per i carichi di lavoro.

    L'identificatore della parte utilizzante ti servirà in un secondo momento, quando configurerai il provider del pool di identità del carico di lavoro.

  5. Tocca Avanti.

  6. Nella pagina Applica controllo dell'accesso dell'accesso, seleziona un criterio di accesso appropriato, quindi fai clic su Avanti.

  7. Nella pagina Configura le autorizzazioni delle applicazioni, aggiungi l'applicazione client creata in precedenza. Quindi, fai clic su Avanti.

  8. Nella pagina Riepilogo, esamina le impostazioni e fai clic su Avanti.

  9. Fai clic su Chiudi per chiudere la finestra di dialogo.

SAML o WS-Trust

Crea un'attendibilità di parte in AD FS:

  1. Apri l'agganciamento MMC di AD FS.
  2. Vai a Considerato fiducia nell'ambito di un'altra parte.
  3. Fai clic su Aggiungi attendibilità componente.
  4. Nella pagina Benvenuto della procedura guidata Aggiungi attendibilità componente, segui questi passaggi:
    1. Seleziona Consapevole delle rivendicazioni.
    2. Fai clic su Avvia.
  5. Nella pagina Seleziona origine dati, segui questi passaggi:
    1. Seleziona Inserisci manualmente i dati sul richiedente.
    2. Tocca Avanti.
  6. Nella pagina Specifica il nome visualizzato, segui questi passaggi:

    1. Inserisci un nome per il trust.
    2. Tocca Avanti.
  7. Nella pagina Configura il certificato, fai clic su Avanti. Sebbene la federazione delle identità per i carichi di lavoro supporti SAML criptato, non è descritta in questa procedura. Per saperne di più, consulta le istruzioni gcloud CLI in Creare un pool di identità e il provider, più avanti in questa guida.

  8. Nella pagina Configura URL, procedi nel seguente modo:

    SAML

    Utilizza le seguenti impostazioni:

    • Imposta Attiva il supporto per il protocollo WebSSO SAML 2.0 su abilitato.
    • Nel campo Relying Party SAML 2.0 SSO service URL (URL del servizio SSO SAML 2.0), inserisci il seguente URL:

      https://sts.googleapis.com/v1/token
      

    WS-Trust

    Mantieni le impostazioni predefinite

  9. Tocca Avanti.

  10. Nella pagina Configura identificatori, inserisci un identificatore della parte utilizzata.

    Anziché definire un identificatore della parte attendibile, puoi utilizzare il seguente URI come identificatore della parte attendibile:

    https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_POOL_ID/providers/PROVIDER_ID
    

    Sostituisci quanto segue:

    • PROJECT_NUMBER: il numero di progetto del progetto Google Cloud che utilizzi per creare il pool di identità per i carichi di lavoro.
    • WORKLOAD_POOL_ID: un ID a tua scelta che identifica il pool di identità per i carichi di lavoro. Devi utilizzare lo stesso ID durante la creazione del pool di identità per i carichi di lavoro in un secondo momento.
    • PROVIDER_ID: un ID a tua scelta che identifica il provider del pool di identità per i carichi di lavoro. Devi utilizzare lo stesso ID durante la creazione del provider del pool di identità per i carichi di lavoro in un secondo momento.

    La formattazione dell'URI in questo modo garantisce che l'identificatore della parte richiedente identifichi in modo univoco un provider di pool di identità per i carichi di lavoro.

    L'identificatore della parte utilizzante ti servirà in un secondo momento, quando configurerai il provider del pool di identità del carico di lavoro.

  11. Tocca Avanti.

  12. Nella pagina Scegli il controllo dell'accesso dell'accesso, seleziona un criterio di controllo dell'accesso appropriato e fai clic su Avanti.

  13. Nella pagina Tutto pronto per l'aggiunta di attendibilità, rivedi le impostazioni e fai clic su Avanti.

  14. Nella pagina Fine, fai clic su Chiudi per chiudere la finestra di dialogo.

Per essere compatibili con la federazione delle identità per i carichi di lavoro, le asserzioni SAML devono contenere almeno un'attestazione che identifica in modo univoco l'utente di Active Directory. In genere, a questo scopo viene utilizzata l'attestazione Name ID, che corrisponde al valore dell'elemento NameID nell'asserzione SAML.

Per personalizzare l'insieme di attestazioni dell'asserzione SAML, devi modificare le norme di emissione delle rivendicazioni della parte attendibile. Per modificare le norme di emissione delle rivendicazioni:

  1. Nell'elenco dei trust di parti, seleziona il trust che hai appena creato e fai clic su Modifica norma di emissione delle rivendicazioni.
  2. Fai clic su Aggiungi regola.
  3. Nella pagina Scegli il tipo di regola della procedura guidata Aggiungi regola di trasformazione, procedi nel seguente modo:
    1. Seleziona Trasforma una rivendicazione in arrivo.
    2. Tocca Avanti.
  4. Nella pagina Configura regola di rivendicazione, configura le seguenti impostazioni:

    • Nome regola di rivendicazione: Name Identifier.
    • Tipo di rivendicazione in entrata: seleziona SID principale, UPN o una rivendicazione diversa per identificare in modo univoco il soggetto.
    • Tipo di attestazione in uscita: ID nome.
    • Formato ID nome in uscita: non specificato.
  5. Seleziona Supera tutti i valori delle rivendicazioni e fai clic su Fine.

  6. Se vuoi, configura regole aggiuntive per includere più attributi nelle asserzioni SAML.

  7. Fai clic su OK per chiudere la finestra di dialogo delle norme di emissione delle rivendicazioni.

Configura la federazione delle identità per i carichi di lavoro

Devi eseguire questi passaggi solo una volta per ogni tenant di Azure AD o con l'account AWS con cui vuoi effettuare la federazione. Puoi quindi utilizzare lo stesso pool di identità per i carichi di lavoro e lo stesso provider per più carichi di lavoro e su più progetti Google Cloud.

Per avviare la configurazione della federazione delle identità per i carichi di lavoro:

  1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  2. È preferibile utilizzare un progetto dedicato per gestire provider e pool di identità per i carichi di lavoro.
  3. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

  4. Abilita le API IAM, Resource Manager, Service Account Credentials, and Security Token Service.

    Abilita le API

Definisci una mappatura e una condizione degli attributi

Le credenziali specifiche per l'ambiente del tuo carico di lavoro AWS o Azure contengono più attributi e devi decidere quale attributo utilizzare come identificatore soggetto (google.subject) in Google Cloud.

Se vuoi, puoi mappare ulteriori attributi. Puoi quindi fare riferimento a questi attributi aggiuntivi quando concedi l'accesso alle risorse.

OIDC

Le mappature degli attributi possono utilizzare le rivendicazioni incorporate nei token di accesso AD FS come attributi di origine.

Per autenticare un'applicazione, puoi utilizzare la seguente mappatura degli attributi:

google.subject=assertion.appid

Questa mappatura imposta google.subject sul valore dell'attestazione appid, che contiene l'ID client dell'applicazione AD FS.

SAML o WS-Trust

I mapping degli attributi possono utilizzare le rivendicazioni incorporate nell'asserzione emessa da AD FS, come descritto in precedenza in questa guida.

Utilizza la mappatura seguente per consentire alla federazione delle identità per i carichi di lavoro di utilizzare l'attestazione ID nome dell'asserzione SAML per identificare in modo univoco l'utente:

google.subject=assertion.subject

Se hai configurato i criteri di emissione delle rivendicazioni in modo da includere ulteriori rivendicazioni nelle asserzioni SAML, puoi aggiungere ulteriori mappature. Ad esempio:

google.groups=assertion.attributes['http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid']
attribute.userip=['http://schemas.microsoft.com/2014/09/requestcontext/claims/userip'][0]

Facoltativamente, definisci una condizione dell'attributo. Le condizioni degli attributi sono espressioni CEL in grado di controllare gli attributi di asserzioni e gli attributi di destinazione. Se la condizione dell'attributo ha valore true per una determinata credenziale, la credenziale viene accettata. In caso contrario, la credenziale viene rifiutata.

OIDC

Puoi utilizzare una condizione degli attributi per limitare i client che possono utilizzare la federazione delle identità per i carichi di lavoro per ottenere token Google Cloud a breve durata.

Ad esempio, la condizione seguente definisce che le applicazioni devono utilizzare IWA per l'autenticazione in AD FS:

assertion.authmethod=='http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/windows'

Per controllare l'elenco delle applicazioni che possono ottenere credenziali di breve durata per Google Cloud, non definire condizioni degli attributi. Utilizza invece le autorizzazioni client in AD FS per definire le applicazioni consentite.

SAML o WS-Trust

Puoi utilizzare una condizione degli attributi per limitare gli utenti di Active Directory che possono utilizzare la federazione delle identità per i carichi di lavoro per ottenere token Google Cloud a breve durata.

Ad esempio, la condizione seguente consente solo le asserzioni SAML che includono una determinata dichiarazione di appartenenza a un gruppo:

"S-1-5-6" in google.groups

Crea il pool di identità per i carichi di lavoro e il provider

Ruoli obbligatori

Per ottenere le autorizzazioni necessarie per configurare la federazione delle identità per i carichi di lavoro, chiedi all'amministratore di concederti i seguenti ruoli IAM sul progetto:

Per saperne di più sulla concessione dei ruoli, consulta Gestire l'accesso.

Potresti anche essere in grado di ottenere le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.

In alternativa, il ruolo di base Proprietario IAM (roles/owner) include anche le autorizzazioni per configurare la federazione delle identità. Non devi concedere ruoli di base in un ambiente di produzione, ma puoi concederli in un ambiente di sviluppo o test.

Console

  1. Nella console Google Cloud, vai alla pagina Nuovo provider e pool di carichi di lavoro.

    Vai a Nuovo provider e pool di carichi di lavoro

  2. In Crea un pool di identità, inserisci quanto segue:

    • Nome: il nome del pool. Il nome viene utilizzato anche come ID pool. Non potrai modificare l'ID pool in un secondo momento.
    • Descrizione: testo che descrive lo scopo del pool.
  3. Fai clic su Continua.

  4. Configura le impostazioni del provider:

    OIDC

    • Seleziona un provider: OpenID Connect (OIDC).
    • Nome provider: il nome del provider. Il nome viene utilizzato anche come ID provider. Non puoi modificare l'ID provider in un secondo momento.
    • URL emittente: https://ADFS_DOMAIN/adfs dove ADFS_DOMAIN è il nome di dominio pubblico della farm o del server AD FS.

    SAML

    Per configurare la federazione delle identità per i carichi di lavoro da un IdP compatibile con SAML 2.0, puoi utilizzare le istruzioni di gcloud CLI.

  5. Fai clic su Continua.

  6. In Configura gli attributi del provider, aggiungi le mappature degli attributi identificate in precedenza.

  7. In Condizioni degli attributi, inserisci la condizione dell'attributo identificata in precedenza. Lascia vuoto il campo se non hai una condizione per l'attributo.

  8. Fai clic su Salva per creare il provider e il pool di identità per i carichi di lavoro.

gcloud

  1. Crea un nuovo pool di identità per i carichi di lavoro:

    gcloud iam workload-identity-pools create WORKLOAD_POOL_ID \
        --location="global" \
        --description="DESCRIPTION" \
        --display-name="DISPLAY_NAME"
    

    Sostituisci quanto segue:

    • WORKLOAD_POOL_ID: ID univoco del pool.
    • DISPLAY_NAME: nome del pool.
    • DESCRIPTION: descrizione del pool. Questa descrizione viene visualizzata quando si concede l'accesso alle identità dei pool.
  2. Aggiungi un provider di pool di identità per i carichi di lavoro:

    OIDC

    gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
        --location="global" \
        --workload-identity-pool="WORKLOAD_POOL_ID" \
        --issuer-uri="https://ADFS_DOMAIN/adfs" \
        --allowed-audiences="RELYING_PARTY_ID" \
        --attribute-mapping="MAPPINGS" \
        --attribute-condition="CONDITIONS"
    

    Sostituisci quanto segue:

    Il prefisso gcp- è riservato e non può essere utilizzato in un ID pool o provider.

    SAML o WS-Trust

    curl -O https://ADFS_DOMAIN/federationmetadata/2007-06/federationmetadata.xml
    
    gcloud iam workload-identity-pools providers create-saml PROVIDER_ID \
        --location="global" \
        --workload-identity-pool="POOL_ID" \
        --idp-metadata-path="federationmetadata.xml" \
        --attribute-mapping="MAPPINGS" \
        --attribute-condition="CONDITIONS"
    

    Sostituisci quanto segue:

    Il prefisso gcp- è riservato e non può essere utilizzato in un ID pool o provider.

    Esempio:

    gcloud iam workload-identity-pools providers create-saml example-provider \
        --location="global" \
        --workload-identity-pool="pool-1" \
        --idp-metadata-path="federationmetadata.xml" \
        --attribute-mapping=google.subject=assertion.subject"
    

    (Facoltativo) Accetta le asserzioni SAML criptate dal tuo IdP

    Per consentire all'IdP SAML 2.0 di produrre asserzioni SAML criptate che possono essere accettate dalla federazione delle identità per i carichi di lavoro:

    • Nella federazione delle identità per i carichi di lavoro, segui questi passaggi:
      • Crea una coppia di chiavi asimmetriche per il provider del pool di identità per i carichi di lavoro.
      • Scarica un file di certificato contenente la chiave pubblica.
      • Configura l'IdP SAML in modo che utilizzi la chiave pubblica per criptare le asserzioni SAML che causa.
    • Nell'IdP, segui questi passaggi:
      • Consente di attivare la crittografia delle asserzioni, nota anche come crittografia dei token.
      • Carica la chiave pubblica che hai creato nella federazione delle identità per i carichi di lavoro.
      • Verifica che l'IdP generi asserzioni SAML criptate.
    Tieni presente che, anche se sono configurate le chiavi del provider di crittografia SAML, la federazione delle identità per i carichi di lavoro può comunque elaborare un'asserzione in testo non crittografato.

    Crea chiavi di crittografia delle asserzioni SAML della federazione delle identità per i carichi di lavoro

    Questa sezione illustra come creare una coppia di chiavi asimmetriche che consente alla federazione delle identità dei carichi di lavoro di accettare asserzioni SAML criptate.

    Google Cloud utilizza la chiave privata per decriptare le asserzioni SAML problematiche dall'IdP. Per creare una coppia di chiavi asimmetriche da utilizzare con la crittografia SAML, esegui questo comando. Per scoprire di più, vedi Algoritmi di crittografia SAML supportati.

    gcloud iam workload-identity-pools providers keys create KEY_ID \
        --workload-identity-pool WORKLOAD_POOL_ID \
        --provider PROVIDER_ID \
        --location global \
        --use encryption \
        --spec KEY_SPECIFICATION
    

    Sostituisci quanto segue:

    • KEY_ID: un nome chiave a tua scelta
    • WORKLOAD_POOL_ID: l'ID pool
    • PROVIDER_ID: l'ID provider
    • KEY_SPECIFICATION: la specifica della chiave, che può essere rsa-2048, rsa-3072 e rsa-4096.

    Dopo aver creato la coppia di chiavi, esegui questo comando per scaricare la chiave pubblica in un file di certificato. Solo la federazione delle identità per i carichi di lavoro ha accesso alla chiave privata.

    gcloud iam workload-identity-pools providers keys describe KEY_ID \
        --workload-identity-pool WORKLOAD_POOL_ID \
        --provider PROVIDER_ID \
        --location global \
        --format "value(keyData.key)" \
        > CERTIFICATE_PATH
    

    Sostituisci quanto segue:

    • KEY_ID: il nome della chiave
    • WORKLOAD_POOL_ID: l'ID pool
    • PROVIDER_ID: l'ID provider
    • CERTIFICATE_PATH: il percorso in cui scrivere il certificato, ad esempio saml-certificate.cer o saml-certificate.pem

    Configura il tuo IdP conforme a SAML 2.0 per emettere asserzioni SAML criptate

    1. Sposta il file del certificato nel server AD FS.
    2. Sul server AD FS, fai clic con il pulsante destro del mouse sul pulsante Start (o premi Win+X) e fai clic su Windows PowerShell (amministratore).
    3. In PowerShell, esegui questo comando per abilitare la crittografia:
              Set-AdfsRelyingPartyTrust `
              -TargetName NAME `
              -SamlResponseSignature MessageAndAssertion `
              -EncryptionCertificate PATH `
              -EncryptClaims $True
          

      Sostituisci quanto segue:

      • NAME: il nome del trust a cui fai riferimento
      • PATH: il percorso del file del certificato

    Utenti WS-Trust: questa funzionalità è disponibile solo quando utilizzi SAML.

    Dopo aver configurato l'IdP per criptare le asserzioni SAML, ti consigliamo di assicurarti che le asserzioni che genera siano effettivamente criptate. Anche se è configurata la crittografia delle asserzioni SAML, la federazione delle identità per i carichi di lavoro può comunque elaborare le asserzioni di testo non crittografato.

    Elimina le chiavi di crittografia della federazione delle identità per i carichi di lavoro

    Per eliminare le chiavi di crittografia SAML, esegui questo comando:
      gcloud iam workload-identity-pools providers keys delete KEY_ID \
          --workload-identity-pool WORKLOAD_POOL_ID \
          --provider PROVIDER_ID \
          --location global
    

    Sostituisci quanto segue:

    • KEY_ID: il nome della chiave
    • WORKLOAD_POOL_ID: l'ID pool
    • PROVIDER_ID: l'ID provider

    Algoritmi di crittografia SAML supportati

    La federazione delle identità per i carichi di lavoro supporta i seguenti algoritmi di trasporto chiave:

    La federazione delle identità per i carichi di lavoro supporta i seguenti algoritmi di crittografia a blocchi:

Autentica un carico di lavoro

Devi eseguire questi passaggi una volta per carico di lavoro.

Crea un account di servizio per il carico di lavoro esterno

  1. Abilita le API IAM, Security Token Service, and Service Account Credentials.

    Abilita le API

  2. Crea un account di servizio che rappresenti il carico di lavoro. È preferibile utilizzare un account di servizio dedicato per ogni carico di lavoro.

    L'account di servizio non deve necessariamente trovarsi nello stesso progetto del pool di identità dei carichi di lavoro.

  3. Concedi all'account di servizio l'accesso alle risorse a cui vuoi che accedano le identità esterne.

Consenti al carico di lavoro esterno di impersonare l'account di servizio

Per consentire a identità esterne di impersonare un account di servizio, concedi loro il ruolo Utente Workload Identity (roles/iam.workloadIdentityUser) per l'account di servizio. Puoi concedere il ruolo a un'identità esterna specifica o a più identità esterne:

  • Per un'identità esterna specifica, scrivi una condizione dell'attributo che controlli l'attributo google.subject.
  • Per un gruppo di identità esterne, scrivi una condizione dell'attributo che controlli l'attributo google.groups o un attributo personalizzato attribute.NAME.

Console

Per consentire alle identità esterne di impersonare un account di servizio utilizzando la console Google Cloud:

  1. Nella console Google Cloud, vai alla pagina Pool di identità carichi di lavoro.

    Vai ai pool Workload Identity

  2. Individua e seleziona il pool Workload Identity da aggiornare.

  3. Per concedere l'accesso al pool di identità per i carichi di lavoro selezionato, fai clic su Concedi l'accesso.

  4. Nell'elenco Account di servizio, seleziona l'account di servizio per le identità esterne da impersonare.

  5. Per scegliere quali identità nel pool possono impersonare l'account di servizio, esegui una delle seguenti azioni:

    • Per consentire solo a identità specifiche del pool di identità per i carichi di lavoro di assumere l'identità dell'account di servizio, seleziona Solo le identità che corrispondono al filtro.

      Nell'elenco Nome attributo, seleziona l'attributo in base al quale applicare il filtro.

      Nel campo Valore attributo, inserisci il valore previsto dell'attributo; ad esempio, se utilizzi una mappatura degli attributi google.subject=assertion.sub, imposta Nome attributo su subject e Valore attributo sul valore dell'attestazione sub nei token emessi dal tuo provider di identità esterno.

  6. Per salvare la configurazione, fai clic su Salva e poi su Ignora.

gcloud

Per consentire alle identità esterne di impersonare un account di servizio utilizzando gcloud CLI, segui questi passaggi:

  1. Per ottenere il numero del tuo progetto attuale, esegui questo comando:

    gcloud projects describe $(gcloud config get-value core/project) --format=value\(projectNumber\)
    
  2. Per concedere il ruolo Utente Workload Identity (roles/iam.workloadIdentityUser) alle identità esterne che soddisfano determinati criteri:

    Per soggetto

    gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
        --role=roles/iam.workloadIdentityUser \
        --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT"
    

    Per gruppo

    gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
        --role=roles/iam.workloadIdentityUser \
        --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP"
    

    Per attributo

    gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
        --role=roles/iam.workloadIdentityUser \
        --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE"
    

    Sostituisci quanto segue:

    • SERVICE_ACCOUNT_EMAIL: l'indirizzo email dell'account di servizio
    • PROJECT_NUMBER: il numero di progetto del progetto che contiene il pool di identità per i carichi di lavoro
    • POOL_ID: l'ID pool del pool di identità per i carichi di lavoro
    • SUBJECT: il valore previsto per l'attributo che hai mappato a google.subject
    • GROUP: il valore previsto per l'attributo che hai mappato a google.groups
    • ATTRIBUTE_NAME: il nome di un attributo personalizzato nella mappatura degli attributi

Crea una configurazione delle credenziali

Puoi consentire alle librerie client Cloud e a strumenti come gcloud CLI e Terraform di utilizzare le credenziali di Active Directory per eseguire l'autenticazione su Google Cloud utilizzando Workload Authenticator per Windows.

Workload Authenticator per Windows è uno strumento open source che funge da plug-in per le librerie client di Cloud e per strumenti come gcloud CLI:

  1. Quando lo strumento o la libreria hanno bisogno di una nuova credenziale, avvia Workload Authenticator in background.
  2. Workload Authenticator utilizza OIDC, SAML o WS-Trust per ottenere un nuovo token o una nuova asserzione SAML da AD FS e li ritrasmette allo strumento o alla libreria.
  3. Lo strumento o la libreria utilizza quindi il token o l'asserzione SAML rispetto a credenziali Google Cloud di breve durata utilizzando la federazione delle identità per i carichi di lavoro.

Per utilizzare Workload Authenticator per Windows, devi creare un file di configurazione delle credenziali. Questo file definisce quanto segue:

  • Dove trovare l'eseguibile Workload Authenticator per Windows (wwauth.exe) e i parametri con cui eseguirlo
  • Provider di identità e pool di identità per i carichi di lavoro da utilizzare
  • Quale account di servizio utilizzare

Per creare un file di configurazione delle credenziali, esegui queste operazioni su Windows Server che esegue il carico di lavoro:

  1. Fai clic con il pulsante destro del mouse sul pulsante Start (o premi Win+X) e fai clic su Windows PowerShell.
  2. Scarica Workload Authenticator per Windows e salvalo in una posizione accessibile al tuo carico di lavoro:

    (New-Object Net.WebClient).DownloadFile(
      "https://github.com/GoogleCloudPlatform/iam-windows-authenticator/releases/latest/download/wwauth.exe",
      "${env:ProgramData}\wwauth.exe")
    

    Se crei un file di configurazione delle credenziali utilizzando Workload Authenticator per Windows, il file conterrà il percorso del relativo eseguibile. Se in seguito elimini o sposti l'eseguibile, i carichi di lavoro non potranno trovarlo e utilizzarlo.

  3. Avvia wwauth.exe:

    & ${env:ProgramData}\wwauth.exe
    

    Si apre una finestra di dialogo di configurazione:

    Workload Authenticator

  4. Seleziona la scheda AD FS e inserisci le seguenti impostazioni:

    • URI emittente del server AD FS: URI pubblico del server o della farm AD FS.

      https://ADFS_DOMAIN/adfs/
      

      Sostituisci ADFS_DOMAIN con il nome di dominio pubblico del server AD FS o della server farm.

    Le impostazioni successive dipendono dal protocollo che vuoi utilizzare:

    OIDC

    • Protocollo: AdfsOidc
    • ID parte di riferimento: mantieni l'impostazione predefinita.
    • ID client Identificatore client (ID client) dell'applicazione server in AD FS.

    SAML

    • Protocollo: AdfsSamlPost
    • URL Assertion Consumer Service (URL Assertion Consumer Service): https://sts.googleapis.com/v1/token.
    • Firma le richieste utilizzando il certificato: disabilitato

    WS-Trust

    • Protocollo: AdfsWsTrust
  5. Seleziona la scheda Identità carico di lavoro e inserisci le seguenti impostazioni:

    • Numero di progetto: numero di progetto che contiene il pool Identity per i carichi di lavoro
    • ID pool: ID del pool di identità per i carichi di lavoro
    • ID provider: ID del provider del pool di identità per i carichi di lavoro
    • Impersona account di servizio: abilitato
    • Indirizzo email: l'indirizzo email dell'account di servizio.
  6. Seleziona la scheda AD FS e verifica che il campo ID parte di riferimento contenga ora l'URL del provider del pool di identità per i carichi di lavoro.

  7. Fai clic su Applica e scegli una posizione in cui salvare il file di configurazione delle credenziali.

    A differenza di una chiave dell'account di servizio, un file di configurazione delle credenziali non contiene alcun secret e non deve essere necessariamente riservato. I dettagli sul file di configurazione delle credenziali sono disponibili all'indirizzo https://google.aip.dev/auth/4117.

Ora tutto è pronto per testare la configurazione:

  1. Seleziona un utente di Active Directory con cui eseguire il test. Può essere l'utente di Active Directory del carico di lavoro o l'utente con cui hai eseguito l'accesso.

  2. Per testare la configurazione con l'utente corrente, fai clic su Testa.

    Per eseguire il test con un altro utente, seleziona Test > Testa configurazione come utente e inserisci le credenziali dell'utente.

    Lo strumento ora tenta di autenticarsi su Google Cloud eseguendo questi passaggi:

    1. Acquisisci un token OIDC o un'asserzione SAML da AD FS.
    2. Procurati un token del servizio token di sicurezza di Google.
    3. Utilizza l'identità dell'account di servizio.

    Se l'autenticazione ha esito positivo, viene visualizzato il messaggio Test completato correttamente:

    Risultato test

Utilizzo della configurazione delle credenziali per accedere a Google Cloud

Per consentire a strumenti e librerie client di utilizzare la configurazione delle credenziali, segui questi passaggi su Windows Server che esegue il carico di lavoro:

  1. Fai clic con il pulsante destro del mouse sul pulsante Start e fai clic su Esegui.
  2. Inserisci sysdm.cpl e fai clic su OK.
  3. Nella scheda Avanzate, fai clic su Variabili di ambiente.
  4. Nella sezione Variabili di sistema, aggiungi due nuove variabili:

    Nome Valore
    GOOGLE_APPLICATION_CREDENTIALS Percorso del file di configurazione delle credenziali
    GOOGLE_EXTERNAL_ACCOUNT_ALLOW_EXECUTABLES 1
  5. Fai clic su Ok.

  6. Utilizza una libreria client o uno strumento che supporti la federazione delle identità per i carichi di lavoro e che possa trovare le credenziali automaticamente:

    C++

    Le librerie client di Google Cloud per C++ supportano la federazione delle identità per i carichi di lavoro a partire dalla versione v2.6.0. Per utilizzare la federazione delle identità per i carichi di lavoro, devi creare le librerie client con versione 1.36.0 o successiva di gRPC.

    Go

    Le librerie client per Go supportano la federazione delle identità se utilizzano la versione v0.0.0-20210218202405-ba52d332ba99 o successiva del modulo golang.org/x/oauth2.

    Per verificare quale versione di questo modulo utilizza la tua libreria client, esegui questi comandi:

    cd $GOPATH/src/cloud.google.com/go
    go list -m golang.org/x/oauth2
    

    Java

    Le librerie client per Java supportano la federazione delle identità se utilizzano la versione 0.24.0 o successive dell'artefatto com.google.auth:google-auth-library-oauth2-http.

    Per verificare quale versione di questo artefatto utilizza la tua libreria client, esegui il seguente comando Maven nella directory dell'applicazione:

    mvn dependency:list -DincludeArtifactIds=google-auth-library-oauth2-http
    

    Node.js

    Le librerie client per Node.js supportano la federazione delle identità per i carichi di lavoro se utilizzano la versione 7.0.2 o successiva del pacchetto google-auth-library.

    Per verificare quale versione di questo pacchetto viene utilizzata dalla tua libreria client, esegui questo comando nella directory dell'applicazione:

    npm list google-auth-library
    

    Quando crei un oggetto GoogleAuth, puoi specificare un ID progetto o consentire a GoogleAuth di trovare automaticamente l'ID progetto. Per trovare automaticamente l'ID progetto, l'account di servizio nel file di configurazione deve avere il ruolo Browser (roles/browser) o un ruolo con autorizzazioni equivalenti nel progetto. Per maggiori dettagli, consulta il documento README per il pacchetto google-auth-library.

    Python

    Le librerie client per Python supportano la federazione delle identità se utilizzano la versione 1.27.0 o successiva del pacchetto google-auth.

    Per verificare quale versione di questo pacchetto viene utilizzata dalla tua libreria client, esegui questo comando nell'ambiente in cui è installato il pacchetto:

    pip show google-auth
    

    Per specificare un ID progetto per il client di autenticazione, puoi impostare la variabile di ambiente GOOGLE_CLOUD_PROJECT o consentire al client di trovare automaticamente l'ID progetto. Per trovare automaticamente l'ID progetto, l'account di servizio nel file di configurazione deve avere il ruolo Browser (roles/browser) o un ruolo con autorizzazioni equivalenti nel progetto. Per i dettagli, consulta la guida dell'utente per il pacchetto google-auth.

    gcloud

    Per eseguire l'autenticazione con la federazione delle identità per i carichi di lavoro, utilizza il comando gcloud auth login:

    gcloud auth login --cred-file=FILEPATH.json
    

    Sostituisci FILEPATH con il percorso del file di configurazione delle credenziali.

    Il supporto per la federazione delle identità per i carichi di lavoro in gcloud CLI è disponibile nella versione 363.0.0 e successive di gcloud CLI.

    Terraform

    Il provider Google Cloud supporta la federazione delle identità per i carichi di lavoro se utilizzi la versione 3.61.0 o successive:

    terraform {
      required_providers {
        google = {
          source  = "hashicorp/google"
          version = "~> 3.61.0"
        }
      }
    }
    

    gsutil

    Per eseguire l'autenticazione con la federazione delle identità per i carichi di lavoro, utilizza uno dei seguenti metodi:

    Quando utilizzi gsutil in combinazione con gcloud, accedi normalmente:

    gcloud auth login --cred-file=FILEPATH.json
    

    Quando utilizzi gsutil come applicazione a riga di comando autonoma, modifica il file .boto in modo da includere la seguente sezione:

    [Credentials]
    gs_external_account_file = FILEPATH
    

    In entrambi i casi, sostituisci FILEPATH con il percorso del file di configurazione delle credenziali.

    Il supporto per la federazione delle identità per i carichi di lavoro in gsutil è disponibile nella versione 379.0.0 e nelle versioni successive di gcloud CLI.

    bq

    Per eseguire l'autenticazione con la federazione delle identità per i carichi di lavoro, utilizza il comando gcloud auth login come segue:

    gcloud auth login --cred-file=FILEPATH.json
    

    Sostituisci FILEPATH con il percorso del file di configurazione delle credenziali.

    Il supporto per la federazione delle identità per i carichi di lavoro in bq è disponibile nella versione 390.0.0 e successive di gcloud CLI.

Passaggi successivi