Securing Control Plane

    Currently Antrea only requires a single server certificate for the antrea-controller API server endpoint, which is for the following communication:

    • The kube-aggregator (i.e. kube-apiserver) talks to the antrea-controller for proxying antctl’s requests (when run in “controller” mode)

    Antrea doesn’t require client certificates for its own components as it delegates authentication and authorization to the Kubernetes API, using Kubernetes ServiceAccount tokens for client authentication.

    By default, antrea-controller generates a self-signed certificate. You can override the behavior by providing your own certificates. Either way, the antrea-controller will distribute the CA certificate as a ConfigMap named in the Antrea deployment Namespace and inject it into the APIServices resources created by Antrea in order to allow its clients (i.e. antrea-agent, kube-apiserver) to perform authentication.

    Typically, clients that wish to access the antrea-controller API can authenticate the server by validating against the CA certificate published in the antrea-ca ConfigMap.

    Since Antrea v0.7.0, you can provide your own certificates to Antrea. To do so, you must set the selfSignedCert field of antrea-controller.conf to false, so that the antrea-controller will read the certificate key pair from the antrea-controller-tls Secret. The example manifests and descriptions below assume Antrea is deployed in the Namespace. If you deploy Antrea in a different Namepace, please update the Namespace name in the manifests accordingly.

    X509 key usages:

    • digital signature
    • key encipherment
    • server auth

    DNS names:

    • antrea.kube-system.svc
    • antrea.kube-system.svc.cluster.local

    Note: It assumes you are using cluster.local as the cluster domain, you should replace it with the actual one of your Kubernetes cluster.

    You can then create the antrea-controller-tls Secret with the certificate key pair and the CA certificate in the following form:

    You can use kubectl apply -f <PATH TO SECRET YAML> to create the above secret, or use kubectl create secret:

    Using cert-manager

    To get started, follow the cert-manager installation documentation to deploy cert-manager and configure Issuer or resources.

    The Certificate should be created in the kube-system namespace. For example, A Certificate may look like:

    Once the Certificate is created, you should see the antrea-controller-tls Secret created in the Namespace.

    Note it may take up to 1 minute for Kubernetes to propagate the Secret update to the antrea-controller Pod if the Pod starts before the Secret is created.

    Antrea v0.7.0 and higher supports certificate rotation. It can be achieved by simply updating the antrea-controller-tls Secret. The antrea-controller will react to the change, updating its serving certificate and re-distributing the latest CA certificate (if applicable).

    If you are using certificates signed by Antrea, Antrea will rotate the certificate automatically before expiration.