Page Comparison

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

Gliffy

macroId	97901e45-0ed4-43a7-be17-4db2fe53ec4c
name	K8SIngressVsIstioGateway
pagePin	1

...

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

...

Gliffy

border	true
name	ONAP Logging Function Component Architecture
pageid	10341730216472259

ONAP supports open-source- and standard-based Logging architecture.

Once all ONAP components push their logs into STDOUT/STDERR, any standard log pipe can work.

Allowing the logging component stack is realized by choices of vendors
ONAP provides a reference implementation/choice

ONAP logs will be exported to a different and centralized location for security, persistent and aggregation

Note: e.g., for apps uses log4j/slf4j properties file, the stdout and stderr redirection can be configured

log4j.appender.stdout = org.apache.log4j.ConsoleAppender
log4j.appender.stdout.Threshold = TRACE
log4j.appender.stdout.Target   = System.out

log4j.appender.stderr = org.apache.log4j.ConsoleAppender
log4j.appender.stderr.Threshold = WARN
log4j.appender.stderr.Target   = System.err

<log4j:configuration>
    <appender name="stderr" class="org.apache.log4j.ConsoleAppender">
        <param name="threshold" value="warn" />
        <param name="target" value="System.err"/>
        <layout class="org.apache.log4j.PatternLayout">
            <param name="ConversionPattern" value="%-5p %d [%t][%F:%L] : %m%n" />
        </layout>
    </appender>
    <appender name="stdout" class="org.apache.log4j.ConsoleAppender">
        <param name="threshold" value="debug" />
        <param name="target" value="System.out"/>
        <layout class="org.apache.log4j.PatternLayout">
            <param name="ConversionPattern" value="%-5p %d [%t][%F:%L] : %m%n" />
        </layout>
        <filter class="org.apache.log4j.varia.LevelRangeFilter">
            <param name="LevelMin" value="debug" />
            <param name="LevelMax" value="info" />
        </filter>
    </appender>
    <root>
        <priority value="debug"></priority>
        <appender-ref ref="stderr" />
        <appender-ref ref="stdout" />
    </root>
</log4j:configuration>

The stdout or stderr streams will be picked up by the kubelet service running on that node and end up in the PV (PVC).
ONAP logs will be exported to a different and centralized location for security, persistent and aggregation reasons
- Log collector sends logs to the aggregator in a different container
- Aggregator sends logs to the centralized database in a different container
Logging Functional Blocks:
- Collector (one per K8S node)
- Aggregator (few per K8S cluster)
- Database (one per K8S cluster)
- Visualization (one per K8S cluster)
ONAP reference implementation choice:
- EFK: Elastic Search, Fluentd, Fluentbit, Kibana
- LFG: Loki, Grafana, Fluentd / Flentbit
ONAP logging conforms to SECCOM Container Logging requirements
- Event Types
- Log Data
- Log Management

...

Cluster-level Logging Architecture (A) - ONAP Reference implementation uses this option

Use a node-level logging agent (e.g., DaemonSet) that runs on every node
- the logging agent has access to a directory with log files from all of the application containers on that node
- one agent per node is used
~~Include a dedicated sidecar container for logging in an application pod~~
A container engine handles and redirects any output generated to a containerized application's stdout and stderr.
Push logs directly to a backend from within an application
Note:
1. node-level logging creates only one agent per node and does not require any changes to the applications running on the node
2. Prerequisite: Application containers write STDOUT and STDERR
3. A node-level agent collects these logs and forwards them for aggregation

...

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

macroId	7ea31a1e-7547-4735-9cd6-1f6d2ff0f5f3
displayName	Log Sidecar in K8S
name	Log Sidecar in K8S
pagePin	2

...

ONAP Next Generation Security Architecture, https://wikilf-onap.onapatlassian.orgnet/wiki/pages/viewpage.action?pageId=10341745616472429
Istio Architecture, https://istio.io/latest/docs/ops/deployment/architecture/
Istio Security, https://istio.io/latest/docs/concepts/security/#authentication-policies
Service Mesh Risk Analysis, https://wikilf-onap.onapatlassian.orgnet/wiki/display/DW/Service+Mesh+Risk+Analysis
Service Mesh Impact on Project, https://wikilf-onap.onapatlassian.orgnet/wiki/display/DW/Service+Mesh+Impact+on+Projects
ONAP Security Model, https://wikilf-onap.onapatlassian.orgnet/wiki/display/DW/ONAP+Security+Model
Logging Architecture Proposal, https://wikilf-onap.onapatlassian.orgnet/wiki/display/DW/Logging+Architecture+Proposal
Logging Enhancements Project proposal, https:///lf-onap.atlassian.net/wiki.onap.org/display/DW/Logging+Enhancements+Project+Proposal
SECCOM Container Logging Requirements, https://wikilf-onap.onapatlassian.orgnet/wiki/display/DW/CNF+2021+Meeting+Minutes?focusedTaskId=239&preview=/93004634/100896899/2021-02-22_LoggingRequirementEvents_v8.pptx

Overview: ONAP Next Generation Security & Logging Architecture, Design and Roadmap

...

The following diagram depicts ONAP Security Architecture.

bedb821e-d0a3-48ab-b558-186a3d3fd33b

Gliffy

macroId


displayName	ONAP NG Security Component Architecture
name	ONAP NG Security Component Architecture
pagePin	33

...

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

...

Gliffy

border	true
name	ONAP Logging Function Component Architecture
pageid	10341730216472259

ONAP supports open-source- and standard-based Logging architecture.
Once all ONAP components push their logs into STDOUT/STDERR, any standard log pipe can work.
- Allowing the logging component stack is realized by choices of vendors
- ONAP provides a reference implementation/choice
ONAP logs will be exported to a different and centralized location for security, persistent and aggregation reasons
- Log collector sends logs to the aggregator in a different container
- Aggregator sends logs to the centralized database in a different container
Logging Functional Blocks:
- Collector (one per K8S node)
- Aggregator (few per K8S cluster)
- Database (one per K8S cluster)
- Visualization (one per K8S cluster)
ONAP reference implementation choice:
- EFK: Elastic Search, Fluentd, Fluentbit, Kibana
- LFG: Loki, Grafana, Fluentd / Flentbit
ONAP logging conforms to SECCOM Container Logging requirements
- Event Types
- Log Data
- Log Management

...

ONAP Next Generation Security Architecture, https://wikilf-onap.onapatlassian.orgnet/wiki/pages/viewpage.action?pageId=10341745616472429
Istio Architecture, https://istio.io/latest/docs/ops/deployment/architecture/
Istio Security, https://istio.io/latest/docs/concepts/security/#authentication-policies
Service Mesh Risk Analysis, https://wikilf-onap.onapatlassian.orgnet/wiki/display/DW/Service+Mesh+Risk+Analysis
Service Mesh Impact on Project, https://wikilf-onap.onapatlassian.orgnet/wiki/display/DW/Service+Mesh+Impact+on+Projects
ONAP Security Model, https://wikilf-onap.onapatlassian.orgnet/wiki/display/DW/ONAP+Security+Model
Logging Architecture Proposal, https://wikilf-onap.onapatlassian.orgnet/wiki/display/DW/Logging+Architecture+Proposal
Logging Enhancements Project proposal, https://wikilf-onap.onapatlassian.orgnet/wiki/display/DW/Logging+Enhancements+Project+Proposal
SECCOM Container Logging Requirements, https://wikilf-onap.onapatlassian.orgnet/wiki/display/DW/CNF+2021+Meeting+Minutes?focusedTaskId=239&preview=/93004634/100896899/2021-02-22_LoggingRequirementEvents_v8.pptx

Gliffy

macroId	6a38edce-7175-4014-9689-8ac8734cd759
name	Nephio Architecture
pagePin	1

Versions Compared

Old Version 170

New Version Current

Key

Table of Contents

Security Functional Blocks

Kubernetes Ingress vs. Istio Ingress Gateway

Kubernetes Ingress

Istio Ingress Gateway

Role-Based Access Control

Table of Contents

Overview: ONAP Next Generation Security & Logging Architecture, Design and Roadmap

Role-Based Access Control