Versions Compared

Old Version 182

changes.mady.by.user Byung-Woo Jun

Saved on

compared with

New Version Current

changes.mady.by.user Gliffy Diagram for Confluence

Saved on

Key

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

Table of Contents

...

The following diagram depicts ONAP Security Architecture.

-- latest diagram

Image Removed

-- to be replaced


Gliffy
displayNameONAP NG Security Component Architecture London
nameONAP NG Security Component Architecture London
pagePin33version334



Security Functional Blocks

...

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
bordertrue
nameONAP Logging Function Component Architecture
pageid10341730216472259

  • 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
    • 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

...



Table of Contents

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

...

The following diagram depicts ONAP Security Architecture.


bedb821e-d0a3-48ab-b558-186a3d3fd33b
Gliffy
macroId
displayNameONAP NG Security Component Architecture
nameONAP NG Security Component Architecture
pagePin33

...

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
bordertrue
nameONAP Logging Function Component Architecture
pageid10341730216472259

  • 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

...



Gliffy
macroId6a38edce-7175-4014-9689-8ac8734cd759
nameNephio Architecture
pagePin1