2 Overview

Deployment Environment

The OCNADD can be deployed in a variety of possible configurations and environments:

Table 2-1 Deployment Environment

Type	Host	CNE	Description
Cloud	Customer Cloud	OCCNE	The OCCNE is deployed on the cloud provided by the customer. The Data Director is deployed on the Kubernetes cluster managed by OCCNE.
Cloud	Customer CNE	Customer CNE(TANZU)	The customer provides the CNE and deploys the OCNADD directly into the environment. The Oracle provided DBTier is used. The list of all other required software is listed in the install guide Oracle Communications Network Analytics Data Director Installation and Upgrade Guide section "Software Requirements".

OCNADD Services

Table 2-2 OCNADD Services

Services	Descriptio
Admin Service	The Admin Service administers the Kafka Cluster and it provides an interface to create and delete a Consumer Adapter deployment.
Aggregation Service	The Aggregation Service collects and aggregates network traffic from multiple NFs (e.g: SCP 1 & 2 and/or SEPP, NRF, 3rd party NF, etc.).
Alarm Service	The OCNADD Alarm service is used to store the alarms generated by other OCNADD services.
Backend Router Service	The Backend Router Service is the gateway that forwards GUI requests to various other backed services like config, health, alarm, Prometheus, etc.
Configuration Service	This service is used by the Data Director UI service to configure 3rd party message feed.
Consumer Adapter Service	This Consumer Adapter Service allows OCNADD to send data feed to 3rd party consumer applications through the Egress Gateway service.
Egress Gateway Service	The Egress Gateway service is used for all the outbound communication towards the 3rd party consumer applications.The outgoing traffic is controlled and monitored by the Egress Gateway Service.
Health Monitoring Service	The Health Monitoring Service monitors the health of each OCNADD service and provides alerts related to the overall health of the OCNADD.
Kafka Broker Service	The Kafka Broker Service stores the incoming network traffic from different NFs. It also stores the intermediate processed data from different microservices.

Secure Development Practices

Given below are the practices followed for a secure development environment:

Vulnerability Handling

For details about vulnerability handling, refer Oracle Critical Patch Update Program. The primary mechanism to backport fixes for security vulnerabilities in Oracle products is the quarterly Critical Patch Update (CPU) program.

In general, the OCNADD will follow a quarterly release cycle, with each release providing feature updates and fixes, and updates to relevant third-party software. These quarterly releases provide cumulative patch updates.

Trust Model

The following Trust Model depicts the reference trust model (regardless of the target environment). The model describes the critical access points and controls site deployment.

Context Diagram

Figure 2-1 Context Diagram

Key Trust Boundaries

Following are the key trust boundaries:

Table 2-3 Key Trust Boundaries

Trust Boundary	Access Control
OCNADD	Kubernetes Namespace for Data Director where its internal micro-services are deployed.
Site	Where the Kubernetes cluster is deployed.
Control Plane	This trust boundary delineates the control plane elements of the clusters, that is, API Server, kubelet, containerd and etcd. The configuration database (ETCD service) is isolated so that only control plane services can access it.
Database	MySQL service deployed in a separate Kubernetes namespace.
CNE Infra	Namespace containing all the infrastructure related services (like Prometheus). Provided by CNE.
Orchestration	Includes the orchestration server and the Code and Image Repository.

External Data Flows

Table 2-4 External Data Flows

Data Flow	Protocol	Description
DF1 : Management	SSH	Operator will login to the orchestration server through SSH for deploying OCNADD and/or managing the OCNADD Kubernetes deployment using helm.
DF2 : Browser	HTTPS	Operator uses CNCC to create, manage feed configuration and monitor OCNADD. CNCC will be accessed through browser and Operator will be authenticated with username, password before access is granted.
DF3 : Kafka	SASL	Oracle NFs write the 5G SBI data or messages into the Kafka exposed by OCNADD in the respective topics. OCNADD will then process according to the feed configurations. The communications are encrypted using TLS and Oracle NF will authenticate themselves to Kafka through SASL/PLAIN (username and password).
DF4 : Consumer NF	HTTP2(w/TLS)	OCNADD will forward the message feed to respective consumer NF/s as HTTP2 (over TLS) or H2C (HTTP2 clear text) messages according to the feed configurations.