Versions Compared

Old Version 186

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.


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



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

...

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

...