Communication patterns
- Intra-Component communication (e.g. between so-bpmn-infra and so-sdnc-adapter)
- Inter-Component communication (e.g. between onap-cli and so)
- External communication (e.g. user → sdc-ui)
Assumptions (to be agreed)
- AAF will be removed
- → No Container port encryption
- Services must not use NodePorts
- → external communication only via Ingress
- Ingress is the default for external communication
- Istio IngressGateway
- Nginx Ingress ?
- Rules for URLs (<comp-api>.<base-url>)
- Background: wildcard-certificate usually covers just 1 level e.g. a.simpledemo.onap.org, not b.a.simpledemo.org
current Ingress settings (see HOSTS):
- → should we make a common rule for Ingress URLs, e.g.
- don't use sub-urls (e.g. aai.api), but use dash (e.g. aai-api)
- use "-api" for apis, use "-ui" for UIs
- use common way of naming: <component>-<application>-<api|ui>
- Possible result:
- Inter-component communication can be
- directly (as today)
- via Ingress (Seshu's proposal) ?
- Communication encryption can be done:
- on Ingress level (adding certificate to Gateway)
- on SM (e.g. Istio sidecars)
- on Kernel Level (using eBPF via Cilium)
ONAP Setups (supported by OOM)
Default Secure ONAP setup
- Discussed and agreed with SECCOM Meeting (19.07.22)
- External communication:
- Components expose (external) interfaces to Ingress
- Encryption on Ingress (optional)
- Internal communication:
- Service Mesh enabled
- No TLS port encryption on pods
- Direct encrypted inter-component communication (via sidecars)
Solution using Istio (ONAP components deployed on one k8s cluster):
Solution using Istio (ONAP components deployed on different k8s clusters):
Alternative future solution using eBPF via Cilium:
https://cilium.io/blog/2020/11/10/ebpf-future-of-networking/
https://ebpf.io/
Also supported in Istio (Merbridge): https://istio.io/latest/blog/2022/merbridge/
Alternative (insecure options)
Option 1 (no ONAP internal Encryption)
- External communication:
- Components expose (external) interfaces to Ingress
- Encryption on Ingress (optional)
- Internal communication:
- No service Mesh
- No TLS port encryption on pods
- Direct unencrypted inter-component communication
Option 2 (inter-component encryption)
- External communication:
- Components expose (external) interfaces to Ingress
- Encryption on Ingress (optional)
- Internal communication:
- No service Mesh
- No TLS port encryption on pods
- Inter-component communication via Ingress (encrypted)