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 communication, the customers can also opt to use TLS for internal OCNADD communication. To enable internal TLS, follow the steps below:

  • Enable internal TLS in Helm Charts.

    • Change the value of global.ssl.intraTlsEnabled to true in the ocnadd-custom-values-23.3.0.yaml. It is set to false 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 http.
      
DD_CONFIG_API: http://ocnaddconfiguration:12590
DD_ALARM_API: http://ocnaddalarm:9099
DD_HEALTH_API: http://ocnaddhealthmonitoring:12591
  • Create TLS certificates for all the internal services.
    • If the generate_certs script is used to create the certificates, add entries for internal services in the ssl_certs/default_values/values file. For more information see, Certificate and Secret Generation.
    • If the following entries are not present in the values file, add them:

      In following example, ocnadd-deploy is the namespace where OCNADD is deployed and occne-ocdd represents the Kubernetes domain name. 

      [ocnadduirouter]
client.commonName=ocnadduirouter-client
server.commonName=ocnadduirouter
DNS.1=*.ocnadduirouter.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnadduirouter
 
[ocnaddadminservice]
client.commonName=ocnaddadminservice-client
server.commonName=ocnaddadminservice
DNS.1=*.ocnaddadminservice.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddadminservice
 
[ocnaddalarm]
client.commonName=ocnaddalarm-client
server.commonName=ocnaddalarm
DNS.1=*.ocnaddalarm.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddalarm
 
[ocnaddconfiguration]
client.commonName=ocnaddconfiguration-client
server.commonName=ocnaddconfiguration
DNS.1=*.ocnaddconfiguration.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddconfiguration
 
[ocnaddcache]
client.commonName=ocnaddcache-client
server.commonName=ocnaddcache
DNS.1=*.ocnaddcache.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddcache
 
[ocnaddhealthmonitoring]
client.commonName=ocnaddhealthmonitoring-client
server.commonName=ocnaddhealthmonitoring
DNS.1=*.ocnaddhealthmonitoring.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddhealthmonitoring
 
[ocnaddscpaggregation]
client.commonName=ocnaddscpaggregation-client
server.commonName=ocnaddscpaggregation
DNS.1=*.ocnaddscpaggregation.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddscpaggregation
 
[ocnaddnrfaggregation]
client.commonName=ocnaddnrfaggregation-client
server.commonName=ocnaddnrfaggregation
DNS.1=*.ocnaddnrfaggregation.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddnrfaggregation
 
[ocnaddseppaggregation]
client.commonName=ocnaddseppaggregation-client
server.commonName=ocnaddseppaggregation
DNS.1=*.ocnaddseppaggregation.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddseppaggregation
  
[ocnaddcorrelation]
client.commonName=ocnaddcorrelation-client
server.commonName=ocnaddcorrelation
DNS.1=*.ocnaddcorrelation.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddcorrelation
 
[ocnaddfilter]
client.commonName=ocnaddfilter-client
server.commonName=ocnaddfilter
DNS.1=*.ocnaddfilter.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddfilter

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 unsecure 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. For more information, refer to the Oracle Communications Network Analytics Data Director Installation, Upgrade, and Fault Recovery Guide.

The generated service certificates are stored as the K8s 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 when not using internal TLS. This reduces 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

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=365
 
##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
 
[zookeeper]
client.commonName=zookeeper-zk
server.commonName=zookeeper
DNS.1=*.zookeeper.ocnadd-deploy.svc.occne-ocdd
DNS.2=zookeeper
 
[adapter]
client.commonName=adapter
server.commonName=adapter-server
DNS.1=*adapter.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddconsumeradapter
 
##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=365
 
##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.ocnadd-deploy.svc.occne-ocdd
DNS.3=kafka-broker
DNS.4=*.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
 
[zookeeper]
client.commonName=zookeeper-zk
server.commonName=zookeeper
DNS.1=*.zookeeper.ocnadd-deploy.svc.occne-ocdd
DNS.2=zookeeper
 
[ocnadduirouter]
client.commonName=ocnadduirouter-client
server.commonName=ocnadduirouter
DNS.1=*.ocnadduirouter.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnadduirouter
 
[ocnaddadminservice]
client.commonName=ocnaddadminservice-client
server.commonName=ocnaddadminservice
DNS.1=*.ocnaddadminservice.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddadminservice
 
[ocnaddalarm]
client.commonName=ocnaddalarm-client
server.commonName=ocnaddalarm
DNS.1=*.ocnaddalarm.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddalarm
 
[ocnaddconfiguration]
client.commonName=ocnaddconfiguration-client
server.commonName=ocnaddconfiguration
DNS.1=*.ocnaddconfiguration.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddconfiguration
 
[ocnaddhealthmonitoring]
client.commonName=ocnaddhealthmonitoring-client
server.commonName=ocnaddhealthmonitoring
DNS.1=*.ocnaddhealthmonitoring.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddhealthmonitoring
 
[ocnaddscpaggregation]
client.commonName=ocnaddscpaggregation-client
server.commonName=ocnaddscpaggregation
DNS.1=*.ocnaddscpaggregation.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddscpaggregation
 
[ocnaddnrfaggregation]
client.commonName=ocnaddnrfaggregation-client
server.commonName=ocnaddnrfaggregation
DNS.1=*.ocnaddnrfaggregation.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddnrfaggregation
 
[ocnaddseppaggregation]
client.commonName=ocnaddseppaggregation-client
server.commonName=ocnaddseppaggregation
DNS.1=*.ocnaddseppaggregation.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddseppaggregation
 
[adapter]
client.commonName=adapter
server.commonName=adapter-server
DNS.1=*adapter.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddconsumeradapter
 
[ocnaddcache]
client.commonName=ocnaddcache-client
server.commonName=ocnaddcache-server
DNS.1=*ocnaddcache.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddcache
DNS.3=ocnaddcache-wka
DNS.4=ocnaddcache-wka.ocnadd-deploy.svc.occne-ocdd
 
[ocnaddcorrelation]
client.commonName=ocnaddcorrelation-client
server.commonName=ocnaddcorrelation
DNS.1=*.ocnaddcorrelation.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddcorrelation
 
[ocnaddfilter]
client.commonName=ocnaddfilter-client
server.commonName=ocnaddfilter
DNS.1=*.ocnaddfilter.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddfilter
 
##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. 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=365
 
##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.ocnadd-deploy.svc.occne-ocdd
DNS.3=kafka-broker
DNS.4=*.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
 
[zookeeper]
client.commonName=zookeeper-zk
server.commonName=zookeeper
DNS.1=*.zookeeper.ocnadd-deploy.svc.occne-ocdd
DNS.2=zookeeper
 
[ocnadduirouter]
client.commonName=ocnadduirouter-client
server.commonName=ocnadduirouter
DNS.1=*.ocnadduirouter.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnadduirouter
 
[ocnaddadminservice]
client.commonName=ocnaddadminservice-client
server.commonName=ocnaddadminservice
DNS.1=*.ocnaddadminservice.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddadminservice
 
[ocnaddalarm]
client.commonName=ocnaddalarm-client
server.commonName=ocnaddalarm
DNS.1=*.ocnaddalarm.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddalarm
 
[ocnaddconfiguration]
client.commonName=ocnaddconfiguration-client
server.commonName=ocnaddconfiguration
DNS.1=*.ocnaddconfiguration.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddconfiguration
 
[ocnaddhealthmonitoring]
client.commonName=ocnaddhealthmonitoring-client
server.commonName=ocnaddhealthmonitoring
DNS.1=*.ocnaddhealthmonitoring.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddhealthmonitoring
 
[ocnaddscpaggregation]
client.commonName=ocnaddscpaggregation-client
server.commonName=ocnaddscpaggregation
DNS.1=*.ocnaddscpaggregation.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddscpaggregation
 
[ocnaddnrfaggregation]
client.commonName=ocnaddnrfaggregation-client
server.commonName=ocnaddnrfaggregation
DNS.1=*.ocnaddnrfaggregation.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddnrfaggregation
 
[ocnaddseppaggregation]
client.commonName=ocnaddseppaggregation-client
server.commonName=ocnaddseppaggregation
DNS.1=*.ocnaddseppaggregation.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddseppaggregation
 
[ocnaddcache]
client.commonName=ocnaddcache-client
server.commonName=ocnaddcache-server
DNS.1=*ocnaddcache.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddcache
DNS.3=ocnaddcache-wka
DNS.4=ocnaddcache-wka.ocnadd-deploy.svc.occne-ocdd
 
[ocnaddcorrelation]
client.commonName=ocnaddcorrelation-client
server.commonName=ocnaddcorrelation
DNS.1=*.ocnaddcorrelation.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddcorrelation
 
[ocnaddfilter]
client.commonName=ocnaddfilter-client
server.commonName=ocnaddfilter
DNS.1=*.ocnaddfilter.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddfilter
 
##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 ssl.client-auth to "required" in <chart-path>/charts/ocnaddkafka/template/scripts-config.yaml 

    ssl.client.auth=required
  • The certificate creation step remains the same as mentioned in the "TLS Configuration" section.

    Note:

    • It is mandatory 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.

Listed below are some sample scenarios where file modifications are required:

Subject Alternative Name (SAN) Requirement for Client Certificate Signing Request (CSR)

When external Certificate Authorities (CAs) are used to issue certificates based on the CSR generated by the generate_certs.sh script, the CA may require that the CSR contains Subject Alternative Name (SAN) in addition to Common Name (CN). SAN is added in the Server CSR but omitted in the Client CSR.

To add SAN extension for client CSR, append the following text at the bottom of ssl_certs/templates/services_client_openssl.cnf:
[ req_ext ]
 
# Extensions to add to a certificate request
 
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
 
subjectAltName = @alt_names # Add this for SAN support
 
[ alt_names ]
Modify the [ req ] section in ssl_certs/templates/services_client_openssl.cnf 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

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 file. For example, if you need to add a load balancer IP for Kafka-brokers, modify the default_values/values section as follows:
    [kafka-broker]
client.commonName=kafka-broker-zk
server.commonName=kafka-broker
DNS.1=*.kafka-broker.dd-adc.svc.cluster.local
DNS.2=kafka-broker
DNS.3=*.kafka-broker
IP.1=10.156.123.64
  • Delete the demoCA folder inside the ssl_certs directory. If the CA certificate and CA key were located inside the demoCA folder, remove them before deleting the folder:
    $ ls
default_values  demoCA  generate_certs.sh  generate_secrets.sh  logs  template
$ rm -rf demoCA/
$ ls
cacert.pem  cakey.pem  default_values  generate_certs.sh  generate_secrets.sh  logs  template
  • To create certificates or CSR, follow the steps provided in "Configuring SSL or TLS Certificates" section of Oracle Communications Network Analytics Data Director Installation, Upgrade, and Fault Recovery Guide.

4.1.2 Network Policy

The OCNADD is also shipped with Network Policies for ingress connections which are disabled by default.

The Network Policies can be categorized into three categories:

  • Internal Service Connections: The service connections that are internal to the OCNADD namespace. 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.
    network:
    # enable network policies
    policy:
      enable: true
  • External Service Connections: The service connections that are connecting to the OCNADD namespace. The policy gets applied on connections from OCCNCC, OCSCP, OCNRF and so on which are deployed outside the OCNADD namespace. To allow connections from specific namespaces (when network policies are enabled), add the namespace to the namespaces list in global.network.policy.ingress.namespaces of ocnadd-custom-values.yaml file as below:
    # allow ingress network connections from below namespaces
namespaces:
  - occne-infra
  - occncc

    In the above example, the connections from all pods of occne-infra (prometheus, grafana, etc.) and occncc namespace are allowed. Similarly add the SCP, and NRF namespace to this list.

  • External Service Connection from specific IP address: This can be enabled (disabled by default) to allow connections from specific IP address ranges when Network Policy is enabled. In the below example, the connections from the 10.0.0.0/8 subnet are allowed. In other words, all connections from IP address 10.0.0.0 - 10.255.255.255 are allowed.
    
# to allow external connections from postman, curl, etc.
# only needed for development/debugging purposes
external:  
   enable:true
   cidrs:  
     - 10.0.0.0/8

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. 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=365
 
kafka-broker
zookeeper
ocnaddthirdpartyconsumer
oralcenfproducer
ocnadduirouter
ocnaddadminservice
ocnaddalarm
ocnaddconfiguration
ocnaddhealthmonitoring
ocnaddscpaggregation
ocnaddnrfaggregation
ocnaddsepaggreagation
adapter
ocnaddcache
ocnaddcorrelation
ocnaddfilter
  2. To generate the certificate, run the following command:
    ./generate_certs.sh -cacert <path to>/cacert.pem -cakey <path to>/cakey.pem --renew
  3. Provide the password to your CA key at the "Enter passphrase for CA Key file:" prompt.
  4. Old certificates are revoked, and new certificates are created.
  5. At the prompt "Would you like to choose any above namespace for creating secrets (y/n)", enter "y".
  6. At the prompt "Enter Kubernetes Namespace: ", enter the OCNADD namespace. Secrets containing the certificates are replaced.
  7. Enter the OCNADD namespace at the prompt "Enter namespace: ", a rolling restart of all the OCNADD services is triggered.
  8. Wait for the rollout restart completion and for all pods to return to the "Running" state.

Only CSR is Generated

If only the CSR is generated:

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

    The following example displays how to navigate to client folder of the adapter service:

    [ssl_certs]$ ls
default_values  demoCA  generate_certs.sh  generate_secrets.sh  logs  template
[ssl_certs]$ cd demoCA/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
    kubectl rollout restart -n <ocnadd-deploy> statefulset
    Where, <ocnadd-deploy> is the namespace where OCNADD is deployed.

Only Secrets are Generated

If only the secrets are generated:

  1. Generate new certificates and follow step 3 of the "Generate Certificate and Private Keys" procedure in the Oracle Communications Network Analytics Data Director Installation, Upgrade, and Fault Recovery Guide to recreate the secrets.
  2. Run the following commands to perform rollout restart of all OCNADD services:
    kubectl rollout restart -n <ocnadd-deploy> deployment
    kubectl rollout restart -n <ocnadd-deploy> statefulset
    Where, <ocnadd-deploy> is the namespace where OCNADD is deployed.