ONAP is expected to be central entity across multiple K8S clusters. We know that ONAP is expected to deploy workloads across K8S clusters. Since ONAP is a central entity, we expect ONAP to keep the K8S clusters (Edge location) be ready to take up workloads. Each Edge (k8s cluster) is assumed to come up with the ISTIO. Central orchestrator, using the SC API will generate intermediate CA key for each edge and configure ISTIO Citadel of that edge. Essentially, ONAP would have its own root or intermediate CA and ONAP is expected to monitor for new edges, generate next level of intermediate CA key and populate.

Security controller will be a Micro-service. This Micro-service exposes set of APIs on its north side. Every time Edge information is made known to the security controller(SC) via API, SC (if it is new edge), generates CA key pair and returns it via the API. Other APIs – When the edge is removed, it should also remove the certificate from the remote location. In addition, it should expose API to revoke the certificate. Internally, it should also honor the renewals.

Traffic controller will be another Micro-service. This will expose it's own API's and is responsible for providing traffic policy/rules for each of the edge cloud as they come-up.