2 CNC Console Features

This sections describes the features supported by CNC Console.

2.1 Support for Network Functions

CNC Console GUI provides a user interface to configure and manage the following Network Functions (NFs):

Oracle Communications Cloud Native Core, Binding Support Function (BSF)

BSF provides the following functions:
  • Allows PCF users to register, update, and remove the binding information.
  • Allows NF consumers to retrieve the binding information.
CNC Console provides an interface to configure global and service parameters in BSF.

For more information about configuring parameters, see the Configuring BSF Using CNC Console section in Oracle Communications Cloud Native Core, Binding Support Function User Guide.

Note:

: The performance and capacity of the CNC Console system may vary based on the call model, feature or interface configuration, and underlying CNE and hardware environment.

Oracle Communications Network Analytics Data Director (OCNADD)

OCNADD is a Network Data Broker (NDB) in the 5G core network. It receives the network traffic data from various sources such as 5G NFs, Non-5G nodes, and third-party producers, and sends the filtered and consolidated data securely to the subscribed consumers, which are third party consumer applications or platforms.

Data collection is a complex task in a 5G Service Based Architecture (SBA). The data is collected to provide meaningful insights to the customers. The OCNADD can filter, replicate, aggregate data, and route these data feeds to third party consumers who have subscribed to the feeds. OCNADD ensures data security, low latency, and redundancy while collecting and processing the data feeds. The OCNADD enables the Communications Service Providers (CSP) to correlate and transform the acquired data as per their data feed configuration to create comprehensive dashboards and Key Performance Indicators (KPIs). This enables them to achieve meaningful insights about all functions in the 5G network. This information can be used for monetizing, providing good quality service for the user, reducing downtime, ensuring easy network scalability, and minimizing losses. The OCNADD generated data feed can be beneficial for monitoring and troubleshooting during a network failure. OCNADD is a crucial function that aids in creating self-healing networks.

Oracle Communications Cloud Native Core, Network Repository Function (NRF)

NRF provides the following functions:

  • Maintains the profiles of the available NF instances and their supported services in the 5G core network.
  • Allows consumer NF instances to discover other provider's NF instances in the 5G core network.
  • Allows NF instances to track the status of other NF instances.
  • Provides OAuth2 based Access Token service for consumer NF authorization.
  • Provides specific NF Type selection based on subscriber identity.
  • Supports forwarding of messages from one NRF to another NRF.
  • Supports georedundancy to ensure service availability.

The NRF interacts with every other NF in the 5G core network and it supports the above functions through the following services:

  • Management Service
  • Discovery Service
  • Access Token Service

CNC Console provides an interface to configure global and service parameters in NRF.

For more information about configuring parameters, see the Configuring NRF Using CNC Console section in Oracle Communications Cloud Native Core, Network Repository Function User Guide.

Oracle Communications Cloud Native Core, Network Slice Selection Function (NSSF)

NSSF provides the following functions:

Network slices allow the users to select customized networks with different functionalities (such as mobility) and performance requirements (such as latency, availability, and reliability). Network slices differ in features supported and NF optimizations. In such cases, network slices may have different S-NSSAIs with different slice and service types. The user can deploy instances of multiple network slices delivering the same features but for different groups of User Equipments (UEs). These instances deliver different committed services as they are dedicated to a customer. The network slices may have different S-NSSAIs with the same slice or service type but different slice differentiators. The NSSF fulfills the requirement for determining the individual NF pertaining to a slice.

NSSF is a functional element that supports the following functionalities:
  • NSSF enables the Access and Mobility Management Function (AMF) to perform initial registration and Protocol Data Unit (PDU) session establishment.
  • AMF can retrieve NRF, NSI ID, and target AMFs as part of UE initial registration and PDU establishment procedure.
  • NSSF uses an NF Service Consumer (AMF) to update the S-NSSAIs that AMF supports and notifies of any changes in the status.
  • NSSF selects the network slicing instance (NSI) and determines the authorized Network Slice Selection Assistance Information (NSSAIs) and AMF to serve the UE.
  • NSSF interaction with NRF allows retrieving specific NF services to be used for registration request.

NSSF provides the following information when queried by the AMF:

  • Allowed NSSAIs
  • Configured NSSAIs
  • Restricted NSSAIs
  • Candidate AMF List (in case of registration)
  • Network Slice instance ID (for PDU session establishment)
  • Slice-level NRF information (for PDU Connectivity)

NSSF supports the above functions through the following NSSF services:

  • NS Selection service (Nnssf_NSSelection): This service is used by an NF Service Consumer (AMF) to retrieve the information related to network slice. It enables network slice selection in the serving Home Public Land Mobile Network (HPLMN).
  • NS Availability Service (Nnssf_NSAvailability): This service stores and maintains list of supported S-NSSAIs per TA. It allows NF service Consumer (AMF) to update and subscribe the above data and get notifications for any addition or deletion of supported S-NSSAIs.

Oracle Communications Networks Data Analytics Function (NWDAF)

The NWDAF enables the operator to collect and analyze the data in the network through an analytics function. The 5G technology requires prescriptive analytics to drive closed-loop automation and self-healing networks. In a 5G network, the consumers of data are 5G NFs, Application Functions (AFs), and Operations, Administration, and Maintenance (OAM) and the data producers are NFs. The NWDAF supports the following functions:

  • NWDAF collects data from Access and Mobility Management Function (AMF), Session Management Function (SMF), and Network Repository Function (NRF) in the network. The data is collected directly from the NFs or through the Network Exposure Function (OCNEF).
  • The NWDAF is designed to provide analytics information to consumer such as NFs, AFs and OAM.

A 5G network contains a vast number of devices and sensors generating an enormous amount of data. The NWDAF function allows the Communications Service Providers (CSPs) to efficiently monitor, manage, automate, and optimize their network operations by the data collected and analytics generated across the network. The NWDAF also helps the CSPs in achieving the operational efficiency and provides an enhanced service experience.

The analytics information provided by the NWDAF is either statistical information based on past events or predictive information. This analytics information is used to balance the resources on the network. The NWDAF can predict the User Equipment (UE) location and also detect if the UE is in an abnormal location. Based on the collected analytics information, the CSPs can roll out new services or modify the existing services without waiting for a maintenance window in the network. This ensures significantly fewer chances of network experiencing downtime.

An NWDAF consumer can avail analytics information for different analytic events. Alternatively, the consumers can subscribe or unsubscribe for specific analytics information as a one-time event or periodically get notified when a specifically defined event (for example, a threshold is breached) is detected.

The NRF discovers the NWDAF instances for the NF consumers in the network. The NWDAF information can also be locally configured on the NF consumers. The NWDAF selection function in the consumer NF selects an NWDAF instance among available NWDAF instances. Different NWDAF instances present in the 5G network can be configured to provide a specific type of analytics information. This information about the NWDAF instance is described in the NWDAF profile stored in the NRF. The consumer NFs that need specific analytics types query the NRF and include the Analytics ID based on the required data.

Oracle Communications Cloud Native Core, Converged Policy (Policy)

Policy is an NF for policy control decision and flow based charging control. It consists of the following functions:
  • Policy rules for application and service data flow detection, gating, QoS, and flow based charging to the Session Management Function (SMF).
  • Access and Mobility Management related policies to the Access and Mobility Management Function (AMF).
  • UE Route Selection Policies (URSP) rules to User Equipement (UE) through AMF.
  • Access to subscription information relevant for policy decisions in a Unified Data Repository (UDR).
  • Network control for service data flow detection, gating, and Quality of Service (QoS).
  • Flow based charging towards the Policy and Charging Enforcement Function (PCEF).
  • Receiving session and media related information from Application Function (AF) and informing AF of traffic plane events.
  • Provision of Policy and Charging Control (PCC) Rules to Policy and Charging Enforcement Function (PCEF) through the Gx reference point.
Policy supports the above functions through the following services:
  • Session Management Service
  • Access and Mobility Service
  • Policy Authorization Service
  • User Equipment (UE) Policy Service
  • PCRF Core Service

CNC Console provides an interface to configure policies and manageable objects in Policy.

For more information about configuring parameters, see the Configuring CNC Policy Using CNC Console section in Oracle Communications Cloud Native Core, Policy User Guide.

Provisioning Gateway (PROVGW)

Oracle Provisioning Gateway (PROVGW) for Subscriber Location Function (SLF) is implemented as a cloud native function. It supports:

  • HTTP1.1 over TLS.
  • Custom entities or fields in UDR mode over SOAP/XML interface.
  • Conversion of requests as defined in SEC.yaml configurations for SOAP/XML interface in UDR mode.
  • Auditor functionality in SLF mode.
  • OAM interface and configuration APIs to configure Ingress Gateway, Egress Gateway, and other Provisioning Gateway microservices.

It has two modes, which are as follows:

  • SLF mode: This mode is applicable when Provisioning Gateway is deployed with UDR for SLF use case. You can configure Provisioning Gateway to connect to multiple segments of SLF, where each segment has two SLFs. This mode offers an HTTP2 based secured REST/JSON interface (through Ingress Gateway API) for SLF data provisioning. It relays the request received by the provisioning client (for example, MTAS) to multiple 5G UDR or SLF segments. The response received from each UDR or SLF segment is then consolidated and the final response is sent to the provisioning system.

    You can deploy multiple Provisioning Gateways in the same segment or across multiple segments, where each one is stateless and does not interact with each other. If one of the Provisioning Gateway goes down, MTAS can uses second Provisioning Gateway instance to continue provisioning SLF data on UDR.

  • UDR mode: This mode is applicable when deployed with UDR for converged policy database solution. In this mode, Provisioning Gateway supports SOAP/XML interface, which is similar to 4G UDR.

Oracle Communications Cloud Native Core, Service Communication Proxy (SCP)

SCP provides the following functionalities to other 5G Network Functions (NFs):

  • Routing/Selection: Routing rules, refresh cache, and handle application failures and redirects.
    • Dynamic Discovery: The 5G topology is determined from Network Repository Function (NRF) and creation of routing rules.
    • Static Configuration: Enables NF Profiles configuration.
  • Load Balancing: Load balancing based on static capacity, NF Type, NF Specific, and NF Priority as mentioned in the NF Profile.
  • NF Subscription: Subscription for all NF types.
  • Circuit Breaking: Initiated on a per FQDN basis when outstanding transactions exceed a configurable value.
  • Message Priority: Message Priority assignment and override based on the 3GPP-SBI-Message-Priority header.
  • Congestion and Overload: Uniform load balancing and routing strategy across the network and protects the pod from overload related to various system resources.

CNC Console provides an interface to configure the SCP features.

For more information about configuring parameters, see the Configuring SCP Using CNC Console section in Oracle Communications Cloud Native Core, Service Communication Proxy User Guide.

Oracle Communications Cloud Native Core, Security Edge Protection Proxy (SEPP)

SEPP supports the following functionalities:

  • Protects application layer control plane messages and sensitive data between two NFs belonging to different PLMNs that use the N32 interface to communicate with each other. The N32 interface is used between the SEPPs of a VPLMN and a HPLMN in roaming scenarios. 3GPP has specified N32 to be considered as two separate interfaces: N32-c and N32-f.
    • N32-c is the control plane interface between the SEPPs for performing the initial handshake and negotiating the parameters to be applied for the actual N32 message forwarding.
    • N32-f is the forwarding interface between the SEPPs, that is used for forwarding the communication between the Network Function (NF) service consumer and the NF service producer after applying the application level security protection.
  • Provides secure communication of Inter PLMN messages from Consumer NF to Producer NF using TLS protection mode (HTTP over TLS).
  • Supports configuration of roaming partner profiles using REST API.
  • Performs mutual authentication and negotiation of cipher suites with the SEPP in the roaming partner’s network.
  • Handles key management aspects that involve setting up the required cryptographic keys needed for securing messages on the N32 interface between two SEPPs.
  • Provides a single point of access and control to internal NFs.
  • Validates inbound traffic as to whether it is from an authorized external PLMN.
  • Supports cross-layer validation of source and destination addresses and identifiers to provide anti-spoofing capabilities.

CNC Console provides an interface to configure different services in SEPP.

For more information about configuring parameters, see the Configuring SEPP Using CNC Console section in Oracle Communications Cloud Native Core, Security Edge Protection Proxy User Guide.

Oracle Communications Cloud Native Core, Unified Data Repository (UDR)

Oracle's 5G UDR:
  • Leverages a common Oracle Communications Cloud Native Framework.
  • Is compliant with 3GPP 29.505 Release 15 specifications UDM.
  • Is compliant with 3GPP 29.519 Release 16 (backward compatible with Release 15) specifications for PCF.
  • Has tiered architecture providing separation between the connectivity, business logic, and data layers.
  • Uses Oracle MySQL NDB Cluster CGE Edition as backend database in the Data Tier.
  • Registers with NRF in the 5G network so that the other NFs in the network can discover UDR through NRF.
  • Registers UDR with services like DR-SERVICE and GROUP-ID-MAP.

CNC Console provides an interface to configure global and service parameters in UDR.

For more information about configuring parameters, see the Configuring UDR Using CNC Console section in Oracle Communications Cloud Native Core, Unified Data Repository User Guide.

Oracle Communications Cloud Native Core, Certificate Management (OCCM)

Oracle Communications Cloud Native core, Certificate Management (OCCM) is an automated solution for managing the certificates needed for Oracle 5G Network Functions (NFs). OCCM constantly monitors and renews the certificates based on their validity or expiry period.

As 3GPP recommends using separate certificates based on the client or server mode and the type of workflow, it leads to many certificates in the network. Automated certificate management eliminates any possibilities of network disruption due to expired certificates. In SBA network deployments, the Network Functions (NFs) are required to support multiple operator certificates for different purposes and interfaces. This amounts to hundreds of certificates in the network with varying validity periods and difficulty in monitoring and renewing the certificates manually. Therefore, automation of certificate management becomes important to avoid network disruptions due to expired certificates.

OCCM integrates with the Certificate Authority(s) using Certificate Management Protocol Version 2 (CMPv2) and RFC4210 to facilitate the following certificate management operations:

  • Operator-initiated certificate creation
  • Operator-initiated certificate recreation
  • Automatic certificate monitoring and renewal
CNC Console supports the following OCCM functionalities:
  • Creating certificates based on applicable NF certificate parameters.
  • Automatic certificate renewal by OCCM.
  • Manual certificate renewal. This can be used in case a certificate is revoked, or when migrating from manual certificate management to automatic certificate management.
  • Integration with single or multiple Certificate Authorities (CAs) for signing certificates.

CNC Console provides an interface to configure different services in OCCM. For more information, see OCCM Supported Features in the Oracle Communications Cloud Native Core, Certificate Management User Guide.

Oracle Communications Cloud Native Core, Network Exposure Function (NEF)

Oracle Communications Cloud Native Core, Network Exposure Function (NEF) is a key component of the 5G Service Based Architecture. It provides a platform to securely expose the network services and capabilities offered by the 5G Network Functions (NFs) to either third-party applications or the internal Application Functions (AFs). Located between the 5G core network and third-party applications or AFs, NEF enables the external application administrators to customize the network for providing innovative services to their end-users. The applications communicate through NEF to access the internal data of the 5G core network.

NEF performs the following functions:

  • Facilitates robust and secure exposure of network services, such as voice, data connectivity, charging, subscriber data, IoT, and so on to trusted third-party applications or AFs.
  • Provides programmable environment access of 5G network to both internal and external application administrators through a set of northbound RESTful APIs.
  • Enables AF to securely provide information to 3GPP network to authenticate, authorize, and assist in throttling the AF.
  • Translates the information received from the AF to the internal 3GPP NFs, and vice versa.
  • Provides support to expose information collected from other 3GPP NFs to the AF.
  • Monitors User Equipment (UEs) related events present in the 5G system and makes the event information available for external exposure. For example, monitoring of user location and services.

CNC Console provides an interface to configure different services in NEF. For more information, see Oracle Communications Cloud Native Core, Network Exposure Function User Guide

Oracle Communications Common API Framework (CAPIF)

Oracle Communications Common API Framework (CAPIF) is the service interface between NEF and the external third-party applications or internal Application Functions (AFs). CAPIF is a 3GPP defined secured framework to expose network service interfaces. It enables the API invokers (external applications) to discover and communicate with service APIs of the API provider (NEF). This framework manages API security, logging of events, auditing capability, multiple service exposure, policy based routing, dynamic routing of information, and so on.

CAPIF performs the following services:
  • API Manager: Responsible for managing the registration and publish functionality of NEF. The API Provider Domain (APD) manager service handles all the transactions related to NEF using the package services of the CAPIF that are useful for the core functionality of NEF.
  • AF Manager: Responsible for the secured interactions between API Invokers (external applications) and API Provider (NEF). This service facilitates the following tasks:
    • API Invoker onboarding and offboarding by establishing a communication between API Invoker and CAPIF.
    • Security Context creation. The API invoker negotiates and obtains the information about service API security method from the AF manager service.
  • Event Manager: Manages the subscription, unsubscription, and notification for all the events supported by CAPIF. This service facilitates AFs and other NEF services to subscribe to CAPIF specific event notifications, receive notifications about the subscribed events, and unsubscribe from the notifications.
  • External Ingress Gateway: Acts as a gateway for all the HTTP requests towards CAPIF from external applications. This service provides security and load balancing functionality to manage and control the incoming traffic.
  • External Egress Gateway: Acts as a gateway for all the HTTP requests from CAPIF to external applications. This service provides security and load balancing functionality to manage and control the outgoing traffic.
  • Network Ingress Gateway: Acts as a gateway for all the HTTP requests towards CAPIF from NEF.
  • Network Egress Gateway: Acts as a gateway for all the HTTP requests from CAPIF to NEF.

CNC Console provides an interface to configure different services in CAPIF. For more information, see Oracle Communications Cloud Native Core, Network Exposure Function User Guide.

Managing CNC Console Support for NF GUI

Observe

For information on Metrics and KPIs, see CNC Console Metrics, and CNC Console KPIs sections.

Maintain

If you encounter alerts at system or application levels, see CNC Console Alerts section for resolution steps.

In case the alert still persists, perform the following:
  1. Collect the logs: For more information on how to collect logs, see CNC Console Logs.
  2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

2.2 Support for cnDBTier APIs in CNC Console

With the implementation of this feature, cnDBTier APIs are integrated into the CNC Console, and NF users can view specific cnDBTier APIs, such as checking the cnDBTier version, status of cnDBTier clusters, and georeplication status on the CNC Console.

The following cnDBTier APIs are read only and can be viewed in CNC Console:
  • Backup List: This API displays the details of stored backups, such as the ID and size of the backup.
  • cnDBTier version: This API displays the cnDBTier version.
  • Database Statistics Report: This API displays the number of available database.
  • Georeplication Status:
    • Real-Time Overall Replication Status: This API displays the overall replication status in multisite deployments. For example, in a four-site deployment, it provides the replication status between the following sites: site1-site2, site1-site3, site1-site4, site2-site3, site2-site4, and site2-site1. This is applicable for all other sites.
    • Site-Specific Real-Time Replication Status: This API displays the site-specific replication status.
  • Georeplication Recovery:
    • Update Cluster as Failed: This API is used to mark the the disruped cluster as failed.
    • Start Georeplication Recovery: This API is used to initiate georeplication recovery.
    • Georeplication Recovery Status: This API is used to monitor the georeplication recovery status.
  • HeartBeat Status: This API displays the connectivity status between the local site and the remote site name to which CNC Console is connected.
  • Local Cluster Status: This API displays the status of the local cluster.
  • On-Demand Backup: This API displays the status of initiated on-demand backups.
  • cnDBTier Health: This API displays the health status of the following services:
    • Replication Health Status: This API displays the health status of the replication service. It checks the following:
      • if the replication service is up or not
      • if the replication service can connect to database or not
    • Monitor Health Status: This API displays the health status of the monitor service. It checks the following:
      • if the monitor service is up or not
      • if the service can connect to database or not
      • if the metrics are fetched or not (the metrics are fetched when the service is up and vice versa)
    • NDB Health Status: This API displays the health status of the NDB service pods like (data pods, sql pods, app-my-sql pods, mgmt pods). It checks the following:
      • if the pod is connected to PVC or not
      • if the pods status is up or not

      Note:

      PVC Health Status attribute is set to NA when some of the database pods are not connected to the PVC.
    • Backup Manager Health Status: This API displays the health status of the backup manager service. It checks the following:
      • if the backup manager service is up or not
      • if the service can connect to database or not

Managing cnDBTier APIs at CNC Console

Enable

This feature is enabled automatically when cnDBTier is configured as an instance during the CNC Console deployment. cnDBTier APIs can be added for NFs or CNC Console instance. For more information about integrating cnDBTier APIs in CNC Console, see Oracle Communications Cloud Native Core, cnDBTier User Guide and for information on how to enable at CNC Console, see Oracle Communications Cloud Native Configuration Console Installation, Upgrade, and Fault Recovery Guide.

Observe

For information on Metrics and KPIs, see CNC Console Metrics, and CNC Console KPIs sections.

Maintain

If you encounter alerts at system or application levels, see CNC Console Alerts section for resolution steps.

In case the alert still persists, perform the following:
  1. Collect the logs: For more information on how to collect logs, see CNC Console Logs.
  2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

2.3 Support for CNE Common Services

Note:

Not applicable for OCI deployment.

CNC Console Common Services GUI provides an option to enable cards (hyperlinks) for CNE Common services and OSO services.

When CNC Console is integrated with common services, it provides an additional layer of security through authentication and authorization for common services that don't have their own authentication mechanism. CNC Console also provides the user a single login for all common services as per your assigned roles.

CNC Console Common Services GUI provides an option to enable cards (hyperlinks) for OCCNE Common services such as Grafana, Kibana, Jaeger, Prometheus, AlertManager, Promxy, OpenSearch, and Jaeger-ES.

OSO Common Services

CNC Console Common Services GUI also provides an option to enable cards (hyperlinks) for OSO services such as Prometheus and AlertManager.

Managing Common Service Support (OSO Cards and CNE Cards)

Enable and Configure

Prometheus and Alertmanager GUIs can be accessed using the CNC Console. For more information on accessing Prometheus and Alertmanager GUIs using CNC Console, refer to Oracle Communications Cloud Native Configuration Console User Guide.

Observe

For information on Metrics and KPIs, see CNC Console Metrics, and CNC Console KPIs sections.

Maintain

If you encounter alerts at system or application levels, see CNC Console Alerts section for resolution steps.

In case the alert still persists, perform the following:
  1. Collect the logs: For more information on how to collect logs, see CNC Console Logs.
  2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

2.4 LDAP Integration

Note:

For OCI: See the OCI Active Directory Integration section.

The Lightweight Directory Access Protocol (LDAP) is a protocol that defines the technique for accessing the directory data.

Figure 2-1 LDAP


LDAP

The CNC Console IAM is used as an integration platform to connect it into existing Lightweight Directory Access Protocol (LDAP) and Active Directory (AD) servers.

CNC Console IAM can combine existing external user databases having user and credential details. You can integrate the CNC Console IAM to perform validation of these user credentials and pull in the identity information.

CNC Console IAM provides LDAP over TLS support to securely communicate with external LDAP and active directory servers.

CNC Console IAM also supports Lightweight Directory Access Protocol Secure (LDAPS) between the client and server to make the communication secure.

Managing LDAP Integration

Enable and Configure

For enabling and configuring LDAP integration feature, see Integrating CNC Console LDAP Server with CNC Console IAM

Observe

For information on Metrics and KPIs, seeCNC Console Metrics, and CNC Console KPIs sections.

Maintain

If you encounter alerts at system or application levels, see CNC Console Alerts section for resolution steps.

In case the alert still persists, perform the following:
  1. Collect the logs: For more information on how to collect logs, see CNC Console Logs.
  2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

2.5 SAML 2.0 Integration

Note:

For OCI: See the OCI SAML Integration section.

SAML (Security Assertion Markup Language) enables applications to authenticate a user using an identity provider. CNC Console can broker identity providers based on the SAML v2.0 protocol.

Managing SAML 2.0 Integration with CNC Console

Enable and Configure

For enabling and configuring SAML 2.0 feature integration with CNC Console, see Integrating SAML SSO with CNC Console IAM section.

Observe

For information on Metrics and KPIs, see CNC Console Metrics, and CNC Console KPIs sections.

Maintain

If you encounter alerts at system or application levels, see CNC Console Alerts section for resolution steps.

In case the alert still persists, perform the following:
  1. Collect the logs: For more information on how to collect logs, see CNC Console Logs.
  2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

2.6 Logging Support

Note:

Logging for CNC Console IAM is not applicable for OCI deployment.
The CNC Console logs are categorized into the following types:
  • Regular logs
  • Audit logs
  • Security logs

Regular Logs

These logs contain all kinds of error messages, warnings, or other events written within the application which provide logical, high level information about the application and ongoing events.

Example:

{"level": "INFO","message": "Started GatewayApplication in 10.748 seconds (JVM running for 12.825)"}
{"level": "INFO","message": "Creating plain httpClient"}
{"level": "INFO","message": "Creating plain restTemplate"}
{"level": "ERROR","message": "Can't get cfgs of topic public.dynamic.datamodel,  exception is:\n
javax.ws.rs.ProcessingException: java.net.ConnectException: Connection refused (Connection
        refused)"}

Audit Logs

These logs contain user related information and the activity within the system.

Security Logs

These logs contain the header, payload, method, scheme, URI, and other details for all requests and the corresponding responses.

Disabling Security Logs

By default, Security Log is enabled for both CCNC Core and CNCC IAM. To disable, set securityLogEnabled flag to false in custom-core_values.yaml and custom-iam_values.yaml files.
# CNCC configuration
cncc:
  enabled: false
  enablehttp1: false
  securityLogEnabled: false

Log Levels

The log level indicates the level of the logs.

The default log levels for CNC Console Core are as follows:


ingress-gateway:
  log:
    level:
      cncc:
        root: WARN
        audit: INFO
        security: INFO

The default log levels for CNC Console IAM are as follows:


ingress-gateway:
  log:
    level:
      cncc:
        root: WARN
        security: INFO

Managing Security Logs and Audit Logs

Enable and Configure

For enabling and configuring Security Logs and User Activity Logs, see CNC Console Logs section.

Observe

For information on Metrics and KPIs, see CNC Console Metrics, and CNC Console KPIs sections.

Maintain

If you encounter alerts at system or application levels, see CNC Console Alerts section for resolution steps.

In case the alert still persists, perform the following:
  1. Collect the logs: For more information on how to collect logs, see CNC Console Logs.
  2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

2.7 Support for Multi Instance and Multicluster Deployment

Note:

Not supported for OCI deployment.

Multicluster deployment is a method of deploying an application on or across multiple Kubernetes clusters for improving availability, isolation, and scalability.

Support for Multiple Instances of NFs within a cluster

CNC Console supports multiple instances of NFs within a Kubernetes cluster using Manager CNC Console IAM (M-CNCC IAM), Manager CNC Console Core (M-CNCC Core), and Agent CNC Console Core (A-CNCC Core).

Note:

CNC Console supports instance level access control. For more information, see Support for Instance Level Access Control and Types of Roles in CNC Console.

Support for Multicluster Deployment for NFs

CNC Console supports NF deployment across Kubernetes clusters using Manager CNC Console IAM (M-CNCC IAM), Manager CNC Console Core (M-CNCC Core), and Agent CNC Console Core (A-CNCC Core). In a multicluster deployment, CNC Console can manage NFs and OCCNE common services deployed in remote Kubernetes clusters.

Support for multicluster deployment mTLS configuration is added to provide secure communication between CNC Console Manager and Agent.

Note:

The user must be assigned the cluster role to access multiple clusters. For more information, see Types of Roles in CNC Console.

Selecting the Instance

CNC Console multicluster deployment has introduced a drop-down on header pane for selecting the instance.

Values configured in M-CNCC Core instances section get displayed in the drop down. The naming convention used for instance drop-down display is <owner>.<type>.<instance id>

Figure 2-2 Selecting the Instance

img/mimc1.png
Once the user selects the required instance from the drop-down, the corresponding menu gets loaded.

Figure 2-3 Loading the Menu

img/mimc2.png

The common service instances configured in the instances section gets displayed in the drop-down.img/mc_ug4.png

For more details on multicluster configurations, see CNC Console Multi-Cluster Configurations section in Oracle Communications Cloud Native Configuration Console, Installation, Upgrade, and Fault Recovery Guide.

2.8 cnDBTier Integration

CNC Console is integrated with cnDBTier in a containerized Oracle Communications Cloud Native Environment. For more information, see Oracle Communications cnDBTier Installation Guide.

2.9 Support for TLS

CNC Console uses Hypertext Transfer Protocol Secure (HTTPS) to establish secure connections with Consumer NFs and Producer NFs, respectively. These communication protocols are encrypted using Transport Layer Security (TLS). TLS comprises the following components:

  • Handshake Protocol: Exchanges the security parameters of a connection. Handshake messages are supplied to the TLS record layer.
  • Record Protocol: Receives the messages to be transmitted, fragments the data into multiple blocks, secures the records, and then transmits the result. Received data is delivered to higher-level peers.

From Release 24.3.0 onwards, CNC Console supports TLSv1.3 for all Consumer NFs, Producer NFs, Data Director, SBI Interfaces, and interfaces where TLSv1.2 was supported. TLSv1.2 will continue to be supported.

TLS Handshake

This section describes the differences between TLSv1.2 and TLSv1.3 and the advantages of TLSv1.3 over TLSv1.2 and earlier versions.


TLS Handshake

TLSv1.2

  1. The connection or handshake starts when the client sends a “client hello” message to the server. This message consists of cryptographic information such as supported protocols and supported cipher suites. It also contains a random value or random byte string.
  2. To respond to the “client hello” message, the server sends the “server hello” message. This message contains the CipherSuite that the server has selected from the options provided by the client. The server also sends its certificate along with the session ID and another random value.
  3. The client verifies the certificate sent by the server. When the verification is complete, it sends a byte string and encrypts it using the public key of the server certificate.
  4. When the server receives the secret, both the client and server generate a master key along with session keys (ephemeral keys). These session keys are used to symmetrically encrypt the data.
  5. The client sends an “HTTP Request” message to the server to enable the server to switch to symmetric encryption using the session keys.
  6. To respond to the client’s “HTTP Request” message, the server does the same and switches its security state to symmetric encryption. The server concludes the handshake by sending an HTTP response.
  7. The client-server handshake is completed in two round-trips.

TLSv1.3

  1. The connection or handshake starts when the client sends a “client hello” message to the server. The client sends the list of supported cipher suites. The client also sends its key share for that particular key agreement protocol.
  2. To respond to the “client hello” message, the server sends the key agreement protocol that it has chosen. The “Server Hello” message comprises the server key share, server certificate, and the “Server Finished” message.
  3. The client verifies the server certificate, generates keys as it has the key share of the server, and sends the “Client Finished” message along with an HTTP request.
  4. The server completes the handshake by sending an HTTP response.

The following digital signature algorithms are supported in TLS handshake:

Table 2-1 Digital Signature Algorithms

Algorithm Key Size (Bits) Elliptic Curve (EC)
RS256 (RSA) 2048 NA
4096

This is the recommended value.

 NA
ES256 (ECDSA) NA SECP384r1

This is the recommended value.

Comparison Between TLSv1.2 and TLSv1.3

The following table provides a comparison of TLSv1.2 and TLSv1.3:

Table 2-2 Comparison of TLSv1.2 and TLSv1.3

Feature TLS v1.2 TLS v1.3
TLS Handshake
  • The initial handshake was carried out in clear text.
  • A typical handshake in TLSv1.2 involves the exchange of 5 to 7 packets.
  • The initial handshake is carried out along with the key share.
  • A typical handshake IN TLSv1.3 involves the exchange of up to 3 packets.
Cipher Suites
  • Less secure Cipher suites.
  • Use SHA-256 and SHA-384 hashing
    • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
    • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
    • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
    • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • More secure Cipher suites.
  • Apart from all the ciphers supported for TLSv1.2, the following additional ciphers are supported for only TLSv1.3:
    • TLS_AES_128_GCM_SHA256
    • TLS_AES_256_GCM_SHA384
    • TLS_CHACHA20_POLY1305_SHA256
Round-Trip Time (RTT) This has a high RTT during the TLS handshake. This has low RTT during the TLS handshake.
Perfect Forward Secrecy (PFS) This doesn't support PFS. TLSv1.3 supports PFS. PFS ensures that each session key is completely independent of long-term private keys, which are keys that are used for an extended period to decrypt encrypted data.
Privacy This is less secure, as the ciphers used are weak. This is more secure, as the ciphers used are strong.
Performance This has high latency and a less responsive connection. This has low latency and a more responsive connection.

Advantages of TLSv1.3

The TLSv1.3 handshake offers the following improvements over earlier versions:

  • All handshake messages after the ServerHello are encrypted.
  • It improves efficiency in the handshake process by requiring fewer round trips than TLSv1.2. It also uses cryptographic algorithms that are faster.
  • It provides better security than TLSv1.2, addressing known vulnerabilities in the handshake process.
  • It eliminates data compression.

The following table describes the TLS versions supported on the client and server sides. The last column indicates which version will be used.

TLS Version Used

When CNC Console is acting as a client or a server, it can support different TLS versions.

The following table provides information about which TLS version will be used when various combinations of TLS versions are present between the server and the client.

Table 2-3 TLS Version Used

Client Support Server Support TLS Version Used
TLSv1.2, TLSv1.3 TLSv1.2, TLSv1.3 TLSv1.3
TLSv1.3 TLSv1.3 TLSv1.3
TLSv1.3 TLSv1.2, TLSv1.3 TLSv1.3
TLSv1.2, TLSv1.3 TLS v1.3 TLSv1.3
TLSv1.2 TLSv1.2, TLSv1.3 TLSv1.2
TLSv1.2, TLSv1.3 TLSv1.2 TLSv1.2
TLS v1.3 TLSv1.2 Sends an error message.

For more information about the error message, see Oracle Communications Cloud Native Configuration Console Troubleshooting Guide.
TLSv1.2 TLSv1.3 Sends an error message.

For more information about the error message, see Oracle Communications Cloud Native Configuration Console Troubleshooting Guide.

Note:

  • If Egress Gateway is deployed with both the versions of TLS that is TLSv1.2 and TLSv1.3, then Egress Gateway as client will send both versions of TLS in the client hello message during the handshake and the server needs to decide which version to be used.
  • If Ingress Gateway is deployed with both the version of TLS that is with TLSv1.2 and TLSv1.3, then Ingress Gateway as the server will use the TLS version received from the client in the server hello message during the handshake.
  • This feature does not work in ASM deployment.

Managing Support for TLSv1.2 and TLSv1.3

Enable:

This feature can be enabled or disabled at the time of CNC Console deployment using the following Helm parameters:

  • enableIncomingHttps: This flag is used for enabling/disabling HTTPS/2.0 (secured TLS) in the Ingress Gateway. If the value is set to false, CNC Console will not accept any HTTPS/2.0 (secured) traffic. If the value is set to true, CNC Console will accept HTTPS/2.0 (secured) traffic.
  • enableOutgoingHttps: This flag is used for enabling/disabling HTTPS/2.0 (secured TLS) in the Egress Gateway. If the value is set to false, CNC Console will not accept any HTTPS/2.0 (secured) traffic. If the value is set to true, CNC Console will accept HTTPS/2.0 (secured) traffic.

    For more information on enabling this flag, see the "Customizong CNC Console section in the Oracle Communications Cloud Native Configuration Console Installation, Upgrade, and Fault Recovery Guide.

Configure

You can configure this feature using Helm parameters.

The following parameters in the Ingress Gateway and Egress Gateway microservices must be customized to support TLSv1.2 or TLSv1.3:

  1. Generate HTTPS certificates for both the ingress and egress gateways. Ensure that the certificates are correctly configured for secure communication. After generating the certificates, create a Kubernetes secret for each gateway (egress and ingress). Then, configure these secrets to be used by the respective gateways. For more information about HTTPS configuration, generating certificates, and creating secrets, see the "Configuring Secrets for Enabling HTTPS" section in the Oracle Communications Cloud Native Configuration Console Installation, Upgrade, and Fault Recovery Guide .
  2. After configuring the secret and applying it to the namespace where CNC Console is deployed, perform the following Helm changes for Ingress and Egress gateways in the occncc_custom_values_<version>.yaml file:
    • Parameters required to support TLSv1.2:
      • service.ssl.tlsVersion indicates the TLS version.
      • cipherSuites indicates supported cipher suites.
      • allowedCipherSuites indicates allowed cipher suites.
    • Parameters required to support TLSv1.3:
      • service.ssl.tlsVersion indicates the TLS version.
      • cipherSuites indicates the supported cipher suites.
      • allowedCipherSuites indicates the allowed cipher suites.
      • clientDisabledExtension is used to disable the extension sent by messages originating from clients during the TLS handshake with the server.
      • serverDisabledExtension is used to disable the extension sent by messages originating from servers during the TLS handshake with the client.
      • tlsNamedGroups is used to provide a list of values sent in the supported_groups extension. These are comma-separated values.
      • clientSignatureSchemes is used to provide a list of values sent in the signature_algorithms extension.

    For more information about configuring the values of the above-mentioned parameters, see the "Customizing CNC Console" section in the Oracle Communications Cloud Native Configuration Console Installation, Upgrade, and Fault Recovery Guide.

  3. Save the occncc_custom_values_<version>.yaml file.
  4. Install CNC Console. For more information about the installation procedure, see the Oracle Communications Cloud Native Configuration Console Installation, Upgrade, and Fault Recovery Guide .
  5. Run Helm upgrade if you are enabling this feature after CNC Console deployment. For more information about the upgrade procedure, see the Oracle Communications Cloud Native Configuration Console Installation, Upgrade, and Fault Recovery Guide .

Note:

  • CNC Console does not prioritize cipher suites based on priority. To select a cipher based on priority, you must list the cipher suites in decreasing order of priority.
  • CNC Console does not prioritize supported groups based on priority. To select a supported group based on priority, you must list the supported group values in decreasing order of priority.
  • If you want to provide values for the signature_algorithms extension using the clientSignatureSchemes parameter, the following comma-separated values must be provided to deploy the services:
    • rsa_pkcs1_sha512
    • rsa_pkcs1_sha384
    • rsa_pkcs1_sha256

    Note:

    By default, it is null.
  • The mandatory extensions as listed in RFC 8446 cannot be disabled using the clientDisabledExtension attribute on the client or using the serverDisabledExtension attribute on the server side. The following is the list of the extensions that cannot be disabled:
    • supported_versions
    • key_share
    • supported_groups
    • signature_algorithms
    • pre_shared_key

Observe

Metrics

There are no new mterics for this feature.

For more information about metrics, see CNC Console Metrics section.

KPIs

There are no new KPIs for this feature.

Alerts

There are no new alerts for this feature.

Maintain

To resolve any alerts at the system or application level, see CNC Console Alerts section. If the alerts persist, perform the following:
  1. Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.
  2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

2.10 TLS Support with Automated Certificate Management

Introduction

In CNC Console 24.2.x and earlier, X.509 and Transport Layer Security (TLS) certificates were managed manually. When multiple instances of CNC Console were deployed in a 5G network, certificate management, such as certificate creation, renewal, removal, and so on, became tedious and error-prone.

Starting with CNC Console 24.3.x, you can integrate CNC Console with Oracle Communications Cloud Native Core, Certificate Management (OCCM) to support automation of certificate lifecycle management. OCCM manages TLS certificates stored in Kubernetes secrets by integrating with Certificate Authority (CA) using the Certificate Management Protocol Version 2 (CMPv2) protocol in the Kubernetes secret. OCCM obtains and signs TLS certificates within the CNC Console namespace. For more information about OCCM, see Oracle Communications Cloud Native Core, Certificate Management User Guide.

Support for OCCM

This feature enables CNC Console to create, recreate, and renew TLS certificates using OCCM, Certificate validity is monitored for auto renewal. For information about enabling HTTPS, see "Configuring Secrets for Enabling HTTPS" in Oracle Communications Cloud Native Core, Cloud Native Core Console Installation, Upgrade, and Fault Recovery Guide.

The below diagram indicates that OCCM writes the keys to the certificates and CNC Console reads these keys to establish a TLS connection.

  • M-CNCC IAM TLS certificates
  • M-CNCC Core TLS certificates
  • A-CNCC Core TLS Certificates

Figure 2-4 Establishing Connection Between CNC Console and TLS Using OCCM Key


Establishing Connection Between CNC Console and TLS Using OCCM Key

Install Guide Considerations

Upgrade: When CNC Console is deployed with OCCM, follow the specific upgrade procedure. For more information, see "Upgrade Automated Certificate Lifecycle Management Through OCCM" in Oracle Communications Cloud Native Configuration Console Installation, Upgrade, and Fault Recovery Guide.

• Rollback: For more information on migrating the secrets from CNC Console to OCCM, see "Rollback from Automated Certificate Management to Manual Certificate Management" in Oracle Communications Cloud Native Configuration Console Installation, Upgrade, and Fault Recovery Guide.

Maintain

If you encounter any OCCM-specific alerts, see the "OCCM Alerts" section in Oracle Communications Cloud Native Core, Certificate Management User Guide.

If you encounter alerts at system or application levels, see CNC Console Alerts section for resolution steps.

In case the alert still persists, perform the following:
  1. Collect the logs and Troubleshooting Scenarios: For more information on how to collect logs and troubleshooting information, see Oracle Communications Cloud Native Configuration Console Troubleshooting Guide.
  2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

2.11 Service Mesh Communication

Note:

Not applicable for OCI deployment.

CNC Console leverages the Istio or Envoy service mesh (Aspen Service Mesh) for all internal and external communication. The service mesh integration provides Console-NF communication and allows API gateway to co-work with service mesh. The service mesh integration supports these services by deploying a special sidecar proxy in the environment to intercept all network communication between microservices.

For more information, see CNC Console Configuration to Support ASM and OSO in Oracle Communications Cloud Native Configuration Console Installation and Upgrade Guide.

2.12 Support for Dual Stack Networking

Using the dual stack mechanism, applications or NFs can establish connections with pods and services in a Kubernetes cluster using IPv4 or IPv6 or both simultaneously. Dual stack provides:
  • Coexistence strategy that allows hosts to reach IPv4 and IPv6 simultaneously.
  • IPv4 and IPv6 allocation to the Kubernetes clusters during cluster creation. This allocation is applicable for all Kubernetes resources unless explicitly specified during cluster creation.

Kubernetes cluster can have either IPv4 preferred or IPv6 preferred IP address configuration.

IP Address Allocation to Pods

IP address allocation to pods depends on the IP address preference set in the Kubernetes cluster. Pods do not have the privilege to choose an IP address. Consider the following example of a pod deployed in an IPv4 preferred infrastructure. Here, if the Kubernetes cluster has IPv4 preferred configuration, both IPv4 and IPv6 are allocated to the pod, but the primary IP address is IPv4. Example:
IP:               10.xxx.xxx.xxx
IPs:
  IP:           10.xxx.xxx.xxx
  IP:           fd00::1:cxxx:bxxx:8xxx:xxxx
Controlled By:  ReplicaSet/cncc-iam-ingress-gateway-577d8c7d66
Containers:
.....

IP Address Allocation to Services

IP address allocation to all the console services, depends on the cnccDeploymentMode Helm parameter configuration. This Helm parameter automatically configures IP Family Policy and IP Families attributes to the console services. For more information about cnccDeploymentMode, see the Customising CNC Console section in the Oracle Communications Cloud Native Configuration Console Installation, Upgrade, and Fault Recovery Guide.

You can customize the IP address allocation to services based on the cnccDeploymentMode Helm parameter. Services route the traffic to the destination endpoints based on this configuration. If the cnccDeploymentMode Helm parameter is set to IPv4, then IPv4 is allocated to services, and services use IPv4 pod IPs to send the traffic to endpoints.

The following table describes how IP address allocation, IP Family Policy, and IP Families vary based on the cnccDeploymentMode Helm parameter configuration for services:

Table 2-4 IP Address Allocation

Infrastructure Preference Application Preference (cnccDeploymentMode Helm Parameter) IP Family Policy Attribute IP Families Attribute Pod IP Service IP Endpoints
IPv4 Preferred IPv4 SingleStack IPv4 IPv4,IPv6 IPv4 IPv4
IPv6 Preferred IPv4 SingleStack IPv4 IPv6,IPv4 IPv4 IPv4
IPv4 Preferred IPv6 SingleStack IPv6 IPv4,IPv6 IPv6 IPv6
IPv6 Preferred IPv6 SingleStack IPv6 IPv6,IPv4 IPv6 IPv6
IPv4 Preferred IPv4_IPv6 (IPv4Preferred) RequiredDualStack IPv4 Preferred IPv4,IPv6 IPv4,IPv6 IPv4
IPv6 Preferred IPv4_IPv6 (IPv4Preferred) RequiredDualStack IPv4 Preferred IPv6,IPv4 IPv6,IPv4 IPv4
IPv4 Preferred IPv6_IPv4 (IPv6Preferred) RequiredDualStack IPv6 Preferred IPv4,IPv6 IPv4,IPv6 IPv6
IPv6 Preferred IPv6_IPv4 (IPv6Preferred) RequiredDualStack IPv6 Preferred IPv6,IPv4 IPv6,IPv4 IPv6

The following columns are used in the table above:

  • Infrastructure Preference: This is the Kubernetes cluster deployment. It can have either IPv4 preferred or IPv6 preferred.
  • cnccDeploymentMode Helm Parameter: This parameter is configured to set the preference of IP address allocation to the CNC Console services. It has the following values:
    • IPv4: The Ingress Gateway service will be single stack with IPv4 only. It uses IPv4 pod IPs to establish connections.
    • IPv6: The Ingress Gateway service will be single stack with IPv6 only. It uses IPv6 pod IPs to establish connections.
    • IPv4_IPv6: The Ingress Gateway service will be dual stack with both IPv4 and IPv6 addresses. It uses IPv4 pod IPs to establish connections.
    • IPv6_IPv4: The Ingress Gateway service will be dual stack with both IPv4 and IPv6 addresses. It uses IPv6 pod IPs to establish connections.
    • ClusterPreferred: Default value configured for cnccDeploymentMode, All console services will be single stack with IPv4 or IPv6 based on the infrastructure preference.
  • IP Family Policy Attribute: This attribute is automatically configured based on the cnccDeploymentMode Helm parameter configuration. It has the following values:
    • SingleStack: It can allocate only a single IP address to services based on the IP Families attribute configuration. For example, if the IP Family Policy attribute is set to SingleStack and IP Families is set to IPv4, then IPv4 is allocated to services.
    • RequiredDualStack: It can allocate both the IP addresses to services based on the IP Families attribute configuration. For example, if the IP Family Policy attribute is set to RequiredDualStack and IP Families is set to IPv6 preferred, then both IPv6 and IPv4 are allocated to services with IPv6 preferred. If the infrastructure is not dual stack, then Helm upgrade or install will fail.
  • IP Families Attribute: This attribute is automatically configured based on the cnccDeploymentMode Helm parameter. It has the following values:
    • IPv4
    • IPv6
    • IPv4 Preferred
    • IPv6 Preferred
  • Pod IP: Primary IP address allocated to pods in the Kubernetes cluster.
  • Service IP: Primary IP address allocated to services in the Kubernetes cluster.
  • Endpoints: Selected pod IP addresses based on the primary service IP.
Example of a service deployed with IPv4 preferred IP address:
IP Family Policy:    RequireDualStack
IP Families:         IPv4,IPv6
IP:                  10.xx.xx.xx
IPs:                 10.xx.xx.xx,fd00:x:x:x::xxxx

Example of a service deployed with IPv6 preferred IP address:

IP Family Policy:     RequireDualStack
IP Families:          IPv6,IPv4
IP:                   fd00:x:x:x::xx
IPs:                  fd00:x:x:x::xxxx,10.xx.xx.xxx

Enable

This feature is disabled by default. You can enable this feature by configuring the cnccDeploymentMode Helm parameter appropriately.

2.13 CNC Console GUI Session Timeout

The duration (in seconds) before a CNC Console GUI session times out and the user has to log in again can be configured using the ingress-gateway.cncc.core.sessionTimeout parameter in the custom_values.yaml file.

By default, the session time out value is set to 1800 seconds. However, you can set it to any value between 300 and 7200 seconds.

Note:

The value of the CNC Console IAM SSO session idle timeout configuration is not considered for CNC Console Core session management.

2.14 Support for Instance Level Access Control

With this feature, CNC Console supports access management at the instance level. This enables CNC Console to enforce restrictions on users based on the instances assigned to them. With instance based access restriction, CNC Console can stop users from accessing the instances that they are not entitled to. This capability is in addition to the existing RBAC capabilities.

Instance level access control is supported for the following deployment scenarios:
  • Non-OCI deployments
  • OCI Deployments

CNC console allows associating instance roles to the users. This feature can be controled using the instanceLevelAuthorizationEnabled Helm parameter. When this feature is enabled, user must have the instance level role to access the instance. For more information on instance level role, see Types of Roles in CNC Console.

When this feature is enabled for the first time, the INSTANCE_ALL role is assigned to all existing users. To control instance level acces, the operator must assign instance specific roles and remove the INSTANCE_ALL role from users.

2.15 Network Policies

Note:

Not applicable for OCI deployment.

Network Policies are an application-centric construct that allow you to specify how a pod communicates with various network entities. They create pod-level rules to control communication between cluster pods and services, and determine which pods and services can access one another inside a cluster.

Previously, the pods under CNC Console deployment could be contacted by any other pods in the Kubernetes cluster without any restrictions. Now, Network Policies provide namespace-level isolation, which allow secure communications to and from CNC Console with rules defined in the respective network policies. Network policies enforce access restrictions for all the applicable data flows, except communication from Kubernetes node to pod for invoking container probe. For example, CNC Console internal microservices cannot be contacted directly by any other pods.

Managing Support for Network Policies

Enable

To use this feature, network policies must be applied to the namespace where CNC Console is applied.

Configure

You can configure this feature using Helm. For information about Configuring Network Policy for CNC Console Deployment, see Cloud Native Configuration Console Installation, Upgrade, and Fault Recovery Guide.

Observe

There are no specific metrics and alerts required for the Support of Network Policy functionality.

2.16 Traffic Segregation

This feature provides end-to-end traffic segregation to CNC Console based on traffic types. Within a Kubernetes cluster, traffic segregation can divide applications or workloads into distinct sections such as OAM, SBI, Kubernetes control traffic, etc. The Multus CNI container network interface (CNI) plugin for Kubernetes enables attaching multiple network interfaces to pods to help segregate traffic from each CNC Console microservice.

This feature addresses the challenge of logically separating IP traffic of different profiles, which are typically handled through a single network (Kubernetes overlay). The new functionality ensures that critical networks are not cross-connected or sharing the same routes, thereby preventing network congestion.

With traffic segregation, operators can segregate traffic to external feeds and applications more effectively. Previously, all external traffic was routed through the same external network, but now, egress traffic from the CNC Console pods can be directed through non-default networks to third-party applications. This separation is achieved by leveraging cloud-native infrastructure and the load balancing algorithms in OCCNE.

The feature supports the configuration of separate networks, Network Attachment Definitions (NADs), and the Cloud Native Load Balancer (CNLB). These configurations are crucial for enabling cloud native load balancing, facilitating ingress-egress traffic separation, and optimizing load distribution within CNC Console.

Prerequisites

The CNLB feature is only available in CNC Console if OCCNE is installed with CNLB and Multus.

Cloud Native Load Balancer (CNLB)

CNE provides Cloud Native Load Balancer (CNLB) for managing the ingress and egress network as an alternate to the existing LBVM, lb-controller, and egress-controller solutions. You can enable or disable this feature only during a fresh CNE installation. When this feature is enabled, CNE automatically uses CNLB to control ingress traffic. To manage the egress traffic, you must preconfigure the egress network details in the cnlb.ini file before installing CNE.

For more information about enabling and configuring CNLB, see Oracle Communications Cloud Native Core, Cloud Native Environment User Guide, and Oracle Communications Cloud Native Core, Cloud Native Environment Installation, Upgrade, and Fault Recovery Guide.

Network Attachment Definitions for CNLB

A Network Attachment Definition (NAD) is a resource used to set up a network attachment, in this case, a secondary network interface to a pod. CNC Console supports two types of CNLB NADs:

  1. Ingress Network Attachment Definitions

    Ingress NADs are used to handle inbound traffic only. This traffic enters the CNLB application through an external interface service IP address and is routed internally using interfaces within CNLB networks.

    • Naming Convention: nf-<service_network_name>-int
  2. Egress Only Network Attachment Definitions

    Egress Only NADs enable outbound traffic only. An NF pod can initiate traffic and route it through a CNLB application, translating the source IP address to an external egress IP address. An egress NAD contains network information to create interfaces for NF pods and routes to external subnets.

    • Requirements:
      • Ingress NADs are already created for the desired internal networks.
      • Destination (egress) subnet addresses are known beforehand and defined under the cnlb.ini file's egress_dest variable to generate NADs.
      • The use of an Egress NAD on a deployment can be combined with Ingress NADs to route traffic through specific CNLB apps.
    • Naming Convention: nf-<service_network_name>-egr

Managing Ingress and Egress Traffic Segregation

Enable:

This feature is disabled by default. To enable this feature, you must configure the network attachment annotations in the custom values file.

Configuration

For more information about Traffic Segregation configuration, see the "Installing CNC Console Package" section in the Oracle Communications Cloud Native Configuration Console Installation, Upgrade, and Fault Recovery Guide.

Observe

There are no Metrics, KPIs, or Alerts available for this feature.

Maintain

To resolve any alerts at the system or application level, see CNC Console Alerts section. If the alerts persist, perform the following:

  1. Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.
  2. Raise a service request: See My Oracle Support for more information on how to raise a service request.