Use Gloo Mesh self-signed CAs

When you install Gloo Mesh Enterprise, the communcation between the Gloo management server and the Gloo agents is secured via mutual TLS (mTLS) by default. No additional setup or configuration is required.

You can follow the Multicluster getting started guide to use Gloo Mesh self-signed certificates for the root CA and to automatically generate intermediate CA credentials that Gloo Mesh can use to issue and sign client TLS certificates for the Gloo agent in each workload cluster. For more information about this setup, see Option 2: Gloo Mesh self-signed CAs with automatic client certificate rotation.

To understand this setup, let's take a look at the default Helm chart values that are used to install the Gloo management server and agents.

Management server settings

When you install Gloo Mesh Enterprise, a self-signed root CA certificate and key are automatically created and stored in the relay-root-tls-secret Kubernetes secret. The root CA credentials are used to create a server TLS certificates that is stored in the relay-server-tls-secret Kubernetes secret and an intermediate CA certificate and key that are stored in the relay-tls-signing-secret secret. These credentials are later used to issue and sign client TLS certificates for Gloo agents that register with the management server.

To establish initial trust when a workload cluster registers with the management server, an identity token is automatically created and stored in the relay-identity-token-secret Kubernetes secret on the management cluster.

The following Helm values are used to set up Gloo Mesh self-signed certificates for the relay root CA. To install the management server with these values, you can either follow the Multicluster getting started guide or the Install Gloo Mesh guide.

 
glooMgmtServer:
    relay:
        disableCa: false
        disableCaCertGeneration: false
        disableTokenGeneration: false
        # Push RBAC resources to the management server. Required for multicluster RBAC in the Gloo UI.
        pushRbac: true
        # Secret containing TLS certs used to sign CSRs created by workload agents.
        signingTlsSecret:
            name: relay-tls-signing-secret
        # Secret containing client TLS certs used to secure the management server.
        tlsSecret:
            name: relay-server-tls-secret
        # Secret containing a shared token for authenticating Gloo agents when they first communicate with the management server.
        tokenSecret:
            # Key value of the data within the Kubernetes secret.
            key: token
            # Name of the Kubernetes secret.
            name: relay-identity-token-secret
            # Namespace of the Kubernetes secret.
            namespace: ""

Agent settings

To allow the agent to establish initial trust with the management server, the identity token and root CA certificate must be present on the workload cluster before the workload cluster is registered with the management server. If you use meshctl to install the management server and register your workload clusters, this step is automatically done for you. However, when you use Helm to install the management and data plane, you must manually copy the identity token and root CA certificate from the management cluster to each workload cluster.

1. Get the value of the root CA certificate from the management cluster and create a secret in the workload cluster.

   kubectl get secret relay-root-tls-secret -n gloo-mesh --context $MGMT_CONTEXT -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt
   kubectl create secret generic relay-root-tls-secret -n gloo-mesh --context $REMOTE_CONTEXT --from-file ca.crt=ca.crt
   rm ca.crt
   

2. Get the identity token from the management cluster and create a secret in the workload cluster.

   kubectl get secret relay-identity-token-secret -n gloo-mesh --context $MGMT_CONTEXT -o jsonpath='{.data.token}' | base64 -d > token
   kubectl create secret generic relay-identity-token-secret -n gloo-mesh --context $REMOTE_CONTEXT --from-file token=token
   rm token
   

3. Use the following Helm values when registering your workload clusters to install the Gloo agent.

    
   glooAgent:
       relay:
           # SNI name in the authority/host header used to connect to relay forwarding server. Must match server certificate CommonName. Do not change the default value.
           authority: gloo-mesh-mgmt-server.gloo-mesh
           # Custom certs: Secret containing client TLS certs used to identify the Gloo agent to the management server. If you do not specify a clientTlssSecret, you must specify a tokenSecret and a rootTlsSecret.
           clientTlsSecret:
               name: relay-client-tls-secret
           # The ratio of the client TLS certificate lifetime to when the management server starts the certificate rotation process.
           clientTlsSecretRotationGracePeriodRatio: ""
           # Secret containing a root TLS cert used to verify the management server cert. The secret can also optionally specify a 'tls.key', which is used to generate the agent client cert.
           rootTlsSecret:
               name: relay-root-tls-secret
           # Address and port by which gloo-mesh-mgmt-server in the Gloo control plane can be accessed by the Gloo workload agents.
           serverAddress: ""
           # Secret containing a shared token for authenticating Gloo agents when they first communicate with the management server. A token secret is not needed with ACM certs.
           tokenSecret:
               # Key value of the data within the Kubernetes secret.
               key: token
               # Name of the Kubernetes secret.
               name: relay-identity-token-secret
               # Namespace of the Kubernetes secret.
               namespace: ""