If you choose to provide your own CA root certificate and key, you can use the provided backend. With this option, you must also manage the certificate lifecycle yourself.
Unlike the builtin backend, with provided you first upload the certificate and key as Secret resource, and then reference the Secrets in the mTLS configuration.
Kong Mesh then provisions data plane proxy certificates for every replica of every service from the CA root certificate and key.
Here’s an example of how to configure a provided CA:
apiVersion: kuma.io/v1alpha1
kind: Mesh
metadata:
name: default
spec:
mtls:
enabledBackend: ca-1
backends:
- name: ca-1
type: provided
dpCert:
rotation:
expiration: 1d
conf:
cert:
secret: $CERT_SECRET_NAME
key:
secret: $KEY_SECRET_NAME
Apply the configuration with kubectl apply -f [..].
type: Mesh
name: default
mtls:
enabledBackend: ca-1
backends:
- name: ca-1
type: provided
dpCert:
rotation:
expiration: 1d
conf:
cert:
secret: $CERT_SECRET_NAME
key:
secret: $KEY_SECRET_NAME
Apply the configuration with kumactl apply -f [..] or via the HTTP API.
- The
dpCert configuration determines how often Kong Mesh should automatically rotate the certificates assigned to every data plane proxy.
- The Secrets must exist before referencing them in a
provided backend.
You can also use an intermediate CA with a provided backend. Generate the certificate and place it first in certificate file, before the certificate from the root CA. The certificate from the root CA should start on a new line:
-----BEGIN CERTIFICATE-----
<intermediate CA certificate content>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<root CA certificate content>
-----END CERTIFICATE-----
Then create the Secret to use in the cert section of the config. The secret for the key should contain only the private key for the certificate from the intermediate CA.
You can chain certificates from multiple intermediate CAs the same way. Place the certificate from the closest CA at the top of the cert file, followed by certificates in order up the certificate chain, then generate the Secret to hold the contents of the file.
When using an arbitrary certificate and key for a provided backend, ensure compliance with the following requirements:
The following example generates a sample CA certificate and key:
Do not use this example in production, instead generate valid and compliant certificates. This example is intended for usage in a development environment.
The following command will generate a CA root certificate and key that can be uploaded to Kong Mesh as a Secret and then used in a provided mTLS backend:
SAMPLE_CA_CONFIG="
[req]
distinguished_name=dn
[ dn ]
[ ext ]
basicConstraints=CA:TRUE,pathlen:0
keyUsage=keyCertSign
"
openssl req -config <(echo "$SAMPLE_CA_CONFIG") -new -newkey rsa:2048 -nodes \
-subj "/CN=Hello" -x509 -extensions ext -keyout key.pem -out crt.pem
The command generates a certificate at crt.pem and the key at key.pem. Generate the Kong Mesh Secret resources using the Secret resource.
In development mode, you can provide the cert and key properties of the provided backend using an inline value instead of a Secret resource.
Using the inline modes in production presents a security risk since it makes the CA root certificate and key more easily accessible to a malicious actor. Only use inline in development mode.
Use the inline properties instead of secret:
apiVersion: kuma.io/v1alpha1
kind: Mesh
metadata:
name: default
spec:
mtls:
enabledBackend: ca-1
backends:
- name: ca-1
type: provided
conf:
cert:
inline: <base64-encoded certificate>
key:
inline: <base64-encoded key>
Use the inline properties instead of secret:
type: Mesh
name: default
mtls:
enabledBackend: ca-1
backends:
- name: ca-1
type: provided
conf:
cert:
inline: <base64-encoded certificate>
key:
inline: <base64-encoded key>