Default Secret for TLS Routes

By default, AKO expects all routes with TLS termination to have key and cert to be specified in the route spec. Sometimes, users might want to apply a common key-cert for multiple routes.

To handle such use cases, AKO supports TLS routes without key/cert specified in the route spec.

You can apply a common key-cert value for multiple routes using the default secret for TLS routes. For example, a wild card secret can be used for all host names in the same subdomain.

Using a Wild Card Secret for Routes

In such a scenario, a common key-cert value can be specified in a secret that can be used for TLS routes that do not have a key-cert value specified in the route spec.

To use the wild card secret,

1. Create a secret with name router-certs-default in the same namespace where the AKO pod is running (avi-system). Ensure that the secret has a tls.crt and tls.key fields in its data section.

   An example of the default secret is given below:

    apiVersion: v1
   kind: Secret
   metadata:
   name: router-certs-default
   namespace: avi-system
   type: kubernetes.io/tls
   data:
   tls.crt:
   -----BEGIN CERTIFICATE-----
   [...]
   -----END CERTIFICATE-----
   tls.key:
   -----BEGIN PRIVATE KEY-----
   [...]
   -----END PRIVATE KEY-----
   alt.key:
   -----BEGIN PRIVATE KEY-----
   [...]
   -----END PRIVATE KEY-----
   alt.crt:
   -----BEGIN CERTIFICATE-----
   [...]
   -----END CERTIFICATE-----
    

2. Update the alt.crt and alt.key fields to allow multiple default certificates when trying to configure both RSA and ECC signed certificates. NSX Advanced Load Balancer Controller allows a Virtual Service to be configured with two certificates at a time, one each of RSA and ECC. This enables NSX Advanced Load Balancer Controller to negotiate the optimal algorithm or cipher with the client. If the client supports ECC, in that case the ECC algorithm is preferred, and RSA is used as a fallback in cases where the clients do not support ECC.

3. After creating the secret, we can add a secure route without a key or cert in the spec. For example,

   apiVersion: v1
    kind: Route
    metadata:
      name: secure-route-no-cert
    spec:
      host: secure-no-cert.avi.internal
      to:
        kind: Service
        name: avisvc
      tls:
        termination: edge

AKO uses the default secret to fetch the key and cert values for processing all such routes.

Note:

1. For TLS routes with termination type re-encrypt, the value of the destination CA has to be specified in the route spec itself.

2. The CA certificate can not be specified as a part of the default secret.

3. The field router-certs-default present in the OpenShift-ingress namespace is not used by AKO. Create router-certs-default in the avi-system namespace.