Panoramica di mTLS di backend con identità dei workload gestita

Questo documento fornisce una panoramica dell'utilizzo dell'identità del workload gestita per ottenere mutual TLS (mTLS) 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.

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

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

Introduzione all'identità del workload 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 del bilanciatore del carico, l'identità del 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 reciprocamente 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 utilizzando le identità di workload gestite.
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 Google Cloud e i relativi backend entrano a far parte di un pool di identità del workload, diventano parte di un dominio attendibile. 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.

Requisiti di certificato

Quando configuri i certificati, assicurati che siano conformi ai seguenti requisiti:

  • Gli strumenti di crittografia moderni costituiscono la base dell'autenticazione mTLS. I certificati devono utilizzare gli algoritmi RSA o ECDSA per lo scambio di chiavi. Gli algoritmi di hashing devono utilizzare SHA-256 o una funzione hash crittografica più sicura. Gli algoritmi di hashing come MD4, MD5 e SHA-1 non sono supportati.

  • I certificati del server foglia forniti dal backend devono soddisfare i seguenti requisiti:

  • I certificati client foglia (bilanciamento del carico) utilizzati in mTLS di backend sono i certificati di identità gestita di Certificate Manager creati automaticamente e devono soddisfare automaticamente i seguenti requisiti:

  • Per autenticare i certificati server che il backend presenta al bilanciatore del carico, i certificati root e intermedi che si trovano nella configurazione di attendibilità devono soddisfare i seguenti requisiti:

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 le identità di 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 dell'identità gestita di Certificate Manager e la configurazione dell'attendibilità di Certificate Manager.

    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 da Certificate Manager (X.509-SVID) viene allegato 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.

mTLS di backend utilizzando Workload Identity 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à di 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 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.

Pool di identità del workload

Le identità dei workload gestite sono definite all'interno di un pool di identità dei workload, che funge da dominio attendibile.

Il dominio di attendibilità rappresenta un limite di sicurezza logico all'interno del quale i workload possono autenticarsi e autorizzarsi a vicenda utilizzando i propri ID SPIFFE. Tutti i workload all'interno dello stesso dominio di attendibilità condividono una radice di attendibilità comune, che consente ai workload di verificare reciprocamente le identità.

Per utilizzare le identità gestite, devi configurare il pool di identità del workload in modalità TRUST_DOMAIN. Tutte le identità all'interno di un pool sono costituite da un singolo spazio dei nomi e da un identificatore del workload individuale.

Spazio dei nomi

All'interno di un pool di identità del workload, le identità dei workload gestite sono organizzate in confini amministrativi chiamati spazi dei nomi. Gli spazi dei nomi consentono di organizzare e concedere l'accesso alle identità dei workload correlate.

Workload Identity gestita

L'identità del workload gestita si basa sullo standard SPIFFE, che fornisce un framework per identificare, autenticare e proteggere le comunicazioni tra i workload utilizzando un ID SPIFFE univoco.

Un'identità del workload gestita o un'identità gestita è un identificatore del workload configurato in un pool di identità del workload. È collegato a una risorsa Google Cloud . Ogni identità gestita è identificata in modo univoco da un spazio dei nomi e da un identificatore del workload individuale.

Nel contesto dell'implementazione di mTLS del backend, l'identità gestita è collegata alla risorsa del servizio di backend del bilanciatore del carico.

Il valore di un'identità gestita è un ID SPIFFE completamente specificato che deve essere conforme al seguente formato:

spiffe://TRUST_DOMAIN_NAME/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID

Un TRUST_DOMAIN_NAME viene ulteriormente ampliato come segue:

WORKLOAD_IDENTITY_POOL_ID.global.PROJECT_NUMBER.workload.id.goog

Per mettere insieme il tutto, i workload di Compute Engine, come la risorsa del servizio di backend di un bilanciatore del carico, possono avere un'identità gestita come segue:

spiffe://WORKLOAD_IDENTITY_POOL_ID.global.PROJECT_NUMBER.workload.id.goog/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID

Policy di attestazione

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

Se la verifica delle norme di attestazione viene superata, IAM richiede un certificato X.509 per l'identità gestita al Certificate Authority Service. Il certificato X.509 viene creato nel pool di CA associato all'identità gestita. CA Service esegue il provisioning del certificato tramite la 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à di 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à del workload. A questo scopo, 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 dell'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 Certificate Manager 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.

Nel seguente diagramma, il bilanciatore del carico e il backend fanno parte dello stesso dominio di attendibilità e condividono lo stesso certificato radice. Il certificato radice viene utilizzato per creare una catena di attendibilità e verificare l'identità dei workload all'interno del dominio attendibile.

Gerarchia delle risorse dell'identità del workload gestita.
Gerarchia delle risorse di Workload Identity gestita (fai clic per ingrandire).

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. Una volta assegnato 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 dell'attendibilità incorporata del pool di identità del workload. Per saperne di più, vedi Verificare che la configurazione dell'attendibilità di Certificate Manager contenga il campo spiffeTrustStores.

Per scoprire di più su come il campo spiffeTrustStores nella configurazione dell'attendibilità di Certificate Manager consente la convalida dei certificati SPIFFE, consulta Passaggi di convalida del certificato server.

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

Il certificato di identità gestita di Certificate Manager viene creato automaticamente da Managed Workload Identity. Il certificato dell'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 Certificate Manager si basa sulla configurazione dell'emissione dei certificati inline, definita nel pool di identità del workload.

Il certificato dell'identità gestita di Certificate Manager ha una proprietà managedIdentity, che lo identifica come certificato dell'identità gestita. La risorsa del certificato di identità gestita di Certificate Manager memorizza l'X.509-SVID in formato con codifica PEM. Questo SVID X.509 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 carico di lavoro. 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.

Passaggi di convalida del certificato server

Durante la convalida del certificato del server durante mTLS del backend, il bilanciatore del carico esegue le seguenti operazioni:

  1. Verifica che il server disponga della chiave privata del certificato.

    Il server dimostra di possedere la chiave privata associata al certificato che presenta al bilanciatore del carico firmando un'informazione utilizzando la chiave privata e inviandola al bilanciatore del carico come parte del messaggio CertificateVerify. Il bilanciatore del carico verifica questa firma utilizzando la chiave pubblica del certificato del server. Se la verifica della firma non va a buon fine, significa che il server di backend non dispone della chiave privata corrispondente al certificato. In questi casi, il bilanciatore del carico termina l'handshake TLS senza registrare errori.

  2. Verifica la catena di attendibilità.

    Il campo spiffeTrustStores nella configurazione dell'attendibilità di Certificate Manager consente la convalida dei certificati SPIFFE. Il campo spiffeTrustStores nella configurazione di attendibilità di Certificate Manager viene abilitato 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 di attendibilità correlato a un pool di identità del workload (nel formato che termina con .workload.id.goog) sia un dominio di attendibilità 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 con trust store di più domini di sicurezza distinti. Quando un backend presenta il proprio certificato SPIFFE, il bilanciatore del carico estrae l'ID SPIFFE, identifica il dominio attendibile e utilizza la mappa spiffeTrustStores per cercare l'archivio di attendibilità corretto per verificare la catena di attendibilità e convalidare il certificato.

    I controlli di verifica includono quanto segue:

    • Il certificato server, i certificati intermedi (se forniti) e il certificato radice configurato del backend sono conformi ai requisiti dei certificati.
    • Per tutti i certificati nella catena di attendibilità, il campo Subject (Soggetto) nel certificato padre corrisponde al campo Issuer (Emittente) nel certificato figlio. Questa verifica contribuisce a garantire che l'identità (oggetto) del certificato principale sia la stessa indicata come emittente nel certificato secondario.
    • Per tutti i certificati nella catena di attendibilità, l'identificatore della chiave del soggetto (SKID) del certificato padre corrisponde all'identificatore della chiave dell'autorità (AKID) nel certificato figlio. Questa corrispondenza conferma che il certificato secondario è stato emesso dall'autorità radice corretta e che può essere considerato attendibile perché la chiave pubblica della radice viene citata nell'AKID per verificare la validità del certificato.

  3. Stabilisci una connessione con il backend.

    Se la convalida del certificato ha esito positivo, il bilanciatore del carico procede con la connessione al backend.

    Tuttavia, se la convalida del certificato non riesce, il bilanciatore del carico termina la connessione al backend, invia un codice di stato HTTP 502 al client e registra il motivo della terminazione in Cloud Logging. In caso di un errore di convalida del certificato, le successive richieste in entrata attivano il bilanciamento del carico per riavviare la connessione backend.

    La connessione di backend può non riuscire anche se il server di backend rifiuta la connessione. Con mTLS backend, questo può accadere perché il certificato client risulta non valido. Quando la connessione al backend non va a buon fine, il bilanciatore del carico risponde alle richieste proxy con un codice di stato HTTP 502 e registra un motivo di errore generico in Cloud Logging.

Gestione degli errori e logging

I bilanciatori del carico delle applicazioni forniscono funzionalità di logging dettagliate che consentono di monitorare la convalida dei certificati server, identificare potenziali problemi e risolvere i problemi di connessione. Questa sezione descrive i diversi tipi di errori che possono verificarsi durante la convalida mTLS e come vengono registrati.

Se la convalida del certificato del server non riesce, la connessione viene interrotta e gli errori vengono registrati in Cloud Logging. Questi errori sono descritti nella tabella seguente.

Stato del certificato server Errore registrato
La catena di certificati del server è troppo lunga (più di 10 certificati intermedi inclusi nel certificato server). server_cert_chain_exceeded_limit

Un server o un certificato intermedio ha una dimensione della chiave RSA non valida.

Non viene eseguita alcuna convalida.

Le chiavi RSA possono variare da 2048 a 4096 bit.

 server_cert_invalid_rsa_key_size

Un server o un certificato intermedio utilizza una curva ellittica non supportata.

Non viene eseguita alcuna convalida.

Le curve valide sono P-256 e P-384.

 server_cert_unsupported_elliptic_curve_key

Un server o un certificato intermedio utilizza un algoritmo non RSA o non ECDSA.

Non viene eseguita alcuna convalida.

 server_cert_unsupported_key_algorithm

L'infrastruttura a chiave pubblica da utilizzare per la convalida ha più di dieci certificati intermedi che condividono le stesse informazioni Subject e Subject Public Key Info.

Non viene eseguita alcuna convalida.

 server_cert_pki_too_large

Un certificato intermedio fornito per la convalida aveva più di dieci vincoli di nome.

server_cert_chain_max_name_constraints_exceeded

Il certificato server ha un campo di estensione Extended Key Usage (EKU), ma questo campo non include serverAuth.

server_cert_chain_invalid_eku
Il limite di tempo è stato superato durante il tentativo di convalidare la catena di certificati. server_cert_validation_timed_out

È stato raggiunto il limite di profondità o iterazione durante il tentativo di convalidare la catena di certificati.

La profondità massima per una catena di certificati è dieci, inclusi i certificati radice e server. Il numero massimo di iterazioni è 100 (certificati esaminati per convalidare la catena di certificati del server).

 server_cert_validation_search_limit_exceeded

Hai configurato mTLS senza configurare una risorsa TrustConfig.

 server_cert_validation_not_performed

Il server non ha fornito il certificato richiesto durante l'handshake.

 server_cert_not_provided

La verifica del certificato del server non è riuscita con la risorsa TrustConfig.

 ssl_certificate_verification_failed

Il servizio non è in grado di eseguire la convalida della catena di certificati.

 server_cert_validation_unavailable
Errore interno durante la convalida della catena di certificati. server_cert_validation_internal_error

TrustConfig corrispondente non trovato.

 server_cert_trust_config_not_found
Il payload del certificato server (inclusi eventuali certificati intermedi) è troppo grande (superiore a 16 KB). server_cert_exceeded_size_limit

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 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 può essere aggiornata o eliminata.

Passaggi successivi