Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

...

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

...

Not all the container in K8S is writing logs to stdout, though it is recommended. Placing a log sidecar next to the container application would facilitate the uniform logging and distribution.

Note: In ONAP, the POD sidecar is not used because each ONAP application generates app logs to STDOUT or STDERR; i.e., no need to use the POD sidecar. 

Gliffy
macroId7ea31a1e-7547-4735-9cd6-1f6d2ff0f5f3
displayNameLog Sidecar in K8S
nameLog Sidecar in K8S
pagePin2

...

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

...