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
orDENY
. - Istio authorization policies are configured using
.yaml
files.
<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).
<source: https://istio.io/latest/docs/concepts/security/#authentication-policies>
Example,
<source: https://istio.io/latest/docs/concepts/security/#authentication-policies>
Role-Based Access Control
...
- 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>
- 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:
- node-level logging creates only one agent per node and does not require any changes to the applications running on the node
- Prerequisite: Application containers write STDOUT and STDERR
- A node-level agent collects these logs and forwards them for aggregation
...
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
orDENY
. - Istio authorization policies are configured using
.yaml
files.
<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).
<source: https://istio.io/latest/docs/concepts/security/#authentication-policies>
Example,
<source: https://istio.io/latest/docs/concepts/security/#authentication-policies>
Role-Based Access Control
...