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. Refer to the next section for more info about certificate creation.

DF4: Consumer NF communication can be configured to use clear text or TLS through the GUI. Refer to the GUI guide for more info on how to do so.

Internal TLS Communication

In addition to the above communications, the customers can also opt to use TLS for internal OCNADD communication. To enable internal TLS, the following steps need to be undertaken:

Enable internal TLS in Helm Charts.

Change the value of global.ssl.intraTlsEnabled to true in the ocnadd-custom-values.yaml. By default it is set to false.


ssl:
    intraTlsEnabled:true

Make Sure to Remove the below line in ocnadd-custom-values.yaml:


Remove ocnaddadminsvc.ocnadd.admin.env.OCNADD_ADAPTER_SERVER_SSL: false (Before helm install or upgrade) Line:273
Remove ocnaddbackendrouter.ocnaddbackendrouter.env.OCNADD_BKNROUTER_CLIENT_SSL_USE_TS: true (Before helm upgrade) Line: 313

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. Refer to the "Certificate and Secret Generation" section for more details.

The following entries should be added to the values file, if not present:

[zookeeper]
client.commonName=zookeeper-zk
server.commonName=zookeeper
DNS.1=*.zookeeper.ocnadd-deploy.svc.occne-ocdd
DNS.2=zookeeper

[ocnaddbackendrouter]
client.commonName=ocnaddbackendrouter-client
server.commonName=ocnaddbackendrouter
DNS.1=*.ocnaddbackendrouter.ocnadd-deploy.svc.occne-ocdd
DNS.2=ocnaddbackendrouter

[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

where, ocnadd-deploy is the namespace where OCNADD is deployed and occne-ocdd is the Kubernetes cluster name.

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. 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.The Certificates for the NF producer and OCNADD Consumer can also be created separately, but it is essential that

The NF producer includes OCNADD's CA certificate in their trust store.
The third-party consumer certificate is also created by using the same OCNADD's CA.

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 Cluster name
[ocnaddthirdpartyconsumer] : is the OCNADD consumer
[oraclenfproducer] : is the Oracle 5G NF/producer

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.20.30.40
#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-ocnadd
 
[kafka-broker1]
client.commonName=kafka-broker1-zk
server.commonName=kafka-broker1
DNS.1=*.kafka-broker1.ocnadd-deploy.svc.occne-ocnadd
DNS.2=kafka-broker1
 
[kafka-broker2]
client.commonName=kafka-broker2-zk
server.commonName=kafka-broker2
DNS.1=*.kafka-broker2.ocnadd-deploy.svc.occne-ocnadd
DNS.2=kafka-broker2
 
[kafka-broker3]
client.commonName=kafka-broker3-zk
server.commonName=kafka-broker3
DNS.1=*.kafka-broker3.ocnadd-deploy.svc.occne-ocnadd
DNS.2=kafka-broker3
 
[kafka-broker4]
client.commonName=kafka-broker4-zk
server.commonName=kafka-broker4
DNS.1=*.kafka-broker4.ocnadd-deploy.svc.occne-ocnadd
DNS.2=kafka-broker4
 
[kafka-broker5]
client.commonName=kafka-broker5-zk
server.commonName=kafka-broker5
DNS.1=*.kafka-broker5.ocnadd-deploy.svc.occne-ocnadd
DNS.2=kafka-broker5
 
[kafka-broker6]
client.commonName=kafka-broker6-zk
server.commonName=kafka-broker6
DNS.1=*.kafka-broker6.ocnadd-deploy.svc.occne-ocnadd
DNS.2=kafka-broker6
 
[kafka-broker7]
client.commonName=kafka-broker7-zk
server.commonName=kafka-broker7
DNS.1=*.kafka-broker7.ocnadd-deploy.svc.occne-ocnadd
DNS.2=kafka-broker7
 
[egw]
client.commonName=egw-client
server.commonName=egw
DNS.1=*egw.ocnadd-deploy.svc.occne-ocnadd
DNS.2=ocnaddegressgateway
 
[ocnaddthirdpartyconsumer]
server.commonName=ocnaddthirdpartyconsumer
DNS.1=*.ocnaddthirdpartyconsumer.ocnadd-deploy.svc.occne-ocnadd
DNS.2=ocnaddthirdpartyconsumer
 
[oraclenfproducer]
client.commonName=oraclenfproducer
DNS.1=*.oraclenfproducer.ocnadd-deploy.svc.occne-ocnadd
DNS.2=oraclenfproducer
 
##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.20.30.40
#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-ocnadd
 
[kafka-broker1]
client.commonName=kafka-broker1-zk
server.commonName=kafka-broker1
DNS.1=*.kafka-broker1.ocnadd-deploy.svc.occne-ocnadd
DNS.2=kafka-broker1
 
[kafka-broker2]
client.commonName=kafka-broker2-zk
server.commonName=kafka-broker2
DNS.1=*.kafka-broker2.ocnadd-deploy.svc.occne-ocnadd
DNS.2=kafka-broker2
 
[kafka-broker3]
client.commonName=kafka-broker3-zk
server.commonName=kafka-broker3
DNS.1=*.kafka-broker3.ocnadd-deploy.svc.occne-ocnadd
DNS.2=kafka-broker3
 
[kafka-broker4]
client.commonName=kafka-broker4-zk
server.commonName=kafka-broker4
DNS.1=*.kafka-broker4.ocnadd-deploy.svc.occne-ocnadd
DNS.2=kafka-broker4
 
[kafka-broker5]
client.commonName=kafka-broker5-zk
server.commonName=kafka-broker5
DNS.1=*.kafka-broker5.ocnadd-deploy.svc.occne-ocnadd
DNS.2=kafka-broker5
 
[kafka-broker6]
client.commonName=kafka-broker6-zk
server.commonName=kafka-broker6
DNS.1=*.kafka-broker6.ocnadd-deploy.svc.occne-ocnadd
DNS.2=kafka-broker6
 
[kafka-broker7]
client.commonName=kafka-broker7-zk
server.commonName=kafka-broker7
DNS.1=*.kafka-broker7.ocnadd-deploy.svc.occne-ocnadd
DNS.2=kafka-broker7
 
[zookeeper]
client.commonName=zookeeper-zk
server.commonName=zookeeper
DNS.1=*.zookeeper.ocnadd-deploy.svc.occne-ocnadd
DNS.2=zookeeper
 
[egw]
client.commonName=egw-client
server.commonName=egw
DNS.1=*egw.ocnadd-deploy.svc.occne-ocnadd
DNS.2=ocnaddegressgateway
 
[ocnaddthirdpartyconsumer]
client.commonName=ocnaddthirdpartyconsumer-client
server.commonName=ocnaddthirdpartyconsumer
DNS.1=*.ocnaddthirdpartyconsumer.ocnadd-deploy.svc.occne-ocnadd
DNS.2=ocnaddthirdpartyconsumer
 
[oraclenfproducer]
client.commonName=oraclenfproducer
server.commonName=oraclenfproducer-server
DNS.1=*.oraclenfproducer.ocnadd-deploy.svc.occne-ocnadd
DNS.2=oraclenfproducer
 
[ocnaddbackendrouter]
client.commonName=ocnaddbackendrouter-client
server.commonName=ocnaddbackendrouter
DNS.1=*.ocnaddbackendrouter.ocnadd-deploy.svc.occne-ocnadd
DNS.2=ocnaddbackendrouter
 
[ocnaddadminservice]
client.commonName=ocnaddadminservice-client
server.commonName=ocnaddadminservice
DNS.1=*.ocnaddadminservice.ocnadd-deploy.svc.occne-ocnadd
DNS.2=ocnaddadminservice
 
[ocnaddalarm]
client.commonName=ocnaddalarm-client
server.commonName=ocnaddalarm
DNS.1=*.ocnaddalarm.ocnadd-deploy.svc.occne-ocnadd
DNS.2=ocnaddalarm
 
[ocnaddconfiguration]
client.commonName=ocnaddconfiguration-client
server.commonName=ocnaddconfiguration
DNS.1=*.ocnaddconfiguration.ocnadd-deploy.svc.occne-ocnadd
DNS.2=ocnaddconfiguration
 
[ocnaddhealthmonitoring]
client.commonName=ocnaddhealthmonitoring-client
server.commonName=ocnaddhealthmonitoring
DNS.1=*.ocnaddhealthmonitoring.ocnadd-deploy.svc.occne-ocnadd
DNS.2=ocnaddhealthmonitoring
 
[ocnaddfilter]
client.commonName=ocnaddfilter-client
server.commonName=ocnaddfilter
DNS.1=*.ocnaddfilter.ocnadd-deploy.svc.occne-ocnadd
DNS.2=ocnaddfilter
 
[ocnaddscpaggregation]
client.commonName=ocnaddscpaggregation-client
server.commonName=ocnaddscpaggregation
DNS.1=*.ocnaddscpaggregation.ocnadd-deploy.svc.occne-ocnadd
DNS.2=ocnaddscpaggregation
 
[ocnaddnrfaggregation]
client.commonName=ocnaddnrfaggregation-client
server.commonName=ocnaddnrfaggregation
DNS.1=*.ocnaddnrfaggregation.ocnadd-deploy.svc.occne-ocnadd
DNS.2=ocnaddnrfaggregation
 
[adapter]
client.commonName=adapter
server.commonName=adapter-server
DNS.1=*adapter.ocnadd-deploy.svc.occne-ocnadd
DNS.2=ocnaddconsumeradapter
 
##end

MTLS Configuration

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

Enable internal MTLS in Helm Charts.

Change the value of global.ssl.mTLS to true in the ocnadd-custom-values.yaml. By default it is set to false.

ssl:    
    intraTlsEnabled: true    
    mTLS: true

Make Sure to Remove the below line in ocnadd-custom-values.yaml:

Remove ocnaddadminsvc.ocnadd.admin.env.OCNADD_ADAPTER_SERVER_SSL: false (Before helm install or upgrade) Line: 273
Remove ocnaddbackendrouter.ocnaddbackendrouter.env.OCNADD_BKNROUTER_CLIENT_SSL_USE_TS: true Before helm upgrade) Line: 313

The certificate creation step remains the same as mentioned in the "TLS Configuration" section. Please note it is mandatory to create certificates and secrets for MTLS to work.
Note:
- It is mandatory to create certificates and secrets for MTLS to work
- Make sure the above parameter is updated before deployment or upgrade.

4.2.1 TLS Configuration