Panoramica di mTLS di backend con identità dei workload gestita

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini di servizio generali dei Termini di servizio specifici. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per ulteriori informazioni, consulta le descrizioni delle fasi di lancio.

Puoi ottenere mTLS di backend con o senza l'identità dei workload gestita. Per scoprire di più su mTLS del backend senza l'identità dei workload gestita, vedi Panoramica di TLS autenticato dal backend e mTLS del backend.

Questo documento fornisce una panoramica dell'utilizzo dell'identità del workload gestita per ottenere TLS (mTLS) reciproco tra un bilanciatore del carico delle applicazioni e i relativi backend. L'identità dei workload gestita esegue automaticamente il provisioning e la gestione dei certificati X.509 da Certificate Authority Service.

Nota: per l'anteprima, l'identità del workload gestita può essere assegnata solo al servizio di backend di un bilanciatore del carico delle applicazioni esterno globale.

Le informazioni contenute in questo documento si basano sui concetti introdotti nei seguenti documenti:

• Panoramica delle workload identity gestite
• Secure Production Identity Framework For Everyone (SPIFFE)
• Certificate Authority Service
• Panoramica di TLS autenticato dal backend e mTLS del backend

Introduzione a Workload Identity gestita per i bilanciatori del carico

Senza Workload Identity gestita, la configurazione di mTLS di backend richiede la configurazione di più risorse. Quando assegni un'identità gestita a un servizio di backend di un bilanciatore del carico, l'identità dei workload gestita crea automaticamente le risorse necessarie per mTLS, come il certificato client, la configurazione di attendibilità e la configurazione dell'autenticazione del backend.

Per mTLS del backend, la risorsa del servizio di backend del bilanciatore del carico funge da carico di lavoro di origine che si autentica al backend, ovvero il carico di lavoro di destinazione.

Puoi assegnare un'identità gestita, rappresentata da un ID SPIFFE, al servizio di backend di un bilanciatore del carico. Google Cloud Certificate Authority Service esegue automaticamente il provisioning di un certificato X.509 per l'ID SPIFFE. Questo certificato X.509 per l'ID SPIFFE è noto anche come documento di identità verificabile SPIFFE (SVID). Il servizio di backend del bilanciatore del carico e i relativi backend utilizzano gli SVID per autenticarsi a vicenda tramite l'autenticazione mTLS.

Il seguente diagramma mostra il bilanciatore del carico (workload di origine) e il backend (workload di destinazione) che si autenticano reciprocamente utilizzando l'identità dei workload gestita.

mTLS di backend che utilizza l'identità del workload gestita (fai clic per ingrandire).

Di seguito è riportato un esempio di X.509-SVID che funge da wrapper per l'ID SPIFFE. L'ID SPIFFE, rappresentato come URI, è codificato nel nome alternativo del soggetto (SAN) di un certificato X.509.

Issuer:
    C=US
    O=Example Inc.
    CN=Example CA

Validity:
    Not Before: Jun 14 00:00:00 2025 GMT
    Not After : Jun 16 00:00:00 2025 GMT

Subject (Distinguished Name):
    C=US
    O=Example Inc.
    OU=Production
    CN=api.example.com

Subject Public Key Info:
    Public Key Algorithm: RSA Encryption
    RSA Public-Key: (2048 bit)

X.509v3 Extensions:
    Subject Alternative Name (SAN):
        DNS: api.example.com
        URI: spiffe://WORKLOAD_IDENTITY_POOL_ID.global.PROJECT_NUMBER.workload.id.goog/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID

Questo output include i seguenti valori:

• WORKLOAD_IDENTITY_POOL_ID: l'ID del pool di identità del workload
• PROJECT_NUMBER: il numero di progetto del tuo Google Cloud progetto
• NAMESPACE_ID: l'ID spazio dei nomi
• MANAGED_IDENTITY_ID: l'ID dell'identità gestita

Vantaggi dell'utilizzo di Workload Identity gestita

Di seguito sono riportati alcuni vantaggi dell'utilizzo di Workload Identity gestito per mTLS di backend:

• Maggiore sicurezza: se un bilanciatore del carico e i relativi backend entrano a far parte di un pool di identità del workload, diventano parte di un dominio attendibile. Google Cloud Se utilizzato in combinazione con mTLS del backend, il bilanciatore del carico e i workload di backend si autenticano reciprocamente. Questa autenticazione reciproca impedisce ai workload non autorizzati di accedere ai tuoi servizi e cripta i dati in transito.

• Gestione automatica dei certificati: dopo l'attestazione riuscita del workload, Google Cloud esegue automaticamente il provisioning e la rotazione dei certificati X.509 per i workload che partecipano al dominio di attendibilità del pool di identità dei workload. Questa gestione automatica dei certificati X.509 elimina il processo complesso e soggetto a errori della gestione manuale dei certificati.

• Identità interoperabile: i pool di identità dei workload utilizzano il framework SPIFFE, uno standard per la gestione delle identità in sistemi distribuiti, che consente l'autenticazione e l'autorizzazione in architetture moderne basate su microservizi.

• Governance centralizzata: i pool di identità del workload forniscono un punto di controllo centrale. Gli amministratori possono definire domini attendibili e stabilire norme di attestazione per stabilire quali workload possono ricevere un certificato X.509 per l'identità gestita.

Architettura di mTLS di backend che utilizza Workload Identity gestita

I seguenti componenti collaborano per ottenere mTLS di backend utilizzando Workload Identity gestita:

• Servizio di backend del bilanciatore del carico (API Compute Engine)
• Dominio attendibile Identity and Access Management (API Identity and Access Management)
• Pool di autorità di certificazione (API Certificate Authority Service)
• Configurazione dell'autenticazione del backend (API Network Security)
• Configurazione dell'attendibilità di Certificate Manager (API Certificate Manager)
• Certificato di identità gestita di Certificate Manager (API Certificate Manager)

Il seguente diagramma mostra un'identità gestita sul servizio di backend del bilanciatore del carico, che consente al bilanciatore del carico di autenticarsi al backend. Nel diagramma, i passaggi 1-3 rappresentano le risorse create in modo esplicito, mentre i passaggi 4-5 rappresentano le risorse create automaticamente.

1. Configura un pool di CA di Certificate Authority Service per l'emissione di certificati per identità dei workload gestite.
2. Configura un dominio attendibile creando un pool di identità del workload. Questo pool richiede uno spazio dei nomi, un'identità gestita, una policy di attestazione, una risorsa di configurazione dell'emissione di certificati in linea e una risorsa di configurazione dell'attendibilità in linea.
3. Configura il servizio di backend del bilanciatore del carico con l'identità gestita.

4. L'identità dei workload gestita crea automaticamente il certificato di identità gestita di Gestore certificati e la configurazione dell'attendibilità di Gestore certificati.

   Il certificato di identità gestita di Certificate Manager viene creato in base alla configurazione dell'emissione dei certificati nel pool di identità del workload. La configurazione dell'attendibilità di Certificate Manager è sincronizzata con la configurazione dell'attendibilità incorporata del pool di identità del workload.

5. Workload Identity gestita crea automaticamente la configurazione di autenticazione del backend.

   La configurazione dell'attendibilità di Certificate Manager è collegata alla configurazione dell'autenticazione del backend. Il certificato di identità gestito (X.509-SVID) di Certificate Manager è collegato anche alla configurazione dell'autenticazione del backend, che viene poi utilizzata per l'autenticazione al backend.

Per scoprire di più sulla configurazione di mTLS del backend utilizzando l'identità gestita, consulta Configura mTLS del backend utilizzando l'identità dei workload gestita.

Architettura di mTLS di backend che utilizza Workload Identity gestita (fai clic per ingrandire).

Risorse create durante mTLS backend utilizzando l'identità gestita

Come mostrato nel diagramma dell'architettura precedente, quando assegni un'identità gestita al servizio di backend, non devi configurare la configurazione di autenticazione del backend, la configurazione di attendibilità di Certificate Manager e il certificato Certificate Manager. Queste risorse vengono create automaticamente dall'identità del workload gestita.

Questa sezione esamina più da vicino le diverse parti del processo di configurazione dell'identità gestita, concentrandosi sulle risorse create in modo esplicito e su quelle create automaticamente.

Risorse create esplicitamente

Le seguenti risorse devono essere create in modo esplicito durante la configurazione di mTLS di backend utilizzando l'identità del workload gestita.

Pool di autorità di certificazione

Per configurare le identità del workload gestite per il bilanciatore del carico, devi prima configurare un'autorità di certificazione e, facoltativamente, una o più CA subordinate. Questa configurazione è chiamata gerarchia di CA.

Puoi utilizzare i pool del servizio CA per configurare questa gerarchia.

Il pool di identità del workload è associato al pool di CA aggiornando il pool di identità del workload con la configurazione dell'emissione di certificati inline.

Workload Identity gestita

Devi creare un'identità del workload gestita nello spazio dei nomi del pool di identità del workload. L'identità gestita è un ID SPIFFE completamente specificato utilizzato nell'SVID presentato dal carico di lavoro del bilanciatore del carico.

Policy di attestazione

Una policy di attestazione contiene regole per IAM per verificare se il servizio di backend è idoneo a ricevere un certificato X.509 per l'identità gestita assegnata al servizio di backend. Google Cloud

Se la verifica delle norme di attestazione viene superata, IAM richiede un certificato X.509 per l'identità gestita al servizio autorità di certificazione. Il certificato X.509 viene creato nel pool di CA associato all'identità gestita. CA Service esegue il provisioning del certificato tramite riflessione dell'identità, in cui l'ID SPIFFE configurato viene riflesso su un certificato X.509.

Configurazione di emissione dei certificati in linea

Quando configuri un pool di identità del workload, configuri una configurazione dell'emissione di certificati inline. Questa configurazione specifica quale pool di CA della tua istanza di Certificate Authority Service viene utilizzato per generare certificati X.509 per le identità all'interno del pool di identità del workload. Il file di configurazione specifica anche la durata del certificato, la percentuale della finestra di rotazione e l'algoritmo della chiave.

Il pool di CA emette certificati X.509 per le identità dei workload gestiti dopo che l'applicazione del criterio di attestazione ha esito positivo.

Configurazione dell'attendibilità inline del pool di identità del workload

Per impostazione predefinita, i tuoi workload all'interno dello stesso dominio attendibile possono autenticarsi reciprocamente utilizzando le identità dei workload gestite. Se vuoi che i workload in domini attendibili diversi si autentichino reciprocamente, devi dichiarare esplicitamente la relazione di trust nel pool di identità dei workload. Per farlo, crea una configurazione di trust incorporata che riconosce e accetta i certificati di altri domini di trust. Questi certificati vengono utilizzati per creare una catena di attendibilità e verificare l'identità dei workload di altri domini.

La configurazione di attendibilità incorporata contiene un insieme di trust anchor che l'identità del workload gestita utilizza per convalidare i certificati peer. La configurazione di attendibilità di Gestione certificati include un archivio di attendibilità SPIFFE, che rimane sincronizzato con la configurazione di attendibilità incorporata del pool di identità del workload.

Poiché il pool di identità del workload è associato al pool di CA, il pool di identità del workload considera automaticamente attendibili i certificati radice dello stesso pool di CA. Non è necessario aggiungere le CA root del pool alla configurazione di attendibilità incorporata perché l'attendibilità è già integrata.

Servizio di backend (API Compute Engine)

Per assegnare un'identità gestita al bilanciatore del carico, devi configurare il servizio di backend del bilanciatore del carico in modo che il relativo attributo tlsSettings punti alla nuova proprietà identity (backendService.tlsSettings.identity).

Tieni presenti le seguenti limitazioni che si applicano quando utilizzi il campo identity nel servizio di backend del bilanciatore del carico:

• Se imposti la proprietà identity, non puoi impostare manualmente i seguenti campi dell'attributo tlsSettings:

  • tlsSettings.sni
  • tlsSettings.subjectAltNames
  • tlsSettings.authenticationConfig

• Il campo identity può essere assegnato solo durante la creazione del servizio di backend.

• Il campo identity è immutabile. Dopo averne assegnato uno al servizio di backend del bilanciatore del carico, non può essere aggiornato o eliminato.

Risorse create automaticamente

Dopo aver impostato la proprietà identity (backendService.tlsSettings.identity) nel servizio di backend del bilanciatore del carico, le seguenti risorse nelle API Certificate Manager e Network Security vengono create automaticamente da Workload Identity gestito.

Le risorse create automaticamente vengono create nello stesso progetto del servizio di backend e utilizzano le quote standard in quel progetto.

Configurazione dell'attendibilità di Certificate Manager (API Certificate Manager)

La configurazione di attendibilità di Certificate Manager viene creata automaticamente e non può essere modificata o eliminata direttamente.

La configurazione dell'attendibilità di Certificate Manager contiene un campo denominato spiffeTrustStores. Il campo spiffeTrustStores contiene il bundle di attendibilità associato al dominio attendibile del pool di identità del workload e tutti i bundle di attendibilità aggiuntivi specificati dal campo additionalTrustBundles nella configurazione di attendibilità incorporata del pool di identità del workload.

Per convalidare i certificati SPIFFE, il campo spiffeTrustStores nella configurazione di attendibilità di Certificate Manager viene attivato automaticamente quando utilizzi l'identità del workload gestita. Se il campo spiffeTrustStores è attivo, il campo trustStores rimane vuoto.

Il campo spiffeTrustStores è una struttura di dati della mappa in cui la coppia chiave-valore è la seguente:

• La chiave può essere sia un dominio attendibile correlato a un pool di identità per i carichi di lavoro (nel formato che termina con .workload.id.goog) sia un dominio attendibile aggiuntivo.
• Il valore è un oggetto TrustStore. Questo oggetto contiene una raccolta di certificati root attendibili (noti come bundle di attendibilità) utilizzati per convalidare i certificati SPIFFE di quel dominio di attendibilità specifico.

In sostanza, questa mappa consente di configurare il bilanciatore del carico in modo che consideri attendibili gli store di più domini di sicurezza distinti. Quando un backend presenta il proprio certificato, il bilanciatore del carico estrae l'ID SPIFFE, identifica il dominio attendibile e utilizza la mappa per cercare l'archivio attendibile corretto necessario per convalidare il certificato.

Certificato di identità gestita di Certificate Manager (API Certificate Manager)

Il certificato di identità gestita di Gestore certificati viene creato automaticamente da Workload Identity gestita. Il certificato di identità gestita di Certificate Manager è di sola lettura e non può essere modificato o eliminato direttamente utilizzando l'API Certificate Manager. Il certificato di identità gestita di Gestore certificati si basa sulla configurazione dell'emissione dei certificati inline, definita nel pool di identità del workload.

Il certificato di identità gestita di Certificate Manager ha una proprietà managedIdentity, che lo identifica come certificato di identità gestita. La risorsa certificato di identità gestita di Certificate Manager memorizza l'X.509-SVID in formato con codifica PEM. Questo X.509-SVID contiene l'ID SPIFFE codificato come URI nel campo SAN. Questo ID SPIFFE corrisponde all'identità gestita nel pool di identità del workload.

L'ambito del certificato di identità gestita di Certificate Manager è CLIENT_AUTH, il che indica che questo certificato viene utilizzato come certificato client in mTLS di backend.

Configurazione dell'autenticazione del backend (API Network Security)

La configurazione di autenticazione del backend viene creata automaticamente dall'identità gestita del workload. La configurazione di autenticazione del backend è di sola lettura e non può essere modificata o eliminata direttamente utilizzando l'API Network Security.

La configurazione dell'attendibilità di Certificate Manager è collegata alla configurazione dell'autenticazione del backend.

Il certificato di identità gestita di Certificate Manager viene allegato anche alla configurazione dell'autenticazione del backend e viene utilizzato come X.509-SVID nelle richieste mTLS di backend tra il bilanciatore del carico e i workload di destinazione.

Limitazioni

• mTLS del backend con Workload Identity gestita può essere configurato solo per i bilanciatori del carico delle applicazioni esterni globali. I bilanciatori del carico delle applicazioni classici non supportano mTLS di backend.

• mTLS del backend non è supportato per i backend NEG internet globali.

• Se assegni un'identità gestita al servizio di backend (backendService.tlsSettings.identity), non puoi impostare manualmente i seguenti campi nella proprietà tlsSettings del servizio di backend:

  • backendService.tlsSettings.sni
  • backendService.tlsSettings.subjectAltNames
  • backendService.tlsSettings.authenticationConfig

• L'identità gestita può essere assegnata solo al momento della creazione del servizio di backend.

• L'identità gestita è immutabile. Dopo aver assegnato un'identità gestita al servizio di backend del bilanciatore del carico, non è possibile aggiornarla o eliminarla.

Passaggi successivi

• Configurare mTLS di backend utilizzando Workload Identity gestita