Motivation
Service Mesh simplifies infrastructure management on a an application by:
- applying security policies in a centralized way
- applying upgrade policies also in a centralized way
- giving simple tracing view of the calls of an application
Today, ONAP uses AAF for certificates management and leaves the https implementation to the modules. Thus blacklisting a weak cipher or other security issue needs a verification on the ~200 services used by ONAP.
Having only one point of configuration would help a lot.
Troubleshooting issues is also very complex. Thus adding new tools such as tracing will help the ops people.
Service Mesh principles to apply
Generic principles
In order to make the service mesh work, here are the common principles:
- Prefer use of (non headless) services. Pod to pod communication is not a first class citizen in a Service mesh (as the name stands). Thus using non headless services in the preferred way.
- Name the ports in the service / pod with their protocol. In order to detect protocol, service mesh tends to use the naming of the port (on the service and pod part). Naming it "foo" doesn't help whereas "http" or "http-foo" helps the service mesh provider to know which protocol is used. allowed protocols are "tcp", "http", "https", "http2", "grpc".
- Allow to disable https (or enable http). As the ssl part can be done by the service mesh, there's no need to do it on the pod side. Thus, we should be able to disable https (or enable http).
- If Service 2 Service authorization is needed, per service service account must be created as service mesh implementation uses service account for Authorization
Principles specific to ONAP
- As AAF is used for certificates generation and as AAF is not compliant with service mesh, we need to be able to disable AAF integration in ONAP components.
JIRA Tickets created for Service Mesh
EPICS
Components on Service Mesh EPIC
Components Service Account creation EPIC
Service 2 Service Authorization EPIC
Customer 2 Service Authorization EPIC