2 Installing CNC Console

This chapter provides information about installing Oracle Communications Cloud Native Configuration Console (CNC Console) in a cloud native environment.

Note:

CNC Console supports fresh installation. For more information on how to upgrade CNC Console, see Upgrading CNC Console section.

2.1 Prerequisites

Before installing Oracle Communications CNC Console, make sure that the following requirements are met:

2.1.1 Software Requirements

This section lists the software that must be installed before installing CNC Console:

Install the following software before installing CNC Console:

Table 2-1 Preinstalled Software

Software Version
Kubernetes 1.30.x, 1.29.x, 1.28.x
Helm 3.11.3
Podman 4.4.1
To check the current Helm, Kubernetes , and Podman version installed in the CNE, run the following commands:
 kubectl version
 helm version 
podman version
The following software are available if CNC Console is deployed in CNE. If you are deploying CNC Console in any other cloud native environment, these additional software must be installed before installing CNC Console. To check the installed software, run the following command: 
helm ls -A
The list of additional software items, along with the supported versions and usage, is provided in the following table:

Table 2-2 Additional Software

Software Version Required For
FluentBit 1.9.4 Logging
Grafana 9.5.3 KPIs
Jaeger 1.60.0 Tracing
Kyverno 1.12.5 Logging
MetalLB 0.14.4 External IP
Opensearch 2.11.0 Logging
OpenSearch Dashboard 2.11.0 Logging
Prometheus 2.51.1 Metrics
snmp-notifier 1.2.1 Alerts

Note:

Not applicable for OCI deployment.

2.1.2 Environment Setup Requirements

This section provides information on environment setup requirements for installing CNC Console.

Client Machine Requirement

This section describes the requirements for client machine, that is, the machine used by the user to run deployment commands.

Client machine must have:
  • Helm repository configured.
  • network access to the Helm repository and Docker image repository.
  • network access to the Kubernetes cluster.
  • required environment settings to run the kubectl, docker, and podman commands. The environment must have privileges to create a namespace in the Kubernetes cluster.
  • Helm client installed with the push plugin. Configure the environment in such a manner that the helm install command deploys the software in the Kubernetes cluster.

Network Access Requirement

The Kubernetes cluster hosts must have network access to the following repositories:

  • Local helm repository, where the CNC Console helm charts are available.
    To check if the Kubernetes cluster hosts have network access to the local helm repository, run the following command: 
    helm repo update
  • Local docker image repository: It contains the CNC Console Docker images.
    To check if the Kubernetes cluster hosts can access the the local Docker image repository, try to retrieve any image with tag name to check connectivity by running the following command: 
    docker pull <docker-repo>/<image-name>:<image-tag>
    podman pull <Podman-repo>/<image-name>:<image-tag>
    where:
    • <docker-repo> is the IP address or host name of the repository.
    • <Podman-repo> is the IP address or host name of the Podman repository.
    • <image-name> is the docker image name.
    • <image-tag> is the tag the image used for the CNC Console pod.

Note:

Run the kubectl and helm commands on a system based on the deployment infrastructure. For instance, they can be run on a client machine such as VM, server, local desktop, and so on.

Server or Space Requirement

For information about the server or space requirements, see the Oracle Communications Cloud Native Core, Cloud Native Environment Installation, Upgrade, and Fault Recovery Guide.

CNE Requirement

This section is applicable only if you are installing CNC Console on Cloud Native Environment (CNE).

To check the CNE version, run the following command:
echo $OCCNE_VERSION

For more information about CNE, see Oracle Communications Cloud Native Core, Cloud Native Environment Installation, Upgrade, and Fault Recovery Guide.

cnDBTier Requirement

CNC Console supports cnDBTier . cnDBTier must be configured and running before installing CNC Console. For more information about installation procedure, see Oracle Communications cnDBTier Installation, Upgrade, and Fault Recovery Guide.

OSO Requirement

CNC Console supports OSO for common operation services (Prometheus and components such as alertmanager, pushgateway) for Kubernetes cluster which does not have these common services. For more information on installation procedure, see Oracle Communications OSO Installation Guide.

OCI Requirements

CNC Console can be deployed in OCI.

While deploying CNC Console in OCI, the user must use the Operator instance or VM instead of Bastion Host.

For more information about OCI deployment, see Oracle Communications Oracle Cloud Interface, NF Deployment on OCI using OCI Adaptor.

2.1.3 CNC Console Resource Requirement

This section lists the resource requirements to install and run CNC Console.

CNC Console and cnDBTier Resource Usage Guidelines

This section explains the guidelines for CNC Console and cnDBTier resource usage guidelines.

Note:

For OCI:
  • In the OCI environment, the M-CNCC IAM DB is not applicable but M-CNCC Core DB is applicable, and therefore, there are no changes to the database requirement. The CNC Console and cnDBTier Resource Usage table remains valid.
  • In the CNC Console and cnDBTier Resource Usage table, only Model 1 and Model 2 are supported for OCI deployment.

Note:

In case of deployment using shared DBTier between NF and Console, you must include Console DB Profile sizing in NF DB Profile sizing.

Note:

  • DBProfile replica count to be updated as per GR setup.
  • Depending on GR setup of two, three, or four site choose replica count two, four, or six for SQL (ndbmysqld).

Table 2-3 CNC Console and cnDBTier Resource Usage

Deployment Model cnDBTier Usage DBTier Resource Profile Console Resources
Model 1 - Single Cluster, Single Instance (dedicated Console for each NF in a cluster)

Console and NF have a single shared DBTier

  • M-CNCC on same Kubernetes cluster use shared DBTier
  • DBProfile
  • A-CNCC on a same Kubernetes cluster does not have any DBTier dependency.
For the details, see cnDBTier Profiles

Model 2 - Single Cluster, Multiple Instances (One Console for many NFs/Instances in a cluster)

Dedicated DBTier for Console

  • M-CNCC on same Kubernetes cluster use single Console DBTier
  • DBProfile
  • A-CNCC on a same Kubernetes cluster does not have anyDBTier dependency.

For the details, see cnDBTier Profiles

Model 3 - Multiple Clusters, Single Instance. (Multiple clusters with single NF/Instance in each cluster, M-CNCC/A-CNCC sitting in same/different clusters)

Console and NF have a single shared DBTier

  • M-CNCC on same Kubernetes cluster use shared DBTier
  • Manager - DBProfile
  • A-CNCC on a remote Kubernetes cluster does not have any DBTier dependency.

For the details, see cnDBTier Profiles

Model 4 - Multiple Clusters, Multiple Instances (Multiple clusters with multiple NF/Instance in each cluster, M-CNCC/A-CNCC sitting in same/different clusters)

Dedicated DBTier for Console per Kubernetes cluster

  • M-CNCC on same Kubernetes cluster use single Console DBTier
  • Manager - DBProfile
  • A-CNCC on a remote Kubernetes cluster does not have any DBTier dependency.

For the details, see cnDBTier profiles

Note:

  • Time synchronization is required between Kubernetes nodes across cluster for functioning of CNC Console security procedures.
  • Ensure NTP sync before proceeding with M-CNCC IAM, M-CNCC Core, and A-CNCC Core installation.
Resource Usage for CNC Console Deployment

Resource usage for CNC Console Single Cluster and Multicluster deployment is listed in the following tables.

Note:

The M-CNCC IAM Resource component is not applicable in OCI deployment.
Resource Usage for CNC Console Single Cluster Deployment

Single Cluster Deployment includes M-CNCC IAM, M-CNCC Core and A-CNCC Core components. It also includes common resource needed for manager or agent deployment.

Table 2-4 Resource Usage for CNC Console Single Cluster Deployment

Component Max Min
CPU Memory (Gi) CPU Memory (Gi)
M-CNCC IAM 4.5 4.5 4.5 4.5
M-CNCC Core 4 4 4 4
A-CNCC Core 2 2 2 2
CNCC Common Resource 2 2 2 2
Total 12.5 12.5 12.5 12.5

Formula

Total Resource = M-CNCC IAM Resource + M-CNCC Core Resource + A-CNCC Core Resource + CNCC Common Resource

Resource Usage for CNC Console Multicluster Deployment

Multicluster Deployment will include M-CNCC IAM and M-CNCC Core components in Manager cluster. A-CNCC Core component shall be deployed in Manager cluster if there is a local NF.

A-CNCC Core is needed in each Agent cluster for managing local NF. CNC Console Common Resource is a common resource needed for manager or agent deployment.

Table 2-5 Resource Usage for CNC Console Multicluster Deployment

Component Max Min
CPU Memory (Gi) CPU Memory (Gi)
M-CNCC IAM 4.5 4.5 4.5 4.5
M-CNCC Core 4 4 4 4
A-CNCC Core 2 2 2 2
CNCC Common Resource 2 2 2 2
*No Of Agents In Other Clusters 2
Total 18.5 18.5 18.5 18.5

* Assumed number of Agents (A-CNCC Core deployments) for the calculation

Formula to calculate total resource usage:

Total Resource = M-CNCC IAM Resource + M-CNCC Core Resource + Common Resources + (No Of Agents In Other Clusters x (CNCC Common Resource + A-CNCC Core Resource))

CNC Console Manager Only Deployment

The following table shows resource requirement for manager only deployment. In this case, agent will be deployed in separate cluster.

Table 2-6 CNC Console Manager Only Deployment

Component Max Min
CPU Memory (Gi) CPU Memory (Gi)
M-CNCC IAM 4.5 4.5 4.5 4.5
M-CNCC Core 4 4 4 4
A-CNCC Core 0 0 0 0
CNCC Common Resource 2 2 2 2
Total 10.5 10.5 10.5 10.5

CNC Console Agent Only Deployment

The following table shows resource requirement for agent only deployment, in this case manager will be deployed in separate cluster.

Table 2-7 CNC Console Agent Only Deployment

Component Max Min
CPU Memory (Gi) CPU Memory (Gi)
M-CNCC IAM 0 0 0 0
M-CNCC Core 0 0 0 0
A-CNCC Core 2 2 2 2
CNCC Common Resource 2 2 2 2
Total 4 4 4 4

CNC Console Manager with Agent Deployment

The following table shows resource requirement for manager with agent deployment, in this case agent will be deployed along with manager to manage local NF.

This manager can manage agents deployed in other clusters.

Table 2-8 CNC Console Manager with Agent Deployment

Component Max Min
CPU Memory (Gi) CPU Memory (Gi)
M-CNCC IAM 4.5 4.5 4.5 4.5
M-CNCC Core 4 4 4 4
A-CNCC Core 2 2 2 2
CNCC Common Resource 2 2 2 2
Total 12.5 12.5 12.5 12.5

CNC Console Component wise Resource Usage

Table 2-9 CNCC Common Resource Usage

Microservice Name Containers Max Min Comments
CPU Memory CPU Memory
hookJobResources NA 2 2 2 2 Common Hook Resource
helm test cncc-test 0 0 0 0 Uses hookJobResources
Total   2 2 2 2  

Note:

  • Debug tool resources are not considered in the calculation. Debug tool resources usage is per pod, if debug tool is enabled for more than one pod then max 1vCPU and 2Gi Memory per pod is needed.
  • Service Mesh (ASM) sidecar resources are not considered in the calculation. Service Mesh sidecar resources usage is per pod, that is, if Service Mesh is enabled and sidecar is injected, then max 1vCPU and 1Gi Memory per pod is needed.

Table 2-10 M-CNCC IAM Resource Usage

Microservice Name Containers Max Min Comments
CPU Memory CPU Memory
cncc-iam-ingress-gateway ingress-gateway 2 2 2 2  
  init-service* 0 0 0 0 Applicable when HTTPS is enabled.

*Init-service container's resources are not counted because the container gets terminated after initialization completes.
  common_config_hook 0 0 0 0 common_config_hook not used in IAM
cncc-iam-kc-http kc 2 2 2 2
  init-service* 0 0 0 0 Optional, used for enabling LDAPS.

*Init-service container's resources are not counted because the container gets terminated after initialization completes.
  healthcheck 0.5 0.5 0.3 0.3  
  cnnc-iam--pre-install 0 0 0 0 Uses hookJobResources
  cnnc-iam-pre-upgrade 0 0 0 0 Uses hookJobResources
  cnnc-iam-post-install 0 0 0 0 Uses hookJobResources
  cnnc-iam-post-upgrade 0 0 0 0 Uses hookJobResources
Total   4.5 4.5 4.5 4.5  

Table 2-11 M-CNCC Core Resource Usage

Microservice Name Containers Max Min Comments
CPU Memory CPU Memory
cncc-mcore-ingress-gateway ingress-gateway 2 2 2 2  
  init-service* 0 0 0 9 Applicable when HTTPS is enabled.

*Init-service container's resources are not counted because the container gets terminated after initialization completes.
  common_config_hook* 0 0 0 0 Common Configuration Hook container creates databases which are used by Common Configuration Client.

*common_config_hook container's resources are not counted because the container gets terminated after initialization completes.
cncc-mcore-cmservice cmservice 2 2 2 2  
  validation-hook 0 0 0 0 Uses common hookJobResources
Total   4 4 4 4  

Table 2-12 A-CNCC Core Resource Usage

Microservice Name Containers Max Min Comments
CPU Memory CPU Memory
cncc-acore-ingress-gateway ingress-gateway 2 2 2 2  
  init-service* 0 0 0 0 Applicable when HTTPS is enabled.

*Init-service container's resources are not counted because the container gets terminated after initialization completes.
  common_config_hook* 0 0 0 0 Common Configuration Hook container creates databases which are used by Common Configuration Client.

*Init-service container's resources are not counted because the container gets terminated after initialization completes.
  validation-hook 0 0 0 0 Uses common hookJobResources
Total   2 2 2 2  

2.2 Installation Sequence

This section describes the CNC Console preinstallation, installation, and postinstallation tasks.

2.2.1 Preinstallation Tasks

Before installing CNC Console, perform the tasks described in this section.

Note:

For IPv4 or IPv6 configurations, see unresolvable-reference.html#GUID-6A927EB5-35AB-4705-AA1A-CB7D47F9EA2B.
2.2.1.1 Configuring OCI IAM

Note:

Only applicable for OCI deployment.

Configure OCI IAM for Authentication and Authorization

Before working with OCI IAM, you must have OCI tenancy along with Identity Domain created.

When seeking a more secure connection method to access CNC Console beyond basic authentication, OAuth 2.0 is the preferred choice. To implement OAuth 2.0 with CNC Console to connect Integration Cloud, you must configure client-server confidential applications in OCI IAM (formerly known as OCI IAM – Identity Cloud Service). This section provides a step-by-step guide on setting up this application for a CNC Console.

Note:

To perform the following steps, only OCI Admins are allowed to configure OCI IAM and Custom Claims. For more information, see the Oracle Communications Cloud Native Core OCI Adaptor, NF Deployment in OCI Guide

2.2.1.1.1 Create a Confidential Application Under OCI IAM
To create a confidential application under OCI IAM:
  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains.
  2. Click the name of the identity domain that you want to work in. You might need to change the compartment to find the domain that you want. Then, click Integrated applications.
  3. Click Add application.
  4. In the Add application window, click Confidential Application, and then click Launch workflow.
  5. In the Add application details page, update the following fields:

    Figure 2-1 Add Application


    Add application

    1. Name: Enter a name for the confidential application. You can enter up to 125 characters. Ex: cncc-iam.
    2. Description: Enter a description for the confidential application. You can enter up to 250 characters.
  6. Click Next.
  7. On the Configure OAuth pane, click Configure this application as a client now. Update the following fields.
    1. Authorization Types: Within the configuration page, toggle on the Resource owner, Client Credentials and Refresh token.

      Figure 2-2 Authorization Types


      Authorization Types

    2. Client type: Select Confidential.

      Figure 2-3 Client Type


      Client Type

    3. Allowed Operations: Select Introspect.
    4. Bypass Consent: Enable it.
    5. Client IP address: Select Anywhere.
    6. Token Issuance Policy: From the available options, select All.
    7. Add App Role:

      Figure 2-4 Add App Roles


      Add App Roles

      • Click the Add roles button to open a side panel for additional configurations.
      • In this new panel, locate the role Identity Domain Administrator.
      • Confirm that the Identity Domain Administrator role is checked and added.
  8. Click Next.
  9. Click Finish.

    Figure 2-5 Finish


    Finish

  10. At the top of the page, to the right of the application name, click Activate.
  11. In the Activate application dialog box, click Activate application.

    Figure 2-6 Activate Application


    Activate Application

2.2.1.1.2 Update OCI IAM Issuer URL

To updated OCI IAM issuer url:

  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains.
  2. Click the name of the identity domain that you want to work in. You might need to change the compartment to find the domain that you want.
  3. On the domain details page, click Security.
  4. On the Security page, click OAuth.
  5. In the Issuer field, enter the domain URL. This issuer value is used in the newly issued tokens. For more information, see Accessing OCI IAM.

    Figure 2-7 Update Issuer


    Update Issuer

Note:

  • If the OCI IAM domain URL is with default ports 80 or 443, remove the port from the domain URL while updating the Issuer field. Please refer the attached screenshot.
  • The OCI IAM domain URL needs to be configured in mCnccIams while installing CNC Console.
2.2.1.1.3 Enabling Access to the Signing Certificate

To allow CNC Console to access the signing certificate for the identity domain in IAM without logging in to an identity domain:

  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains.
  2. Click the name of the identity domain that you want to work in. You might need to change the compartment to find the domain that you want.
  3. Click Settings and then click Domain settings.

    Figure 2-8 Domain Settings


    Domain Settings

  4. Under Access signing certificate, select Configure client access to allow CNC Console to access the tenant signing certificate and the SAML metadata without logging in to the identity domain.

    If this option is cleared, CNC Console can access the tenant signing certificate and the SAML metadata only after they authenticate by logging in to the identity domain.

  5. Click Save changes.
2.2.1.1.4 Disabling User's Email Address for Account Creation (Optional)

Note:

By default, Primary email address required is enabled for OCI IAM unless OCI IAM Admin disables it.

Set whether a primary email address is required to create user accounts in an identity domain in IAM.

  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains.
  2. Click the name of the identity domain that you want to work in. You might need to change the compartment to find the domain that you want.
  3. Click Settings and then click Domain settings.
  4. Under User settings, select or unselect Primary email address required.
  5. Click Save changes.

Figure 2-9 User Settings


User Settings

2.2.1.1.5 Create Custom Claim in OCI IAM
Configure the Custom Claim you use OCI IAM's Custom Claims REST API:
curl --location 'https://<oci-iam-domain-url>/admin/v1/CustomClaims' \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer <oci-iam-access-token>' \
--data '{
    "schemas": [
        "urn:ietf:params:scim:schemas:oracle:idcs:CustomClaim"
    ],
    "name": "roles",
    "value": "$user.groups.*.display",
    "expression": true,
    "mode": "always",
    "tokenType": "BOTH",
    "allScopes": true
}'

The attributes used in above request are:

Dynamic Attributes Description
<oci-iam-domain-url> OCI IAM Domain URL. For information, see Accessing OCI IAM.
<oci-iam-access-token> OCI IAM Access token of the OCI IAM Admin User. For more information see the Access NF Resources Through Curl or Postman for OCI section in the Oracle Communications Cloud Native Configuration Console User Guide.
Static Attributes Description
name Value: roles - The claim name.
expression Value: true - OCI IAM identifies the value field will be with expression and not static value.
value Value: $user.groups.*.display - Expression.
mode Value: always – Always include the claim.
tokenType Value: BOTH - The claim will be added to Access and ID Token.
allScopes Value: true - It will be added to any scope.
2.2.1.2 Downloading CNC Console Package

To download the CNCC package from My Oracle Support My Oracle Support (MOS), perform the following steps

  1. Log in to My Oracle Support using your login credentials.
  2. Click the Patches & Updates tab to locate the patch.
  3. In the Patch Search console, click the Product or Family (Advanced) option.
  4. Enter Oracle Communications Cloud Native Core - 5G in Product field and select the product from the Product drop-down list.
  5. From the Release drop-down list, select "Oracle Communications Cloud Native Configuration Console <release_number>".

    Where, <release_number> indicates the required release number of CNCC.

  6. Click Search.

    The Patch Advanced Search Results list appears.

  7. Select the required patch from the list.

    The Patch Details window appears.

  8. Click on Download.

    The File Download window appears.

  9. Click on the <p********_<release_number>_Tekelec>.zip file.
  10. Extract the release package zip file to download the network function patch to the system where network function must be installed.
  11. Extract the release package zip file.

    Package is named as follows:

    occncc_csar_<marketing-release-number>.zip

    Example:

    occncc_csar_24_3_0_0_0.zip

    Note:

    The user must have their own repository for storing the CNC Console images and repository which must be accessible from the Kubernetes cluster.

2.2.1.3 Pushing the Images to Customer Docker Registry

CNC Console deployment package includes ready-to-use images and Helm charts to help orchestrate containers in Kubernetes. The communication between Pods of services of CNC Console products are preconfigured in the Helm charts.

To push the images to the registry, perform the following steps:

  1. Unzip the CNC Console package file: Unzip the CNC Console package file to the specific repository:

    unzip occncc_csar_<marketing-release-number>.zip

    The package consists of following files and folders:

    1. Files: CNC Console Docker images file and CNC Console Helm Charts
    2. Scripts: Custom values and alert files:
      • CNC Console custom values file: occncc_custom_values_<version>.yaml
      • CNC Console cnDBTier custom values file: occncc_dbtier_<cndbtier_version>_custom_values_<version>.yaml
      • CNC Console network policy custom values file: occncc_network_policy_custom_values_<version>.yaml
      • CNC Console IAM Schema file for rollback to previous version: occncc_rollback_iam_schema_<version>.sql
      • CNC Console Metric Dashboard file for CNE without Prometheus Operator: occncc_metric_dashboard_<version>.json
      • CNC Console Metric Dashboard file for CNE with Prometheus HA Operator: occncc_metric_dashboard_promha_<version>.json
      • CNC Console Metric Dashboard file for OCI deployment: occncc_oci_metric_dashboard_<version>.zip
      • CNC Console Alert Rules file for CNE without Prometheus Operator: occncc_alertrules_<version>.yaml
      • CNC Console Alert Rules file for CNE with Prometheus HA Operator: occncc_metric_dashboard_promha_<version>.json
      • CNC Console Alert Rules file for OCI deployment: occncc_oci_alertrules_<version>.zip
      • CNC Console MIB files: occncc_mib_<version>.mib, occncc_mib_tc_<version>.mib
      • CNC Top level mib file: toplevel.mib
    3. Definitions: Definitions folder contains the CNE Compatibility and definition files.
      • occncc_cne_compatibility.yaml
      • occncc.yaml
    4. TOSCA-Metadata: TOSCA.meta
    5. The package folder structure is as follows: 
      Definitions
       occncc_cne_compatibility.yaml
       occncc.yaml
Files
    apigw-common-config-hook-24.3.3.tar
    apigw-configurationinit-24.3.3.tar
    ChangeLog.txt
    cncc-apigateway-24.3.3.tar
    cncc-cmservice-24.3.0.tar
    cncc-core-validationhook-24.3.0.tar
    cncc-iam-24.3.0.tar
    cncc-iam-healthcheck-24.3.0.tar
    cncc-iam-hook-24.3.0.tar
    Helm
        occncc-24.3.0.tgz
        occncc-network-policy-24.3.0.tgz
    Licenses
    nf_test-24.3.2.tar
    ocdebug-tools-24.3.1.tar
    Oracle.cert
    Tests
occncc.mf
Scripts
    occncc_alerting_rules_promha_24.3.0.yaml
    occncc_alertrules_24.3.0.yaml
    occncc_custom_values_24.3.0.yaml
    occncc_dbtier_24.3.0_custom_values_24.3.0.yaml 
    occncc_metric_dashboard_24.3.0.json
    occncc_metric_dashboard_promha_24.3.0.json
    occncc_mib_24.3.0.mib
    occncc_mib_tc_24.3.0.mib
    occncc_network_policy_custom_values_24.3.0.yaml
    occncc_rollback_iam_schema_24.3.0.sql
    occncc_oci_metric_dashboard_24.3.0.zip
    occncc_oci_alertrules_24.3.0.zip
    toplevel.mib
TOSCA-Metadata
    TOSCA.meta
 
Example: unzip occncc_csar_24_3_0_0_0.zip
Archive: occncc_csar_24_3_0_0_0.zip
creating: Definitions/
inflating: Definitions/occncc_cne_compatibility.yaml
inflating: Definitions/occncc.yaml
creating: Files/
creating: Files/Tests/
creating: Files/Helm/
inflating: Files/Helm/occncc-24.3.0.tgz
extracting: Files/Helm/occncc-network-policy-24.3.0.tgz
creating: Files/Licenses/
inflating: Files/apigw-configurationinit-24.3.3.tar
inflating: Files/apigw-common-config-hook-24.3.3.tar
inflating: Files/ocdebug-tools-24.3.1.tar
inflating: Files/cncc-apigateway-24.3.3.tar
inflating: Files/cncc-iam-24.3.0.tar
inflating: Files/cncc-iam-hook-24.3.0.tar
inflating: Files/cncc-iam-healthcheck-24.3.0.tar
inflating: Files/nf_test-24.3.2.tar
inflating: Files/cncc-core-validationhook-24.3.0.tar
inflating: Files/cncc-cmservice-24.3.0.tar
inflating: Files/ChangeLog.txt
extracting: Files/Oracle.cert
creating: Scripts/
inflating: Scripts/occncc_custom_values_24.3.0.yaml
inflating: Scripts/occncc_network_policy_custom_values_24.3.0.yaml
inflating: Scripts/occncc_mib_tc_24.3.0.mib
inflating: Scripts/occncc_mib_24.3.0.mib
inflating: Scripts/toplevel.mib
inflating: Scripts/occncc_metric_dashboard_24.3.0.json
inflating: Scripts/occncc_metric_dashboard_promha_24.3.0.json
inflating: Scripts/occncc_alertrules_24.3.0.yaml
inflating: Scripts/occncc_alerting_rules_promha_24.3.0.yaml
inflating: Scripts/occncc_rollback_iam_schema_24.3.0.sql
inflating: Scripts/occncc_dbtier_24.3.0_custom_values_24.3.0.yaml
inflating: Scripts/occncc_oci_metric_dashboard_24.3.0.zip
inflating: Scripts/occncc_oci_alertrules_24.3.0.zip
creating: TOSCA-Metadata/
inflating: TOSCA-Metadata/TOSCA.meta
inflating: occncc.mf
 
 
occncc_oci_metric_dashboard_<version>.zip file contains the metric dashboard files for OCI deployment.
occncc_oci_metric_dashboard_<version>.json  covers overall metrics including all the supported NF flows.
occncc_oci_<NF>_metric_dashboard_<version>.json covers NF flow specific metrics.
 
Example:
unzip occncc_oci_metric_dashboard_24.3.0.zip
Archive:  occncc_oci_metric_dashboard_24.3.0.zip
   creating: occncc_oci_metric_dashboard/
  inflating: occncc_oci_metric_dashboard/occncc_oci_bsf_metric_dashboard_24.3.0.json 
  inflating: occncc_oci_metric_dashboard/occncc_oci_dd_metric_dashboard_24.3.0.json 
  inflating: occncc_oci_metric_dashboard/occncc_oci_metric_dashboard_24.3.0.json 
  inflating: occncc_oci_metric_dashboard/occncc_oci_nef_metric_dashboard_24.3.0.json
  inflating: occncc_oci_metric_dashboard/occncc_oci_capif_metric_dashboard_24.3.0.json  
  inflating: occncc_oci_metric_dashboard/occncc_oci_nrf_metric_dashboard_24.3.0.json 
  inflating: occncc_oci_metric_dashboard/occncc_oci_nssf_metric_dashboard_24.3.0.json 
  inflating: occncc_oci_metric_dashboard/occncc_oci_nwdaf_metric_dashboard_24.3.0.json 
  inflating: occncc_oci_metric_dashboard/occncc_oci_occm_metric_dashboard_24.3.0.json 
  inflating: occncc_oci_metric_dashboard/occncc_oci_policy_metric_dashboard_24.3.0.json 
  inflating: occncc_oci_metric_dashboard/occncc_oci_provgw_metric_dashboard_24.3.0.json 
  inflating: occncc_oci_metric_dashboard/occncc_oci_scp_metric_dashboard_24.3.0.json 
  inflating: occncc_oci_metric_dashboard/occncc_oci_sepp_metric_dashboard_24.3.0.json 
  inflating: occncc_oci_metric_dashboard/occncc_oci_udr_metric_dashboard_24.3.0.json
 
occncc_oci_alertrules_<version>.zip file contains the alarm terraform directory for OCI deployment.
occncc_oci directory contains CNC Console feature specific alarms.
occncc_oci_resources directory contains CNC Console pod/container memory alarms.
 
Example:
unzip occncc_oci_alertrules_24.3.0.zip
Archive:  occncc_oci_alertrules_24.3.0.zip
   creating: occncc_oci_alertrules/
   creating: occncc_oci_alertrules/occncc_oci_resources/
  inflating: occncc_oci_alertrules/occncc_oci_resources/notifications.tf 
  inflating: occncc_oci_alertrules/occncc_oci_resources/alarms.tf 
  inflating: occncc_oci_alertrules/occncc_oci_resources/variables.tf 
  inflating: occncc_oci_alertrules/occncc_oci_resources/schema.yaml 
   creating: occncc_oci_alertrules/occncc_oci/
  inflating: occncc_oci_alertrules/occncc_oci/notifications.tf 
  inflating: occncc_oci_alertrules/occncc_oci/alarms.tf 
  inflating: occncc_oci_alertrules/occncc_oci/variables.tf 
  inflating: occncc_oci_alertrules/occncc_oci/schema.yaml
  2. Run the following command to move to Files Folder To load docker image: 
    cd Files
  3. Run the following command to load the tarballs to system and push to registry:

    Note:

    For OCI
    • cncc-iam-* images are not applicable for OCI deployment.
    • CNC Console images must be pushed to OCI Registry. In the following commands, replace <docker-repo>/<podman-repo> with <oci-repo>

    OCI Registry:

    1. To push the images to OCI Registry you need to login to the OCI Registry:
      Docker command: 
      docker login -u <REGISTRY_USERNAME> -p <REGISTRY_PASSWORD> <REGISTRY_NAME>
      Podman command:
      podman login -u <REGISTRY_USERNAME> -p <REGISTRY_PASSWORD> <REGISTRY_NAME>
      where,
      • REGISTRY_NAME is <Region_Key>.ocir.io.
      • REGISTRY_USERNAME is <Object Storage Namespace>/<identity_domain>/email_id.
      • REGISTRY_PASSWORD is the Authtoken generated by the user.
      For details about the Region Key, refer to Regions and Availability Domains.

      Identity Domain is the domain to which the user is present.

      Object Storage Namespace is available at OCI Console > Governanace & Administration > Account Management > Tenenancy Details > Object Storage Namespace.

    2. Push the images to OCI Registry.

    Run the following command to push the images to the required registry:

    Docker:
    docker load --input <image-name>-<image-tag>.tar  
docker tag <image-name>:<image-tag> <docker-repo>/<image-name>:<image-tag>
docker push <docker_repo>/<image_name>:<image-tag>
    For example:
    docker load --input apigw-common-config-hook-24.3.0.tar
docker tag occncc/apigw-common-config-hook:24.3.0 <docker-repo>/occncc/apigw-common-config-hook:24.3.0
docker push <docker-repo>/occncc/apigw-common-config-hook:24.3.0
 
docker load --input cncc-core-validationhook-24.3.0.tar
docker tag occncc/cncc-core-validationhook:24.3.0 <docker-repo>/occncc/cncc-core-validationhook:24.3.0
docker push <docker-repo>/occncc/cncc-core-validationhook:24.3.0
 
docker load --input nf_test-24.3.0.tar
docker tag occncc/nf_test:24.3.0 <docker-repo>/occncc/nf_test:24.3.0
docker push <docker-repo>/occncc/nf_test:24.3.0
 
docker load --input apigw-configurationinit-24.3.0.tar
docker tag occncc/apigw-configurationinit:24.3.0 <docker-repo>/occncc/apigw-configurationinit:24.3.0
docker push <docker-repo>/occncc/apigw-configurationinit:24.3.0
 
docker load --input cncc-iam-24.3.0.tar
docker tag occncc/cncc-iam:24.3.0 <docker-repo>/occncc/cncc-iam:24.3.0
docker push <docker-repo>/occncc/cncc-iam:24.3.0
 
docker load --input ocdebug-tools-24.3.0.tar
docker tag occncc/ocdebug-tools:24.3.0 <docker-repo>/occncc/ocdebug-tools:24.3.0
docker push <docker-repo>/occncc/ocdebug-tools:24.3.0
  
docker load --input cncc-iam-healthcheck-24.3.0.tar
docker tag occncc/cncc-iam-healthcheck:24.3.0 <docker-repo>/occncc/cncc-iam-healthcheck:24.3.0
docker push <docker-repo>/occncc/cncc-iam-healthcheck:24.3.0
 
docker load --input cncc-iam-hook-24.3.0.tar
docker tag occncc/cncc-iam-hook:24.3.0 <docker-repo>/occncc/cncc-iam-hook:24.3.0
docker push <docker-repo>/occncc/cncc-iam-hook:24.3.0
 
docker load --input cncc-apigateway-24.3.0.tar
docker tag occncc/cncc-apigateway:24.3.0 <docker-repo>/occncc/cncc-apigateway:24.3.0
docker push <docker-repo>/occncc/cncc-apigateway:24.3.0
 
docker load --input cncc-cmservice-24.3.0.tar
docker tag occncc/cncc-cmservice:24.3.0<docker-repo>/occncc/cncc-cmservice:24.3.0
docker push <docker-repo>/occncc/cncc-cmservice:24.3.0
    Podman:
    podman load --input <image-name>-<image-tag>.tar   
podman tag <image-name>:<image-tag> <podman-repo>/<image-name>:<image-tag>
podman push <podman_repo>/<image_name>:<image-tag>
  4. Run the following command to check whether all the images are loaded:

    Note:

    For OCI:

    All the image repositories in OCI Registry must be public. Run the following steps to make all image repositories to public:

    1. Go to OCI Console > Developer Services > Containers & Artifacts > Container Registry.
    2. Select the root Compartment.
    3. In the Repositories and Images Search option, the images will be listed. Select each image and click Change to Public. This step must be performed for all the images sequentially. 
    docker images
    podman images
  5. Run the following command to move to the Helm Directory 
    cd Helm
    For example:
    helm cm-push --force occncc-24.3.0.tgz ocspf-helm-repo
  6. Run the following command to push helm charts to Helm Repository:
    helm cm-push --force <chart name>.tgz <helm repo>
    For example:
    helm cm-push --force occncc-24.3.0.tgz ocspf-helm-repo
2.2.1.4 Verifying and Creating CNC Console Namespace

This section explains how to verify or create new namespace in the system.

Note:

This is a mandatory procedure. Run this before proceeding further with the installation. The namespace created or verified in this procedure is an input for the next procedures.

To verify and create a namespace:

Note:

To install CNC Console in NF specific namespace, replace cncc namespace with custom namespace.
  1. Run the following command to verify if the required namespace already exists in system:
    kubectl get namespaces
  2. If the namespace exists, continue with the next steps of installation. If the required namespace is not available, create a namespace using the following command:
    kubectl create namespace <required namespace>
  3. For example:
    kubectl create namespace cncc

Sample output: namespace/cncc created

Naming Convention for Namespaces

The namespace should:

  • start and end with an alphanumeric character.
  • contain 63 characters or less.
  • contain only alphanumeric characters or '-'.

Note:

It is recommended to avoid using the prefix kube- when creating namespace. The prefix is reserved for Kubernetes system namespaces.

Note:

For the information about extra privileges required to enable debug tools, see the steps mentioned in the CNC Console Debug Tools section in the Oracle Communications, Cloud Native Configuration Console Troubleshooting Guide.
2.2.1.5 Creating Service Account, Role, and Rolebinding
2.2.1.5.1 Global Service Account Configuration

This section is optional and it describes how to manually create a service account, role, and rolebinding.

Note:

The secrets should exist in the same namespace where CNC Console is getting deployed. This helps bind the Kubernetes role with the given service account.
  1. Run the following command to create an CNC Console resource file:
    vi <occncc-resource-file>

    For example:vi occncc-resource-template.yaml.

  2. Update the occncc-resource-template.yaml file with release specific information.

    Note:

    Update <helm-release> and <namespace> with its respective CNC Console namespace and CNC Console Helm release name.

    A sample CNC Console service account yaml file is as follows:

    ## Service account yaml file for cncc-sa
apiVersion: v1
kind: ServiceAccount
metadata:
  name: cncc-sa
  namespace: cncc
  annotations: {}
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: cncc-role
  namespace: cncc
rules:
- apiGroups:
  - "" # "" indicates the core API group
  resources:
  - services
  - configmaps
  - pods
  - secrets
  - endpoints
  - persistentvolumeclaims
  verbs:
  - get
  - watch
  - list
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: cncc-rolebinding
  namespace: cncc
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: cncc-role
subjects:
- kind: ServiceAccount
  name: cncc-sa
  namespace: cncc
  3. Run the following command to create service account, role, and role binding:
    kubectl -n <occncc-namespace> create -f occncc-resource-template.yaml
  4. Update the serviceAccountName parameter in the occncc_custom_values_<version>.yaml file with the value updated in the name field for ingress-gateway and keycloak.

    For Ingress Gateway and keycloak, provide custom service account under global.serviceAccountName. as follows: 

    global:
 
  serviceAccountName: &serviceAccountName cncc-sa
 
cncc-iam:
  kc:
    keycloak:
      serviceAccount:
        # The name of the service account to use.
        name: *serviceAccountName
2.2.1.5.2 Helm Test Service Account Configuration

This section is optional and it describes how to manually create a service account, role, and rolebinding for helm test.

Custom service account can be provided for helm test in global.helmTestServiceAccountName: 

global:
 
  # ********    Sub-Section Start: Common Global Parameters        ********
  # ***********************************************************************
 
  helmTestServiceAccountName: cncc-helmtest-serviceaccount
  1. Run the following command to create an CNC Console resource file:
    vi <occncc-resource-file>

    For example:vi occncc-resource-template.yaml.

  2. Update the occncc-resource-template.yaml file with release specific information.

    Note:

    Update <helm-release> and <namespace> with its respective CNC Console namespace and CNC Console Helm release name.

    A sample CNC Console service account yaml file is as follows:

    Sample helm test service account : cncc-helmtest-serviceaccount.yaml
    
apiVersion: v1
kind: ServiceAccount
metadata:
  name: cncc-helmtest-serviceaccount
  namespace: cncc
  annotations: {}
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: cncc-helmtest-role
  namespace: cncc
rules:
- apiGroups:
  - "" # "" indicates the core API group
  resources:
  - services
  - configmaps
  - pods
  - secrets
  - endpoints
  - persistentvolumeclaims
  - serviceaccounts
  verbs:
  - get
  - watch
  - list
- apiGroups:
  - policy
  resources:
  - poddisruptionbudgets
  verbs:
  - get
  - watch
  - list
  - update
- apiGroups:
  - apps
  resources:
  - deployments
  - statefulsets
  verbs:
  - get
  - watch
  - list
  - update
- apiGroups:
  - autoscaling
  resources:
  - horizontalpodautoscalers
  verbs:
  - get
  - watch
  - list
  - update
- apiGroups:
  - rbac.authorization.k8s.io
  resources:
  - roles
  - rolebindings
  verbs:
  - get
  - watch
  - list
  - update
- apiGroups:
  - monitoring.coreos.com
  resources:
  - prometheusrules
  verbs:
  - get
  - watch
  - list
  - update
 
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: cncc-helmtest-rolebinding
  namespace: cncc
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: cncc-helmtest-role
subjects:
- kind: ServiceAccount
  name: cncc-helmtest-serviceaccount
  namespace: cncc
  3. Run the following command to create service account, role, and role binding:
    kubectl -n <occncc-namespace> create -f occncc-resource-template.yaml
  4. Update the global.helmTestServiceAccountName parameter in the occncc_custom_values_<version>.yaml file with the value updated in the name field for ingress-gateway and keycloak.

Note:

If user doesn't want to create the separate service account for helm test, then logging of resources and complaint check could also be done using global service account. For that, required resources should be added to the global service account. For more details on helmTestserviceAccount, see Helm Test section.
2.2.1.6 Configuring Database

This section explains how database administrators can create users and database in a single and multisite deployment.

Note:

  • Before running the procedure for georedundant sites, ensure that the DBTier for georedundant sites is up and replication channels are enabled.
  • While performing a fresh installation, if CNCC release is already deployed, purge the deployment, and remove the database and users that were used for the previous deployment. For uninstallation procedure, see Uninstalling CNC Console.
  • If cnDBTier 23.3.0 is used during installation, set the ndb_allow_copying_alter_table parameter to 'ON' in the occncc_dbtier_23.3.0_custom_values_23.3.0.yaml file before installing CNC Console. After CNC Console installation, the parameter value can be set to its default value 'OFF'.

Caution:

Verify the value of the following parameters, before deploying CNC Console in a three site georedundency setup:

ndb:

MaxNoOfOrderedIndexes: 1024

MaxNoOfTables: 1024

NoOfFragmentLogFiles: 512

Naming Convention for CNCC Database

As the CNCC instances cannot share the same database, user must provide a unique name to the CNCC DB in the cnDBTier either limited to a site or spanning across sites.

The recommended format for database name is as follows: 
<database-name>_<site-name>_<cluster>
Example:
 cnccdb_site1_cluster1
The name of the database should:
  • starts and ends with an alphanumeric character
  • contains a maximum of 63 characters
  • contains only alphanumeric characters or '-'

2.2.1.6.1 Configuring the Database User

This section explains how to create or verify the existing cncc user.

  1. Log in to the server or machine which has permission to access the SQL nodes of the NDB cluster.
  2. Connect to the SQL node of the NDB cluster or connect to the cnDbTier.

    Run the following command to connect to cnDbTier:

    
$ kubectl -n <cndbtier_namespace> exec -it <cndbtier_sql_pod_name> -c <cndbtier_sql_container_name> -- bash
    Example:
    $ kubectl -n cndbtier  exec -it ndbappmysqld-0 -c mysqlndbcluster -- bash
  3. Log in to the MySQL prompt using root permission or user, which has permission to create users with permissions.
    mysql -h 127.0.0.1 -u root -p

    Note:

    Provide MySQL password, when prompted.
  4. Check if CNC Console user already exists by running the following command:
    $ SELECT User FROM mysql.user;
  5. If the user does not exist, create a cncc-user by running the following command:
    $ CREATE USER IF NOT EXISTS '<CNCC User Name>'@'%' IDENTIFIED BY '<CNCC Password>';
    Example:
    $ CREATE USER IF NOT EXISTS 'cnccusr'@'%' IDENTIFIED BY 'cnccpasswd'
  6. Run the following command to grant NDB_STORED_USER permission to the cncc-user:
    $ GRANT NDB_STORED_USER ON *.* TO '<username>'@'%' WITH GRANT OPTION;
    Example:
    $ GRANT NDB_STORED_USER ON *.* TO 'cnccusr'@'%' WITH GRANT OPTION;
2.2.1.6.2 Configuring M-CNCC IAM Database

Note:

Not applicable for OCI deployment.

This section explains how to create M-CNCC IAM database and grant permissions to the CNC Console IAM database user for relevant operations on the database.

Note:

As the CNC Console instances cannot share the same database, user must provide a unique name to the CNC Console database in the DBTier either limited to a site or spanning across sites.

The recommended format for database name is as follows:

<database-name>_<site-name>_<cluster>

Sample database name: cnccdb_site1_cluster1

While choosing the name of the database, make sure the following requirements are met:
  • It starts and ends with an alphanumeric character.
  • It contains 63 characters or less.
  • It contains only alphanumeric characters or '-'.
In this guide, the commands use "cnccdb" as sample database name. If a custom database name is used, user must use it in place of cnccdb.
  1. Log in to the server or machine with permission to access the SQL nodes of NDB cluster.
  2. Run the following command to connect to the SQL node of the NDB cluster or connect to the cnDbTier
    
$ kubectl -n <cndbtier_namespace> exec -it <cndbtier_sql_pod_name> -c <cndbtier_sql_container_name> -- bash
    For example:
    $ kubectl -n cndbtier  exec -it ndbappmysqld-0 -c mysqlndbcluster -- bash
  3. Run the following command to log in to the MySQL prompt as a user with root permissions, which has permission to create users with permissions: 
    mysql -h 127.0.0.1 -u root -p

    Note:

    After writing the command, user will be prompted to enter the mysql password. Provide MySql password.
  4. Run the following command to check if cnccdb already exists:
    show databases;
  5. Run the following command to drop the existing cnccdb database:
    DROP DATABASE <CNCC IAM Database>
  6. Run the following command to create the cnccdb:
    $ CREATE DATABASE IF NOT EXISTS <CNCC IAM Database>;
    For example:
    $ CREATE DATABASE IF NOT EXISTS cnccdb;
  7. Run the following command to grant permission to cncc-user:
    $ GRANT SELECT, INSERT, CREATE, ALTER, DROP, LOCK TABLES, REFERENCES, INDEX, CREATE TEMPORARY TABLES, DELETE, UPDATE, EXECUTE ON <M-CNCC IAM Database>.* TO'<CNCC IAM DB User Name>'@'%';
    For example: 
    
$ GRANT SELECT, INSERT, CREATE, ALTER, DROP, LOCK TABLES, REFERENCES, INDEX, CREATE TEMPORARY TABLES, DELETE, UPDATE, EXECUTE ON cnccdb .* TO'cnccusr'@'%';
2.2.1.6.3 Configuring M-CNCC Core Database

This section explains how to create M-CNCC Core database (mcncccommonconfig) and grant permissions to the M-CNCC Core database user for relevant operations on the mcncccommonconfig Database.

Note:

In this installation guide, the commands use "mcncccommonconfig" as sample db name. The sample db name "mcncccommonconfig" must be replaced to the name chosen as per naming conventions defined by this note.
  1. Log in to the server or machine which has permission to access the SQL nodes of the NDB cluster.
  2. Connect to the SQL node of the NDB cluster or connect to the cnDBTier.

    Run the following command to connect to the cnDBTier:

    
$ kubectl -n <cndbtier_namespace> exec -it <cndbtier_sql_pod_name> -c <cndbtier_sql_container_name> -- bash
    Example:
    $  kubectl -n occne-cndbtier  exec -it ndbappmysqld-0 -c mysqlndbcluster -- bash
  3. Log in to the MySQL prompt using root permission or as a user with permission to create new users (with permissions). 
    $ mysql -h 127.0.0.1 -u root -p

    Note:

    After running the command mentioned above, user must enter MySQL password.
  4. Run the following command to check if Database mcncccommonconfig exists: 
    $ show databases;
  5. Run the following command to create a mcncccommonconfig, if the mcncccommonconfig does not exist:
    $ CREATE DATABASE IF NOT EXISTS <M-CNCC Common Config Database>;
  6. Run the following command to grant permission to cncc-user: 

    $ GRANT SELECT, INSERT, CREATE, ALTER, DROP, LOCK TABLES, CREATE TEMPORARY TABLES, DELETE, UPDATE, 
EXECUTE ON <M-CNCC Core Common Config Database>.* TO'<CNCC User Name>'@'%';
Example to demonstrate mcncccommonconfig creation, and granting permissions to cncc user: 

# Command to check if database exists:
$ show databases;
# Database creation for CNCC mcncccommonconfig if do not exists
$ CREATE DATABASE IF NOT EXISTS mcncccommonconfig;
# Granting permission to user:
$ GRANT SELECT, INSERT, CREATE, ALTER, DROP, LOCK TABLES, CREATE TEMPORARY TABLES, DELETE, UPDATE, EXECUTE ON mcncccommonconfig .* TO'cnccusr'@'%';
2.2.1.7 Configuring Kubernetes Secret

This section explains how to configure Kubernetes secrets for accessing the database and the M-CNCC IAM default user.

2.2.1.7.1 Configuring Kubernetes Secret for Accessing Database

This section explains how to configure Kubernetes secrets for accessing the database.

  1. Run the following command to create the kubernetes secret:
    
kubectl create secret generic <database secret name> --from-literal=dbUserNameKey=<CNCC MySQL database username> --from-literal=dbPasswordKey='<CNCC MySQL database passsword>' -n <Namespace of MySQL secret>

    Note:

    You must use a strong non-predictable password consisting of complex strings of more than 10 mixed characters.
  2. Verify the secret created using following command:
    kubectl describe secret <database secret name> -n <Namespace of MYSQL secret>
    Example:
    
$ kubectl create secret generic cncc-db-secret --from-literal=dbUserNameKey=cnccusr --from-literal=dbPasswordKey='<db password>' -n cncc
$ kubectl describe secret cncc-db-secret -n cncc
2.2.1.7.2 Configuring Secret for the Admin User in M-CNCC IAM

Note:

Not applicable for OCI Deployment.

To create and update Kubernetes secret for default (admin) user:

  1. Run the following command to create the Kubernetes secret for admin user: 

    $ kubectl create secret generic <secret-name> --from-literal=iamAdminPasswordKey='<password>'--namespace <namespace>
    Example:
    
$ kubectl create secret generic cncc-iam-secret --from-literal=iamAdminPasswordKey='password' --namespace cncc

    Note:

    This Command is just for reference. You must use a strong non-predictable password consisting of complex strings of more than 10 mixed characters.
  2. Run the following command to verify the secret creation: 
    $ kubectl describe secret <secret name> -n <namespace>
    Example:
    
$ kubectl describe secret cncc-iam-secret -n cncc

2.2.1.7.3 Configuring OCI IAM Secret

Note:

Applicable only for OCI deployment.

This section describes the procedure to configure OCI IAM Secret with clientId and clientSecret for M-CNCC Core and A-CNCC Core:

  1. Run the following command to create Kubernetes secret for OCI IAM clientId and clientSecret:
    $ kubectl create secret generic <secret-name> --from-literal=clientId='<clientId>' --from-literal=clientSecret='<clientSecret>' --namespace <namespace>
    For example:
    $ kubectl create secret generic oci-iam-secret --from-literal=clientId='269d98xxxxbb5064'--from-literal=clientSecret='6779exxxxx9602' --namespace cncc
  2. Run the following command to verify if the secret is created:
    $ kubectl describe secret <secret name> -n <namespace>
    For example:
    $ kubectl describe secret oci-iam-secret -n cncc

Note:

For getting clientId and clientSecret for OCI IAM, see the How to access ClientId and ClientSecret of OCI IAM section in the Oracle Communications Cloud Native Configuration Console User Guide.
2.2.1.7.4 Configuring OCI IAM Secret With Admin Username and Password

Note:

Perform the following procedure to configure OCI IAM secet with admin username and password:
  1. Run the following command to create the Kubernetes secret for OCI IAM admin username and password. Replace <username> with the admin username and <password> with the admin password:
    $ kubectl create secret generic oci-iam-admin-secret --from-literal=username='<username>' --from-literal=password='<password>' --namespace <namespace>
  2. Run the following command to verify that the secret has been created:
    $ kubectl describe secret oci-iam-admin-secret -n <namespace>
    For example:
    $ kubectl describe secret oci-iam-admin-secret -n cncc
2.2.1.8 Configuring Secrets for Enabling HTTPS

Following files must be present prior to configuring secrets for CNC Console for HTTPs deployment:

  1. The Root Certificate Authority (CA) (caroot.cer) and its associated private Key (caroot.key) are required.

    Note:

    If the Root Certificate Authority (CA) and its associated private Key are not available from your organization, generate a Self-Signed Root CA and its Key.
    1. If the initial algorithm is ES256, an ECDSA Root CA Certificate (ssl_ecdsa_certificate.crt) along with its private key (ssl_ecdsa_private_key.pem) are necessary.
    2. If the initial algorithm is RSA256, an RSA Root CA Certificate (ssl_rsa_certificate.crt) along with its private key (ssl_rsa_private_key.pem) are necessary.
  2. A CA Bundle (cabundle.cer) is needed in case multiple Root CA Certificates are involved.
    -----BEGIN CERTIFICATE-----
MIID4TCC...
...
...jtUl/zQ==
-----END CERTIFICATE-----
--------
-----BEGIN CERTIFICATE-----
MIID4TCC...
...
...jtUl/zQ==
-----END CERTIFICATE-----
--------
-----BEGIN CERTIFICATE-----
MIID4TCC...
...
...jtUl/zQ==
-----END CERTIFICATE-----
  3. Additionally, files containing passwords for the TrustStore (ssl_truststore.txt) and KeyStore (ssl_keystore.txt) are required.

Note:

The creation process for private keys, CA Root Certificates, CA Bundle and passwords is left to the discretion of the user or operator. The CNC Console does not document these procedures.
2.2.1.8.1 Configuring Secret to Enable HTTPS in M-CNCC IAM

Note:

Not applicable for OCI deployment.

This section describes how create and configure secrets to enable HTTPS. This section must be executed before configuring secret to enable HTTPS CNC Console Core Ingress Gateway.

Following files must be present prior to configure secrets for M-CNCC IAM for HTTPs deployment.

  1. If the initial algorithm is ES256, an ECDSA Intermediate Certificate (ssl_ecdsa_certificate.crt) along with its private key (ssl_ecdsa_private_key.pem) signed by Root CA.
  2. If the initial algorithm is RSA256, an RSA Root CA Certificate (ssl_rsa_certificate.crt) along with its private key (ssl_rsa_private_key.pem) signed by Root CA.
  1. Run the following command to create secret:
    $ kubectl create secret generic <secret-name> --from-file=<ssl_ecdsa_private_key.pem>
      --from-file=<rsa_private_key_pkcs1.pem> --from-file=<ssl_truststore.txt>
      --from-file=<ssl_keystore.txt> --from-file=<caroot.cer> --from-file=<cabundle.cer>
      --from-file=<ssl_rsa_certificate.crt> --from-file=<ssl_ecdsa_certificate.crt> -n <Namespace of CNCC
      IAM Ingress Gateway secret>

    Note:

    Note down the command used during the creation of Kubernetes secret as this command is used for future updates.

    For example:

    $ kubectl create secret generic cncc-iam-ingress-secret
        --from-file=ssl_ecdsa_private_key.pem  --from-file=rsa_private_key_pkcs1.pem
        --from-file=ssl_truststore.txt --from-file=ssl_keystore.txt --from-file=caroot.cer
        --from-file=cabundle.cer --from-file=ssl_rsa_certificate.crt
        --from-file=ssl_ecdsa_certificate.crt -n cncc

    Note:

    The names used in the above command must be as same as the names provided in the custom_values.yaml in CNC Console deployment.
  2. On successfully running the above command, the following message is displayed:

    secret/cncc-iam-ingress-secret created

  3. Run the following command to verify the secret creation: 
    $ kubectl describe secret cncc-iam-ingress-secret -n cncc

Perform the following procedure to update existing secrets to enable HTTPS, if they already exist:

  1. Run the following command to create secret:
    $ kubectl create secret generic <secret-name> --from-file=<ssl_ecdsa_private_key.pem> --from-file=<rsa_private_key_pkcs1.pem> --from-file=<ssl_truststore.txt> --from-file=<ssl_keystore.txt> --from-file=<caroot.cer> --from-file=<ssl_rsa_certificate.crt> --from-file=<ssl_ecdsa_certificate.crt> --dry-run -o yaml -n <Namespace of CNCC IAM Ingress Gateway secret> | kubectl replace -f --n <Namespace of CNCC IAM Ingress Gateway secret>

    For xample:

    $ kubectl create secret generic cncc-iam-ingress-secret --from-file=ssl_ecdsa_private_key.pem --from-file=rsa_private_key_pkcs1.pem --from-file=ssl_truststore.txt --from-file=ssl_keystore.txt --from-file=caroot.cer --from-file=ssl_rsa_certificate.crt --from-file=ssl_ecdsa_certificate.crt --dry-run -o yaml -n cncc | kubectl replace -f --n cncc
  2. On successfully running the above command, the following message is displayed:

    secret/cncc-iam-ingress-secret replaced

Dynamic Reloading of Certificates of M-CNCC IAM

Perform the following procedure for configuring CNC Console IAM to Support Dynamic Reloading of Certificates of M-CNCC IAM:

CNC Console supports Dynamic Reload of Certificates that are used to establish both TLS and mTLS connections.

To enable dynamic reloading of certificates, the following flags must be enabled in the occncc_custom_values_<version>.yaml file. 

cncc-iam:
  global:
    ingressGwCertReloadEnabled: &iamIGwCertReloadEnabled true

Note:

The new certificate must be created with the existing secret and certificate name.
The procedure for dynamic reloading of certificates as follows:
  1. Delete the existing certificates with which existing secure connections were established.
  2. Create the new certificate as per the requirement. The certificate must be created with the same name as the existing certificate.
  3. The Ingress Gateway pods automatically pick up the new certificates and the changes will be reflected in the browser.

Note:

Naming Update of Certificates and Secrets

If the name of the secret or the certificate is changed then the corresponding changes must be made in the occncc_custom_values_<version>.yaml file, and either a reinstall or a helm upgrade must be done.

2.2.1.8.2 Configuring Secret to Enable HTTPS in M-CNCC Core

This section describes how to create secret configuration for enabling HTTPS. This section must be run before enabling HTTPS in CNC Console Core Ingress Gateway.

Note:

For OCI:
  1. Download OCI IAM Root CA Certificates
    1. Obtain the Intermediate Root CA: DigiCert TLS RSA SHA256 2020 CA1 from the specified URL: https://cacerts.digicert.com/DigiCertTLSRSASHA2562020CA1-1.crt.pem.
    2. Acquire the Root CA: DigiCert Global Root CA from the following link: https://cacerts.digicert.com/DigiCertGlobalRootCA.crt.pem.
  2. Create a CA Bundle with OCI IAM Root CA Certificates and CNC Console Root CA Certificates (Organization or Self-Signed).
  3. Create M-CNCC Core secret with the CA Bundle.

Note:

  • For single cluster deployment, both M-CNCC Core and A-CNCC Core can use same configurations as both reside in same cluster namespace.
  • For multicluster deployment, configurations need to be created on both the clusters separately.

Prerequisite

Following files must be present prior to configuring secrets for M-CNCC Core for HTTPs deployment:

  1. If the initial algorithm is ES256, an ECDSA Intermediate Certificate (ssl_ecdsa_certificate.crt) along with its private key (ssl_ecdsa_private_key.pem) signed by Root CA.
  2. If the initial algorithm is RSA256, an RSA Root CA Certificate (ssl_rsa_certificate.crt) along with its private key (ssl_rsa_private_key.pem) signed by Root CA.
  1. Run the following command to create secret:
    $ kubectl create secret generic <secret-name> --from-file=<ssl_ecdsa_private_key.pem> --from-file=<rsa_private_key_pkcs1.pem> --from-file=<ssl_truststore.txt> --from-file=<ssl_keystore.txt> --from-file=<caroot.cer> --from-file=<cabundle.cer>--from-file=<ssl_rsa_certificate.crt> --from-file=<ssl

    Note:

    Note down the command used during the creation of kubernetes secret, this command is used for updates in future.

    For example:

    kubectl create secret generic cncc-core-ingress-secret --from-file=ssl_ecdsa_private_key.pem --from-file=rsa_private_key_pkcs1.pem --from-file=ssl_truststore.txt --from-file=ssl_keystore.txt --from-file=caroot.cer --from-file=ssl_rsa_certificate.crt --from-file=ssl_ecdsa_certificate.crt -n cncc
    On successfully running the above command, the following message will be displayed:

    secret/cncc-core-ingress-secret created

  2. Run the following command to verify the secret creation: 
    $ kubectl describe secret cncc-core-ingress-secret -n cncc

Perform the following procedure to update existing secrets to enable HTTPS:

  1. Run the following command to create secret:
    $ kubectl create secret generic <secret-name> --from-file=<ssl_ecdsa_private_key.pem> --from-file=<rsa_private_key_pkcs1.pem> --from-file=<ssl_truststore.txt> --from-file=<ssl_keystore.txt> --from-file=<caroot.cer> --from-file=<ssl_rsa_certificate.crt> --from-file=<ssl_ecdsa_certificate.crt> --dry-run -o yaml -n <Namespace of M-CNCC Core Ingress Gateway secret> | kubectl replace -f - -n <Namespace of CNC Console Core Ingress Gateway secret>

    For example:

    $ kubectl create secret generic cncc-core-ingress-secret --from-file=ssl_ecdsa_private_key.pem  --from-file=rsa_private_key_pkcs1.pem --from-file=ssl_truststore.txt --from-file=ssl_keystore.txt --from-file=caroot.cer --from-file=ssl_rsa_certificate.crt --from-file=ssl_ecdsa_certificate.crt --dry-run -o yaml -n cncc | kubectl replace -f - -n cncc
  2. On successfully running the above command, the following message will be displayed:

    secret/cncc-core-ingress-secret replaced

Dynamic Reloading of Certificates of M-CNCC Core

CNC Console supports dynamic reloading of certificates that are used to establish both TLS and mTLS connections. To enable dynamic reloading of certificates, the following flags must be enabled in the occncc_custom_values_<version>.yaml file. 

mcncc-core:
  global:

       ingressGwCertReloadEnabled: & mcoreIGwCertReloadEnabled true

Note:

Here, the new certificate must be created with the existing secret and certificate name.
The procedure for dynamic reloading of certificates is as follows:
  1. Delete the existing certificates with which existing secure connections were established.
  2. Create the new certificate as per the requirement. The certificate must be created with the same name as the existing certificate.
  3. The Ingress Gateway pods automatically pick up the new certificates and the changes are reflected in the browser.

Note:

Naming update of Certificates and Secrets

If the name of the secret or the certificate is changed, then the corresponding changes must be made in the occncc_custom_values_<version>.yaml file, and either a reinstall or a helm upgrade must be done.

2.2.1.8.3 Configuring Secret to Enable HTTPS in A-CNCC Core

This section describes how create and configure secrets to enable HTTPS. This section must be run before configuring secret to enable HTTPS CNC Console Core Ingress Gateway.

Note:

For OCI
  1. Download OCI IAM Root CA Certificates
    1. Obtain the Intermediate Root CA: DigiCert TLS RSA SHA256 2020 CA1 from the specified URL: https://cacerts.digicert.com/DigiCertTLSRSASHA2562020CA1-1.crt.pem.
    2. Acquire the Root CA: DigiCert Global Root CA from the provided link: https://cacerts.digicert.com/DigiCertGlobalRootCA.crt.pem.
  2. Create a CA Bundle with OCI IAM Root CA Certificates and CNC Console Root CA Certificates (Organization or Self-Signed).
  3. Create A-CNCC Core secret with the CA Bundle.

Note:

  • For single cluster deployment, both M-CNCC Core and A-CNCC Core can use same configurations as both reside in same cluster namespace.
  • For multicluster deployment configurations need to be created on both the clusters separately.

Prerequisite

Following files must be present prior to configuring secrets for A-CNCC Core for HTTPs deployment:

  1. If the initial algorithm is ES256, an ECDSA Intermediate Certificate (ssl_ecdsa_certificate.crt) along with its private key (ssl_ecdsa_private_key.pem) signed by Root CA.
  2. If the initial algorithm is RSA256, an RSA Root CA Certificate (ssl_rsa_certificate.crt) along with its private key (ssl_rsa_private_key.pem) signed by Root CA.

Procedure:

  1. Run the following command to create secret:
    $ kubectl create secret generic <secret-name> --from-file=<ssl_ecdsa_private_key.pem>
        --from-file=<rsa_private_key_pkcs1.pem> --from-file=<ssl_truststore.txt>
        --from-file=<ssl_keystore.txt> --from-file=<caroot.cer> --from-file=<cabundle.cer>
        --from-file=<ssl_rsa_certificate.crt> --from-file=<ssl_ecdsa_certificate.crt> -n <Namespace of
        CNCC Core Ingress Gateway secret>

    Note:

    Note down the command used during the creation of Kubernetes secret, this command is used for updating the secrets in future.

    For example:

    The names used below are same as provided in custom values.yaml in CNC Console Core deployment 
    $ kubectl create secret generic cncc-core-ingress-secret
        --from-file=ssl_ecdsa_private_key.pem  --from-file=rsa_private_key_pkcs1.pem
        --from-file=ssl_truststore.txt --from-file=ssl_keystore.txt --from-file=caroot.cer
        --from-file=cabundle.cer --from-file=ssl_rsa_certificate.crt
        --from-file=ssl_ecdsa_certificate.crt -n cncc

    On successfully running the above command, the following message will be displayed:

    secret/cncc-core-ingress-secret created

  2. Run the following command to verify the secret creation:

    $ kubectl describe secret cncc-core-ingress-secret -n cncc

Perform the following procedure to update existing secrets to enable HTTPS:

  • Copy the exact command used in preveious section during creation of secret. Update the same command with string "--dry-run -o yaml" and "kubectl replace -f - -n <Namespace of CNCC Core Ingress Gateway secret>". The command will become:
    $ kubectl create secret generic <secret-name> --from-file=<ssl_ecdsa_private_key.pem>
        --from-file=<rsa_private_key_pkcs1.pem> --from-file=<ssl_truststore.txt>
        --from-file=<ssl_keystore.txt> --from-file=<caroot.cer> --from-file=<cabundle.cer>
        --from-file=<ssl_rsa_certificate.crt> --from-file=<ssl_ecdsa_certificate.crt> --dry-run -o yaml
        -n <Namespace of CNCC Core Ingress Gateway secret> | kubectl replace -f - -n <Namespace of CNCC
        Core Ingress Gateway secret>
    For example:
    $ kubectl create secret generic cncc-core-ingress-secret
        --from-file=ssl_ecdsa_private_key.pem  --from-file=rsa_private_key_pkcs1.pem
        --from-file=ssl_truststore.txt --from-file=ssl_keystore.txt --from-file=caroot.cer
        --from-file=cabundle.cer --from-file=ssl_rsa_certificate.crt
        --from-file=ssl_ecdsa_certificate.crt --dry-run -o yaml -n cncc | kubectl replace -f - -n
        cncc

    The names used here are the same as the ones given in the custom values.yaml in CNC Console Core deployment.

  • The following message appears when you execute the above command:secret/cncc-core-ingress-secret replaced

Dynamic Reloading of Certificates of A-CNCC Core

CNC Console supports dynamic reloading of certificates that are used to establish both TLS and mTLS connections. To enable dynamic reloading of certificates, the following flags must be enabled in the occncc_custom_values_<version>.yaml file. 


acncc-core:
  global:         
     ingressGwCertReloadEnabled: &acoreIGwCertReloadEnabled true

Under this provision, we use the existing secret and the certificate name, but create a completely new certificate for the same name.

The procedure for dynamic reloading of certificates is as follows:
  1. Delete the existing certificates with which existing secure connections were established.
  2. Create the new certificate as per the requirement. The certificate must be created with the same name as the existing certificate.
  3. The Ingress Gateway pods automatically pick up the new certificates and the changes are reflected in the browser.

Note:

Naming update of Certificates and Secrets

If the name of the secret or the certificate is changed, then the corresponding changes must be made in the occncc_custom_values_<version>.yaml file, and either a reinstall or a helm upgrade must be done.

2.2.1.9 Configuring CNC Console to support Aspen Service Mesh

Note:

Not applicable for OCI deployment.
2.2.1.9.1 Introduction

CNC Console leverages the Platform Service Mesh (for example, Aspen Service Mesh (ASM)) for all internal and external TLS communication by deploying a special sidecar proxy in each pod to intercept all the network communications. The service mesh integration provides inter-NF communication, and allows API gateway to cowork with service mesh. The service mesh integration supports the services by deploying a special sidecar proxy in each pods to intercept all the network communications between microservices.

Supported ASM version: 1.14.x

For ASM installation and configuration, see the official Aspen Service Mesh website.

Aspen Service Mesh (ASM) configurations are categorized as follows:

  • Control Plane: It involves adding labels or annotations to inject sidecar. The control plane configurations are part of the NF Helm chart.
  • Data Plane: It helps in traffic management, such as handling NF call flows by adding Service Entries (SE), Destination Rules (DR), Envoy Filters (EF), and other resource changes such as apiVersion change between different versions. This configuration is done manually by considering each NF requirement and ASM deployment.

Data Plane Configuration

Data Plane configuration consists of following Custom Resource Definitions (CRDs):

  • Service Entry (SE)
  • Destination Rule (DR)
  • Envoy Filter (EF)

Note:

Use Helm charts to add or remove CRDs that you may require due to ASM upgrades to configure features across different releases.

The data plane configuration is applicable in the following scenarios:

  • NF to NF Communication: During NF to NF communication, where sidecar is injected on both the NFs, SE and DR must communicate with the corresponding SE and DR of the other NF. Otherwise, the sidecar rejects the communication. All egress communications of NFs must have a configured entry for SE and DR.

    Note:

    Configure the core DNS with the producer NF endpoint to enable the sidecar access for establishing communication between cluster.
  • Kube-api-server: For Kube-api-server, there are a few NFs that require access to the Kubernetes API server. The ASM proxy (mTLS enabled) may block this. As per F5 recommendation, the NF must add SE for the Kubernetes API server for its own namespace.
  • Envoy Filters: Sidecars rewrite the header with its own default value. Therefore, the headers from back end services are lost. So, you need Envoy Filters to help in passing the headers from back-end services to use it as it is.

Note:

For ASM installation and configuration, refer Official Aspen Service Mesh website for details.
2.2.1.9.2 Predeployment Configuration

Following are the prerequisites to install CNCC with support for ASM:

Enabling Auto sidecar Injection for Namespace

This section explains how to enable auto sidecar injection for namespace.

  1. Run the following command to enable auto sidecar injection to automatically add the sidecars in all of the pods spawned in CNCC namespace:
    $ kubectl label ns <cncc-namespace> istio-injection=enabled

    Example:

    $ kubectl label ns cncc istio-injection=enabled

Update Default Kyverno Policy Restriction to add CNC Console Namespace

Note:

You need admin privileges to edit/patch the clusterpolicies that are mentioned in following steps.
From 23.2.0 CNE, we have support for Kyverno policies. The default Kyerno policy restrictions don't allow istio-proxy containers. To allow running of istio-proxy containers on CNC Console with ASM deployment, you must perform the following kubectl operation on the namespace where the CNC Console is installed.
$ kubectl patch clusterpolicy disallow-capabilities --type=json \
  -p='[{"op": "add", "path": "/spec/rules/0/exclude/any/0/resources/namespaces/-", "value": "<cncc_namespace>" }]'
For example,
$ kubectl patch clusterpolicy disallow-capabilities --type=json \
  -p='[{"op": "add", "path": "/spec/rules/0/exclude/any/0/resources/namespaces/-", "value": "cncc" }]'

Establish connectivity to services that are not part of Service Mesh Registry

Note:

This is an optional step. Depending on the underlying Service Mesh deployment, Service Entry and Destination Rule may be required for CNC Console to connect to other kubernetes microservices that are not a part of Service Mesh Registry. The kubernetes microservices may be DB service, NF services, or Common services.
You can use the following sample service entry and destination rule template:
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: <Unique ServiceEntry Name for Service>
  namespace: <CNCC-NAMESPACE>
spec:
  exportTo:
  - "."
  hosts:
  - <Service-public-FQDN>
  ports:
  - number: <Service-public-PORT>
    name: <Service-PORTNAME>
    protocol: <Service-PROTOCOL>
  location: MESH_EXTERNAL
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: <Unique DestinationRule Name for Service>
  namespace: <CNCC-NAMESPACE>
spec:
  exportTo:
  - "."
  host: <Service-public-FQDN>
  trafficPolicy:
    tls:
      mode: DISABLE
If kubernetes services only have IP and does not have public FQDN, then first create the necessary headless service and then create Service Entry and Destination Rule. Here is a sample headless service template.
apiVersion: v1
kind: Endpoints
metadata:
  name: <Unique Endpoint Name for Service>
  namespace: <CNCC_NAMESPACE>
subsets:
- addresses:
  - ip: <Service-public-IP>
  ports:
  - port: <Service-public-PORT>
    protocol: <Service-PROTOCOL>
---
apiVersion: v1
kind: Service
metadata:
  name: <Unique Endpoint Name for Service>-headless
  namespace: <CNCC_NAMESPACE>
spec:
  clusterIP: None
  ports:
  - port: <Service-public-PORT>
    protocol: <Service-PROTOCOL>
    targetPort: <Service-public-PORT>
  sessionAffinity: None
  type: ClusterIP

Set the mTLS Connection from Client Browser to ASM

Prerequisites

Enable certificateCustomFields in ASM values.yaml

Note:

Ensure that ASM is deployed with certificateCustomFields enabled. 

global: 
  certificateCustomFields: true
Using ASM self-signed CA (Default)
  1. ASM creates istio-ca secrets (ca-certs, ca-key) in istio-namespace which contains CA public and private key.
    1. Run the following command to verify if the certificate is created : 

      $ kubectl get secrets -n istio-system -o yaml istio-ca-secret

      Note:

      Export the ca-cert.pem, ca-key.pem from the secret istio-ca-secret to your local machine where browser is installed.
      ca-cert.pem → Istio CA public
      ca-key.pem → CA private key
    2. Run the following commands to get ASM Istio CA certificate with base64 decoded and copy the output to a file in you local machine:
    
kubectl get secret istio-ca-secret -n istio-system -o go-template='{{ index .data "ca-cert.pem" | base64decode}}'
kubectl get secret istio-ca-secret -n istio-system -o go-template='{{ index .data "ca-key.pem" | base64decode}}'
  2. Create client certificate using Openssl commands using ca-cert.pem and ca-key.pem obtained in Step1 and import it to the browser. Refer to your browser specific documentation on how to import certificate and key.
  3. Update the browser configuration to trust the CA certificate (ca-cert.pem) obtained from Step 1. Refer to your browser specific documentation on how to trust the CA certificate.
Existing Organization CA
  1. Create client certificate using Openssl commands using Organization CA public and private key and import it to the browser. Refer to your browser specific documentation on how to import certificate and key.
  2. Update the browser configuration to trust the Organization CA. Refer to your browser specific documentation on how to trust the CA certificate.

Create Service Account, Role and Role bindings with ASM annotations

While creating service account for M-CNCC IAM, M-CNCC Core and A-CNCC Core you need to provide following ASM annotations in the given format:

certificate.aspenmesh.io/customFields:'{"SAN":{"DNS":["<helm-release-name>-ingress-gateway.<cncc_namespace>.svc.<cluster_domain>"]}}'
Sample ASM annotations for M-CNCC-IAM, M-CNCC and A-CNCC

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    certificate.aspenmesh.io/customFields: '{ "SAN": { "DNS": [ "cncc-iam-ingress-gateway.cncc.svc.cluster.local", "cncc-acore-ingress-gateway.cncc.svc.cluster.local", "cncc-mcore-ingress-gateway.cncc.svc.cluster.local"] } }'
Single Cluster Deployment

For Single cluster deployment, where M-CNCC IAM, M-CNCC Core and A-CNCC Core are deployed in same cluster or site can share same service account, role, and rolebinding.

Sample example for M-CNCC IAM, M-CNCC Core and A-CNCC Core| cncc-sa-role-rolebinding.yaml
kubectl apply -n cncc -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: cncc-serviceaccount
  labels:
    app.kubernetes.io/component: internal
  annotations:
    sidecar.istio.io/inject: "false"
    "certificate.aspenmesh.io/customFields": '{ "SAN": { "DNS": [ "cncc-iam-ingress-gateway.cncc.svc.cluster.local", "cncc-acore-ingress-gateway.cncc.svc.cluster.local", "cncc-mcore-ingress-gateway.cncc.svc.cluster.local"] } }'
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: cncc-role
  labels:
    app.kubernetes.io/component: internal
  annotations:
    sidecar.istio.io/inject: "false"
rules:
- apiGroups:
  - "" # "" indicates the core API group
  resources:
  - services
  - configmaps
  - pods
  - secrets
  - endpoints
  - persistentvolumeclaims
  verbs:
  - get
  - watch
  - list
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: cncc-rolebinding
  labels:
    app.kubernetes.io/component: internal
  annotations:
    sidecar.istio.io/inject: "false"
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: cncc-role
subjects:
- kind: ServiceAccount
  name: cncc-serviceaccount
---
EOF
Multi Cluster Deployment

For Multi cluster deployment,

  1. Where M-CNCC IAM, M-CNCC Core and A-CNCC Core are deployed in same site/cluster can share same service account, role and rolebinding.

    See the above single cluster service account example.

    Note:

    In multi cluster deployment A-CNCC Core is an optional component in manager cluster, make sure to take out "cncc-ccore-ingress-gateway.cncc.svc.cluster.local" from "certificate.aspenmesh.io/customFields" in case A-CNCC Core is not deployed in manager cluster
  2. Where M-CNCC IAM and M-CNCC Core which are in same cluster can still share same service account, role and rolebinding and A-CNCC deployed in different cluster, a separate service account, role and rolebinding needs to be created.
    Example for M-CNCC IAM, M-CNCC Core | cncc-sa-role-rolebinding.yaml:
    kubectl apply -n cncc -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: cncc-serviceaccount
  labels:
    app.kubernetes.io/component: internal
  annotations:
    sidecar.istio.io/inject: "false"
    "certificate.aspenmesh.io/customFields": '{ "SAN": { "DNS": [ "cncc-iam-ingress-gateway.cncc.svc.cluster.local", "cncc-mcore-ingress-gateway.cncc.svc.cluster.local"] } }'
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: cncc-role
  labels:
    app.kubernetes.io/component: internal
  annotations:
    sidecar.istio.io/inject: "false"
rules:
- apiGroups:
  - "" # "" indicates the core API group
  resources:
  - services
  - configmaps
  - pods
  - secrets
  - endpoints
  - persistentvolumeclaims
  verbs:
  - get
  - watch
  - list
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: cncc-rolebinding
  labels:
    app.kubernetes.io/component: internal
  annotations:
    sidecar.istio.io/inject: "false"
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: cncc-role
subjects:
- kind: ServiceAccount
  name: cncc-serviceaccount
---
EOF
    Example for A-CNCC Core | cncc-sa-role-rolebinding.yaml
    kubectl apply -n cncc -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: cncc-serviceaccount
  labels:
    app.kubernetes.io/component: internal
  annotations:
    sidecar.istio.io/inject: "false"
    "certificate.aspenmesh.io/customFields": '{ "SAN": { "DNS": [ "cncc-acore-ingress-gateway.cncc.svc.cluster.local"] } }'
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: cncc-role
  labels:
    app.kubernetes.io/component: internal
  annotations:
    sidecar.istio.io/inject: "false"
rules:
- apiGroups:
  - "" # "" indicates the core API group
  resources:
  - services
  - configmaps
  - pods
  - secrets
  - endpoints
  - persistentvolumeclaims
  verbs:
  - get
  - watch
  - list
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: cncc-rolebinding
  labels:
    app.kubernetes.io/component: internal
  annotations:
    sidecar.istio.io/inject: "false"
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: cncc-role
subjects:
- kind: ServiceAccount
  name: cncc-serviceaccount
---
EOF
2.2.1.9.3 M-CNCC IAM, M-CNCC Core and A-CNCC Core configuration for ASM

This section explains about the CNC Console IAM deployment configuration for ASM.

Update occncc_custom_values_<version>.yaml as follows:

  1. Add the following sidecar resource configuration annotations:
    global:
  # ********  Sub-Section Start: Common Global Parameters *************
  # *******************************************************************
 
  customExtension:
    allResources:
      labels: {}
      annotations:
        sidecar.istio.io/proxyMemory: "1Gi"
        sidecar.istio.io/proxyMemoryLimit: "1Gi"
        sidecar.istio.io/proxyCPU: "1"
        sidecar.istio.io/proxyCPULimit: "1"
  
  # ********  Sub-Section End: Common Global Parameters *******************
  # ***********************************************************************
  2. Add rewriteAppHTTPProbers annotation to make health checks on services with mTLS enforcement on work:
    global:
  # ********  Sub-Section Start: Common Global Parameters *************
  # *******************************************************************
 
    nonlbStatefulSets:
      labels: {}
      annotations:
        sidecar.istio.io/rewriteAppHTTPProbers: "true"
  
  # ********  Sub-Section End: Common Global Parameters *******************
  # ***********************************************************************
  3. Provide the service account name:
    
global:
  # *****  Sub-Section Start: Ingress Gateway Global Parameters *****
  serviceAccountName: &serviceAccountName <cncc-serviceaccount-name>
  4. Enable Service Mesh Flag:
    global:
  # Mandatory: This flag needs to set it "true" if Service Mesh would be present where CNC Console will be deployed
  serviceMeshCheck: true
  5. If ASM is deployed with mTLS disabled, then set serviceMeshHttpsEnabled flag to false:
    global:
  serviceMeshHttpsEnabled: false
2.2.1.9.4 M-CNCC IAM, M-CNCC Core, and A-CNCC Core Configuration for OSO

Add Annotation oracle.com/cnc: "true" under global.customExtention.lbDeployments.annotations section in occncc_custom_values_<version>.yaml file to indicate OSO to scrape metrics from ingress pod. 

global:
  # ****  Sub-Section Start: Common Global Parameters *****
  
   
  customExtension:
    lbDeployments:
      labels: {}
      annotations:
        oracle.com/cnc: "true"
 
  # ****  Sub-Section End: Common Global Parameters *******
2.2.1.10 Configuring Network Policies

Note:

Not applicable for OCI deployment.

Kubernetes network policies allow you to define ingress or egress rules based on Kubernetes resources such as Pod, Namespace, IP, and Port. These rules are selected based on Kubernetes labels in the application. These network policies enforce access restrictions for all the applicable data flows except communication from Kubernetes node to pod for invoking container probe.

Note:

Configuring network policies is an optional step. Based on the security requirements, network policies may or may not be configured.

For more information on network policies, see https://kubernetes.io/docs/concepts/services-networking/network-policies/.

Note:

  • If the traffic is blocked or unblocked between the pods even after applying network policies, check if any existing policy is impacting the same pod or set of pods that might alter the overall behavior.
  • If changing default ports of services such as Prometheus, Database, or Jaegar, or if Ingress Gateway names are overridden, update them in the corresponding network policies.

Configuring Network Policies

Following are the various operations that can be performed for network policies:

Installing Network Policies

Prerequisite

Network Policies are implemented by using the network plug-in. To use network policies, you must use a networking solution that supports Network Policy.

Note:

For a fresh installation, it is recommended to install Network Policies before installing CNC Console. However, if CNC Console is already installed, you can still install the Network Policies.
  1. Open the occncc_network_policy_custom_values_<version>.yaml file provided in the release package zip file. For downloading the file, see Downloading CNC Console Package and Pushing the Images to Customer Docker Registry.
  2. The file is provided with the default network policies. If required, update the occncc_network_policy_custom_values_<version>.yaml file. For more information on the parameters, see the Table 2-13 table.
  3. Run the following command to install the network policies:
    helm install <release_name> -f <occncc_network_policy_custom_values_<version>.yaml> --namespace <namespace> <chartpath>./<chart>.tgz

    For example:

    helm install occncc-network-policy -f occncc_network_policy_custom_values_24.3.0.yaml --namespace cncc occncc-network-policy-24.3.0.tgz
    Where,
    • helm-release-name: occncc-network-policy helm release name.
    • custom-value-file: occncc-network-policy custom value file.
    • namespace: CNC Console namespace.
    • network-policy: network-policy package.

Note:

Connections that were created before installing network policy and still persist are not impacted by the new network policy. Only the new connections would be impacted.

Upgrading Network Policies

  1. Modify the occncc_network_policy_custom_values_<version>.yaml file to update, add, or delete the network policy.
  2. Run the following command to upgrade the network policies:
    helm upgrade <release_name> -f occncc_network_policy_custom_values_<version>.yaml --namespace <namespace> <chartpath>./<chart>.tgz

    For example:

    helm upgrade occncc-network-policy -f occncc_network_policy_custom_values_24.3.0.yaml --namespace cncc occncc-network-policy-24.3.0.tgz

Verifying Network Policies

Run the following command to verify that the network policies have been applied successfully:

kubectl get networkpolicy -n <namespace>

For example:

kubectl get networkpolicy -n cncc

Uninstalling Network Policies

Run the following command to uninstall the network policies:

$ helm uninstall <release_name> --namespace <namespace>

For example:

$ helm uninstall occncc-network-policy --namespace cncc

Note:

Uninstalling removes all the network policies.

Configuration Parameters for Network Policies

Table 2-13 Configuration Parameters for Network Policies

Parameter Description Details
apiVersion This is a mandatory parameter.

This indicates the Kubernetes version for access control.

Note:This is the supported api version for network policy. This is a read-only parameter.

Data Type: String

Default Value: networking.k8s.io/v1
kind This is a mandatory parameter.

This represents the REST resource this object represents.Note:This is a read-only parameter. 		Data Type: String

Default Value: NetworkPolicy

Supported parameters for Configuring Network Policies

Table 2-14 Supported parameters for Configuring Network Policies

Parameter Description Details
metadata.name This is a mandatory parameter.

Specifies a unique name for the network policy. 		{{ .metadata.name }}
spec.{}

This is a mandatory parameter.

This consists of all the information needed to define a particular network policy in the given namespace.

 NA

For more information about this functionality, see Network Policies in the Oracle Communications Cloud Native Configuration Console User Guide.

2.2.1.11 Global Configurations

CNC Console Deployment Configurations

This section explains about the CNC Console global configurations which are common for M-CNCC and A-CNCC deployment.

Table 2-15 Non OCI

Deployment isMultiClusterDeployment enabled oci-iam enabled cncc-iam enabled mcncc-core enabled acncc-core enabled
Single Cluster false false true true true
Multi Cluster(manager only) true false true true false
Multi Cluster(managing local NF’s) true false true true true
Multi cluster(agent only) true false false false true
Example: Configuration in occncc_custom_values_<version>.yaml file.

In case of single cluster deployment (global.isMultiClusterDeployment: false) the user must configure cncc-iam, mcncc-core and acncc-core flag to true and oci-iam flag to false. 

global:
  
  isMultiClusterDeployment: false
  
  oci-iam:
    enabled: false
  cncc-iam:
    enabled: true
  mcncc-core:
    enabled: true
  acncc-core:
    enabled: true

OCI

Note:

For OCI deployment, only Single cluster is supported.

Table 2-16 OCI

Deployment isMultiClusterDeployment enabled oci-iam enabled cncc-iam enabled mcncc-core enabled acncc-core enabled
Single Cluster false true false true true

Example: Configuration in occncc_custom_values_<version>.yaml

In case of single cluster deployment(global.isMultiClusterDeployment: false) the user must configure oci-iam, mcncc-core and acncc-core flag to true and cncc-iam flag to false. 

global:
  
  isMultiClusterDeployment: false

  oci-iam:
    enabled: true   
  cncc-iam:
    enabled: false
  mcncc-core:
    enabled: true
  acncc-core:
    enabled: true
2.2.1.11.1 M-CNCC IAM Predeployment Configuration

The following are the predeployment configuration procedures of M-CNCC IAM:

Note:

Not applicable for OCI deploymemnt.
2.2.1.11.1.1 Configuring LDAPS in M-CNCC IAM

This section explains the procedure to enable LDAPS in M-CNCC IAM.

When you configure a secured connection URL to your LDAP store (Example: `ldaps://myhost.com:636'), CNC Console IAM uses SSL for communication with the LDAP server. The truststore must be properly configured on the CNC Console IAM server side; otherwise CNC Console IAM cannot trust the SSL connection to LDAP.

For enabling LDAPS update kc section of occncc_custom_values_<version>.yaml as below: 

cncc-iam
  kc:
    ldaps:
      enabled: true

M-CNCC IAM Secret configuration for enabling LDAPS

Note:

The passwords for TrustStore and KeyStore are stored in respective password files.

To create Kubernetes secret for LDAPS, following files are required:

  • TrustStore password file
  • CA certificate or CA Bundle

Creating CA Bundle

When combining multiple CA certificates into a single certificate, add a delimiter after each certificate.

Delimiter: "--------"

Sample CA Bundle 

-----BEGIN CERTIFICATE-----
MIID4TCC...
...
...jtUl/zQ==
-----END CERTIFICATE-----
--------
-----BEGIN CERTIFICATE-----
MIID4TCC...
...
...jtUl/zQ==
-----END CERTIFICATE-----

Note:

Creation process for private keys, certificates and passwords is on discretion of user.

Perform the following procedure to create the secrets to enable LDAPS after required certificates and password files are generated and update details in kc section:

Note:

The value of ssl_truststore.txt and ssl_truststore-password-key value must be same.
  1. Run the following command to create secret: 
    kubectl create secret generic <secret-name> --from-file=<caroot.cer> --from-file=ssl_truststore.txt --from-literal=ssl_truststore-password-key=<password> --namespace cncc

    Note:

    Note down the command used during the creation of Kubernetes secret as this command is used for future updates.

    For example:

    $ kubectl create secret generic cncc-iam-kc-root-ca --from-file=caroot.cer --from-file=ssl_truststore.txt --from-literal=ssl_truststore-password-key=<password> --namespace cncc
    Run the following to display the sample ssl_truststore.txt:
    echo <password> > ssl_truststore.txt
  2. On successfully running the above command, the following message is displayed:

    secret/cncc-iam-kc-root-ca created

  3. Run the following command to verify the secret creation: 
    $ kubectl describe secret cncc-iam-kc-root-ca -n cncc

M-CNCC IAM Service Account configuration for enabling LDAPS

This section describes the customizations that you should make in custom-value.yaml file to configure Kubernetes service account. M-CNCC IAM provides option to configure custom service account.

Note:

Skip this section if service account is already configured as part of HTTPS or ASM configuration.

Configure service account for ingress-gateway and keycloak in custom-cncc_values_<version>.yaml as follows:

  1. For ingress-gateway provide custom service account under global.serviceAccountName.
    global:
 
  serviceAccountName: &serviceAccountName cncc-sa
 
cncc-iam:
  kc:
    keycloak:
      serviceAccount:
        # The name of the service account to use.
        name: *serviceAccountName

For CNC Console IAM LDAP related configurations, see Integrating CNC Console LDAP Server with CNC Console IAM section in Oracle Communications Cloud Native Core Console User Guide.

Sample Service account section in custom-cncc_values_<version>.yaml:

## Service account yaml file for cncc-sa
apiVersion: v1
kind: ServiceAccount
metadata:
  name: cncc-sa
  namespace: cncc
  annotations: {}
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: cncc-role
  namespace: cncc
rules:
- apiGroups:
  - "" # "" indicates the core API group
  resources:
  - services
  - configmaps
  - pods
  - secrets
  - endpoints
  - persistentvolumeclaims
  verbs:
  - get
  - watch
  - list
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: cncc-rolebinding
  namespace: cncc
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: cncc-role
subjects:
- kind: ServiceAccount
  name: cncc-sa
  namespace: cncc

M-CNCC IAM LOG LEVEL Configuration

By default the log level of keycloak is set to WARN. To set the log level set the enable flag under log to true

In the level label, set the log level. Follow the below instruction about the options available to set log level
  • Log level
    • TRACE.
    • DEBUG.
    • INFO.
    • WARN.
    • ERROR.
    • FATAL.
  • level: INFO

    INFO, WARN, ERROR, FATAL will be covered for logs of all packages in KC

  • level: INFO, DEBUG

    In this case it will take the last one as log level, here DEBUG

  • level: INFO, package-group: WARN

    What does this mean?

    INFO level logs for all, but log level will be WARN only for that particular package. For example:
    level: INFO,org.keycloak:WARN,org.infinispan:WARN,org.jgroups:TRACE

    level: OFF

    No logs will appear

    level: ALL

    logs of all the level will appear in the logs

  • Sample KC log configuration: 
    kc:    
  preferIpv6Stack:      
    enabled: false
  log:      
    enabled: true      
    level: DEBUG
2.2.1.11.2 A-CNCC Core Predeployment Configuration

Following are the predeployment configuration procedures:

2.2.1.11.2.1 Configuring A-CNCC Core mTLS

This section describes the A-CNCC Core Configuration for enabling mTLS.

Note:

Not supported for OCI deployment.

mTLS Configuration at A-CNCC Core

mTLS must be enabled at the ingress-gateway SSL configuration section of the A-CNCC Core occncc_custom_values_<version>.yaml file. The parameter scheme must be set to https in the occncc_custom_values_<version>.yaml file.

Sample TLS Configuration section of A-CNCC Core:

acncc-core:
  global
    # CNCC https enabled
    httpsEnabled: &httpsEnabled true
    # Server Configuration for http and https support
    enableIncomingHttp: &enableIncomingHttp false
    enableIncomingHttps: &enableIncomingHttps true
    # Enables server with MTLS
    needClientAuth: &needClientAuth true

Note:

While enabling mTLS, needClientAuth flag must be set to true.

2.2.1.12 Configuring Cloud Native Load Balancer (CNLB) IPs

Note:

Applicable on CNLB enabled CNE only. For more information, see Oracle Communications Cloud Native Core, Cloud Native Environment User Guide.
Add the following annotation in the occncc_custom_values_<version>.yaml file to configure CNLB IP for M-CNCC IAM, M-CNCC Core, and A-CNCC Core:
 annotations:
   k8s.v1.cni.cncf.io/networks: ""
   oracle.com.cnc/cnlb:' [{"backendPortName": "", "cnlbIp": "", "cnlbPort": ""}]'
Here,
  • k8s.v1.cni.cncf.io/networks contains all the network attachment information the pod uses for network segregation.
  • oracle.com.cnc/cnlb : To define service IP and port configurations that the deployment will use for ingress load balancing.
    Where,
    • cnlbIp is the front-end IP utilized by the application.
    • cnlbPort is the front-end port used in conjunction with the cnlbIp for load balancing.
    • backendPortName is the backend port name of the container that needs load balancing, retrievable from the deployment or pod spec of the application.
2.2.1.12.1 Configuring CNLB IP for M-CNCC IAM
Below is the sample configuration for adding annotation to configure CNLB IP for M-CNCC IAM: 
cncc-iam:
  ingress-gateway:
    deployment:
      customExtension:
        annotations:
          k8s.v1.cni.cncf.io/networks: ""
          oracle.com.cnc/cnlb: '[{"backendPortName": "cncc-iam-port", "cnlbIp": "","cnlbPort": ""}]'

Note:

The cnlbIP must be same as the IP configured in the instance configuration.
2.2.1.12.2 Configuring CNLB IP for M-CNCC Core
Below is the sample configuration for adding annotation to configure CNLB IP for M-CNCC Core: 
mcncc-core::
  ingress-gateway:
    deployment:
      customExtension:
        annotations:
          k8s.v1.cni.cncf.io/networks: ""
          oracle.com.cnc/cnlb: '[{"backendPortName": "cncc-core-port", "cnlbIp": "","cnlbPort": ""}]'
2.2.1.12.3 Configuring CNLB IP for A-CNCC Core

Note:

The following annotation is:
  • Applicable for multicluster deployment.
  • Applicable for Agent-only deployment.
  • Not applicable for single cluster deployment.
Below is the sample configuration for adding annotation to configure CNLB IP for A-CNCC Core
acncc-core::
  ingress-gateway:
    deployment:
      customExtension:
        annotations:
          k8s.v1.cni.cncf.io/networks: ""
          oracle.com.cnc/cnlb: '[{"backendPortName": "cncc-acore-port", "cnlbIp": "","cnlbPort": ""}]'
2.2.1.12.4 Configuring Annotation for Egress Traffic for M-CNCC IAM

Use the following annotation to segregate the egress traffic for M-CNCC IAM:

cncc-iam:
  kc:
    keycloak:
      # Pod Annotation for cncc-iam-kc
      podAnnotations:
        k8s.v1.cni.cncf.io/networks: ""

k8s.v1.cni.cncf.io/networks contains all the network attachment information the pod uses for network segregation.

Sample configuration for M-CNCC IAM Annotation for Egress traffic:


cncc-iam:
  kc:
    keycloak:
      # Pod Annotation for cncc-iam-kc 
      podAnnotations: 
        k8s.v1.cni.cncf.io/networks: default/nf-oam-egr1@nf-oam-egr1
2.2.1.12.5 Configuring M-CNCC IAM to Enable Additional Setting

CNC Console provides an option to enable additional settings in M-CNCC IAM by setting below mentioned flag to true in the occncc_custom_values_<version>.yaml file

The additional settings include some of the configuration settings such as authentication settings to configure password policies.

cncc-iam:
  global: 
    iamSettingEnabled: false

2.2.2 Installation Tasks

This section explains how to install CNC Console.

Note:

  • Before installing CNC Console, you must complete the Prerequisites and Preinstallation Tasks.
  • In a georedundant deployment, perform the steps explained in this section on all georedundant sites.

This section describes the prerequisites and installation procedure for the CNC Console.

CNC Console helm chart is a common helm chart to be used for deploying Manager CNC Console IAM (M-CNCC IAM), Manager CNC Console Core (M-CNCC Core), and Agent CNCC Core (A-CNCC Core).

The scripts directory present in the occncc_csar_<marketing-release-number>.zip consists of occncc_custom_values_<version>.yaml file and can be used for deployment of M-CNCC IAM, M-CNCC Core and A-CNCC Core.

This section covers installation instructions for M-CNCC IAM, M-CNCC Core and A-CNCC Core deployment.

Note:

  • For a single cluster deployment, both Manager (M-CNCC) and Agent (A-CNCC) must deployed on the same cluster.
  • For a multicluster deployment,
    • If the manager cluster has a local NF deployment, both M-CNCC and A-CNCC should be deployed on the same cluster
    • If the manager cluster does not have a local NF deployment, only M-CNCC should be deployed. A-CNCC should be deployed on a cluster where NFs are present
  • The Manager manages CNE or OSO common service if present in a cluster.
    • Manager in a cluster is preferred over Agent in the same cluster to manage the CNE common services.
    • Agent in a cluster can manage CNE common service in absence of a Manager in the same cluster.
  • Agent is needed only when NFs are present on the cluster.
2.2.2.1 Installing CNC Console Package

This section provides the installation procedure to install CNC Console using Command Line Interface (CLI).

Perform the following procedure to deploy CNC Console:
  1. Run the following command to check the version of the helm chart installation: 
    helm search repo <release_name> -l
    For example:
     helm search repo cncc -l
    NAME             CHART VERSION  APP VERSION  DESCRIPTION
ocspf-helm-repo/cncc      24.3.0         24.3.0     A Helm chart for CNC Console
  2. Customize the occncc_custom_values_<version>.yaml file with the required deployment parameters. For customizing custom-cncc_values.yaml file, see .

    Note:

    Support for Dual Stack Networking
    • CNC Console Deployment Mode Configuration
       global:
   # Possible values : IPv4, IPv6, IPv4_IPv6,IPv6_IPv4,ClusterPreferred
   cnccDeploymentMode: &cnccDeploymentMode ClusterPreferred

Default value is "ClusterPreferred"

      You can also overwrite the value of cnccDeploymentMode parameter at each CNC Concole services level.

      For more information, see Support for Dual Stack Networking in the Oracle Communications Cloud Native Configuration Console User Guide.

    • Static IP Address Assignment in case of SingleStack (IPv4 or IPv6)

      There are two ways to assign Static IP address for services in case of SingleStack.

      1. By setting staticIpAddressEnabled to true and by configuring staticIpAddress variable with IPv4 or IPv6 IPs as per the configured cnccDeploymentMode parameter.
        Example: Preferring IPv6 
        cncc-iam:
  global:
    staticIpAddressEnabled: true
    staticIpAddress: 2606:bxx:xxx:bxxx::x
      2. By adding annotation metallb.universe.tf/loadBalancerIPs at each component ingress-gateway section to allocate static IP as per the cnccDeploymentMode configured.
        Example: Preferring IPv6 
        cncc-iam:
  ingress-gateway:
    service:
      # Labels and Annotations that are specific to service ingressgateway are added here.
      customExtension:
        labels: {}
        annotations: 
          metallb.universe.tf/loadBalancerIPs: 2606:bxx:xxx:bxxx::x
    • Static IP address assignment in case of RequireDualStack (IPv4_IPv6 or IPv6_IPv4).

      "staticIpAddressEnabled" should be set to false, since "staticIpAddress" variable supports only single IP configuration.

      In case of RequireDualStack, annotation metallb.universe.tf/loadBalancerIPs is required at each component ingress-gateway section to allocate static IPs as per the configured cnccDeploymentMode.

      Example: Preferring IPv6_IPv4
      cncc-iam:
  ingress-gateway:
    service:
      # Labels and Annotations that are specific to service ingressgateway are added here.
      customExtension:
        labels: {}
        annotations: 
          metallb.universe.tf/loadBalancerIPs: 10.xx.xx.xx,2606:xxxx:605:xxxx::a

    Note:

    Assigning LoadBalancer IPs in CNE:

    The annotation metallb.universe.tf/address-pool: signaling/oam is required in global section if MetalLB in CNE 1.8.x onwards is used.
    
customExtension:
  lbServices:
    labels: {}
    annotations:
     # The annotation metallb.universe.tf/address-pool: signaling/oam is required if MetalLB in CNE 1.8.x is used
      metallb.universe.tf/address-pool: oam
      service.beta.kubernetes.io/oci-load-balancer-internal: "true"

    Note:

    For HTTPs deployment in CNE:

    The annotation oracle.com.cnc/app-protocols: '{"http-tls":"TCP"}' is required in the global section of occncc_custom_values_<version>.yaml file when CNC Console is deployed with HTTPs enabled in CNE.
    
customExtension:
  lbServices:
    labels: {}
    annotations:
      oracle.com.cnc/app-protocols: '{"http-tls":"TCP"}'

    Note:

    For LDAP/LDAPS deployment:

    The annotation oracle.com.cnc/egress-network: oam is required under the global section if Ldap or Ldaps is integrated with console.
    nonlbStatefulSets:
  labels: {}
    annotations: 
      oracle.com.cnc/egress-network: oam

    Note:

    For MultiCluster deployment:

    The annotation oracle.com.cnc/egress-network: oam is required under the global section if isMultiClusterDeployment flag is enabled for CNC Console.
    customExtension:
    lbDeployments:
      labels: {}
      annotations:
        oracle.com.cnc/egress-network: oam
    CNC Console IAM deployment has the following Pod Security context and Container Security context:

    Pod Security context: PSC: map[fsGroup:1000]

    Container Security context: runAsUser:1000 runAsNonRoot:true

    Note:

    For OCI:
    • The following annotations musr be used to assign Network Load Balancer IP to the CNC Console Services in OCI environment. <subnet-OCID> is the OCID of the public subnet (nf_lb_subnet).
      customExtension:
  lbServices:
    labels: {}
    annotations:
      oci.oraclecloud.com/load-balancer-type: "nlb"
      oci-network-load-balancer.oraclecloud.com/subnet: "<subnet-OCID>"
      oci-network-load-balancer.oraclecloud.com/security-list-management-mode: All
      For example:
      
customExtension:
  lbServices:
    labels: {}
    annotations:
      oci.oraclecloud.com/load-balancer-type: "nlb"
      oci-network-load-balancer.oraclecloud.com/subnet: "ocid1.subnet.oc1..aaaaaa....vdfw"
      oci-network-load-balancer.oraclecloud.com/security-list-management-mode: All

      For accessing subnet OCID, see the Getting Subnet's Details section in Oracle Cloud Infrastructure Documentation.

    • CNC Console must be deployed with HTTPs only in OCI. Non-HTTPs deployment of CNC Console is not supported in OCI.

    Following configurations are needed in occncc_custom_values_<version>.yaml file. This includes configuring the following based on the deployment:

    1. Update unique CNCC ID per cluster (global.self.cnccId ).
    2. Provide the details of M-CNCC IAMs or OCI-IAMs based on deployment (mCnccIams).
    3. Provide the details of A-CNCC (aCnccs).
    4. Provide the details of Agent Instances (instances).
    5. In case of M-CNCC Core, provide the details of M-CNCC Cores and M-CNCC Instances (instances).

    Note:

    • For instances configuration details, see the CNC Console Instances Configurations section and the CNC Console Instances Configuration Options section.
    • There are multiple M-CNCC, A-CNCC, NF Instances, and OCCNE Instances. You must be cautious while updating occncc_custom_values_<version>.yaml file.
    • In case of M-CNCC Core, cmservice.envSystemName in occncc_custom_values_<version>.yaml file can be used to display cluster name.

      For example: envSystemName: CNCC - Site Name.

    • Route creation happens automatically. There is no need to provide routes in the Ingress Gateway section. Only instances details must be provided in the global section.

      A-CNCC and M-CNCC Core use the same CNC Console helm chart, and only deployment configurations may differ.
    • See CNC Console Deployment Configuration Workflow section for details on deployment specific configuration updates.
  3. The following are the Sample configuration section for CNC Console:

    Note:

    For OCI:
    For deployment of CNC Console on OCI, in all the following sample configurations for different deployments, you must set cncc-iam.enabled flag to false and oci-iam.enabled flag to true:
    global:
  oci-iam:
    enabled: true
  cncc-iam:
    enabled: false
    For OCI, only single cluster configuration is applicable.
    1. Single Cluster Deployment

      Sample configuration section for CNC Console in case of single cluster deployment:

      global:
 
  oci-iam:
    enabled: false
  cncc-iam:
    enabled: true
  mcncc-core:
    enabled: true
  acncc-core:
    enabled: true
 
  isMultiClusterDeployment: false
  # Automatic route generation for CNCC Manager Deployment
  self:
    cnccId: Cluster1
  mCnccIams:
    - id: Cluster1
      ip: 10.xx.xx.xx
  mCnccCores:
    - id: Cluster1
  aCnccs:
    - id: Cluster1
      role: Cluster1
      fqdn: cncc-acore-ingress-gateway.cncc.svc.bumblebee
      port: 80
  instances:
    - id: Cluster1-grafana
      type: CS
      owner: Cluster1
      fqdn: occne-kube-prom-stack-grafana.occne-infra.svc.bumblebee
      apiPrefix: /bumblebee/grafana
    - id: Cluster1-kibana
      type: CS
      owner: Cluster1
      fqdn: occne-kibana.occne-infra.svc.bumblebee
      apiPrefix: /bumblebee/kibana
    - id: Cluster1-scp-instance1
      type: SCP
      owner: Cluster1
      fqdn: ocscp-scpc-configuration.scp.svc.bumblebee
      port: 80

      Note:

      CNC Console only supports prometheus apiprefix and not promxy.
    2. Multicluster Deployment

      Sample configuration section for manager only deployment set cncc-iam, mcncc-core to "true" and acncc-core to "false":

      global:
 
  oci-iam:
    enabled: false    
  cncc-iam:
    enabled: true  
  mcncc-core:
    enabled: true
  acncc-core:
    enabled: false
    
  isMultiClusterDeployment: true    
  # Automatic route generation for CNCC Manager Deployment
  self:
    cnccId: Cluster1
  mCnccIams:
    - id: Cluster1
      ip: 10.xx.xx.xx    
  mCnccCores:
    - id: Cluster1
  aCnccs:
    - id: Cluster2
      role: Cluster2
      ip: 10.xx.xx.xx
      port: 80
  instances:
    - id: Cluster1-grafana
      type: CS
      owner: Cluster1
      fqdn: occne-kube-prom-stack-grafana.occne-infra.svc.bumblebee
      apiPrefix: /bumblebee/grafana
    - id: Cluster1-kibana
      type: CS
      owner: Cluster1
      fqdn: occne-kibana.occne-infra.svc.bumblebee
      apiPrefix: /bumblebee/kibana
    - id: Cluster2-kibana
      type: CS
      owner: Cluster2
      fqdn: occne-kibana.occne-infra.svc.jazz
      apiPrefix: /jazz/kibana
    - id: Cluster2-scp-instance2
      type: SCP
      owner: Cluster2      
      fqdn: ocscp-scpc-configuration.scp.svc.jazz      
      port: 80
    Sample configuration section for manager managing local NFs. User must configure cncc-iam, mcncc-core and acncc-core flag to "true".
    global:
 
  oci-iam:
    enabled: false  
  cncc-iam:
    enabled: true
  mcncc-core:
    enabled: true
  acncc-core:
    enabled: true
    
  isMultiClusterDeployment: true  
  # Automatic route generation for CNCC Manager Deployment
  self:
    cnccId: Cluster1
  mCnccIams:
    - id: Cluster1
      ip: 10.xx.xx.xx  
  mCnccCores:
    - id: Cluster1
  aCnccs:
    - id: Cluster1
      role: Cluster1
      fqdn: cncc-acore-ingress-gateway.cncc.svc.bumblebee
      port: 80   
    - id: Cluster2
      role: Cluster2
      ip: 10.xx.xx.xx
      port: 80
  instances:     
    - id: Cluster1-grafana
      type: CS
      owner: Cluster1
      fqdn: occne-kube-prom-stack-grafana.occne-infra.svc.bumblebee      
      apiPrefix: /bumblebee/grafana
    - id: Cluster1-kibana
      type: CS
      owner: Cluster1
      fqdn: occne-kibana.occne-infra.svc.bumblebee
      apiPrefix: /bumblebee/kibana
    - id: Cluster1-scp-instance1
      type: SCP
      owner: Cluster1      
      fqdn: ocscp-scpc-configuration.scp.svc.bumblebee      
      port: 80
    - id: Cluster2-scp-instance2
      type: SCP
      owner: Cluster2       
      fqdn: ocscp-scpc-configuration.scp.svc.jazz       
      port: 80

    Sample configuration section for agent only deployment. User must configure cncc-iam and mcncc-core to "false" and acncc-core to "true".

    global:
    
  oci-iam:
    enabled: false  
  cncc-iam:
    enabled: false
  mcncc-core:
    enabled: false
  acncc-core:
    enabled: true
    
  isMultiClusterDeployment: true  
  # Automatic route generation for CNCC Manager Deployment
  self:
    cnccId: Cluster2
  mCnccIams:
    - id: Cluster1
      ip: 10.xx.xx.xx  
  mCnccCores:
    - id: Cluster1
  aCnccs:
    - id: Cluster2
      role: Cluster2
  instances:     
    - id: Cluster2-kibana
      type: CS
      owner: Cluster2
      fqdn: occne-kibana.occne-infra.svc.jazz
      apiPrefix: /jazz/kibana
    - id: Cluster2-scp-instance2
      type: SCP
      owner: Cluster2      
      fqdn: ocscp-scpc-configuration.scp.svc.jazz       
      port: 80

    Note:

    • In the above examples, mCnccIams port is assumed as "80". The mCnccIams port configuration must be added only if port value is other than 80 or 443.
    • Instance id must be globally unique as it will be used for routing, here is the recommendation for id naming
    • id: <owner>-<instance name>

      For example:

      id: Cluster2-scp-instance2

    • aCnccs.id:
      • is mandatory as its needed for site authorization.
      • aCnccs.id value must be same as self.cnccId.
      • aCnccs.role and mCnccCores.role are optional, which can be used for overriding site role name.
    • For HTTPS enabled deployment scheme, port must be updated to "https" and "https port value" in mCnccIams and aCnccs. For sample configuration, see CNC Console Core Instances configuration examples listed in the appendix.
  4. Deploy M-CNCC IAM using repository and helm tar.

    Caution:

    CNC Console helm install command appears hung for a while because Kubernetes job run by Install helm hook. Helm deployment status is shown as DONE after the applicable hook is run.

    Caution:

    Pod restarts may be observed at M-CNCC Core Ingress Gateway during fresh installation, upgrade, or rollback. This is because M-CNCC Core Ingress Gateway internally checks if CNC Console IAM KC pod is up or not using CNC Console IAM Ingress Gateway. Once CNC Console IAM KC pod is up, you should see M-CNCC Core Ingress Gateway in running state.

    To verify the deployment status, open a new terminal and run the following command:

    kubectl get pods -n <namespace_name> -w
    For example: 
    kubectl get pods -n cncc -w

    The pod status gets updated at regular intervals. When helm install command is run, and it exits with the status, you may stop watching the status of Kubernetes pods.

    Note:

    If helm purge does not clean the deployment and Kubernetes objects completely, then follow CNC Console IAM Clean up section.
    Update DB details in occncc_custom_values_<version>.yaml file.
    
dbVendor: mysql   
dbName: cnccdb
dbHost: mysql-sds.default.svc.cluster.local
dbPort: 3306

    Note:

    Database must be created first and that Database name must be mentioned as dbName.
    1. Run the following command for installation using helm repository: 
      helm install <release_name> <helm-repo> -f <occncc_custom_values_<version>.yaml> --namespace
      <namespace_name> --version <helm_version>

      Where:

      helm-repo: repository name where the helm images, charts are stored

      values: helm configuration file which needs to be updated based on the docker registry

      release_name and namespace_name: depends on user configuration

      For example:

      helm install cncc ocscp-helm-repo/cncc -f occncc_custom_values_24.3.0.yaml --namespace cncc --version 24.3.0
    2. Run the following command for installation using helm tar: 
      

helm install <release_name> -f <occncc_custom_values_<version>.yaml> --namespace <namespace>
      <chartpath>./<chart>.tgz

      For example:

      helm install cncc -f occncc_custom_values_24.3.0.yaml --namespace cncc occncc-24.3.0.tgz
  5. Run the following commands to upgrade the CNC Console Configuration:

    Note:

    For details about CNC Console Deployment Configuration workflow, see the CNC Console Deployment Configuration Workflow section.
    To upgrade:
    • Prepare the occncc_custom_values_<version>.yaml file for upgrade.
    • Upgrade CNC Console.
    1. Run the following command for upgrading using helm repository:
      $ helm upgrade <release_name> <helm_chart> -f <occncc_custom_values_<version>.yaml> --namespace <namespace-name>
      For example:
      $ helm upgrade cncc ocspf-helm-repo/cncc -f occncc_custom_values_24.3.0.yaml --namespace cncc
    2. Run the following command for upgrading using helm tar:
      helm upgrade <release_name> -f occncc_custom_values_<version>.yaml --namespace <namespace>
      <chartpath>./<chart>.tgz
      For example:
      helm  upgrade cncc -f occncc_custom_values_24.3.0.yaml --namespace cncc occncc-24.3.0.tgz
  6. Run the following command to check the deployment status: 
    helm status <release_name>
  7. Run the following command to check if all the services are deployed and running:
    For Non OCI:
    kubectl -n <namespace_name> get services

    Sample output:

    $ kubectl -n cncc get services
    For example:
    NAME                         TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)                      AGE
cncc-acore-igw-cache         ClusterIP      None            <none>           8000/TCP                     24h
cncc-acore-ingress-gateway   ClusterIP      10.233.47.246   <none>           80/TCP                       24h
cncc-iam-igw-cache           ClusterIP      None            <none>           8000/TCP                     24h
cncc-iam-ingress-gateway     LoadBalancer   10.233.3.123    10.75.224.188    80:30185/TCP                 24h
cncc-iam-kc-headless         ClusterIP      None            <none>           8285/TCP                     24h
cncc-iam-kc-http             ClusterIP      10.233.42.16    <none>           8285/TCP,8443/TCP,9990/TCP   24h
cncc-mcore-cmservice         ClusterIP      10.233.9.144    <none>           8442/TCP                     24h
cncc-mcore-igw-cache         ClusterIP      None            <none>           8000/TCP                     24h
cncc-mcore-ingress-gateway   LoadBalancer   10.233.44.167   10.75.224.189    80:30175/TCP                 24h
    For OCI
    $ kubectl -n <namespace_name> get services
    For example:
    kubectl -n cncc get services
NAME                         TYPE           CLUSTER-IP      EXTERNAL-IP                   PORT(S)         AGE
cncc-acore-igw-cache         ClusterIP      None            <none>                        8000/TCP        34m
cncc-acore-ingress-gateway   ClusterIP      10.96.171.188   <none>                        443/TCP         34m
cncc-mcore-cmservice         ClusterIP      10.96.100.237   <none>                        8442/TCP        34m
cncc-mcore-igw-cache         ClusterIP      None            <none>                        8000/TCP        34m
cncc-mcore-ingress-gateway   LoadBalancer   10.96.64.105    10.0.20.117,129.213.159.165   443:31114/TCP   34m
  8. Run the following command to check if all the pods are up and running:
    Non OCI:
     kubectl -n <namespace_name> get pods

    For example:

    $ kubectl -n cncc get pods
    
NAME                                         READY   STATUS    RESTARTS        AGE
cncc-acore-ingress-gateway-c685bf678-bgmdf   1/1     Running   0               24h
cncc-iam-ingress-gateway-6776df55cd-xzx2m    1/1     Running   0               24h
cncc-iam-kc-0                                2/2     Running   0               24h
cncc-mcore-cmservice-587749d58d-8lnd7        1/1     Running   0               24h
cncc-mcore-ingress-gateway-59758876b-zc7d7   1/1     Running   0               24h
OCI:
$ kubectl -n <namespace_name> get pods
For example:
$ kubectl -n cncc get pods
NAME                                          READY   STATUS    RESTARTS   AGE
cncc-acore-ingress-gateway-84c99d6f86-lcxln   2/2     Running   0          23m
cncc-mcore-cmservice-df5b8b885-nxwpv          2/2     Running   0          23m
cncc-mcore-ingress-gateway-8666dcbc4f-4b2cf   2/2     Running   0          23m

Caution:

Do not exit from the helm install command manually. After running the helm install command, it will take a while to install all the services. Do not press "ctrl+c" to exit from helm install command. It may lead to anomalous behavior.

Note:

Tmeout duration (optional): If not specified, the default value will be 5m (5 minutes) in helm.This specifies the time to wait for any individual Kubernetes operation (like Jobs for hooks). The default value is 5m0s. If the helm install command fails at any point to create a Kubernetes object, it will internally call the purge to delete after timeout value (default: 300s). Here, timeout value is for automatic purge on installation failure, and not for overall installation.

2.2.3 Postinstallation Tasks

This section explains the postinstallation tasks for CNC Console.

For Non OCI postinstallation steps, see CNC Console IAM Postinstallation Steps.

For OCI postinstallation steps, see Postinstallation Steps for OCI IAM.

2.2.3.1 Verifying CNC Console Installation

This section describes how to verify if CNC Console is installed successfully.

Note:

  • M-CNCC IAM helm install command will appear hung for a while because Kubernetes job will get executed by install helm hook. Helm deployment will be shown as DONE after the applicable hook is executed.
  • Pod restarts maybe observed at M-CNCC Core Ingress Gateway during fresh installation, upgrade, or rollback. This is because M-CNCC Core Ingress Gateway internally checks if CNC Console IAM KC pod is up or not using CNC Console IAM Ingress Gateway. Once CNC Console IAM KC pod is up, you should see M-CNCC Core iIngress Gateway in running state.
  1. Run the following command to verify the installation status:
    <helm-release> -n <namespace>
    For example:
    occncc -n cncc

    Status should be deployed

  2. Run the following command to verify if the pods are up and active:
    kubectl get jobs,pods -n release_namespace
    For example:
    kubectl get pod -n cncc

    If the deployment is successful, the status for all pods changes to Running and Ready.

  3. Run the following command to verify if the services are deployed and active: 
    kubectl get services -n release_namespace
    For example: 
    kubectl get services -n cncc

Note:

Take a backup of the following files, which are required during fault recovery:

  • Current custom-values.yaml file from which you are upgrading.
  • Updated occncc_custom_values_<version>.yaml file.
  • Updated Helm charts.
  • Secrets, certificates, and keys that are used during installation.

Note:

  • If the installation is not successful or you do not see the status as Running for all the pods, perform the troubleshooting steps provided in Oracle Communications Cloud Native Configuration ConsoleTroubleshooting Guide.
  • For information on validation-hook errors, see CNC Console Validation-hook Error Codes.
2.2.3.2 Performing Helm Test

Helm Test is a feature which validates the successful installation of CNCC along with readiness (Readiness probe URL configured will be checked for success) of all the pods. The pods to be checked will be based on the namespace and label selector configured for the helm test configurations.

Note:

Helm Test can be performed only on Helm3.
To perform Helm test, perform the following steps:
  1. Configure the helm test configurations which are under global sections in occncc_custom_values_<version>.yaml file. Refer the following configurations :

    CNCC Helm Test

    global:  
  # Helm test related configurations
  test:
    nfName: cncc
    image:
      name: occncc/nf_test
      tag: 24.3.0
      imagePullPolicy: IfNotPresent
    config:
      logLevel: WARN
      timeout: 240
  2. Run the following command to perform the Helm test:
     helm test <helm_release_name> -n <namespace>
    Where,

    <release_name> is the release name.

    <namspace> is the deployment namespace where CNCC is installed.

    Example:
     
E.g. [root@master cncc]# helm test cncc -n cncc
Pod cncc-test pending
Pod cncc-test pending
Pod cncc-test pending
Pod cncc-test pending
Pod cncc-test running
Pod cncc-test succeeded
NAME: cncc
LAST DEPLOYED: Tue Jun  7 06:47:14 2022
NAMESPACE: cncc
STATUS: deployed
REVISION: 1
TEST SUITE:     cncc-test
Last Started:   Wed Jun  8 06:01:10 2022
Last Completed: Wed Jun  8 06:01:44 2022
Phase:          Succeeded
NOTES:
# Copyright 2020 (C), Oracle and/or its affiliates. All rights reserved. Thank you for installing cncc. Your release is named cncc , Release Revision: 1.
To learn more about the release, try: 
 
  $ helm status cncc
  $ helm get cncc
  3. Wait for the helm test to complete. Check for the output to see if the test job is successful.

If the Helm test fails, see the Oracle Communications Cloud Native Configuration Console Troubleshooting Guide.

2.2.3.2.1 Helm Test Kubernetes Resources Logging

The Helm test logging enhancement for Kubernetes resources lists the following details of Kubernetes resources:

  1. Versions of Kubernetes resource available in OCCNE.
  2. Preferred version for that Kubernetes resource on the OCCNE.
  3. For each micro service, it list the version of Kubernetes resource used.

This information can be used in the following cases:

  1. In case of CNE upgrade for customer, helm test shall list the Kubernetes resource versions used by NFs. The operator can use this information to run a pre-upgrade compatibility test to see if the Kubernetes resource versions are available on target CNE.
  2. After CNE upgrade, there might be certain resources for which a newer version is available on CNE which is also supported by Console charts. If the output of helm test indicates failure of compliance for certain resource, then upgrade the Console to use the latest version of Kubernetes resource for which failure was indicated.
  3. List all available versions on CNE. Console can use this detail as an input for apiVersion to be used in latest NF charts to which upgrade will be performed.

Note that this feature is tested and compatible with CNE version 1.10 and above.

To use this feature, set global.test.compliance flag to true.

Separate helm test service account can be created and set at global.helmTestserviceAccountName, see Helm Test Service Account Configuration section.

Note:

For helm test execution preference goes to global.helmTestserviceAccountName first, if this is not available then global.serviceAccountName will be referred. If both of these are missing then default service account will be created and used. 
 # Custom service account for Helm test execution
 helmTestserviceAccountName: ""
 
 # Helm test related configurations
 test:
   nfName: cncc
   image:
     name: occncc/nf_test
     tag: 24.3.0
     imagePullPolicy: IfNotPresent
   config:
     logLevel: WARN
     timeout: 240 #Beyond this duration helm test will be considered failure
   resources:
   - horizontalpodautoscalers/v1
   - deployments/v1
   - configmaps/v1
   - prometheusrules/v1
   - serviceaccounts/v1
   - poddisruptionbudgets/v1
   - roles/v1
   - statefulsets/v1
   - persistentvolumeclaims/v1
   - services/v1
   - rolebindings/v1
   complianceEnable: true
Run the following command to check the helm test logs:
helm test <releaseName> --logs -n <namespace>

Example:

helm test cncc --logs -n cncc

The output lists:

  1. The versions of the Kubernetes resources used by Console, which helps in running pre upgrade compatibility test before CNE upgrade.
  2. Compliance check for each Kubernetes resource, if compliance check is false we need to upgrade the Console charts as latest version is supported both by charts and available in new CNE.
  3. Available Kubernetes resource versions on CNE.
Log Example:
{
  "horizontalpodautoscalers" : {
    "availableVersionOnCne" : [ "v1", "v2beta1", "v2beta2" ],
    "avaliableOnDeployment" : [ ],
    "compliant" : true,
    "prefferedVersionOnCne" : "v1",
    "maxNFVersion" : "v1"
  },
  "deployments" : {
    "availableVersionOnCne" : [ "v1" ],
    "avaliableOnDeployment" : [ ],
    "compliant" : true,
    "prefferedVersionOnCne" : "v1",
    "maxNFVersion" : "v1"
  },
  "configmaps" : {
    "availableVersionOnCne" : [ "v1" ],
    "avaliableOnDeployment" : [ ],
    "compliant" : true,
    "prefferedVersionOnCne" : "v1",
    "maxNFVersion" : "v1"
  },
  "serviceaccounts" : {
    "availableVersionOnCne" : [ "v1" ],
    "avaliableOnDeployment" : [ ],
    "compliant" : true,
    "prefferedVersionOnCne" : "v1",
    "maxNFVersion" : "v1"
  },
  "poddisruptionbudgets" : {
    "availableVersionOnCne" : [ "v1beta1" ],
    "avaliableOnDeployment" : [ ],
    "compliant" : true,
    "prefferedVersionOnCne" : "v1beta1",
    "maxNFVersion" : "v1"
  },
  "roles" : {
    "availableVersionOnCne" : [ "v1", "v1beta1" ],
    "avaliableOnDeployment" : [ ],
    "compliant" : true,
    "prefferedVersionOnCne" : "v1",
    "maxNFVersion" : "v1"
  },
  "statefulsets" : {
    "availableVersionOnCne" : [ "v1" ],
    "avaliableOnDeployment" : [ ],
    "compliant" : true,
    "prefferedVersionOnCne" : "v1",
    "maxNFVersion" : "v1"
  },
  "persistentvolumeclaims" : {
    "availableVersionOnCne" : [ "v1" ],
    "avaliableOnDeployment" : [ ],
    "compliant" : true,
    "prefferedVersionOnCne" : "v1",
    "maxNFVersion" : "v1"
  },
  "services" : {
    "availableVersionOnCne" : [ "v1" ],
    "avaliableOnDeployment" : [ ],
    "compliant" : true,
    "prefferedVersionOnCne" : "v1",
    "maxNFVersion" : "v1"
  },
  "rolebindings" : {
    "availableVersionOnCne" : [ "v1", "v1beta1" ],
    "avaliableOnDeployment" : [ ],
    "compliant" : true,
    "prefferedVersionOnCne" : "v1",
    "maxNFVersion" : "v1"
  }
}
2.2.3.2.2 Helm Test Cleanup

After running the helm test, the pod moves to completed state, to remove the pod manually, run the following command:

kubectl delete pod release_name -test -n <namespace_name>

Example:

kubectl delete pod cncc-test -n cncc
2.2.3.3 CNC Console IAM Postinstallation Steps
This section explains the postinstallation steps such as Configuring CNC Console redirection URL, creating the User, and assigning the roles.

Note:

CNC Console multicluster deployment supports cluster specific roles. The user can create cluster roles in CNC Console IAM and assign cluster specific roles to the user similar to NF roles.

Operators must ensure that the cluster role name matches with the role name given in helm configuration.

  • For M-CNCC cluster role creation in M-CNCC IAM, the value of global.mCnccCores.id or global.mCnccCores.role name must be used.
  • For A-CNCC cluster role creation in M-CNCC IAM, the value of global.aCnccs.id or global.aCnccs.role name must be used.

    Note:

    Cluster role names are case sensitive.

Prerequisites

The CNC Console IAM and CNC Console Core must be deployed.

Admin must perform following tasks once CNC Console IAM is deployed:

  • Set the CNC Console redirection URL.
  • Create the user and assign roles (applicable if not integrated with LDAP).

Steps for configuring CNC Console redirection URL, creating user, and assigning the roles:

  1. Log in to CNC Console IAM Console using admin credentials provided during installation of CNC Console IAM.
    Format:
    <scheme>://<cncc-iam-ingress IP/FQDN>:<cncc-iam-ingress Port>
Node-IP and NodePort
Example: 
http://10.75.xx.xx:30085/*
DNS Resolvable FQDN and NodePort
Example: 
http://cncc-iam-ingress-gateway.cncc.svc.cluster.local:30085/*
External LB-IP and ServicePort
Example: 
http://10.75.xx.xx:8080/*
DNS Resolvable FQDN and ServicePort
Example: 
http://cncc-iam-ingress-gateway.cncc.svc.cluster.local:8080/*

Figure 2-10 Login

img/cnc-console-iam1.9.0login.png

Note:

You must select CNCC from the Realm drop down on the left pane after logging in to CNC Console IAM.
  1. Go to Clients option and click cncc.

    Figure 2-11 Clients Tab


    Clients Tab

  2. Enter CNC Console Core Ingress URI in the Root URIs field and Save.
    <scheme>://<cncc-mcore-ingress IP/FQDN>:<cncc-mcore-ingress Port>

    Note:

    Redirection URL is prepopulated, only root URL needs to be configured as part of postinstallation procedure.

    Figure 2-12 General Settings


    General Settings

  3. Click Manage, click Users, and click Add user on the right pane.

    Figure 2-13 Add User


    Add User

  4. Add user screen appears. Add the user details and click Save.

    Figure 2-14 Save User


    Save User

  5. The user has been created and the user details screen appears.

    Figure 2-15 User Details


    User Details

  6. For setting the password for the user, click the Credentials tab and set the password for that user.

    Note:

    Setting Temporary flag to ON prompts the user to change the password when logging in to the CNC Console Core GUI for the first time.

    Figure 2-16 Set Password


    Set Password

  7. Navigate to the Role Mappings tab and assign roles to the user.

    Figure 2-17 Role Mappings


    Role Mappings

  8. Select Master Realm from the Realm drop down list.

    Figure 2-18 Master Realm


    Master Realm

  9. From the Realm Settings tab, navigate to the General tab. Set Require SSL to All Requests and click Save.

    Note:

    The iamSettingEnabled flag must be set to true in occncc_custom_<version>.yaml file to set Require SSL to All Requests.

    Figure 2-19 Realm Settings


    Realm Settings

  10. Log in to CNC Console Core using the credentials of the user created earlier.

    Figure 2-20 CNC Console Core login

    img/cnc-console-core-1.9.0login.png
2.2.3.3.1 CNC Console Multicluster Deployment Roles

CNC Console multicluster feature needs additional cluster specific roles to be created in M-CNCC IAM.

Composite Role Creation

CNC Console IAM provides an option to create composite (group) the roles. This section explains the steps to create the composite roles.
  1. Click Create Role. The Create Role screen appears. Add the Role Name and click Save.

    Figure 2-21 Add Role Name


    Add Role Name

  2. From the Action drop-down, select Add associated roles.

    Figure 2-22 Assign Role


    Assign Role

  3. This enables the Composite Roles functionality, and the Assign roles screen appears.
  4. Select the required roles from Realm Roles, and click Assign.

    Figure 2-23 Assign Roles


    Assign Roles

  5. The Associated roles tab appears in the Role details screen.

    Figure 2-24 Associates Roles


    Associated Roles

Note:

Here, the name "PolicyAgents" is used for composite role, that can be read as "PolicyAgentCnccs".

Note:

For more information about the Roles, see the Role Based Access Control in CNC Console section in Oracle Communications Cloud Native Configuration Console User Guide.
2.2.3.3.2 CNC Console Password Reset

CNC Console admin Password Reset (optional)

WARNING:

You are recommended to continue using the default admin password because a forgotten admin password can't be recovered. For more information, see Oracle Communications Cloud Native Configuration Console Troubleshooting Guide.
CNC Console provides support to change the password of CNC Console IAM:
  1. Log in to CNC Console IAM and click Admin present on the top right of the screen.

    Figure 2-25 Log in to CNC Console IAM


    Log in to CNC Console IAM

  2. Click Manage Account.

    Figure 2-26 Manage account


    Manage account

  3. Click Signing in Account security.

    Figure 2-27 Account Security


    Account Security

  4. Click Update.

    Figure 2-28 Update


    Update

  5. Update your password.

    Figure 2-29 Update Password


    Update Password

  6. Click Submit.

CNC Console User Password Reset

Note:

Only CNC Console admin can update the user password.
To reset CNC Console user password:
  1. Log in to CNC Console IAM.

    Figure 2-30 CNC Console IAM


    CNC Console IAM

  2. Select cncc realm.

    Figure 2-31 cncc Realm


    cncc Realm

  3. Select Users from menu on left.

    Figure 2-32 Users

    img/users24.3.0.png
  4. Click your desired user, and select credentials.

    Figure 2-33 Credentials


    Credentials

  5. Click reset password, enter your password, and then click Save.

    Figure 2-34 Reset Password


    Reset password

2.2.3.4 Postinstallation Steps for OCI IAM
2.2.3.4.1 Configure CNC Console Redirect URLs in OCI IAM

Once the CNC Console application is deployed in the OKE cluster you must configure the Redirect URL and Post-logout redirect URL in OCI IAM.

  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains.
  2. Click the name of the identity domain that you want to work in. You might need to change the compartment to find the domain that you want. Then, click Integrated applications.

    Figure 2-35 Integrated Applications


    Intergrated Applications

  3. Click the application that you want to modify (for example: cncc-iam).
  4. Click Edit OAuth Configuration.

    Figure 2-36 Edit OAuth


    Edit Oauth

  5. Expand the Client configuration node.
  6. Update the following fields:

    Figure 2-37 Authorization


    Authorization

    1. Authorization Types: select thevResource owner, Client Credentials, Refresh token, and Authorization code checkboxes.
    2. Redirect URL: Application URL where the user is redirected after authentication. This field is mandatory.
      • Configure the following for CNC Console:
        /login/oauth2/code/cncc-iam
      • Template for redirect URL:
        For LoadBalancer IP and Port:
        https://<cncc-mcore-igw-lb-ip>:<port>/login/oauth2/code/cncc-iam
        For DNS resolvable FQDN and port:
        https://<cncc-mcore-igw-dns-resolvable-fqdn>:<port>/login/oauth2/code/cncc-iam
      • Example if port 80 or 443:
        For LoadBalancer IP and port:
        https://xxx.xxx.xx.xxx/login/oauth2/code/cncc-iam
        For DNS resolvable FQDN and port:
        https://cncc-mcore-ingress-gateway.cncc.svc.cluster.local/login/oauth2/code/cncc-iam
      • Example if port is other than 80/443:

        For LoadBalancer IP and port:

        https://xxx.xxx.xx.xxx:8443/login/oauth2/code/cncc-iam
        For DNS resolvable FQDN and port:
        https://cncc-mcore-ingress-gateway.cncc.svc.cluster.local:8443/login/oauth2/code/cncc-iam
    3. Post logout redirect URL: Enter the URL where you want to redirect the user after logging out of the application.
      • Template for Post-logout redirect URL:

        For LoadBalancer IP and port:
        https://<cncc-mcore-igw-lb-ip>:<port>/
        For DNS resolvable FQDN and port:
        https://<cncc-mcore-igw-dns-resolvable-fqdn>:<port>/
      • Example if port is 80 or 443

        For LoadBalancer IP and port
        https://xxx.1xx.xx.xxx/
        For DNS resolvable FQDN and port:
        https://cncc-mcore-ingress-gateway.cncc.svc.cluster.local/
      • Example if port is other than 80 or 443:

        For LoadBalancer IP and port:
        https://xxx.1xx.xx.xxx:8443/
        For DNS resolvable FQDN and port:
        https://cncc-mcore-ingress-gateway.cncc.svc.cluster.local:8443/
  7. Click Save Changes.

    Figure 2-38 Save


    Save

  8. If the application is not activated, , click Activate at the top of the page, to the right of the application name.
  9. In the Activate application dialog box, click Activate application.
2.2.3.4.2 Configure Password Policies in OCI IAM

You can choose the default password policies that OCI IAM provides, or create custom password policies based on your own requirement.

See OCI Password Policies in the Oracle Communications Cloud Native Configuration Console User Guide for customizing password policies.

2.2.3.4.3 Configure Groups in OCI IAM

Verify Created or Imported Groups

To view all groups, see the Create a Group section in the Oracle Communications Cloud Native Configuration Console User Guide.

2.2.3.4.4 Configure Users in OCI IAM

Create Users

You can create users using following options:

  • Importing users via CSV file. For more details, see the Importing Users section in the Oracle Communications Cloud Native Configuration Console User Guide.
  • Manually creating users. For more details, see the Create a User section in the Oracle Communications Cloud Native Configuration Console User Guide.
Assign Users to Groups

To assign users to groups, see the Add a User to a Group section in Oracle Communications Cloud Native Configuration Console User Guide.

Verify Created or Imported Users

To view all users, see the View Users section in the Oracle Communications Cloud Native Configuration Console User Guide.

2.2.3.4.5 Verify CNC Console GUI Access

To verify the CNC Console GUI access, see the Logging into CNC Console GUI section in the Oracle Communications, Cloud Native Configuration Console User Guide.

2.2.3.5 Automate Certificate Lifecycle Management Using OCCM

This section provides details on CNC Console support for automated certificate lifecycle management through OCCM.

For information on upgrading automated certificate lifecycle management through OCCM, see Enabling Automated Certificate Lifecycle Management through OCCM during Console Upgrade.

For more information on support for automated certificate management, see the "TLS Support with Automated Certificate Management" section in Oracle Communications Cloud Native Configuration Console User Guide.