Federazione delle identità per i workload

Questo documento fornisce una panoramica della federazione delle identità per i workload. Utilizzando la federazione delle identità per i workload, puoi fornire ai workload on-premise o multi-cloud l'accesso alle risorse Cloud de Confiance by S3NS utilizzando identità federate anziché una chiave del account di servizio.

Puoi utilizzare la federazione delle identità per i workload con carichi di lavoro che eseguono l'autenticazione utilizzando certificati client X.509; che vengono eseguiti su Amazon Web Services (AWS) o Azure; Active Directory on-premise; servizi di deployment, come GitHub e GitLab; e con qualsiasi provider di identità (IdP) che supporta OpenID Connect (OIDC) o Security Assertion Markup Language (SAML) V2.0.

Perché la federazione delle identità per i workload?

Le applicazioni in esecuzione all'esterno di Cloud de Confiance possono utilizzare le chiavi del service account per accedere alle risorse Cloud de Confiance . Tuttavia, le chiavi dei account di servizio sono credenziali potenti e possono rappresentare un rischio per la sicurezza se non vengono gestite correttamente. La federazione delle identità per i workload elimina l'onere di manutenzione e sicurezza associato alle chiavi deiaccount di serviziot.

Con la federazione delle identità per i workload, puoi utilizzare Identity and Access Management (IAM) per concedere ruoli IAM alle entità basate su identità federate in un pool di identità del workload. Puoi concedere l'accesso alle entità su risorse Cloud de Confiance specifiche. Questo approccio è chiamato accesso diretto. In alternativa, puoi concedere l'accesso a un account di servizio, che può quindi accedere alle risorse Cloud de Confiance . Questo approccio è chiamato simulazione dell'identità del service account.

Pool di identità del workload

Un pool di identità del workload è un'entità che consente di gestire le identità esterne.

In generale, consigliamo di creare un nuovo pool per ogni ambiente nonCloud de Confiance che deve accedere alle risorse Cloud de Confiance , ad esempio ambienti di sviluppo, gestione temporanea o produzione.

Provider di pool di identità del workload

Un provider di pool di identità del workload è un'entità che descrive una relazione tra Cloud de Confiance e il tuo IdP, tra cui:

• AWS
• Microsoft Entra ID
• GitHub
• GitLab
• Cluster Kubernetes
• Okta
• Active Directory Federation Services (AD FS) on-premise
• Terraform

La federazione delle identità per i workload segue la specifica di scambio di token OAuth 2.0. Fornisci una credenziale dal tuo IdP al Security Token Service, che verifica l'identità nella credenziale e poi restituisce un token federato in cambio.

Provider OIDC con JWK locali

Per federare i carichi di lavoro che non hanno un endpoint OIDC pubblico, puoi caricare i set di chiavi web JSON (JWKS) OIDC direttamente nel pool. Questo è comune se hai Terraform o GitHub Enterprise ospitati nel tuo ambiente o se hai requisiti normativi per non esporre URL pubblici. Per saperne di più, consulta Gestire le JWK OIDC (facoltativo).

Mappature degli attributi

I token emessi dal tuo IdP esterno contengono uno o più attributi. Alcuni IdP fanno riferimento a questi attributi come attestazioni.

I token del servizio token di sicurezza Google contengono anche uno o più attributi, come elencato nella tabella seguente:

Una mappatura degli attributi definisce come derivare il valore dell'attributo token del servizio token di sicurezza di Google da un token esterno. Per ogni attributo del token del servizio token di sicurezza Google, puoi definire una mappatura degli attributi, formattata nel seguente modo:

TARGET_ATTRIBUTE=SOURCE_EXPRESSION

Sostituisci quanto segue:

• TARGET_ATTRIBUTE è un attributo del token del servizio token di sicurezza di Google
• SOURCE_EXPRESSION è un'espressione Common Expression Language (CEL) che trasforma uno o più attributi dei token emessi dal tuo IdP esterno

Il seguente elenco fornisce esempi di mappatura degli attributi:

• Assegna l'attributo di asserzione sub a google.subject:

  google.subject=assertion.sub
  

• Concatenare più attributi di asserzione:

  google.subject='myprovider::' + assertion.aud + '::' + assertion.sub
  

• Mappa un attributo di asserzione con valore GUID workload_id a un nome e assegna il risultato a un attributo personalizzato denominato attribute.my_display_name:

  attribute.my_display_name={
    "8bb39bdb-1cc5-4447-b7db-a19e920eb111": "Workload1",
    "55d36609-9bcf-48e0-a366-a3cf19027d2a": "Workload2"
  }[assertion.workload_id]
  

• Utilizza operatori e funzioni logici di CEL per impostare un attributo personalizzato denominato attribute.environment su prod o test, a seconda dell'Amazon Resource Name (ARN) dell'identità:

  attribute.environment=assertion.arn.contains(":instance-profile/Production") ? "prod" : "test"
  

• Utilizza la funzione extract per compilare un attributo personalizzato aws_role con il nome del ruolo assunto o, se non è stato assunto alcun ruolo, con l'ARN dell'identità.

  attribute.aws_role=assertion.arn.contains('assumed-role') ? assertion.arn.extract('{account_arn}assumed-role/') + 'assumed-role/' + assertion.arn.extract('assumed-role/{role_name}/') : assertion.arn
  

• Utilizza la split funzione per dividere una stringa in base a un separatore specificato. Ad esempio, per estrarre l'attributo username da un attributo indirizzo email dividendo il relativo valore in corrispondenza del simbolo @ e utilizzando la prima stringa, utilizza il seguente mapping degli attributi:

  attribute.username=assertion.email.split("@")[0]
  

• Utilizza la funzione join per unire un elenco di stringhe su un separatore specificato. Ad esempio, per compilare l'attributo personalizzato department concatenando un elenco di stringhe con . come separatore, utilizza la seguente mappatura degli attributi:

  attribute.department=assertion.department.join(".")
  

Quando utilizzi certificati client X.509, la federazione delle identità per i workload esegue il mapping di google.subject al nome comune del soggetto del certificato client (assertion.subject.dn.cn) per impostazione predefinita:

google.subject=assertion.subject.dn.cn

Puoi anche mappare attributi aggiuntivi dai certificati foglia e intermedi.

Per AWS, se non specifichi un mapping degli attributi, Google applica il seguente mapping predefinito, che copre gli scenari più comuni:

google.subject=assertion.arn
attribute.aws_role=assertion.arn.contains('assumed-role') ? assertion.arn.extract('{account_arn}assumed-role/') + 'assumed-role/' + assertion.arn.extract('assumed-role/{role_name}/') : assertion.arn

Questa mappatura imposta google.subject sull'ARN del chiamante e attribute.aws_role sull'ARN del ruolo assunto (senza il nome della sessione) se viene assunto un ruolo oppure sull'ARN del chiamante in caso contrario. Puoi anche fornire mappature personalizzate.

Per i provider OIDC e SAML, devi fornire i mapping degli attributi. Per costruire la mappatura, consulta la documentazione del provider per un elenco di attributi nelle sue credenziali.

Per maggiori dettagli, consulta la documentazione dell'API per il campo attributeMapping.

Condizioni attributi

Una condizione dell'attributo è un'espressione CEL che può controllare gli attributi dell'asserzione e gli attributi di destinazione. Se la condizione dell'attributo restituisce true per una determinata credenziale, la credenziale viene accettata. In caso contrario, le credenziali vengono rifiutate.

Puoi utilizzare una condizione dell'attributo per limitare le identità che possono autenticarsi utilizzando il pool di identità del workload.

Le condizioni degli attributi sono utili in scenari come i seguenti:

• Se il tuo workload utilizza un IdP disponibile al pubblico, puoi limitare l'accesso in modo che solo le identità che scegli abbiano accesso al tuo pool di identità del workload.

• Se utilizzi un IdP con più piattaforme cloud, puoi impedire che le credenziali destinate all'uso con un'altra piattaforma vengano utilizzate con Cloud de Confiancee viceversa. In questo modo si evita il problema del deputato confuso.

La condizione dell'attributo per un fornitore di pool di identità del workload può utilizzare la parola chiave assertion, che si riferisce a una mappa che rappresenta la credenziale di autenticazione emessa dall'IdP. Puoi utilizzare la notazione con il punto per accedere ai valori della mappa. Ad esempio, le credenziali AWS includono un valore arn, a cui puoi accedere come assertion.arn. Inoltre, la condizione dell'attributo può utilizzare qualsiasi attributo definito nella mappatura degli attributi del provider.

L'esempio seguente consente solo le richieste provenienti da identità con un ruolo AWS specifico:

attribute.aws_role == "ROLE_MAPPING"

Per maggiori dettagli, consulta la documentazione dell'API per il campo attributeCondition.

Gestione degli accessi

Il flusso di scambio di token restituisce un token di accesso federato. Puoi utilizzare questo token di accesso federato per concedere l'accesso al tuo workload per conto delle identità principali sulle risorse Cloud de Confiance e ottenere un token di accesso OAuth 2.0 di breve durata.

Puoi utilizzare questo token di accesso per fornire l'accesso IAM.

Ti consigliamo di utilizzare la federazione delle identità per i workload per fornire l'accesso direttamente a una risorsa Cloud de Confiance . Sebbene la maggior parte delle Cloud de Confiance API supporti la federazione delle identità per i workload, alcune API presentano limitazioni. In alternativa, puoi utilizzare la simulazione dell'identità del service account.

Il token di accesso di breve durata consente di chiamare qualsiasi API Cloud de Confiance a cui la risorsa o il account di servizio ha accesso.

Accesso diretto alle risorse

Puoi utilizzare l'accesso diretto alle risorse per concedere alla tua identità esterna l'accesso direttamente a una risorsa Cloud de Confiance utilizzando ruoli specifici per le risorse.

Alternativa: simulazione dell'identità del service account

In alternativa a fornire l'accesso diretto alle risorse, puoi utilizzare la simulazione dell'identità del service account.

Devi concedere al tuo account di servizio il ruolo Utente identità del workload (roles/iam.workloadIdentityUser).

Ambiti e sicurezza del principal

Concedi l'accesso alle entità o a sottoinsiemi di queste utilizzando i tipi di entità.

Tipi di entità

La tabella seguente descrive come definire i principal come singoli utenti e gruppi di identità:

Passaggi successivi

• Utilizza la federazione delle identità per i workload per consentire ai tuoi workload di accedere alle risorse da AWS o Azure, certificati X.509, Active Directory, pipeline di deployment o provider OIDC o SAML.

• Scopri come gestire i pool di identità dei carichi di lavoro utilizzando Google Cloud CLI o l'API REST.