AAF supports automatic generation of service certificates via an init container in Kubernetes. For more information see https://onap.readthedocs.io/en/latest/submodules/aaf/authz.git/docs/sections/configuration/AAF_4.1_config.html

There are 2 possible designs for creating and sharing certificates

"Shared certificate" option

In this case one of the replicas triggers the AAF to create a certificate for the service. This certificate is stored on a shared volume, where other replicas pick-up and use this certificate. According to the creator of AAF Application Config & Cert Documentation (Temporary) this seems to be the preferred way to use the automatic generation of certificates.

Open

Advantages:

• allows manageable certificate management (including revoke), as 1 certificate == 1 service

• does not introduce additional hard dependency of each replica on AAF (all works or all fails)

Disadvantages:

• Unknown security of the shared network volume

• Expiration of certificate affects all replicas

• shared volume needed for each service using automatic certificate generation

• short delay on startup to get certificate from shared network volume (network reliability affects replica startup)

"Private certificate" option

In this scenario each service and each replica generates and uses its own certificate, i.e. replicas x service = number of certificates issued.

Open

Advantages:

• Certificate is not shared on a network volume

• soon to be expired certificates can be renewed by killing the replica

• works in environments without shared network volumes (NFS or similar not needed)

Disadvantages:

• Unable to track issued certificates or manage them (e.g. no sensible revoke, no way of telling which issued certificates are still being used etc)

• each replica has a different certificate (not sure if this could be a problem to not)

• harder to track certificates that are due in near future (i.e. no expiration management as replicas come and go in case of dynamic load-balancing for example)

• hard dependency of each new replica on AAF (AAF certmanager will be a bottleneck for service startup)

• longer startup time and resource usage for services (i.e. time to generate certificate and the CPU/Network overhead involved)

Other concerns - how AAF will provide certificate password

Each generated certificate has a password. In order to use the certificate the service/replica needs to know this password. The question is how to make this AAF issued certificate password available to the services in a secure way so they can access their certificate?