Backend mTLS with managed workload identity overview

Preview

This feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA features are available "as is" and might have limited support. For more information, see the launch stage descriptions.

You can achieve backend mTLS with or without managed workload identity. To learn more about backend mTLS without managed workload identity, see Backend authenticated TLS and backend mTLS overview.

This document provides an overview of using managed workload identity to achieve mutual TLS (mTLS) between an Application Load Balancer and its backends. Managed workload identity automatically provisions and manages X.509 certificates from the Certificate Authority Service.

Note: For Preview, managed workload identity can only be assigned to the backend service of a global external Application Load Balancer.

The information in this document builds on concepts introduced in the following documents:

• Managed workload identities overview
• Secure Production Identity Framework For Everyone (SPIFFE)
• Certificate Authority Service
• Backend authenticated TLS and backend mTLS overview

Introduction to managed workload identity for load balancers

Without managed workload identity, setting up backend mTLS requires the configuration of multiple resources. When you assign a managed identity to a load balancer's backend service, the managed workload identity automatically creates the necessary resources for mTLS, such as the client certificate, trust config, and backend authentication config.

For backend mTLS, the load balancer's backend service resource acts as a source workload that authenticates itself to the backend, which is the destination workload.

You can assign a managed identity—represented by a SPIFFE ID— to the backend service of a load balancer. Google Cloud Certificate Authority Service automatically provisions an X.509 certificate for the SPIFFE ID. This X.509 certificate for the SPIFFE ID is also known as a SPIFFE Verifiable Identity Document (SVID). The backend service of the load balancer and its backends use the SVIDs to authenticate each other through mTLS authentication.

The following diagram shows the load balancer (source workload) and the backend (destination workload) mutually authenticating each other using managed workload identity.

Backend mTLS using managed workload identity (click to enlarge).

The following is an example of an X.509-SVID that serves as a wrapper for the SPIFFE ID. The SPIFFE ID, represented as a URI, is encoded in the Subject Alternative Name (SAN) of an X.509 certificate.

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

This output includes the following values:

• WORKLOAD_IDENTITY_POOL_ID: the workload identity pool ID
• PROJECT_NUMBER: the project number of your Google Cloud project
• NAMESPACE_ID: the namespace ID
• MANAGED_IDENTITY_ID: the managed identity ID

Benefits of using managed workload identity

The following are some of the benefits of using managed workload identity for backend mTLS:

• Enhanced security: by joining a workload identity pool, a Google Cloud load balancer and its backends become part of a trust domain. When used in conjunction with backend mTLS, the load balancer and the backend workloads mutually authenticate each other. This mutual authentication prevents unauthorized workloads from accessing your services and encrypts data in transit.

• Automated certificate management: after successful workload attestation, Google Cloud automatically provisions and rotates the X.509 certificates for workloads participating in the workload identity pool's trust domain. This automatic management of X.509 certificates eliminates the complex and error-prone process of manual certificate management.

• Interoperable identity: workload identity pools use the SPIFFE framework—a standard for managing identities across distributed systems, enabling authentication and authorization in modern, microservices-based architectures.

• Centralized governance: workload identity pools provide a central point of control. Administrators can define trust domains and establish attestation policies to govern which workloads can receive an X.509 certificate for the managed identity.

Architecture of backend mTLS using managed workload identity

The following components work together to achieve backend mTLS using managed workload identity:

• Backend service of the load balancer (Compute Engine API)
• Identity and Access Management trust domain (Identity and Access Management API)
• Certificate authority pool (Certificate Authority Service API)
• Backend authentication config (Network Security API)
• Certificate Manager trust config (Certificate Manager API)
• Certificate Manager managed identity certificate (Certificate Manager API)

The following diagram shows a managed identity on the backend service of the load balancer, which lets the load balancer authenticate itself to the backend. In the diagram, steps 1-3 represent explicitly created resources, while steps 4-5 represent automatically created resources.

1. Configure a Certificate Authority Service CA pool for issuing certificates to managed workload identities.
2. Configure a trust domain by creating a workload identity pool. This pool requires a namespace, a managed identity, an attestation policy, an inline certificate issuance config resource, and an inline trust config resource.
3. Configure the backend service of the load balancer with the managed identity.

4. Managed workload identity automatically creates the Certificate Manager managed identity certificate and the Certificate Manager trust config.

   The Certificate Manager managed identity certificate is created based on the certificate issuance config in the workload identity pool. The Certificate Manager trust config is in sync with the inline trust config of the workload identity pool.

5. Managed workload identity automatically creates the backend authentication config.

   The Certificate Manager trust config is attached to the backend authentication config. The Certificate Manager managed identity certificate (X.509-SVID) is also attached to the backend authentication config, which is then used to authenticate to the backend.

To learn more about backend mTLS configuration using managed identity, see Set up backend mTLS using managed workload identity.

Architecture of backend mTLS using managed workload identity (click to enlarge).

Resources created during backend mTLS using managed identity

As shown in the preceding architecture diagram, when assigning a managed identity to the backend service, you don't need to configure the backend authentication config, the Certificate Manager trust config, and the Certificate Manager certificate. These resources are created automatically by managed workload identity.

This section takes a closer look at the different parts of the managed identity configuration process focusing on the resources that are created explicitly and those that are created automatically.

Explicitly created resources

The following resources need to be created explicitly while configuring backend mTLS using managed workload identity.

Certificate authority pool

To configure managed workload identities for the load balancer, you first need to configure a certificate authority, and optionally, one or more subordinate CAs. This setup is referred to as a CA hierarchy.

You can use CA Service pools to set up this hierarchy.

The workload identity pool is bound to the CA pool by updating the workload identity pool with the inline certificate issuance config.

Managed workload identity

You need to create a managed workload identity in the workload identity pool namespace. The managed identity is a fully specified SPIFFE ID used in the SVID presented by the load balancer workload.

Attestation policy

An attestation policy contains rules for Google Cloud IAM to verify whether the backend service is eligible to receive an X.509 certificate for the managed identity that is assigned to the backend service.

If the attestation policy verification passes, IAM requests an X.509 certificate for the managed identity from the Certificate Authority Service. The X.509 certificate is created in the CA pool that is bound to the managed identity. The CA Service provisions the certificate through identity reflection, where the configured SPIFFE ID is reflected onto an X.509 certificate.

Inline certificate issuance config

When you set up a workload identity pool, you configure an inline certificate issuance config. This configuration specifies which CA pool from your Certificate Authority Service instance is used to generate X.509 certificates for the identities within the workload identity pool. The configuration file also specifies the certificate's lifetime, rotation window percentage, and key algorithm.

The CA pool issues X.509 certificates to managed workload identities after the attestation policy enforcement succeeds.

Inline trust config of the workload identity pool

By default, your workloads within the same trust domain can mutually authenticate using managed workload identities. If you want workloads that are in different trust domains to mutually authenticate, then you need to explicitly declare the trust relationship in the workload identity pool. You do this by creating an inline trust config that recognizes and accepts certificates from other trust domains. These certificates are used to build a trust chain and verify the identity of the workloads from other domains.

The inline trust config contains a set of trust anchors that managed workload identity uses to validate peer certificates. The Certificate Manager trust config encapsulates a SPIFFE trust store, which remains in sync with the inline trust config of the workload identity pool.

Because the workload identity pool is bound to the CA pool, the workload identity pool automatically trusts the root certificates of that same CA pool. You don't need to add the pool's CA roots to the inline trust config because that trust is already built-in.

Backend service (Compute Engine API)

To assign a managed identity to the load balancer, you need to configure the backend service of the load balancer such that its tlsSettings attribute points to the new identity property (backendService.tlsSettings.identity).

Note the following restrictions that apply when using the identity field on the backend service of the load balancer:

• If you set the identity property, you cannot manually set the following fields on the tlsSettings attribute:

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

• The identity field can only be assigned during backend service creation.

• The identity field is immutable. After assigning one to the backend service of the load balancer, it cannot be updated or deleted.

Automatically created resources

After you set the identity property (backendService.tlsSettings.identity) on the backend service of the load balancer, the following resources in the Certificate Manager API and Network Security API are created automatically by managed workload identity.

The automatically created resources are created in the same project as the backend service and use the standard quotas in that project.

Certificate Manager trust config (Certificate Manager API)

The Certificate Manager trust config is created automatically and cannot be directly edited or deleted.

The Certificate Manager trust config contains a field called the spiffeTrustStores. The spiffeTrustStores field contains the trust bundle associated with the trust domain of the workload identity pool and any additional trust bundles specified by the additionalTrustBundles field in the workload identity pool's inline trust config.

To validate SPIFFE certificates, the spiffeTrustStores field in the Certificate Manager trust config is automatically enabled when using managed workload identity. With the spiffeTrustStores field enabled, the trustStores field remains empty.

The spiffeTrustStores field is a map data structure where the key-value pair is as follows:

• The key can be both a trust domain related to a workload identity pool (in the format ending with .workload.id.goog), or an additional trust domain.
• The value is a TrustStore object. This object contains a collection of trusted root certificates (known as a trust bundle) used to validate SPIFFE certificates from that specific trust domain.

Essentially, this map allows the load balancer to be configured to trust stores from multiple, distinct security domains. When a backend presents its certificate, the load balancer extracts the SPIFFE ID, identifies the trust domain, and uses the map to look up the correct trust store needed to validate that certificate.

Certificate Manager managed identity certificate (Certificate Manager API)

The Certificate Manager managed identity certificate is created automatically by managed workload identity. The Certificate Manager managed identity certificate is read-only and cannot be directly edited or deleted using the Certificate Manager API. The Certificate Manager managed identity certificate is based on the inline certificate issuance config, which is defined in the workload identity pool.

The Certificate Manager managed identity certificate has a managedIdentity property, which identifies it as a managed identity certificate. The Certificate Manager managed identity certificate resource stores the X.509-SVID in PEM-encoded format. This X.509-SVID contains the SPIFFE ID encoded as a URI in the SAN field. This SPIFFE ID corresponds to the managed identity in the workload identity pool.

The scope of the Certificate Manager managed identity certificate is CLIENT_AUTH, which indicates that this certificate is used as a client certificate in backend mTLS.

Backend authentication config (Network Security API)

The backend authentication config is created automatically by managed workload identity. The backend authentication config is read-only and cannot be edited or deleted directly using the Network Security API.

The Certificate Manager trust config is attached to the backend authentication config.

The Certificate Manager managed identity certificate is also attached to the backend authentication config, and is used as an X.509-SVID in backend mTLS requests between the load balancer and destination workloads.

Limitations

• Backend mTLS with managed workload identity can only be configured for global external Application Load Balancers. Classic Application Load Balancers don't support backend mTLS.

• Backend mTLS isn't supported for global internet NEG backends.

• If you assign a managed identity to the backend service (backendService.tlsSettings.identity), you cannot manually set the following fields on the tlsSettings property of the backend service:

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

• Managed identity can only be assigned at the time of the creation of the backend service.

• Managed identity is immutable. After assigning a managed identity to the backend service of the load balancer, it cannot be updated or deleted.

What's next

• Set up backend mTLS using managed workload identity