Avi Controller to SE Communication


Avi Controllers continually exchange information securely with Avi Service Engines (SEs). This article explains the process of establishing trust and securing communication between SE and the Avi Controller.

Points to Consider

  • Do not replace or edit the System-Default-Secure-Channel-Cert with a custom certificate. Create a new certificate and update the System configuration to point to it. Replacing the existing certificate will break the secure channel certificate verification and the system will have to be restored.
  • Ensure that there are no Service Engines in the system.
  • Ensure that only no access clouds and single node cluster are in the system.

Establishing a Secure Channel

The Avi Controller exposes port 443(API server), 22(SSH), and 8443(system portal specifically dedicated for secure key exchange). All services running inside the Controller listen to the local host. Any service to service communication between Controllers run on top of a SSH port-forwarding based secure tunnel. Internal loopback IP addresses and node names are allocated the Controller(s) and SE(s) for this secure connectivity. SSH forwarding from one Controller to another Controller uses host-key based authentication on the client-side, and an internal user, avictrluser, based on the server-side.

For exchanging the SSH host and the avictrluser keys securely, a securekeyexchange API is exposed on the system portal (8443).

The trust model here is based on a certificate hierarchy, where the Controller generates the following set of self-signed certificates:

  • Root CA
  • Controller certificate (signed by the root CA)

System portal API can be accessed only via HTTPS which presents the Controller certificate.


Initial authentication is based on the following:

  • Exporting a credential bundle on the leader node which consists of the CA certificate and the one-time token valid for a duration of ten minutes.
  • Importing this credential bundle into the follower node that is being added to the existing cluster.

When invoking a secure key exchange API to exchange SSH keys, the authentication involves:

  • The client verifying the certificate on the HTTPS using the CA certificate
  • The server verifying usage of the one-time token that was generated

Subsequent authentication involves the server verifying an API signature key exchange using the SSH keys exchanged.

There is always mutual authentication in terms of exchange of SSH key and connectivity between services using SSH port-forwarding and so, there is no man-in-the-middle attack possible.

While the default is a self-signed certificate, you can also update the certificates on port 8443 with something that is issued by your organization PKI.

Only a limited set of users are allowed via SSH. They are admin and other internal users such as avictlruser, aviseuser and the CLI user. avictlruser and aviseuser only support key based authentication. With this, we limit the exposure of the connectivity to the Controller and SE to minimize the surface area of attack.

Avi Vantage verifies the integrity of the software bundle that is used for an upgrade.