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. See Certificate and Secret Generation for more information about certificate creation.

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

In addition to the above communications, TLS is also used for internal OCNADD communication by default. 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/false in the ocnadd-custom-values-23.3.0.yaml. It is set to true by default.
      
ssl:
    intraTlsEnabled:true
    • Replace http with https in the following fields of ocnadduirouter.ocnadduirouter.env in ocnadd-custom-values-23.3.0.yaml, by default they will be set to https.
      DD_CONFIG_API: http://ocnaddconfiguration:12590
DD_ALARM_API: http://ocnaddalarm:9099
DD_HEALTH_API: http://ocnaddhealthmonitoring:12591
DD_ADMIN_API: https://ocnaddadminservice:9181
  • Create TLS certificates for all the internal services.
    • If the generate_certs script is used to create the certificates, add/modify entries for internal services in the ssl_certs/default_values/values file or in the ssl_certs/default_values/management_service_value and ssl_certs/default_values/worker_group_service_values file in case of centralized deployment. For details on how to add entries for service certificates see, Certificate and Secret Generation.
  • Upgrade OCNADD deployment/s to enable/disable TLS for internal communications
    • If centralized deployment model is used:
      • First, upgrade management group deployment:
        helm upgrade -n <management-namespace> -f <managment-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:
        helm upgrade -n <worker-group-namespace> -f <worker-group-custom-values> <worker-group-release-name> <release-chart>

        For example:

        helm upgrade -n ocnadd-deploy-wg1 -f ocnadd-custom-values-wg.yaml ocnadd-wg ocnadd
      • Update the global.env.admin.OCNADD_UPGRADE_WG_NS in management custom values YAML file with comma separated worker group namespaces:
        global.env.admin.OCNADD_UPGRADE_WG_NS=ocnadd-deploy-wg1,ocnadd-deploy-wg2          # Update in ocnadd-custom-values-mgmt.yaml
      • Upgrade management group charts again with --set global.env.admin.OCNADD_ADAPTER_UPGRADE_ENABLE=true 
        helm upgrade -n <management-namespace> -f <managment-custom-values> <management-release-name> <release-chart> --set global.env.admin.OCNADD_ADAPTER_UPGRADE_ENABLE=true

        For example:

        helm upgrade -n ocnadd-deploy-mgmt -f ocnadd-custom-values-mgmt.yaml ocnadd-mgmt ocnadd --set global.env.admin.OCNADD_ADAPTER_UPGRADE_ENABLE=true
    • If Non-Centralized deployment model is used:
      • Run helm upgrade for release chart with --set global.env.admin.OCNADD_ADAPTER_UPGRADE_ENABLE=true
        helm upgrade -n <release-namespace> -f <custom-values> <release-name> <release-chart> --set global.env.admin.OCNADD_ADAPTER_UPGRADE_ENABLE=true

        helm upgrade -n ocnadd-deploy -f ocnadd-custom-values.yaml ocnadd ocnadd --set global.env.admin.OCNADD_ADAPTER_UPGRADE_ENABLE=true

Note:

External Kafka feed with filter and correlation feature can not be used without enabling intternal TLS.

Certificate and Secret Generation

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.

Note:

The default certification creation assumes that internal TLS is enabled and creates the certificates for all the OCNADD services. The customers can choose to delete surplus entries from ssl_certs/default_values/values file or from ssl_certs/default_values/management_service_value and ssl_certs/default_values/worker_group_service_values file in case of centralized deployment, when not using internal TLS. This will reduce the number of certificates to be signed by the CA.

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

For Non-Centralized Deployment

Without Internal TLS

# 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
 
[zookeeper]
client.commonName=zookeeper-zk
server.commonName=zookeeper
DNS.1=*.zookeeper.ocnadd-deploy.svc.occne-ocdd
DNS.2=zookeeper
DNS.3=zookeeper.ocnadd-deploy
 
[adapter]
client.commonName=adapter
server.commonName=adapter-server
DNS.1=*adapter.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddconsumeradapter
DNS.3=ocnaddconsumeradapter.ocnadd-deploy
 
[ocnaddbackuprestore]
client.commonName=ocnaddbackuprestore
server.commonName=ocnaddbackuprestore-server
DNS.1=ocnaddbackuprestore
 
##end

With Internal TLS

# 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
 
[zookeeper]
client.commonName=zookeeper-zk
server.commonName=zookeeper
DNS.1=*.zookeeper.ocnadd-deploy.svc.occne-ocdd
DNS.2=zookeeper
DNS.3=zookeeper.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
 
[ocnaddseppaggregation]
client.commonName=ocnaddseppaggregation-client
server.commonName=ocnaddseppaggregation
DNS.1=*.ocnaddseppaggregation.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddseppaggregation
DNS.3=ocnaddseppaggregation.ocnadd-deploy
 
[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  
 
##end

Note:

  • External Kafka Feed support is possible only when internal TLS is enabled
  • Customer can delete the adapter section from the ssl_certs/default_values/values file when only External Kafka Feed is required now and in future. The resulting file is given below
    # 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=*.ocnadd-deploy.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
 
[zookeeper]
client.commonName=zookeeper-zk
server.commonName=zookeeper
DNS.1=*.zookeeper.ocnadd-deploy.svc.occne-ocdd
DNS.2=zookeeper
DNS.3=zookeeper.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
 
[ocnaddseppaggregation]
client.commonName=ocnaddseppaggregation-client
server.commonName=ocnaddseppaggregation
DNS.1=*.ocnaddseppaggregation.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddseppaggregation
DNS.3=ocnaddseppaggregation.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
 
##end

For Centralized Deployment

Without Internal TLS

  • ssl_certs/default_values/management_service_values or its copies should be 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
 
##end
  • ssl_certs/default_values/worker_group_service_values or its copies should be 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
 
[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
 
[zookeeper]
client.commonName=zookeeper-zk
server.commonName=zookeeper
DNS.1=*.zookeeper.ocnadd-deploy.svc.occne-ocdd
DNS.2=zookeeper
DNS.3=zookeeper.ocnadd-deploy
 
[adapter]
client.commonName=adapter
server.commonName=adapter-server
DNS.1=*adapter.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddconsumeradapter
DNS.3=ocnaddconsumeradapter.ocnadd-deploy
 
##end

With Internal TLS

  • ssl_certs/default_values/management_service_values or its copies should be 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
 
[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
 
[ocnaddbackuprestore]
client.commonName=ocnaddbackuprestore
server.commonName=ocnaddbackuprestore-server
DNS.1=ocnaddbackuprestore
 
##end
  • ssl_certs/default_values/worker_group_service_values or its copies should be 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
 
[zookeeper]
client.commonName=zookeeper-zk
server.commonName=zookeeper
DNS.1=*.zookeeper.ocnadd-deploy.svc.occne-ocdd
DNS.2=zookeeper
DNS.3=zookeeper.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
 
[ocnaddseppaggregation]
client.commonName=ocnaddseppaggregation-client
server.commonName=ocnaddseppaggregation
DNS.1=*.ocnaddseppaggregation.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddseppaggregation
DNS.3=ocnaddseppaggregation.ocnadd-deploy
 
[adapter]
client.commonName=adapter
server.commonName=adapter-server
DNS.1=*adapter.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddconsumeradapter
DNS.3=ocnaddconsumeradapter.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
 
[ocnaddcorrelation]
client.commonName=ocnaddcorrelation-client
server.commonName=ocnaddcorrelation
DNS.1=*.ocnaddcorrelation.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddcorrelation
DNS.3=ocnaddcorrelation.ocnadd-deploy
 
##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-23.3.0.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-23.3.0.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.

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

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.

Adding or Updating SAN Entries

When you need to update or add Subject Alternative Name (SAN) entries to certificates, and certificates are generated using CACert and CAKey, or only Certificate Signing Requests (CSR) are generated using the generate_certs.sh script, follow these steps:

  • Update the relevant service section in the ssl_certs/default_values/values, ssl_certs/default_values/management_service_values or ssl_certs/default_values/worker_group_service_values file.

    For example, if loadbalancer IP needs to be added for kafka-brokers modify ssl_certs/default_values/values or ssl_certs/default_values/worker_group_service_values file as follows: 

    [kafka-broker]
client.commonName=kafka-broker-zk
server.commonName=kafka-broker
DNS.1=*.kafka-broker.ocnadd-deploy.svc.occne-ocnadd
DNS.2=kafka-broker
DNS.3=*.kafka-broker
IP.1=10.156.123.64
  • Follow steps mentioned in section Renewing OCNADD Certificates to renew/recreate the certificates with the modified SAN entries

4.1.2 Network Policy

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 desired, or if connections from specific IP/network are desired, update the value in global.network.ingress.external.enable to true. Then, add the desired IP/Network address in CIDR format in global.network.ingress.external.cidrs 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:
              - 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

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 and Upgrade 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.

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
zookeeper
ocnadduirouter
ocnaddadminservice
ocnaddalarm
ocnaddconfiguration
ocnaddhealthmonitoring
ocnaddscpaggregation
ocnaddnrfaggregation
ocnaddsepaggreagation
adapter
ocnaddcorrelation
ocnaddfilter
ocnaddbackuprestore
  2. Run ./generate_certs.sh -cacert <path to>/cacert.pem -cakey <path to>/cakey.pem --renew
  3. Choose mode of deployment when prompted Select the mode of deployment.
  4. Choose 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 woker 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 "Generate Certificate Signing Request (CSR)" procedure from step 5 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.