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 prefered way to use the automatic generation of certificates
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 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.
Advantages:
- Certificate is not shared on a network volume
- soon to be expired certificates can be renewed by killing the replica
- sss
Disadvantages:
- Unable to track issued certificates or manage them (e.g. no sensible revoke)
- harder to track certificates that are due in near future (i.e. expiration management)
- hard dependency of each new replica on AAF (AAF certmanager will be a bottleneck)
- longer startup time and resource usage for services (i.e. time to generate certificate and the CPU overhead involved)