Configure Certificate Authority Service for Managed Cloud Service Mesh

This guide describes how to configure Certificate Authority Service for managed Cloud Service Mesh. For information on in-cluster Cloud Service Mesh, see Install default features and Certificate Authority (CA) Service.

In addition to Cloud Service Mesh certificate authority, you can configure Cloud Service Mesh to use Certificate Authority Service. This guide provides you an opportunity to integrate with CA Service, which is recommended for the following use cases:

  • If you need different certificate authorities to sign workload certificates on different clusters.
  • If you need to back your signing keys in a managed HSM.
  • If you are in a highly regulated industry and are subject to compliance.
  • If you want to chain up your Cloud Service Mesh CA to a custom enterprise root certificate to sign workload certificates.

The cost of Cloud Service Mesh certificate authority is included in the Cloud Service Mesh pricing. The CA Service isn't included in the base Cloud Service Mesh price and is charged separately. Additionally, CA Service comes with an explicit SLA, but the Cloud Service Mesh certificate authority does not.

Configure CA Service

  1. 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.
  2. 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.
  3. 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/") )
    
  4. 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.

  5. 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:

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

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

    gcloud privateca pools add-iam-policy-binding CA_POOL \
      --project 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

  1. Verify that the istio-system namespace exists, or create it if it is missing:

      kubectl create ns istio-system
    
  2. Check if asm-options configmap exists in the istio-system namespace:

      kubectl get configmap/asm-options -n istio-system
    
  3. Create the configmap if it does not exist:

      kubectl create configmap -n istio-system asm-options
    
  4. 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/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/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.