4 Implementing Security Recommendations and Guidelines

4.1 Implementing Security Recommendations and Guidelines for OCNADD

This section provides specific recommendations and guidelines for OCNADD security.

4.1.1 TLS Configuration

External TLS Communication

DF2: Browser and DF3: Kafka communication is over TLS only. No additional steps apart from certificate creation need to be performed.

DF4: Consumer NF communication can be configured to use clear text or TLS through the OCNADD GUI. For more information, see "Configuring OCNADD Using CNC Console" section in the Oracle Communications Network Analytics Data Director User Guide.

DF5: Consumer NF (Synthetic Feed) communication can be configured to use TCP or TCP_SECURED through the OCNADD GUI. For more information, see "Configuring OCNADD Using CNC Console" section in the Oracle Communications Network Analytics Data Director User Guide.

DF6: Direct Kafka Consumer Feed communication is over TLS only. No additional steps apart from certificate creation need to be performed. Refer to Internal TLS Communication section for more info about certificate creation.

See Certificate Creation for NFs and Third Party Consumers before creating certificates for NFs, OCNADD, third party consumers, and Kafka Consumers.

Internal TLS Communication

The internal communication between the various data director microservices can be with or without TLS.

IntraTLS Enabled

The internal communication between OCNADD services should be secured. All OCNADD services must use the SSL certificates, the services requiring certificates are mentioned below:

Table 4-1 Management and Worker Group Services when IntraTLS is enabled

Management Group Services Worker Group Services
ocnadduirouter kafka-broker
ocnaddredundancyagent ocnaddbsfaggregation
ocnaddhealthmonitoring ocnaddnrfaggregation
ocnaddexportservice ocnaddseppaggregation
ocnaddconfiguration ocnaddscpaggregation
ocnaddbackuprestore ocnaddpcfaggregation
ocnaddalarm kraft-controller
ocnaddadminservice ocnaddpreupgradeaclhelmhook
- adapter
- ocnaddcorrelation
- ocnaddfilter
- ocnaddingressadapter
- ocnaddnonoracleaggregation
- ocnaddstorageadapterservice

IntraTLS Disabled

When intraTLS is disabled, the services mentioned in the below tables requires the certificates to be created for them

Table 4-2 Management and Worker Group Services when IntraTLS is disabled

Management Group Services Worker Group Services
ocnaddredundancyagent adapter
ocnaddbackuprestore kafka-broker
- kraft-controller
- ocnaddingressadapter

Note:

  • In case intraTLS is disabled then ocnaddfilter service must also be disabled in the charts as ocnaddfilter service can not work without Kafka ACLs and that requires intraTLS as enabled

Caution:

  • Do not delete any secrets that do not correspond to specific services (i.e., the secret name does not contain a specific service name), for example, certdbfilesecret, ocnaddpreupgradeaclhelmhook-secret. These are internal secrets required by Data Director.

Enabling/Disabling intraTLS in OCNADD

In addition to the external communication, TLS is also used for internal OCNADD communication by default. To enable or disable internal TLS, the following steps need to be undertaken:

Note:

The user must ensure before proceeding further that all required certificates as indicated above are created for the services using section "Configuring SSL or TLS Certificates" in Oracle Communications Network Analytics Data Director Installation, Upgrade Guide and Fault Recovery Guide.

For details on adding entries for service certificates, see the "Certificate and Secret Generation" section.

Enable intraTLS in OCNADD

To enable or disable internal TLS, the following steps need to be undertaken:

  • Enable internal TLS in Helm Charts.
    • Change the value of global.ssl.intraTlsEnabled to true if not already set in the ocnadd-custom-values-25.2.100.yaml. It is set to true by default.
      
ssl:
  intraTlsEnabled: true
  • Upgrade OCNADD deployment/s to enable TLS for internal communications
    • If centralized deployment model is used:
      • First, upgrade management group deployment:
        helm upgrade -n <management-namespace> -f <management-custom-values> <management-release-name> <release-chart>

        For example:

        helm upgrade -n ocnadd-deploy-mgmt -f ocnadd-custom-values-mgmt.yaml ocnadd-mgmt ocnadd
      • Then, upgrade each worker group deployment after management group upgrade is complete with Consumer Adapter, Correlation, Storage Adapter, Ingress Adapter upgrade flags set to TRUE in the configuration:
        helm upgrade -n <worker-group-namespace> -f <worker-group-custom-values> <worker-group-release-name> <release-chart>

        Note:

        Use the mgmt group namespace for the default worker group.

        For example:

        helm upgrade -n ocnadd-deploy-wg1 -f ocnadd-custom-values-wg.yaml ocnadd-wg ocnadd

Disable intraTLS in OCNADD

  1. Disable Internal TLS in Helm Charts:
    1. Change the value of global.ssl.intraTlsEnabled to false in the ocnadd-custom-values-25.2.100.yaml file. It is set to true by default.
    2. Example setting:
      ssl:
  intraTlsEnabled: false
  2. Upgrade OCNADD Deployments to Disable TLS for Internal Communications:
    1. If a Centralized Deployment Model is Used:
      1. First, upgrade the management group deployment:
        helm upgrade -n <management-namespace> -f <management-custom-values> <management-release-name> <release-chart>
        For example:
        helm upgrade -n ocnadd-deploy-mgmt -f ocnadd-custom-values-mgmt.yaml ocnadd-mgmt ocnadd
    2. Then, upgrade each worker group deployment after the management group upgrade is complete:
      helm upgrade -n <worker-group-namespace> -f <worker-group-custom-values> <worker-group-release-name> <release-chart>

      Note:

      Use the management group namespace for the default worker group.
      For example:
      helm upgrade -n ocnadd-deploy-wg1 -f ocnadd-custom-values-wg.yaml ocnadd-wg ocnadd

Note:

  • External Kafka feeds with filter and correlation features cannot be used without enabling internal TLS.
  • The Export feature will not work as it is dependent on the Correlation feeds, which require intraTLS to be enabled.

Certificate and Secret Generation

Certificates produced Manually

The OCNADD services can communicate with each other as well as with external interfaces in both secure encrypted mode as well as in insecure mode. For establishing encrypted communication between the services, there is a necessity to generate TLS certificates and private keys for each microservice. The service certificate is generated using the provided CA certificate see the Oracle Communications Network Analytics Data Director Installation and Upgrade Guide section "Configuring SSL or TLS Certificates"

The generated service certificates are stored as the Kubernetes secret.

Below are sample values files with/without internal TLS enabled:

where:

  • ocnadd-deploy: is the namespace where OCNADD is deployed
  • occne-ocnadd: is the Kubernetes domain name

Update the "global" section as per the requirements. The namespace and domain name will be handled by the script.

For Centralized mode with default worker group

intraTLS mode is enabled (all the services should use the TLS certificates).

# Do not modify any keys in global section. Please edit only values present in global section.
# Edit only commonName value for Root CA. Do not modify key
# You can add multiple services in same manner as the sample services are added. The format should be as follows
#service name, common name for service and list of subject alternate name
#e.g.,
#[<service_name>]
#commonName=your.svc.common.name
#IP.1 = 127.0.0.1
#IP.2 = 10.72.31.4
#DNS.1 = localhost
#DNS.2 = svc.cluster.local
# Make sure to provide a single empty line (without space) after end of every section
# Do not add comments anywhere in this script to avoid parsing error
 
[global]
countryName=IN
stateOrProvinceName=KA
localityName=BLR
organizationName=ORACLE
organizationalUnitName=CGBU
defaultDays=365
 
##root_ca
commonName=*.svc.occne-ocdd
 
[kafka-broker]
client.commonName=kafka-broker-zk
server.commonName=kafka-broker
DNS.1=*.kafka-broker.ocnadd-deploy.svc.occne-ocdd
DNS.2=kafka-broker
DNS.3=*.kafka-broker
DNS.4=kafka-broker-0.kafka-broker
DNS.5=kafka-broker-1.kafka-broker
DNS.6=kafka-broker-2.kafka-broker
DNS.7=kafka-broker-3.kafka-broker
DNS.8=kafka-broker.ocnadd-deploy
DNS.9=kafka-broker-0.kafka-broker.ocnadd-deploy
DNS.10=kafka-broker-1.kafka-broker.ocnadd-deploy
DNS.11=kafka-broker-2.kafka-broker.ocnadd-deploy
DNS.12=kafka-broker-3.kafka-broker.ocnadd-deploy
DNS.13=*.kafka-broker-headless.ocnadd-deploy.svc.occne-ocdd
DNS.14=kafka-broker-headless
DNS.15=*.kafka-broker-headless
DNS.16=kafka-broker-0.kafka-broker-headless
DNS.17=kafka-broker-1.kafka-broker-headless
DNS.18=kafka-broker-2.kafka-broker-headless
DNS.19=kafka-broker-3.kafka-broker-headless
DNS.20=kafka-broker-headless.ocnadd-deploy
DNS.21=kafka-broker-0.kafka-broker-headless.ocnadd-deploy
DNS.22=kafka-broker-1.kafka-broker-headless.ocnadd-deploy
DNS.23=kafka-broker-2.kafka-broker-headless.ocnadd-deploy
DNS.24=kafka-broker-3.kafka-broker-headless.ocnadd-deploy
 
 
 
[ocnaddthirdpartyconsumer]
client.commonName=ocnaddthirdpartyconsumer-client
server.commonName=ocnaddthirdpartyconsumer
DNS.1=*.ocnaddthirdpartyconsumer.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddthirdpartyconsumer
DNS.3=ocnaddthirdpartyconsumer.ocnadd-deploy
DNS.4=ocnaddthirdpartyconsumer.ocnadd-deploy.svc.occne-ocdd
 
[oraclenfproducer]
client.commonName=oraclenfproducer
server.commonName=oraclenfproducer-server
DNS.1=*.oraclenfproducer.ocnadd-deploy.svc.occne-ocdd
DNS.2=oraclenfproducer
DNS.3=oraclenfproducer.ocnadd-deploy
 
[ocnadduirouter]
client.commonName=ocnadduirouter-client
server.commonName=ocnadduirouter
DNS.1=*.ocnadduirouter.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnadduirouter
DNS.3=ocnadduirouter.ocnadd-deploy
 
[ocnaddadminservice]
client.commonName=ocnaddadminservice-client
server.commonName=ocnaddadminservice
DNS.1=*.ocnaddadminservice.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddadminservice
DNS.3=ocnaddadminservice.ocnadd-deploy
 
[ocnaddalarm]
client.commonName=ocnaddalarm-client
server.commonName=ocnaddalarm
DNS.1=*.ocnaddalarm.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddalarm
DNS.3=ocnaddalarm.ocnadd-deploy
 
[ocnaddconfiguration]
client.commonName=ocnaddconfiguration-client
server.commonName=ocnaddconfiguration
DNS.1=*.ocnaddconfiguration.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddconfiguration
DNS.3=ocnaddconfiguration.ocnadd-deploy
 
[ocnaddhealthmonitoring]
client.commonName=ocnaddhealthmonitoring-client
server.commonName=ocnaddhealthmonitoring
DNS.1=*.ocnaddhealthmonitoring.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddhealthmonitoring
DNS.3=ocnaddhealthmonitoring.ocnadd-deploy
 
[ocnaddscpaggregation]
client.commonName=ocnaddscpaggregation-client
server.commonName=ocnaddscpaggregation
DNS.1=*.ocnaddscpaggregation.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddscpaggregation
DNS.3=ocnaddscpaggregation.ocnadd-deploy
 
[ocnaddnrfaggregation]
client.commonName=ocnaddnrfaggregation-client
server.commonName=ocnaddnrfaggregation
DNS.1=*.ocnaddnrfaggregation.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddnrfaggregation
DNS.3=ocnaddnrfaggregation.ocnadd-deploy
 
[ocnaddpcfaggregation]
client.commonName=ocnaddpcfaggregation-client
server.commonName=ocnaddpcfaggregation
DNS.1=*.ocnaddpcfaggregation.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddpcfaggregation
DNS.3=ocnaddpcfaggregation.ocnadd-deploy
 
[ocnaddbsfaggregation]
client.commonName=ocnaddbsfaggregation-client
server.commonName=ocnaddbsfaggregation
DNS.1=*.ocnaddbsfaggregation.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddbsfaggregation
DNS.3=ocnaddbsfaggregation.ocnadd-deploy
 
[ocnaddseppaggregation]
client.commonName=ocnaddseppaggregation-client
server.commonName=ocnaddseppaggregation
DNS.1=*.ocnaddseppaggregation.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddseppaggregation
DNS.3=ocnaddseppaggregation.ocnadd-deploy
 
[ocnaddnonoracleaggregation]
client.commonName=ocnaddnonoracleaggregation-client
server.commonName=ocnaddnonoracleaggregation
DNS.1=*.ocnaddnonoracleaggregation.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddnonoracleaggregation
DNS.3=ocnaddnonoracleaggregation.ocnadd-deploy
 
[ocnaddingressadapter]
client.commonName=ocnaddingress-client
server.commonName=ocnaddingress
DNS.1=*.ocnaddingressadapter.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddingressadapter
DNS.3=ocnaddingressadapter.ocnadd-deploy
DNS.4=*ingress-adapter.ocnadd-deploy.svc.occne-ocdd
DNS.5=*ingress-adapter.ocnadd-deploy
DNS.6=*ingress-adapter
 
[adapter]
client.commonName=adapter
server.commonName=adapter-server
DNS.1=*adapter.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddconsumeradapter
DNS.3=ocnaddconsumeradapter.ocnadd-deploy
 
[ocnaddcorrelation]
client.commonName=ocnaddcorrelation-client
server.commonName=ocnaddcorrelation
DNS.1=*.ocnaddcorrelation.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddcorrelation
DNS.3=ocnaddcorrelation.ocnadd-deploy
 
[ocnaddfilter]
client.commonName=ocnaddfilter-client
server.commonName=ocnaddfilter
DNS.1=*.ocnaddfilter.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddfilter
DNS.3=ocnaddfilter.ocnadd-deploy
 
[ocnaddbackuprestore]
client.commonName=ocnaddbackuprestore
server.commonName=ocnaddbackuprestore-server
DNS.1=ocnaddbackuprestore
 
[ocnaddpreupgradeaclhelmhook]
client.commonName=ocnaddpreupgradeaclhelmhook-client
server.commonName=ocnaddpreupgradeaclhelmhook
DNS.1=*.ocnaddpreupgradeaclhelmhook.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddpreupgradeaclhelmhook
DNS.3=ocnaddpreupgradeaclhelmhook.ocnadd-deploy
 
[ocnaddredundancyagent]
client.commonName=ocnaddredundancyagent-client
server.commonName=ocnaddredundancyagent
DNS.1=*.ocnaddredundancyagent.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddredundancyagent
DNS.3=ocnaddredundancyagent.ocnadd-deploy
 
[ocnaddstorageadapterservice]
client.commonName=ocnaddstorageadapterservice-client
server.commonName=ocnaddstorageadapterservice
DNS.1=*.ocnaddstorageadapterservice.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddstorageadapterservice
DNS.3=ocnaddstorageadapterservice.ocnadd-deploy
 
[ocnaddexportservice]
client.commonName=ocnaddexportservice-client
server.commonName=ocnaddexportservice
DNS.1=*.ocnaddexportservice.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddexportservice
DNS.3=ocnaddexportservice.ocnadd-deploy
 
[kraft-controller]
client.commonName=kraft-controller-zk
server.commonName=kraft-controller
DNS.1=*.kraft-controller.ocnadd-deploy.svc.occne-ocdd
DNS.2=kraft-controller
DNS.3=*.kraft-controller
DNS.4=kraft-controller-0.kraft-controller
DNS.5=kraft-controller-1.kraft-controller
DNS.6=kraft-controller-2.kraft-controller
DNS.7=kraft-controller.ocnadd-deploy
DNS.8=kraft-controller-0.kraft-controller.ocnadd-deploy
DNS.9=kraft-controller-1.kraft-controller.ocnadd-deploy
DNS.10=kraft-controller-2.kraft-controller.ocnadd-deploy
DNS.11=kraft-controller-0.kraft-controller.ocnadd-deploy.svc.occne-ocdd
DNS.12=kraft-controller-1.kraft-controller.ocnadd-deploy.svc.occne-ocdd
DNS.13=kraft-controller-2.kraft-controller.ocnadd-deploy.svc.occne-ocdd
 
##end

intraTLS mode is disabled (only services indicated below should use the TLS certificates)

# Do not modify any keys in global section. Please edit only values present in global section.
# Edit only commonName value for Root CA. Do not modify key # You can add multiple services in same manner as the sample services are added. The format should be as follows
#service name, common name for service and list of subject alternate name
#e.g.,
#[<service_name>]
#commonName=your.svc.common.name
#IP.1 = 127.0.0.1
#IP.2 = 10.72.31.4
#DNS.1 = localhost
#DNS.2 = svc.cluster.local
# Make sure to provide a single empty line (without space) after end of every section
# Do not add comments anywhere in this script to avoid parsing error
 
[global]
countryName=IN
stateOrProvinceName=KA
localityName=BLR
organizationName=ORACLE
organizationalUnitName=CGBU
defaultDays=90
 
##root_ca
commonName=*.svc.occne-ocdd
 
[kafka-broker]
client.commonName=kafka-broker-zk
server.commonName=kafka-broker
DNS.1=*.kafka-broker.ocnadd-deploy.svc.occne-ocdd
DNS.2=kafka-broker
DNS.3=*.kafka-broker
DNS.4=kafka-broker-0.kafka-broker
DNS.5=kafka-broker-1.kafka-broker
DNS.6=kafka-broker-2.kafka-broker
DNS.7=kafka-broker-3.kafka-broker
DNS.8=kafka-broker.ocnadd-deploy
DNS.9=kafka-broker-0.kafka-broker.ocnadd-deploy
DNS.10=kafka-broker-1.kafka-broker.ocnadd-deploy
DNS.11=kafka-broker-2.kafka-broker.ocnadd-deploy
DNS.12=kafka-broker-3.kafka-broker.ocnadd-deploy
 
 
 
 
[kraft-controller]
client.commonName=kraft-controller-zk
server.commonName=kraft-controller
DNS.1=*.kraft-controller.ocnadd-deploy.svc.occne-ocdd
DNS.2=kraft-controller
DNS.3=*.kraft-controller
DNS.4=kraft-controller-0.kraft-controller
DNS.5=kraft-controller-1.kraft-controller
DNS.6=kraft-controller-2.kraft-controller
DNS.7=kraft-controller.ocnadd-deploy
DNS.8=kraft-controller-0.kraft-controller.ocnadd-deploy
DNS.9=kraft-controller-1.kraft-controller.ocnadd-deploy
DNS.10=kraft-controller-2.kraft-controller.ocnadd-deploy
DNS.11=kraft-controller-0.kraft-controller.ocnadd-deploy.svc.occne-ocdd
DNS.12=kraft-controller-1.kraft-controller.ocnadd-deploy.svc.occne-ocdd
DNS.13=kraft-controller-2.kraft-controller.ocnadd-deploy.svc.occne-ocdd
 
[adapter]
client.commonName=adapter
server.commonName=adapter-server
DNS.1=*adapter.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddconsumeradapter
DNS.3=ocnaddconsumeradapter.ocnadd-deploy
 
[ocnaddingressadapter]
client.commonName=ocnaddingress-client
server.commonName=ocnaddingress
DNS.1=*.ocnaddingressadapter.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddingressadapter
DNS.3=ocnaddingressadapter.ocnadd-deploy
DNS.4=*ingress-adapter.ocnadd-deploy.svc.occne-ocdd
DNS.5=*ingress-adapter.ocnadd-deploy
DNS.6=*ingress-adapter
 
[ocnaddbackuprestore]
client.commonName=ocnaddbackuprestore
server.commonName=ocnaddbackuprestore-server
DNS.1=ocnaddbackuprestore
 
[ocnaddredundancyagent]
client.commonName=ocnaddredundancyagent-client
server.commonName=ocnaddredundancyagent
DNS.1=*.ocnaddredundancyagent.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddredundancyagent
DNS.3=ocnaddredundancyagent.ocnadd-deploy
 
 
##end

Note:

  • External Kafka feed with filter and correlation features cannot be used without enabling internal TLS. Examples include CORRELATED FEED, FILTER CORRELATED FEED, AGGREGATED KAFKA FEED, etc.
  • The Export feature will not work as it is dependent on the Correlation feeds, which require intraTLS to be enabled.

For Centralized Deployment with non-default or more than one worker groups

When intraTLS mode is enabled, all the services in both the management and worker group(s) should use the TLS certificates to ensure secure internal communication.

  • The ssl_certs/default_values/management_service_values_template or its copies should be configured as follows:
    # Do not modify any keys in global section. Please edit only values present in global section.
# Edit only commonName value for Root CA. Do not modify key
# You can add multiple services in same manner as the sample services are added. The format should be as follows
#service name, common name for service and list of subject alternate name
#e.g.,
#[<service_name>]
#commonName=your.svc.common.name
#IP.1 = 127.0.0.1
#IP.2 = 10.72.31.4
#DNS.1 = localhost
#DNS.2 = svc.cluster.local
# Make sure to provide a single empty line (without space) after end of every section
# Do not add comments anywhere in this script to avoid parsing error
 
[global]
countryName=IN
stateOrProvinceName=KA
localityName=BLR
organizationName=ORACLE
organizationalUnitName=CGBU
defaultDays=365
 
##root_ca
commonName=*.svc.occne-ocdd
 
[ocnadduirouter]
client.commonName=ocnadduirouter-client
server.commonName=ocnadduirouter
DNS.1=*.ocnadduirouter.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnadduirouter
DNS.3=ocnadduirouter.ocnadd-deploy
 
[ocnaddalarm]
client.commonName=ocnaddalarm-client
server.commonName=ocnaddalarm
DNS.1=*.ocnaddalarm.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddalarm
DNS.3=ocnaddalarm.ocnadd-deploy
 
[ocnaddconfiguration]
client.commonName=ocnaddconfiguration-client
server.commonName=ocnaddconfiguration
DNS.1=*.ocnaddconfiguration.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddconfiguration
DNS.3=ocnaddconfiguration.ocnadd-deploy
 
[ocnaddhealthmonitoring]
client.commonName=ocnaddhealthmonitoring-client
server.commonName=ocnaddhealthmonitoring
DNS.1=*.ocnaddhealthmonitoring.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddhealthmonitoring
DNS.3=ocnaddhealthmonitoring.ocnadd-deploy
 
[ocnaddbackuprestore]
client.commonName=ocnaddbackuprestore
server.commonName=ocnaddbackuprestore-server
DNS.1=ocnaddbackuprestore
 
[ocnaddredundancyagent]
client.commonName=ocnaddredundancyagent-client
server.commonName=ocnaddredundancyagent
DNS.1=*.ocnaddredundancyagent.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddredundancyagent
DNS.3=ocnaddredundancyagent.ocnadd-deploy
 
[ocnaddexportservice]
client.commonName=ocnaddexportservice-client
server.commonName=ocnaddexportservice
DNS.1=*.ocnaddexportservice.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddexportservice
DNS.3=ocnaddexportservice.ocnadd-deploy
 
##end
  • The ssl_certs/default_values/worker_group_service_values_template or its copies should be configured as follows:
    # Do not modify any keys in global section. Please edit only values present in global section.
# Edit only commonName value for Root CA. Do not modify key
# You can add multiple services in same manner as the sample services are added. The format should be as follows
#service name, common name for service and list of subject alternate name
#e.g.,
#[<service_name>]
#commonName=your.svc.common.name
#IP.1 = 127.0.0.1
#IP.2 = 10.72.31.4
#DNS.1 = localhost
#DNS.2 = svc.cluster.local
# Make sure to provide a single empty line (without space) after end of every section
# Do not add comments anywhere in this script to avoid parsing error
 
[global]
countryName=IN
stateOrProvinceName=KA
localityName=BLR
organizationName=ORACLE
organizationalUnitName=CGBU
defaultDays=365
 
##root_ca
commonName=*.svc.occne-ocdd
 
[kafka-broker]
client.commonName=kafka-broker-zk
server.commonName=kafka-broker
DNS.1=*.kafka-broker.ocnadd-deploy.svc.occne-ocdd
DNS.2=kafka-broker
DNS.3=*.kafka-broker
DNS.4=kafka-broker-0.kafka-broker
DNS.5=kafka-broker-1.kafka-broker
DNS.6=kafka-broker-2.kafka-broker
DNS.7=kafka-broker-3.kafka-broker
DNS.8=kafka-broker.ocnadd-deploy
DNS.9=kafka-broker-0.kafka-broker.ocnadd-deploy
DNS.10=kafka-broker-1.kafka-broker.ocnadd-deploy
DNS.11=kafka-broker-2.kafka-broker.ocnadd-deploy
DNS.12=kafka-broker-3.kafka-broker.ocnadd-deploy
DNS.13=*.kafka-broker-headless.ocnadd-deploy.svc.occne-ocdd
DNS.14=kafka-broker-headless
DNS.15=*.kafka-broker-headless
DNS.16=kafka-broker-0.kafka-broker-headless
DNS.17=kafka-broker-1.kafka-broker-headless
DNS.18=kafka-broker-2.kafka-broker-headless
DNS.19=kafka-broker-3.kafka-broker-headless
DNS.20=kafka-broker-headless.ocnadd-deploy
DNS.21=kafka-broker-0.kafka-broker-headless.ocnadd-deploy
DNS.22=kafka-broker-1.kafka-broker-headless.ocnadd-deploy
DNS.23=kafka-broker-2.kafka-broker-headless.ocnadd-deploy
DNS.24=kafka-broker-3.kafka-broker-headless.ocnadd-deploy
 
[ocnaddadminservice]
client.commonName=ocnaddadminservice-client
server.commonName=ocnaddadminservice
DNS.1=*.ocnaddadminservice.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddadminservice
DNS.3=ocnaddadminservice.ocnadd-deploy
 
[ocnaddscpaggregation]
client.commonName=ocnaddscpaggregation-client
server.commonName=ocnaddscpaggregation
DNS.1=*.ocnaddscpaggregation.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddscpaggregation
DNS.3=ocnaddscpaggregation.ocnadd-deploy
 
[ocnaddnrfaggregation]
client.commonName=ocnaddnrfaggregation-client
server.commonName=ocnaddnrfaggregation
DNS.1=*.ocnaddnrfaggregation.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddnrfaggregation
DNS.3=ocnaddnrfaggregation.ocnadd-deploy
 
[ocnaddpcfaggregation]
client.commonName=ocnaddpcfaggregation-client
server.commonName=ocnaddpcfaggregation
DNS.1=*.ocnaddpcfaggregation.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddpcfaggregation
DNS.3=ocnaddpcfaggregation.ocnadd-deploy
 
[ocnaddbsfaggregation]
client.commonName=ocnaddbsfaggregation-client
server.commonName=ocnaddbsfaggregation
DNS.1=*.ocnaddbsfaggregation.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddbsfaggregation
DNS.3=ocnaddbsfaggregation.ocnadd-deploy
 
[ocnaddseppaggregation]
client.commonName=ocnaddseppaggregation-client
server.commonName=ocnaddseppaggregation
DNS.1=*.ocnaddseppaggregation.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddseppaggregation
DNS.3=ocnaddseppaggregation.ocnadd-deploy
 
[ocnaddnonoracleaggregation]
client.commonName=ocnaddnonoracleaggregation-client
server.commonName=ocnaddnonoracleaggregation
DNS.1=*.ocnaddnonoracleaggregation.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddnonoracleaggregation
DNS.3=ocnaddnonoracleaggregation.ocnadd-deploy
 
[ocnaddfilter]
client.commonName=ocnaddfilter-client
server.commonName=ocnaddfilter
DNS.1=*.ocnaddfilter.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddfilter
DNS.3=ocnaddfilter.ocnadd-deploy
 
[ocnaddingressadapter]
client.commonName=ocnaddingress-client
server.commonName=ocnaddingress
DNS.1=*.ocnaddingressadapter.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddingressadapter
DNS.3=ocnaddingressadapter.ocnadd-deploy
DNS.4=*ingress-adapter.ocnadd-deploy.svc.occne-ocdd
DNS.5=*ingress-adapter.ocnadd-deploy
DNS.6=*ingress-adapter
 
[adapter]
client.commonName=adapter
server.commonName=adapter-server
DNS.1=*adapter.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddconsumeradapter
DNS.3=ocnaddconsumeradapter.ocnadd-deploy
 
[ocnaddcorrelation]
client.commonName=ocnaddcorrelation-client
server.commonName=ocnaddcorrelation
DNS.1=*.ocnaddcorrelation.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddcorrelation
DNS.3=ocnaddcorrelation.ocnadd-deploy
 
[ocnaddstorageadapterservice]
client.commonName=ocnaddstorageadapterservice-client
server.commonName=ocnaddstorageadapterservice
DNS.1=*.ocnaddstorageadapterservice.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddstorageadapterservice
DNS.3=ocnaddstorageadapterservice.ocnadd-deploy
 
[ocnaddpreupgradeaclhelmhook]
client.commonName=ocnaddpreupgradeaclhelmhook-client
server.commonName=ocnaddpreupgradeaclhelmhook
DNS.1=*.ocnaddpreupgradeaclhelmhook.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddpreupgradeaclhelmhook
DNS.3=ocnaddpreupgradeaclhelmhook.ocnadd-deploy
 
[kraft-controller]
client.commonName=kraft-controller-zk
server.commonName=kraft-controller
DNS.1=*.kraft-controller.ocnadd-deploy.svc.occne-ocdd
DNS.2=kraft-controller
DNS.3=*.kraft-controller
DNS.4=kraft-controller-0.kraft-controller
DNS.5=kraft-controller-1.kraft-controller
DNS.6=kraft-controller-2.kraft-controller
DNS.7=kraft-controller.ocnadd-deploy
DNS.8=kraft-controller-0.kraft-controller.ocnadd-deploy
DNS.9=kraft-controller-1.kraft-controller.ocnadd-deploy
DNS.10=kraft-controller-2.kraft-controller.ocnadd-deploy
DNS.11=kraft-controller-0.kraft-controller.ocnadd-deploy.svc.occne-ocdd
DNS.12=kraft-controller-1.kraft-controller.ocnadd-deploy.svc.occne-ocdd
DNS.13=kraft-controller-2.kraft-controller.ocnadd-deploy.svc.occne-ocdd
 
##end

Note:

  • External Kafka feeds with filter and correlation features cannot be used without enabling internal TLS. Examples include CORRELATED FEED, FILTER CORRELATED FEED, AGGREGATED KAFKA FEED, etc.
  • The Export feature will not function as it depends on Correlation feeds, which require intraTLS to be enabled.

When intraTLS mode is disabled, the services indicated below in both the management and worker group(s) should still use the TLS certificates to maintain secure communication.

  • The ssl_certs/default_values/management_service_values_template or its copies should be configured as follows:
    # Do not modify any keys in global section. Please edit only values present in global section.
# Edit only commonName value for Root CA. Do not modify key
# You can add multiple services in same manner as the sample services are added. The format should be as follows #service name, common name for service and list of subject alternate name
#e.g.,
#[<service_name>]
#commonName=your.svc.common.name
#IP.1 = 127.0.0.1
#IP.2 = 10.72.31.4
#DNS.1 = localhost
#DNS.2 = svc.cluster.local
# Make sure to provide a single empty line (without space) after end of every section # Do not add comments anywhere in this script to avoid parsing error
 
[global]
countryName=IN
stateOrProvinceName=KA
localityName=BLR
organizationName=ORACLE
organizationalUnitName=CGBU
defaultDays=90
 
##root_ca
commonName=*.svc.occne-ocdd
 
 
[ocnaddbackuprestore]
client.commonName=ocnaddbackuprestore
server.commonName=ocnaddbackuprestore-server
DNS.1=ocnaddbackuprestore
 
[ocnaddredundancyagent]
client.commonName=ocnaddredundancyagent-client
server.commonName=ocnaddredundancyagent
DNS.1=*.ocnaddredundancyagent.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddredundancyagent
DNS.3=ocnaddredundancyagent.ocnadd-deploy
 
##end
  • The ssl_certs/default_values/worker_group_service_values_template or its copies should be configured as follows:
    # Do not modify any keys in global section. Please edit only values present in global section.
# Edit only commonName value for Root CA. Do not modify key
# You can add multiple services in same manner as the sample services are added. The format should be as follows
#service name, common name for service and list of subject alternate name
#e.g.,
#[<service_name>]
#commonName=your.svc.common.name
#IP.1 = 127.0.0.1 #IP.2 = 10.72.31.4
#DNS.1 = localhost
#DNS.2 = svc.cluster.local
# Make sure to provide a single empty line (without space) after end of every section # Do not add comments anywhere in this script to avoid parsing error
 
[global]
countryName=IN
stateOrProvinceName=KA
localityName=BLR
organizationName=ORACLE
organizationalUnitName=CGBU
defaultDays=365
 
##root_ca
commonName=*.svc.occne-ocdd
 
[kafka-broker]
client.commonName=kafka-broker-zk
server.commonName=kafka-broker
DNS.1=*.kafka-broker.ocnadd-deploy.svc.occne-ocdd
DNS.2=kafka-broker
DNS.3=*.kafka-broker
DNS.4=kafka-broker-0.kafka-broker
DNS.5=kafka-broker-1.kafka-broker
DNS.6=kafka-broker-2.kafka-broker
DNS.7=kafka-broker-3.kafka-broker
DNS.8=kafka-broker.ocnadd-deploy
DNS.9=kafka-broker-0.kafka-broker.ocnadd-deploy
DNS.10=kafka-broker-1.kafka-broker.ocnadd-deploy
DNS.11=kafka-broker-2.kafka-broker.ocnadd-deploy
DNS.12=kafka-broker-3.kafka-broker.ocnadd-deploy
 
 
 
[kraft-controller]
client.commonName=kraft-controller-zk
server.commonName=kraft-controller
DNS.1=*.kraft-controller.ocnadd-deploy.svc.occne-ocdd
DNS.2=kraft-controller
DNS.3=*.kraft-controller
DNS.4=kraft-controller-0.kraft-controller
DNS.5=kraft-controller-1.kraft-controller
DNS.6=kraft-controller-2.kraft-controller
DNS.7=kraft-controller.ocnadd-deploy
DNS.8=kraft-controller-0.kraft-controller.ocnadd-deploy
DNS.9=kraft-controller-1.kraft-controller.ocnadd-deploy
DNS.10=kraft-controller-2.kraft-controller.ocnadd-deploy
DNS.11=kraft-controller-0.kraft-controller.ocnadd-deploy.svc.occne-ocdd
DNS.12=kraft-controller-1.kraft-controller.ocnadd-deploy.svc.occne-ocdd
DNS.13=kraft-controller-2.kraft-controller.ocnadd-deploy.svc.occne-ocdd
 
[adapter]
client.commonName=adapter
server.commonName=adapter-server
DNS.1=*adapter.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddconsumeradapter
DNS.3=ocnaddconsumeradapter.ocnadd-deploy
 
[ocnaddingressadapter]
client.commonName=ocnaddingress-client
server.commonName=ocnaddingress
DNS.1=*.ocnaddingressadapter.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddingressadapter
DNS.3=ocnaddingressadapter.ocnadd-deploy
DNS.4=*ingress-adapter.ocnadd-deploy.svc.occne-ocdd
DNS.5=*ingress-adapter.ocnadd-deploy
DNS.6=*ingress-adapter
 
##end

MTLS Configuration

The customers can opt to use MTLS for internal OCNADD communication. To enable the internal MTLS, run the following steps:

  • Enable internal MTLS in Helm Charts.
    Change the value of global.ssl.mTLS to "true" in the ocnadd-custom-values-25.2.100.yaml. By default it is set to false.
    ssl:    
    intraTlsEnabled: true    
    mTLS: true

    Change the value of global.acl.kafkaClientAuth to required in ocnadd-custom-values-25.2.100.yaml

    global
    acl
        kafkaClientAuth: required
  • The certificate creation step remains the same as mentioned in the "TLS Configuration" section.

    Note:

    It is mandatory to enable internal TLS and to create certificates and secrets for MTLS to work.

Certificates Produced by OCCM

Oracle Communications Certificate Management (OCCM) is an automated solution for managing the certificates needed for Oracle Communications Network Analytics Data Director services. OCCM constantly monitors and renews the certificates based on their validity or expiry period.

The created certificates will already have the required TLS/mTLS configuration, eliminating the need for additional steps to configure mTLS and TLS requirements.

To generate certificates using OCCM, follow these steps:

  1. Create secrets as outlined in the "OCCM Secrets" section of the Oracle Communications Network Analytics Data Director Installation and Upgrade Guide.
  2. Modify the custom_values.yaml file according to the "Helm Parameter Configuration for OCCM" section of the Oracle Communications Network Analytics Data Director Installation and Upgrade Guide.
  3. Run helm install command. See "Installing OCNADD Package" section in the Oracle Communications Network Analytics Data Director Installation and Upgrade Guide.

Certificates for Apache Druid

Certificate for Apache Druid must be created using the same CA that was used to create OCNADD's certificate.

Customizing CSR and Certificate Extensions

OpenSSL creates the Certificate Signing Requests (CSRs) and certificates in the generate_certs.sh script of OCNADD. OpenSSL configuration file templates ssl_certs/templates/services_client_openssl.cnf and ssl_certs/templates/services_server_openssl.cnf are used during CSR or certificate creation.

Modify the files based on customer requirements. For more information, see OpenSSL x509 v3 Certificate and CSR Configuration.

Key Usage Requirement for Client and Server CSR

Certificates Produced Manually

External CA may require specific key usage and external key usage to be mentioned in the CSR. Add or modify the [ req_ext ] section in both ssl_certs/templates/services_client_openssl.cnf and ssl_certs/templates/services_server_openssl.cnf files as follows: 

[ req_ext ]
 
# Extensions to add to a certificate request
 
basicConstraints = CA:FALSE
keyUsage=critical,digitalSignature,keyEncipherment # Modify Key Usage
extendedKeyUsage=serverAuth,clientAuth # Add Extended Key Usage

Also add reference to req_ext in [ req ] section as follows: 

[ req ]
default_bits        = 2048
default_keyfile     = privkey.pem
distinguished_name  = req_distinguished_name
attributes      = req_attributes
x509_extensions = usr_cert  # The extensions to add to the self signed cert
req_extensions = req_ext # Add extensions required for CSR

The above code snippets add the standard key and extended key usage required by the CA to sign the certificate. The user can similarly add other specific usage requirements.

Certificates Produced by OCCM

In the certificate signing request (CSR) utilized for certificate creation through OCCM, the X509v3 Extended Key Usage is set to "TLS Web Client Authentication" and "TLS Web Server Authentication," specifying the certificate's purpose for client and server authentication. Additionally, the X509v3 Key Usage is set to "DIGITAL_SIGNATURE" and "KEY_ENCIPHERMENT," indicating the permitted functions for the key's usage.

Adding or Updating SAN Entries

Certificates Produced Manually

These steps should be followed when Subject Alternative Name (SAN) entries need to be updated or added to certificates, and certificates are generated using CACert and CAKey, or only Certificate Signing Requests (CSR) are generated using the generate_certs.sh script.

  • If external access is enabled, then while running script, select "y" when prompted to add SAN entries.
    Do you want to add any IP for adding SAN entries to existing dd services (y/n): y

    If user selects "yes," a list of services is shown and user can add the SAN entries for any of the listed services by selecting the corresponding service number.

    In the following example, the list of management services is shown for user to add SAN entries. Enter the number corresponding to the service for which user wants to enter IP. After choosing the service, give IP addresses as input, else enter "n" to exit. 

    For the following services:
1. ocnadduirouter
2. ocnaddadminservice
3. ocnaddalarm
4. ocnaddconfiguration
5. ocnaddhealthmonitoring
6. ocnaddbackuprestore
7. ocnaddredundancyagent
  
Enter the number corresponding to the service for which you want to add IP: 3
Please enter IP for the service ocnaddalarm or enter "n" to exit : 10.20.30.40
Please enter IP for the service ocnaddalarm or enter "n" to exit : 10.20.30.41
Please enter IP for the service ocnaddalarm or enter "n" to exit : n
Do you want to add IP to any other service (y/n) : n
  • Follow the steps mentioned in section Renewing OCNADD Certificates to renew or recreate the certificates with the modified SAN entries.

Certificates Produced by OCCM

To update or add Subject Alternative Name (SAN) entries for Kafka, the redundancy agent, or the ingress adapter, modify the "global.certificates.occm.san" section in the custom_values.yaml file with the necessary SAN entries. See "Adding/Updating Loadbalancer IPs in SAN through OCCM" section of the Oracle Communications Network Analytics Data Director Installation and Upgrade Guide. The certificates generated by OCCM will then incorporate the updated SAN configuration.

Updating SAN Entries

san:
    kafka:
        update_required: false
        # Provide Kafka Load balancer IPs here
        ips: ["10.10.10.10"]
        uuid:
            client:
            server:
    redundancy_agent:
        update_required: false
        # Provide Redundancy Agent Load balancer IP here
        ips: ["10.10.10.11"]
        uuid:
            client:
            server:
    ingress_adapter:
        update_required: false
        # Provide every Ingress Adapter's Load Balancer IP here
        ips: ["10.10.10.12"]
        uuid:
            client:
            server:

4.1.2 Network Policies

OCNADD is also shipped with Network Policies for ingress connections which are disabled by default. Customers can configure the intended sources of connections by modifying the ocnadd-custom-values.yaml file as mentioned below.

Network policies can be enabled to provide an additional security layer restricting both internal and external connections. The Network Policies are categorized into two categories:

  • Internal Service Connections: The connections between services that are internal to the OCNADD namespace or internal to the OCNADD management and worker group namespaces.
  • External Service Connections: The services from sources that are external to the OCNADD namespace or external to both the OCNADD management and worker group namespaces. The external connections can further be categorized into 4 categories:
    • Connections From CNCC: For rendering OCNADD Dashboard
    • Connections From NF: For connections to Kafka from NF acting as Kafka producer or consumer
    • Connections From CNE Infrastructure Services: For fetching metrics and generating alerts
    • Connections From IP blocks/CIDRS: For connections to Kafka from NF acting as Kafka producer or consumer
To enable network policies, change the value of global.network.policy.enable to true in ocnadd-custom-values.yaml file, by default it is false. By enabling this field, network policies for Internal Service Connections are enabled by default, no modifications are required.

network:
    # enable network policies
    policy:
      enable: true
If using the centralized mode of deployment, include the following in the ocnadd-custom-values.yaml file for the management group chart to allow connections from Worker Group:

global:    
    network:
        ingress:
          namespaces:
            # allow ingress network connfections from below worker group namespaces/s
            workergroups:          # Considering two worker groups namepaces
            - ocnadd-deploy-wg1
            - ocnadd-deploy-wg2
To specify the CNCC namespace, update the values in global.network.ingress.namespaces.cncc to the CNCC namespace in the ocnadd-custom-values.yaml file.

global:    
    network:
        ingress:
          namespaces:
            # allow ingress network connections to gui from below cncc namespace/s
            cncc:                 # Allowing connections from CNCC namespace: occncc
            - occncc
To specify the NF namespaces, update the values in global.network.ingress.namespaces.kafka to the NF namespaces in the ocnadd-custom-values.yaml file.

global:    
    network:
        ingress:
          namespaces:
            # allow ingress network connections to kafka from below namespace/s
            kafka:                # Allowing connections from NRF, SCP, SEPP namespaces
            - ocnrf
            - ocsepp
            - ocscp
To specify the namespace containing CNE infrastructure services like Prometheus, update the values in global.network.ingress.namespaces.infra to the CNE infra namespace in the ocnadd-custom-values.yaml file.
global:
     network:
         ingress:
            namespaces:
               # allow ingress network connections from below infra namespace/s
               infra:             # Allowing connection from occne-infra
               - occne-infra

If connections to Kafka from sources external to the Kubernetes cluster are required, or if connections from specific IP/network are required, update the value in global.network.ingress.external.enable to true. Then, add the required IP/Network address in CIDR format in global.network.ingress.external.cidrs.kafka in the ocnadd-custom-values.yaml.

Note:

Allow connection from Druid IPs to Kafka when Druid is configured to ingest from Kafka. 
global:
      network:
          # Allow external network connections to kafka from below IPs/CIDRs/Network
          # needed for external kafka consumer
          external:  
              enable: true                     # Changed to true
              cidrs:
                 kafka:
                     - 10.10.10.10/32          # Allows connections from 10.10.10.10 IP address
                     - 192.168.10.0/24         # Allows connections from 192.168.10.0 - 192.168.10.255 IP addresses
If redundancy agent is enabled, communication from peer redundancy agent in primary or secondary site needs to be allowed. Update the value in global.network.ingress.external.enable to true and update the peer agent's Loadbalancer IP address in global.network.ingress.external.cidrs.agent in the ocnadd-custom-values.yaml.
global:
      network:
          # Allow external network connections to kafka from below IPs/CIDRs/Network
          # needed for external kafka consumer
          external:  
              enable: true                     # Changed to true
              cidrs:
                 agent:
                     - 100.10.123.1/32         # Loadbalancer IP address of peer redundancy agent

Steps to enable Network Policy

  • Install OCNADD.
  • Modify ocnadd-custom-values.yaml as needed:
    • For a centralized deployment model, modify connections for NF namespaces or external IP/CIDRs independently for each worker group in their respective ocnadd-custom-values.yaml files.
  • Perform Helm upgrade of OCNADD deployment:
    • The specific steps for the helm upgrade will vary based on the selected OCNADD deployment model. See Oracle Communications Network Analytics Data Director Installation, Upgrade Guide, and Fault Recovery Guide for detailed instructions.
    • In a centralized deployment model, start by performing the helm upgrade for management group services. Subsequently, perform the helm upgrade for each worker group namespace.

Caution:

The Kafka and Kraft controller deployments use an external health client for registration with the OCNADD health monitoring service. This external health client uses port 18989 to expose health verification endpoints. These endpoints are accessed by internal Data Director services to retrieve the health status of Kafka and Kraft controllers.

Currently, the network policy does not account for this internal port (18989) for Kafka and Kraft controllers. If a network policy is applied to Kafka and Kraft controllers, care must be taken to ensure that port 18989 is either explicitly allowed in the network policy or that the network policy is disabled during any upgrade or rollback.

Additionally, if services such as the Admin service have a dependency on Kafka during their restart, and the network policy on Kafka does not allow port 18989, those services (for example, Admin service) may get stuck in the init state.

4.1.3 Kafka Security Configuration

The basic configuration for Kafka security in order to be compliant with product delivery is described below.

Prerequisites

  • SSL certificates & keys (generated using SSL scripts which are provided as part of OCNADD release)

Configuring SASL for Kafka

Kafka uses the Java Authentication and Authorization Service (JAAS) for SASL configuration. In OCNADD, by default, all Kafka communication (inter-broker, Kafka-client, and Kafka-broker and between Kafka and Zookeeper) happens with a common user (ocnadd) configured in <chart-path>/charts/ocnaddkafka/config/kafka_server_jaas.conf

Customers can add more users in <chart-path>/charts/ocnaddkafka/config/kafka_server_jaas.conf file. In case of Centralized Deployment, <chart-path> should be the path to the worker group services chart, and each worker group can have different users added to them independently of each other.

The "ocnadd" user is the default user for all internal Kafka communication and should not be modified.

Below are the sample changes to add NRF, SCP, and SEPP users in Kafka:

KafkaServer {
org.apache.kafka.common.security.plain.PlainLoginModule required
username="ocnadd"
password="<change this>"
user_ocnadd="<change this>";
user_NRF="NRF-secret";
user_SCP="SCP-secret";
user_SEPP="SEPP-secret";
};
Client {
org.apache.zookeeper.server.auth.DigestLoginModule required
username="ocnadd"
password="<change this>";
};

In the above code snippet user_NRF="NRF-secret" is added for NRF user, user_SEPP="SEPP-secret" is added for SEPP user, and user_SCP="SCP-secret"is added for SCP user. Where "NRF-secret", "SEPP-secret" and "SCP-secret" are the passwords.

After making the above changes, continue with the installation steps as mentioned in the Oracle Communications Network Analytics Data Director Installation, Upgrade, and Fault Recovery Guide.

Note:

  • Field marked as <change this> needs to be updated by the user to set the Kafka admin password.
  • User addition is one time operation and can be done only during installation.
  • It is recommended to use a strong password in kafka_server_jass.conf.

External Kafka Feed

To enable Kafka Feed support, see the steps mentioned in "Enable Kafka Feed Configuration Support" section of Oracle Communications Network Analytics Data Director User Guide.

4.1.4 MySQL Configuration

The OCNADD uses cnDBtier service for the database, which provides secure database connectivity. For configuration details, see Oracle Communications Network Analytics Data Director Installation Guide, Upgrade, and Fault Recovery Guide.

4.1.5 Certificate Creation for NFs and Third Party Consumers

The following sections provide information about certificate creation rules to be considered by the NFs and Third Party Consumers.

Certification Creation for NFs

NFs must ensure the following conditions are met prior to sending data to OCNADD over TLS:

  • NFs must trust the Certificate Authority(CA) that issues the certificate to the OCNADD. The CA certificate for OCNADD's Certificate Authority must be included in the trust store, cacert file, or the ca-bundle of the NF.
  • When mTLS is enabled in OCNADD and an NF in the same Kubernetes cluster wishes to send data to the SSL endpoint instead of SASL_SSL endpoint, the TLS certificate of the NF should be issued by the same CA issuing certificate to the OCNADD or any one of the trusted CAs.

Certification Creation for Third Party Consumers

When TLS encrypted feeds (HTTP2 or TCP_SECURED) are configured, it is essential that the third party endpoint given in the feed configuration supports TLS. In addition to supporting TLS, consider the following while creating certificates for the consumer:

  • The certificate should be signed by any of the trusted CAs or by the CA issuing certificate for the OCNADD.
  • The certificates Common Name (CN) or Subject Alternative Name (SAN) contains the host name or IP address provided as part of the feed configuration.

    For example, if Feed A is configured to send data to Consumer A (https://thirdpartyconsumer/) and Feed B is configured to send data to Consumer B (https://10.10.10.10), the certificate for Consumer A must contain the thirdpartyconsumer in CN or SAN of its certificate and similarly Consumer B's certificate must contain 10.10.10.10 in the SAN field of its certificate.

  • If mTLS is enabled by the Third Party Consumer, it must trust the CA issuing certificate for OCNADD. The CA certificate for OCNADD's CA must be included in the trust store, cacert file or ca-bundle of the Third Party Consumer.

CA Certificate Expiry

Suppose the CA certificate expires before the OCNADD certificate expiry. In that case, the customer can renew the CA (if self-managed) and reuse the certificate provided the CA certificate's hash, private key, public key, and so on remain the same.

Renewing the OCNADD certificate and performing a rollout restart after renewing the CA certificate will ensure that OCNADD services are using a valid, non-expired CA certificate. For more information, see, Renewing OCNADD Certificates.

4.1.6 Renewing OCNADD Certificates

Follow the steps in the sections below to renew the OCNADD certificates.

Note:

Steps to renew the certificate vary based on the method used to create the certificates.

Certificate Generated Using CACert and CAKey

If the certificate is generated using CACert and CAKey:

  1. Add the services whose certificates must be renewed in the ssl_certs/default_values/renew_cert_files file.
    The following code snippet displays the services to be added if Internal TLS is enabled:
    # This files contain the list of services for which certificate needs to be renewed
# The service name should be exactly same for which the certificates has been initially generated
# defaultDays is number of days upto which certificate should be renewed. Certificate for all listed
# service will be updated with this value.
 
defaultDays=90
 
kafka-broker
kraft-controller
ocnadduirouter
ocnaddadminservice
ocnaddalarm
ocnaddconfiguration
ocnaddhealthmonitoring
ocnaddscpaggregation
ocnaddnrfaggregation
ocnaddseppaggreagation
ocnaddpcfaggreagation
ocnaddbsfaggreagation
ocnaddnonoracleaggreagation      
adapter
ocnaddingressadapter
ocnaddcorrelation
ocnaddstorageadapterservice
ocnaddexport
ocnaddfilter
ocnaddbackuprestore
ocnaddpreupgradeaclhelmhook
  2. Run the following command:
    ./generate_certs.sh -cacert <path to>/cacert.pem -cakey <path to>/cakey.pem --renew
  3. Choose the mode of deployment when prompted Select the mode of deployment.
  4. Choose the namespace where OCNADD, OCNADD management group services or OCNADD worker group services is/are deployed when prompted Enter kubernetes namespace:
  5. Provide password to your CA key when prompted Enter passphrase for CA Key file:
  6. Older certificates will be revoked and newer certificates will be created and the rollout restart of services will be performed.

Only CSR is Generated

If only the CSR is generated:

  1. Navigate to ssl_certs/demoCA/dd_mgmt_worker_services/<namespace>/services/<service-name>/client or ssl_certs/demoCA/dd_mgmt_worker_services/<namespace>/services/<service-name>/server ssl_certs/ for each <service-name> given in default_values/values file.

    For example, navigating to client folder for adapter service in worker group namespace ocnadd-deploy-wg1

    [ssl_certs]$ ls
default_values demoCA generate_certs.sh generate_secrets.sh logs template
[ssl_certs]$ cd demoCA/dd_mgmt_worker_services/ocnadd-deploy-wg1/services/adapter/client/
[client]$ ls
adapter-clientcert.pem adapter-client.csr adapter-clientprivatekey.pem adapter_client_ssl.cnf client_rsa_certificate.crt
  2. Delete the old CSR request.
    The following example displays how to delete the old CSR request for the adapter service:
    [client]$ ls
adapter-clientcert.pem  adapter-client.csr  adapter-clientprivatekey.pem  adapter_client_ssl.cnf  client_rsa_certificate.crt
[client]$ rm adapter-client.csr
[client]$ ls
adapter-clientcert.pem  adapter-clientprivatekey.pem  adapter_client_ssl.cnf  client_rsa_certificate.crt
  3. To create a new CSR (client.csr) from the old certificate (clientcert.pem) and private key (clientprivatekey.pem), run the following command:
    openssl x509 -x509toreq -in clientcert.pem -signkey clientprivatekey.pem -out client.csr

    The following example displays how to create a new client CSR for the adapter service:

    [client]$ ls
adapter-clientcert.pem  adapter-clientprivatekey.pem  adapter_client_ssl.cnf  client_rsa_certificate.crt
[client]$ openssl x509 -x509toreq -in adapter-clientcert.pem -signkey adapter-clientprivatekey.pem -out adapter-client.csr
Getting request Private Key
Generating certificate request
[client]$ ls
adapter-clientcert.pem  adapter-client.csr  adapter-clientprivatekey.pem  adapter_client_ssl.cnf  client_rsa_certificate.crt
[client]$
  4. Repeat the steps 1 up to 3 for all other services.
  5. Create new certificates from the newly created CSR and follow the "Generating Certificate Signing Request (CSR)" procedure from step 9 in the Oracle Communications Network Analytics Data Director Installation, Upgrade, and Fault Recovery Guide.
  6. Run the following commands to perform rollout restart of all OCNADD services:
    kubectl rollout restart -n <ocnadd-deploy> deployment

    Where <ocnadd-deploy> is the namespace where OCNADD, OCNADD management group services or OCNADD worker group services is/are deployed.

Certificate is Generated Using OCCM

OCCM monitors the certificate validity and initiates automatic certificate renewal based on the renew before period configuration.

Update the renewBefore (Days) parameter in the custom_values.yaml file to specify the desired number of days before the certificate expiration when renewal should occur. Refer to the Oracle Communications Certificate Management guide to determine the certificate expiration period. After updating the parameter and renewing the certificates, restart the deployments and statefulsets for both the management group and worker group using the following commands: 


kubectl rollout restart -n <ocnadd-deploy> deployment
kubectl rollout restart -n <ocnadd-deploy> statefulset

4.1.7 Signing OCI Container Registry Images for Security

To meet security requirements, images can be signed and stored in Oracle Cloud Infrastructure Registry (also known as Container Registry).

Signed images provide a way to verify both the source of an image and its integrity.

Signing an image requires an Encryption Key.

The Encryption Key can be created as follows:

  1. Log in to the OCI Console.
  2. Click the Hamburger menu and select Identity and Security.
  3. Under Identity and Security, select Vault.
  4. Click the Create Vault button.
  5. Enter the name of the vault to be kept.
  6. Click the Create Vault button.
  7. After some time, the vault is created.
  8. Click the newly created vault.
  9. Click Master Key Encryption.
  10. Click Create Key:
    1. Select Protection Mode as Software.
    2. Enter the name of the key to be kept.
    3. Select Key Shape Algorithm as RSA and KeyShape Length as 2048.
    4. Click Create Key.

To sign the image pushed into Container Registry using the master key and key version in the Vault service:

  1. Open the Developer Tool and click Cloud Shell.
  2. Run the following command to sign the image:
    oci artifacts container image-signature sign-upload --compartment-id <compartment-ocid> --kms-key-id <key-ocid> --kms-key-version-id <key-version-ocid> --signing-algorithm <signing-algorithm> --image-id <image-ocid> --description <signature-description> --metadata <image-metadata-json>

    Where,

    • --compartment-id <compartment-ocid>: Copy from compartment OCID from Identity >> Compartments >> <YOUR COMPARTMENT> >> OCID Copy.
    • --kms-key-id <key-ocid>: Copy the Version of key from Key Management & Secret Management >> Vaults >> <VAULT_NAME> >> KeyDetails >> OCID Copy.
    • --kms-key-version-id <key-version-ocid>: Copy the Version of key from Key Management & Secret Management >> Vaults >> <VAULT_NAME> >> KeyDetails >> Key Version Copy.
    • --signing-algorithm <signing-algorithm>: Any one of the following: SHA_224_RSA_PKCS_PSS, SHA_256_RSA_PKCS_PSS, SHA_384_RSA_PKCS_PSS, SHA_512_RSA_PKCS_PSS.
    • --image-id <image-ocid>: Copy image OCID from Container Registry >> <IMAGE_NAME> >> <VERSION> >> OCID Copy.
    • <Optional>--description <signature-description>: Description of the signature.
    • <Optional>--metadata <image-metadata-json>: JSON file that contains metadata of the image.

To verify if the image is signed:

  1. Open the navigation menu and click Developer Services.
  2. Under Containers & Artifacts, click Container Registry.
  3. Select the region that contains the repository.
  4. Select the compartment that contains the repository.

    The Repositories and images field lists the repositories in the selected region and compartment to which you have access.

  5. Click the plus (+) button beside the name of a repository containing signed images.

    Below the name of the repository, the images in the repository are listed that can be identified by the version identifier of each image.

    The text "(Signed)" appears beside images that have been signed.

4.1.8 Cleaning Up Sensitive Information After Installation

The Helm chart contains critical information, which is required only during installation. Hence, take backup of Helm chart and remove it from bastion server after deployment.

4.1.9 Druid User Management

By default, Apache Druid has two users: admin and druid_system. The druid_system user is used internally by Druid services to communicate with each other. For OCNADD, a user with fewer privileges is sufficient.

The steps to create a new user for OCNADD and assign the required permissions using the REST endpoints exposed by Druid are described below.

Create OCNADD user

Run the following commands to create the Druid authentication and authorization user for OCNADD:
$ curl -k --request POST 'https://<10.10.10.10>:9088/proxy/coordinator/druid-ext/basic-security/authentication/db/db/users/<ocnadd>' -u 'admin:<druid_admin_pwd>'
 
$ curl -k --request POST 'https://<10.10.10.10>:9088/proxy/coordinator/druid-ext/basic-security/authentication/db/db/users/<ocnadd>/credentials' -u 'admin:<druid_admin_pwd>' --header 'Content-Type: application/json' --data-raw '{"password":"<druid_ocnadd_pwd>"}'
 
$ curl -k --request POST 'https://<10.10.10.10>:9088/proxy/coordinator/druid-ext/basic-security/authorization/db/db/users/<ocnadd_user>' -u 'admin:<druid_admin_pwd>'

Where,

  • <10.10.10.10> is the IP of the druid-router service.
  • <druid_admin_pwd> is the password for Druid user with admin privilleges
  • <ocnadd_user> is the user created for OCNADD in Druid
  • <druid_ocnadd_pwd> is the password for OCNADD user

Create OCNADD Role, Add Permissions and Add User to Role

Run the following command to create a role in Druid for OCNADD, add the required permissions and then add user to that role:
$ curl -k --request POST 'https://<10.10.10.10>:9088/proxy/coordinator/druid-ext/basic-security/authorization/db/db/roles/<ocnadd_role>' -u 'admin:<druid_admin_pwd>'
 
$ curl -k --request POST 'https://<10.10.10.10>:9088/proxy/coordinator/druid-ext/basic-security/authorization/db/db/roles/<ocnadd_role>/permissions' -u 'admin:<druid_admin_pwd>' --header 'Content-Type: application/json' --data '[{"resource":{"name":".*","type":"DATASOURCE"},"action":"READ"},{"resource":{"name":".*","type":"DATASOURCE"},"action":"WRITE"},{"resource":{"name":"CONFIG","type":"CONFIG"},"action":"WRITE"},{"resource":{"name":"CONFIG","type":"CONFIG"},"action":"READ"}]'
 
$ curl -k --request POST https://<10.10.10.10>:9088/proxy/coordinator/druid-ext/basic-security/authorization/db/db/users/<ocnadd_user>/roles/<ocnadd_role> -u 'admin:<druid_admin_pwd>'

Where,

  • <10.10.10.10> is the CNLB or LoadBalancer IP of the druid-ocnadd-router service.

  • <druid_admin_pwd> is the password for 'admin' user
  • <ocnadd_user> is the user created for OCNADD in Druid
  • <ocnadd_user> is the role created for OCNADD in Druid