OpenSSL
Learn how to use OpenSSL to manually generate all the certificates for the relay architecture.
About this approach
In this approach, you use OpenSSL to manually create a self-signed root CA certificates for your relay architecture. This certificate is then used to generate the server and client TLS certificates.
Although the root CA credentials are not stored on the management cluster, this setup is not recommended for production as it uses self-signed certificates for the root CA and requires you to protect and store your root CA credentials in a secure place. In a production-level setup, you generate and store the root CA with your preferred PKI provider, such as AWS Private CA, Google Cloud CA, or Vault. In addition, you might want to use certificate management tools, such as cert-manager
to manage the issuing and renewing of your certificate. For more information about this type of setup, see the AWS or Vault guides.
Architecture overview
The certificate and key are then stored on the workload cluster and can immediately be used by the Gloo agent to establish a mutual TLS connection with the management server.
- You use OpenSSL to create a root CA certificate and private key.
- You 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 on the management cluster. - You create a client TLS certificate and key for the Gloo agent that is signed by the root CA. You store these credentials in the
relay-client-tls-secret
Kubernetes secret on the workload cluster. - The Gloo agent and management server establish a mutual TLS connection by using the server and client TLS certificates that were signed by the same root CA.
Step 1: Create the root certificate and key
-
Make sure that you have the OpenSSL version of
openssl
, not LibreSSL. Theopenssl
version must be at least 1.1.- Check the
openssl
version that is installed. If you see LibreSSL in the output, continue to the next step.openssl version
- Install the OpenSSL version (not LibreSSL). For example, you might use Homebrew.
brew install openssl
- Review the output of the OpenSSL installation for the path of the binary file. You can choose to export the binary to your path, or call the entire path whenever the following steps use an
openssl
command.- For example,
openssl
might be installed along the following path:/usr/local/opt/openssl@3/bin/
- To run commands, you can append the path so that your terminal uses this installed version of OpenSSL, and not the default LibreSSL.
/usr/local/opt/openssl@3/bin/openssl req -new -newkey rsa:4096 -x509 -sha256 -days 3650...
- For example,
- Check the
-
Create a self-signed root CA certificate and key.
openssl req -new -newkey rsa:4096 -x509 -sha256 \ -days 3650 -nodes -out relay-root-ca.crt -keyout relay-root-ca.key \ -subj "/CN=relay-root-ca" \ -addext "extendedKeyUsage = clientAuth, serverAuth"
Step 2: Create the server TLS certificate
Use the root CA credentials that you created earlier to derive the server TLS certificate that the Gloo management server uses for mutual TLS connections with the Gloo agents.
-
If it doesn't already exist, create the
gloo-mesh
namespace in each cluster.kubectl create namespace gloo-mesh --context $MGMT_CONTEXT kubectl create namespace gloo-mesh --context $REMOTE_CONTEXT1 kubectl create namespace gloo-mesh --context $REMOTE_CONTEXT2
-
Create the configuration for the server TLS certificate.
# Server certificate configuration cat > "gloo-mesh-mgmt-server.conf" <<EOF [req] req_extensions = v3_req distinguished_name = req_distinguished_name [req_distinguished_name] [ v3_req ] basicConstraints = CA:FALSE keyUsage = digitalSignature, keyEncipherment extendedKeyUsage = clientAuth, serverAuth subjectAltName = @alt_names [alt_names] DNS = *.gloo-mesh EOF
-
Generate the private key and certificate signing request (CSR).
# Generate gloo-mesh-mgmt-server private key openssl genrsa -out "gloo-mesh-mgmt-server.key" 2048 # Generate gloo-mesh-mgmt-server CSR openssl req -new -key "gloo-mesh-mgmt-server.key" -out gloo-mesh-mgmt-server.csr -subj "/CN=gloo-mesh-mgmt-server" -config "gloo-mesh-mgmt-server.conf"
-
Sign the CSR with the root CA key.
# Sign certificate with local relay-root-ca openssl x509 -req \ -days 3650 \ -CA relay-root-ca.crt -CAkey relay-root-ca.key \ -set_serial 0 \ -in gloo-mesh-mgmt-server.csr -out gloo-mesh-mgmt-server.crt \ -extensions v3_req -extfile "gloo-mesh-mgmt-server.conf"
-
Save the server TLS certificate in the
relay-server-tls-secret
Kubernetes secret on the management cluster.kubectl create secret generic relay-server-tls-secret \ --from-file=tls.key=gloo-mesh-mgmt-server.key \ --from-file=tls.crt=gloo-mesh-mgmt-server.crt \ --from-file=ca.crt=relay-root-ca.crt \ --context ${MGMT_CONTEXT} \ --namespace gloo-mesh
Step 3: Create the client TLS certificate
Generate the client TLS certificate that the Gloo agent uses for mutual TLS connections with the Gloo management server and sign the certificate by using the root CA key that you created earlier.
-
Create the client TLS certificate configuration.
# DNS = $REMOTE_CLUSTER1 must match the clusterName used in the gloo-mesh-agent install !! echo "[req] req_extensions = v3_req distinguished_name = req_distinguished_name [req_distinguished_name] [ v3_req ] basicConstraints = CA:FALSE keyUsage = digitalSignature, keyEncipherment extendedKeyUsage = clientAuth, serverAuth subjectAltName = @alt_names [alt_names] DNS = $REMOTE_CLUSTER1" > "gloo-mesh-agent-$REMOTE_CLUSTER1.conf"
-
Generate the private key and certificate signing request (CSR).
# Generate private key openssl genrsa -out "gloo-mesh-agent-$REMOTE_CLUSTER1.key" 2048 # Create CSR openssl req -new -key "gloo-mesh-agent-$REMOTE_CLUSTER1.key" -out gloo-mesh-agent-$REMOTE_CLUSTER1.csr -subj "/CN=gloo-mesh-mgmt-server-ca" -config "gloo-mesh-agent-$REMOTE_CLUSTER1.conf"
-
Sign the CSR with the root CA key.
# Sign certificate with root openssl x509 -req \ -days 3650 \ -CA relay-root-ca.crt -CAkey relay-root-ca.key \ -set_serial 0 \ -in gloo-mesh-agent-$REMOTE_CLUSTER1.csr -out gloo-mesh-agent-$REMOTE_CLUSTER1.crt \ -extensions v3_req -extfile "gloo-mesh-agent-$REMOTE_CLUSTER1.conf"
-
Save the client TLS certificate in the
relay-client-tls-secret
Kubernetes secret on the workload cluster.kubectl create secret generic gloo-mesh-agent-$REMOTE_CLUSTER1-tls-cert \ --from-file=tls.key=gloo-mesh-agent-$REMOTE_CLUSTER1.key \ --from-file=tls.crt=gloo-mesh-agent-$REMOTE_CLUSTER1.crt \ --from-file=ca.crt=relay-root-ca.crt \ --context $REMOTE_CONTEXT1 \ --namespace gloo-mesh
-
Repeat this step on each workload cluster.
Step 4: Install the Gloo management server and agent
Now that added the server and client TLS certificates to your environment, you can install the Gloo management server and agent.
-
Prepare the Helm installation settings for the Gloo management server.
glooMgmtServer: relay: disableCa: true disableCaCertGeneration: true disableTokenGeneration: true # Push RBAC resources to the management server. Required for multicluster RBAC in the Gloo UI. pushRbac: true # Secret containing server TLS certs used to secure the management server. tlsSecret: name: relay-server-tls-secret
-
Install a new or upgrade an existing Gloo management server with the Helm settings from the previous step.
-
Prepare the Helm installation settings for the Gloo agent. fromRoot=”/setup/upgrade/” >}}) instead.
glooAgent: relay: # 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 # Address and port by which gloo-mesh-mgmt-server in the Gloo management plane can be accessed by the Gloo workload agents. serverAddress: $MGMT_SERVER_NETWORKING_ADDRESS # 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: null # Name of the Kubernetes secret. name: null # Namespace of the Kubernetes secret. namespace: null
-
Register the workload cluster or upgrade an existing Gloo agent with the Helm settings from the previous step.