Avi Kubernetes Operator Guide 1.12

AKO 1.13 1.12 1.11 1.10

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.
    Avi Load Balancer Controller
     allows a Virtual Service to be configured with two certificates at a time, one each of RSA and ECC. This enables
    Avi 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.
  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.

Content feedback and comments