Page History

...

Note: There may be some delays due to caching and other propagation overhead.

Service Mesh Migration

Without Istio Authentication and Authorization

ONAP can be easily integrated with Istio service mesh if Istio Auth is disabled. In that case, ONAP can leverage the traffic management, telemetry and policies capabilities of Istio to connect, control and observe ONAP microservies, but without Mutual TLS authentication and authorization.

Though ONAP services can talk to each other within the mesh, to maximize the benefits brought by Istio, we still need to make little compatible changes to the existing services:

Service Port Name

The port names must be of the form protocol-suffix with http, http2, grpc, mongo, or redis as the protocol in order to take advantage of Istio’s routing features.

For example, name: http2-foo or name: http are valid port names, but name: http2foo is not. If the port name does not begin with a recognized prefix or if the port is unnamed, traffic on the port will be treated as plain TCP traffic (unless the port explicitly uses Protocol: UDP to signify a UDP port).

kubectl describe svc aai -n onap
Name:                     aai
Namespace:                onap
Labels:                   app=aai
                          chart=aai-2.0.0
                          heritage=Tiller
                          release=aai1
Annotations:              <none>
Selector:                 app=aai
Type:                     NodePort
IP:                       10.96.29.203
Port:                     http-aai  8080/TCP
---omitted for brevity

Propagate Http Header for Distributed Tracing

Istio uses HTTP headers to record the request tracing information across multiple spans. Although Istio proxies are able to automatically send all the spans to Mixer, they need some hints to tie together the individual spans to get the entire trace. 

To do this, ONAP microservies needs to collect and propagate the following headers from the incoming request to any outgoing requests:

• x-request-id
• x-b3-traceid
• x-b3-spanid
• x-b3-parentspanid
• x-b3-sampled
• x-b3-flags
• x-ot-span-context


With Istio Authentication and Authorization

In addition to the port name format and http header propagation, the followings need to be done to leverage Istio auth.

Liveness probe

Mutual TLS can't work with  8Shttp/tcp liveness probe. If mutual TLS is enabled, http and tcp health checks from the kubelet will not work since they do not have Istio-issued certs. The workaround is using liveness command instead or disabling http and tcp liveness probe for the time being.

Allow both Mutual TLS and Plain Traffic

During the migration, we can use “PERMISSIVE” mode of Istio Auth policy to allow both TLS and plain traffic. After migration is done, the mode can be switched to "STRICT" mode so only TLS traffics are permitted to access services.

cat <<EOF | kubectl apply -n onap -f -
apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
  name: "default"
  namespace: onap
spec:
  peers:
  - mtls:
      mode: PERMISSIVE
EOF  

In that case, the RBAC should be set to allow all users, including the unauthenticated users, to access the services.

 cat <<EOF | kubectl apply -n onap -f -
apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: onap-default
  namespace: onap
spec:
  rules:
  - services: ["*"]
    methods: ["*"]
---
apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: bind-service-default
  namespace: onap
spec:
  subjects:
  - user: "*"
  roleRef:
    kind: ServiceRole
    name: "onap-default"
EOF

By this approach, ONAP can be smoothly migrated to Istio with auth enabled. After every ONAP microservice adopts Istio auth, then we can set the authentication to "STRICT" mode and enforce strict access control per the needs of each service.

What's the next? we will provide a user-friendly Istio UI to manage Istio rules and policies. Comment here to leave your thoughts or join our weekly project meeting if you're interested.