Page Comparison

Table of Contents

...

• Ingress Controller (realized by istio-ingress / gateway)
• AuthN/AuthZ Gateway (sidecar) – future consideration
• ONAP IdAM (realized by Keycloak)
• User Administration
• Tenant Administration
• Proxy (sidecar) – for data plane
• oauth2-proxy
• External IdP (vendor-provided component)
• External IdAM
• Egress
• Istiod – control plane (pilot, citadel, galley, cert-mgr)
• Certificate Authority (CA)

Kubernetes Ingress vs. Istio Ingress Gateway

Kubernetes Ingress

• One NodePort per service
• It is a reverse proxy and Nginx is recommended
• Different ports for different applications
• It has limited traffic control/routing rules and capabilities

Istio Ingress Gateway

• It is a POD with Envoy that does the routing
• It is configured by Gateway and Virtual Service (which configures routing and enables intelligent routing)
• It can be configured for routing rules, traffic rate limiting, policy-based checking, metrics collections

...

Note: during Istanbul, service-to-service (workload-to-workload) authorization will be configured first (high priority). Then, OOM will visit end-user-to-service (workload) authorization.

• The authorization policy enforces access control to the inbound traffic in the server side Envoy proxy. Each Envoy proxy runs an authorization engine that authorizes requests at runtime. 
• When a request comes to the proxy, the authorization engine evaluates the request context against the current authorization policies, and returns the authorization result, either ALLOW or DENY.
• Istio authorization policies are configured using .yaml files.

Image Modified

<source: https://istio.io/latest/docs/concepts/security/#authentication-policies>

Authorization policies support ALLOW, DENY and CUSTOM actions. The following digram depicts the policy precedence. 

• CUSTOM → DENY → ALLOW
• in ONAP Istanbul, DENY and ALLOW will be configured first, as coarse-grained authorization. Then, CUSTOM action would be considered for fine-grained authorization in the future (as time allows).

Image Modified

<source: https://istio.io/latest/docs/concepts/security/#authentication-policies>

Example,

Image Modified

<source: https://istio.io/latest/docs/concepts/security/#authentication-policies>

Role-Based Access Control

...

Note: during Istanbul, service-to-service (workload-to-workload) authorization will be configured first (high priority). Then, OOM will visit end-user-to-service (workload) authorization.

• The authorization policy enforces access control to the inbound traffic in the server side Envoy proxy. Each Envoy proxy runs an authorization engine that authorizes requests at runtime. 
• When a request comes to the proxy, the authorization engine evaluates the request context against the current authorization policies, and returns the authorization result, either ALLOW or DENY.
• Istio authorization policies are configured using .yaml files.

Image Modified

<source: https://istio.io/latest/docs/concepts/security/#authentication-policies>

Authorization policies support ALLOW, DENY and CUSTOM actions. The following digram depicts the policy precedence. 

• CUSTOM → DENY → ALLOW
• in ONAP Istanbul, DENY and ALLOW will be configured first, as coarse-grained authorization. Then, CUSTOM action would be considered for fine-grained authorization in the future (as time allows).

Image Modified

<source: https://istio.io/latest/docs/concepts/security/#authentication-policies>

Example,

Image Modified

<source: https://istio.io/latest/docs/concepts/security/#authentication-policies>

Role-Based Access Control

...