Anthos Service Mesh and Traffic Director are now Cloud Service Mesh. For more information, see the Cloud Service Mesh overview.

Configure Certificate Authority Service for Managed Cloud Service Mesh

Integrating Certificate Authority Service with managed Cloud Service Mesh lets you issue workload certificates using private CAs instead of the default Cloud Service Mesh certificate authority. This setup helps you back signing keys in Cloud HSM, chain certificates to a custom enterprise root, and meet regulatory compliance requirements across multiple clusters.

Unlike the default mesh CA, CA Service carries an explicit SLA and is charged separately. Because CA Service isn't supported under fleet-default configuration during cluster creation, you must configure Cloud Service Mesh per cluster. For in-cluster control planes, see Install default features and Certificate Authority (CA) Service.

Prerequisites

As a starting point, this guide assumes that you have:

A Cloud project
A Cloud Billing account
Obtained the required permissions to provision Cloud Service Mesh
Enabled Workload Identity Federation for GKE on your clusters and node pools.
One or more clusters with a supported version of GKE, in one of the supported regions. To learn how to create a Google Kubernetes Engine cluster with Cloud Service Mesh enabled, see the per cluster configuration in the Provision a managed Cloud Service Mesh control plane on Google Kubernetes Engine document. Enabling managed Cloud Service Mesh as a default configuration for your fleet and registering clusters to the fleet during cluster creation only supports Mesh CA. You must configure Cloud Service Mesh per cluster and enable CA Service explicitly for each cluster.

Requirements

Enable the required API in the project where the CA pool will be configured.

 gcloud services enable privateca.googleapis.com \
      --project=CA_PROJECT_ID

Configure CA Service

Create the CA pool in the tier DevOps and in the same region as the cluster that it serves to avoid excessive latency issues or potential cross-region outages. For more information, see Workload-optimized tiers.
Create the CA to have at least one active certificate authority in the CA pool in the same project as the GKE cluster. Use subordinate CA's to sign Cloud Service Mesh workload certificates. Note down the CA pool corresponding to the subordinate CA.

If it is meant to only service certificates for Cloud Service Mesh workloads, set up the following issuance policy for the CA pool:

policy.yaml

baselineValues:
  keyUsage:
    baseKeyUsage:
      digitalSignature: true
      keyEncipherment: true
    extendedKeyUsage:
      serverAuth: true
      clientAuth: true
  caOptions:
    isCa: false
identityConstraints:
  allowSubjectPassthrough: false
  allowSubjectAltNamesPassthrough: true
  celExpression:
    expression: subject_alt_names.all(san, san.type == URI && san.value.startsWith("spiffe://PROJECT_ID.svc.id.goog/ns/") )

To update the CA pool's issuance policy, use the following command:
```
gcloud privateca pools update CA_POOL --location ca_region --issuance-policy policy.yaml
```
For information on setting a policy on a pool, see Using a certificate issuance policy.
If you are using a certificate template, then configure it now. For more information, follow the CA Service guide for workload identity certificates. Ensure the certificate template is created in the same region as the CA pool. If there are multiple regions for CA pools, then create a certificate template per region.

Roles required to use CA service

For this integration, all workloads in Cloud Service Mesh require the following IAM roles. These roles-bindings need to be explicitly applied for Cloud Service Mesh workloads:

    WORKLOAD_IDENTITY="FLEET_PROJECT_ID.svc.id.goog:/allAuthenticatedUsers/"

    gcloud privateca pools add-iam-policy-binding CA_POOL \
      --project FLEET_PROJECT_ID \
      --location ca_region \
      --member "group:${WORKLOAD_IDENTITY}" \
      --role "roles/privateca.workloadCertificateRequester"

    gcloud privateca pools add-iam-policy-binding CA_POOL \
      --project FLEET_PROJECT_ID \
      --location ca_region \
      --member "group:${WORKLOAD_IDENTITY}" \
      --role "roles/privateca.auditor"

If using certificate templates:

    gcloud privateca templates add-iam-policy-binding CERT_TEMPLATE_ID \
        --member "group:${WORKLOAD_IDENTITY}" \
        --role "roles/privateca.templateUser"

Limitations

Configure and pick the CA before provisioning your Cloud Service Mesh control plane. Changing CA is not supported.

Configure managed Cloud Service Mesh to use CA Service

Verify that the istio-system namespace exists, or create it if it is missing:
```
  kubectl create ns istio-system
```
Check if asm-options configmap exists in the istio-system namespace:
```
  kubectl get configmap/asm-options -n istio-system
```

Create the configmap if it does not exist:

  kubectl create configmap -n istio-system asm-options

Patch the configmap to add CAS configuration:

  kubectl patch configmap/asm-options -n istio-system --type merge \
  -p '{"data":{"ASM_OPTS": "CA=PRIVATECA;CAAddr=projects/CA_PROJECT_ID/locations/ca_region/caPools/CA_POOL"}}'

If a certificate template is needed, append the template ID to the CA Pool address using : as a separator:

  kubectl patch configmap/asm-options -n istio-system --type merge \
  -p '{"data":{"ASM_OPTS": "CA=PRIVATECA;CAAddr=projects/CA_PROJECT_ID/locations/ca_region/caPools/CA_POOL:projects/PROJECT_ID/locations/ca_region/certificateTemplates/CERT_TEMPLATE_ID"}}'

After completing the configuration steps, continue the installation of managed Cloud Service Mesh by enabling automatic management.