☰
Navigation :

Setup options

Review the options that you have to secure the communication between the Gloo management server and Gloo agents. The option that is right for you depends on the type of environment that you have and the level of control you want to have over the client TLS certificate lifecycle.

# Option Description Root CA in cluster? Certificate rotation Suggested environment
1 Insecure setup In this setup, you do not use certificates to secure the communication between the Gloo agent and the management cluster. The HTTP protocol is used for all communication between them. Not applicable Not applicable Demo or testing
2 Gloo Gateway self-signed CAs with automatic client certificate rotation In this setup, you use Gloo Gateway self-signed certificates to set up the root CA in the management cluster. The root CA is used to derive the intermediate CA and the server TLS certificate that the management server uses to prove its identity to the Gloo agent. When workload clusters register, the Gloo agent receives a client TLS certificate that is signed by the intermediate CA in the management cluster. Yes Automatic issueance and rotation of client TLS certificates for the Gloo agent. Testing or POCs
3 Custom CAs with automatic client certificate rotation Instead of using Gloo Gateway self-signed certificates for the root CA, you can create your own root CA certificate and private key by using your preferred PKI provider. Then, you create an intermediate certificate and key from the root CA and store these credentials in a Kubernetes secret on the Gloo management cluster. Because the private key of the intermediate CA exists in the cluster, Gloo Gateway can automatically issue and sign client TLS certificates for the Gloo agent in a workload cluster. No Automatic issueance and rotation of client TLS certificates for the Gloo agent. Production
4 Manually create your own server and agent certificates To enhance the security of your setup even further and have full control over the root and intermediate CA lifecycle, you can generate and store the root and intermediate CA certificates and keys with your own PKI provider. You then have the option to manually generate the client TLS certificate for the Gloo agents or use a tool, such as cert-manager, to automatically issue and rotate client TLS certificates for you. No No automatic rotation of client TLS certificates for the Gloo agent is supported by using Gloo Gateway. You must use other tools to manage the certificate lifecycle for you, such as cert-manager. Production

Option 1: Insecure setup

If you prefer to set up Gloo Gateway without secure communication for quick demonstrations, you can install Gloo Gateway and register workload clusters in insecure mode. Insecure mode means that no certificates are generated to secure the connection between the Gloo management server and the agent. Instead, they use the HTTP protocol to communicate with each other.

Using an insecure connection between the Gloo management server and agents is not a recommended best practice for production and should be used only in testing environments or for quick demonstrations.

Insecure connection between the Gloo management server and agents

For information about how to set up this option, see Insecure setup.

Option 2: Gloo Gateway self-signed CAs with automatic client certificate rotation

Use Gloo Gateway to automatically set up a root and intermediate certificate authority (CA) in the Gloo management cluster with Gloo Gateway self-signed root CA certificates as shown in the following image. Gloo Gateway uses the credentials in the intermediate CA to automatically sign, issue, and rotate the certificates for the Gloo agents.

Using Gloo Gateway self-signed certificates and storing them as the root CA in the management cluster is not a recommended practice for production. The root CA certificate is a very sensitive certificate, and if compromised, can be used to issue certificates for all components in your cluster. To protect the root CA certificate and key, it is recommended to store them in an external PKI provider.

Relay connection with Gloo self-signed root CA certificates
  1. When you install Gloo Gateway, a self-signed root certificate and private key are automatically created for you and stored in the relay-root-tls-secret Kubernetes secret on the management cluster. The secret represents the relay root certificate authority (CA).
  2. Gloo Gateway then creates an intermediate CA certificate and key that is used to sign certificats for Gloo agents. The certificate and key are stored in the relay-tls-signing-secret Kubernetes secret.
  3. Gloo Gateway creates a Gloo server TLS secret that is signed by the root CA. This certificate is stored in the relay-server-tls-secret Kubernetes secret on the management cluster.
  4. Gloo Gateway creates an identity token that is used to validate an initial connection between the Gloo agent and the management server. This identity token is stored in the relay-identity-token-secret Kubernetes secret on the management cluster.
  5. Before a workload cluster is registered with the management cluster, the root CA certificate must be added in the relay-root-tls-secret Kubernetes secret on the workload cluster. This secret is automatically set up for you when you use meshctl to register the cluster.
  6. Before a workload cluster is registered with the management cluster, the relay-identity-token-secret Kubernetes secret must be created on the workload cluster. The identity token must match the value of the identity token that is present on the management cluster. To request a client TLS certificate, the Gloo agent uses the identity token as a proof of its identity in the initial TLS connection with the Gloo management server. The identity token is automatically added to the workload cluster when you use meshctl to register the cluster.
  7. The Gloo agent creates a private key and stores this key in the relay-tls-client-secret Kubernetes secret. This key is used to encrypt traffic to the management server.
  8. To start the initial TLS connection to the management server, the Gloo agent gets the value of the identity token from the relay-identity-token-secret Kubernetes secret.
  9. The Gloo agent sends a request to the management server that includes the root CA certificate, the identity token and the private key that it created. This information is used by the management server to verify the agent's identity and establish initial trust.
  10. The Gloo management server verifies the identity token that was sent by the Gloo agent.
  11. The Gloo management server uses the private key of the intermediate CA to sign and issue a client TLS certificate.
  12. The client TLS certificate is returned to the Gloo agent.
  13. The Gloo agent stores the TLS certificate in the relay-tls-client-secret on the workload cluster.
  14. For subsequent requests, the Gloo agent uses the client TLS certificate to prove its identity to the Gloo management server and to establish a mutual TLS connection with the server.

For information about how to set up this option, see Use Gloo Gateway self-signed CAs.

Option 3: Custom CAs with automatic client TLS certificate rotation

Instead of using Gloo Gateway self-signed certificates for the root CA, you can use your preferred PKI provider to create the root and intermediate CA certificates and private keys for you. You then store the intermediate CA credentials on the management cluster so that Gloo Gateway can use these credentials to automatically issue and rotate client TLS certificates for the agents in your workload clusters.

Note that in order to leverage the automatic client TLS certificate rotation feature, you must use identity tokens to establish initial trust between the Gloo agent in a workload cluster and the Gloo management server as shown in the following image.

Custom root and intermediate CAs when using an identity token to establish initial trust
  1. You use your preferred PKI provider to create a root CA certificate and private key.
  2. You store the root CA certificate in the relay-root-tls-secret Kubernetes secret on the management cluster. The root CA private is not added to the management cluster, and instead is stored securely with your preferred PKI provider.
  3. You use your preferred PKI provider to create an intermediate CA certificate and key that is signed by the root CA. You store these credentials in the relay-tls-signing-secret Kubernetes secret on the management cluster.
  4. You use your preferred PKI provider to create a server TLS certificate for the Gloo management server that is signed by the root CA. You store this certificate in the relay-server-tls-secret Kubernetes secret.
  5. You create an identity token of your choice and store that in the relay-identity-token-secret Kubernetes secret. You can use any string value that you want, such as 1vafj9032npvr90n20fn.
  6. Before a workload cluster is registered, you copy the root CA certificate and put it in the root-relay-tls-secret Kubernetes secret on the workload cluster.
  7. Before a workload cluster is registered, you add the identity token that you created in the management cluster to the relay-identity-token-secret Kubernetes secret in the workload cluster. To use the identity token to establish initial trust, these token values must match.
  8. The Gloo agent creates a private key and stores this key in the relay-tls-client-secret Kubernetes secret. This key is used to encrypt traffic to the management server.
  9. The Gloo agent gets the value of the identity token from the relay-identity-token-secret Kubernetes secret and the root CA certificate from the relay-root-tls-secret secret.
  10. The Gloo agent sends a request to the management server that includes the root CA certificate, the identity token and the private key that it created. This information is used by the management server to verify the agent’s identity and establish initial trust.
  11. The Gloo management server verifies the agent's identity by verifying the identity token and root CA certificate.
  12. After successful verification, the Gloo management server uses the private key of the intermediate CA to sign and issue a client TLS certificate.
  13. The client TLS certificate is returned to the Gloo agent.
  14. The Gloo agent stores the TLS certificate in the relay-tls-client-secret on the workload cluster.
  15. For subsequent requests, the Gloo agent uses the client TLS certificate to prove its identity to the Gloo management server and to establish a mutual TLS connection with the server.

For information about how to set up this option, see Use custom CAs.

Option 4: Manually provide the client TLS certificates

Instead of storing the root or intermediate CA certificate and signing key on the Gloo management cluster, you generate and store these credentials by using your preferred PKI provider. Then, you manually create a server and client TLS certificate, and store it on the management and workload clusters.

Manually provide and rotate Gloo management server and agent certificates
  1. You use your preferred PKI provider to create a root CA certificate and private key.
  2. You use your preferred PKI provider to create an intermediate CA certificate and key that is signed by the root CA.
  3. You use the intermediate CA in your preferred PKI provider to create a server TLS certificate. You store this secret in the relay-server-tls-secret Kubernetes secret on the management cluster.
  4. You use the intermediate CA in your preferred PKI provider to create a client TLS certificate. You store this secret in the relay-client-tls-secret Kubernetes secret on the workload cluster.
  5. The Gloo agent establishes a secure mTLS connection to the management server by using the client TLS certificate.

For information about how to set up this option, see Manage certificates yourself.