Enable Or Disable Kafka Feed Configuration Support

12 Enable Or Disable Kafka Feed Configuration Support

This section explains how to enable or disable Kafka Feed configuration in OCNADD.

12.1 Enable Kafka Feed Configuration Support

This chapter lists the prerequisites for both NF producers and third-party consumer applications to communicate securely with the Data Director Kafka cluster. Additionally, the section lists the necessary configuration settings to be applied at the Kafka broker.

Certain prerequisites must be fulfilled before the external Kafka feed can operate effectively for consumer applications. Notably, some of these prerequisites have the potential to impact communication with producer clients, particularly if any client ACL (Access Control List) rules are configured in Kafka. In such cases, Kafka will authenticate and authorize each client, potentially causing disruption for existing clients if they are not already utilizing SASL_SSL or SSL (mTLS) connections. It is advisable to follow recommendations outlined in the Oracle Communications Network Analytics Security Guide to ensure a seamless transition.

Note:

The procedure mentioned below should be executed corresponding to the worker group on which the Kafka feed configuration support is being enabled.

12.1.1 Prerequisites for NF Producers

This applies to all Oracle NF producers (SCP, NRF, PCF, BSF, and SEPP).

Ensure that the producers use either SASL_SSL or SSL (mTLS) to establish a connection with the Data Director Kafka cluster. The Data Director exposes SASL_SSL on port 9094 and SSL on port 9093.

SASL_SSL:
1. Bootstrap Server List: KAFKABROKER_0_LB_IP:9094, KAFKABROKER_1_LB_IP:9094, KAFKABROKER_2_LB_IP:9094 or KAFKABROKER_0_FQDN:9094, KAFKABROKER_1_FQDN:9094, KAFKABROKER_2_FQDN:9094
2. security.protocol: SASL_SSL
3. sasl.mechanism: PLAIN
4. Verify and update JAAS configuration - The Java Authentication and Authorization Service (JAAS) user used in the producer configuration must be available in the Data Director Kafka broker's JAAS configuration. It is recommended that each of the NFs configures its own JAAS user. Make a list of NF producer SASL users and follow the steps in Update Kafka Broker Configuration for updating the Data Director Broker configuration.
5. Create Client ACL with configured JAAS user on the Data Director. See Creating Client ACL with SASL username.
SSL:
1. Bootstrap Server List: KAFKABROKER_0_LB_IP:9093, KAFKABROKER_1_LB_IP:9093, KAFKABROKER_2_LB_IP:9093 or KAFKABROKER_0_FQDN:9093, KAFKABROKER_1_FQDN:9093, KAFKABROKER_2_FQDN:9093
2. security.protocol: SSL
3. Ensure that SSL parameters are set correctly and SSL certificates are generated using the same CA root as the Data Director. Refer to the section "Certificate and Secret Generation" in Oracle Communications Network Analytics Security Guide for recommendations
4. Create Client ACL on the Data Director with CN name in the client SSL certificate. See Creating Client ACL with CN Name from SSL Client Certificate.

Note:

In case any of the prerequisites are not met then the external Kafka feed must not be created as it can disrupt the traffic between NF producers and DD and may impact other feeds HTTP2/Synthetic.

12.1.2 Prerequisites for External Consumers

The External Consumer application requires user-based authorizations. Data Director does not provide any Kafka user creation interface, either from the UI or backend services. The user must be present in the Kafka JAAS configuration, which is not possible without a Kafka broker restart. This is the reason Data Director does not enforce user verification during Kafka Feed creation, making it mandatory for the user to be created before the Kafka Feed can be created using the UI.

For added security, the user for the External Consumer application must also be created in the Kafka SCRAM configuration. The steps are explained below and must be followed for the Mediation group Kafka Cluster.

Create the ACL user in the Kafka JAAS and SCRAM configuration, and use the same user name when creating the Kafka Feed from the UI. Without this, the External Consumer application will not be able to consume from Kafka.
To create ACL user:
1. Update Kafka Broker JAAS configuration for the external feed user, refer to the section Updating JAAS Configuration with Users.
2. Update the Kafka SCRAM configuration with the external feed user, refer to the section Updating SCRAM Configuration with Users. This step must be done only after the JAAS configuration is updated in Kafka Broker.
The external Kafka consumer application must support SASL_SSL to communicate with the Data Director's Mediation group Kafka cluster.
The external Kafka consumer application must create SSL certificates to communicate with the Data Director's Mediation group Kafka cluster. See the "Certificate and Secret Generation" section in Oracle Communications Network Analytics Data Director Security Guide for recommendations.

12.1.3 Updating OCNADD Configuration

After ensuring that prerequisites are completed, perform the procedure below to enable external Kafka Feed support on the intended worker group (relayagent and mediation).

Step 1: Update OCNADD intra TLS/mTLS Configuration. For more details, See Internal TLS Communication section in the Oracle Communications Network Analytics Data Director Security Guide.

Step 2: Update the corresponding ocnadd-common-custom-values.yaml as shown below. Make sure to update the ocnadd-common-custom-values.yaml across clusters if OCNADD deployment is spanned across clusters.

global:
    ssl:
        mTLS: true        ## ==========> this should be set to true if not already true
    acl:
        kafkaClientAuth: none        ## ---> update it to 'required'
        aclNotAllowed: true          ## ---> update it to 'false'

Step 3: Update Kafka Broker Configuration

Add the ACL users for Oracle NF producers or external consumer applications inside the kafka_server_jaas.conf (<chart-path>/helm-charts/charts/ocnaddkafka/config) of the Relay Agent group and Mediation group helm charts on which the Kafka Feeds should be enabled.
Refer to the section Updating JAAS Configuration with Users.

Perform helm upgrade of Management Group, Relay Agent Group, and Mediation Group:

Upgrade Management Group:

helm upgrade ocnadd-mgmt -f ocnadd-common-custom-values.yaml -f ocnadd-mgmt-custom-values-mgmt-group.yaml --namespace ocnadd-mgmt ocnadd

Upgrade Relay Agent Group:

helm upgrade ocnadd-relay -f ocnadd-common-custom-values.yaml -f ocnadd-relayagent-custom-values-relayagent-group.yaml --namespace ocnadd-relay ocnadd --set global.acl.genericAclAllowed=true

Upgrade Mediation Group:

helm upgrade ocnadd-med -f ocnadd-common-custom-values.yaml -f ocnadd-mediation-custom-values-med-group.yaml --namespace ocnadd-med ocnadd --set global.acl.genericAclAllowed=true,global.ocnaddmediation.env.admin.OCNADD_ADAPTER_UPGRADE_ENABLE=true,global.ocnaddmediation.env.admin.OCNADD_CORR_UPGRADE_ENABLE=true

Verify that all PODs are in a running state after the helm upgrade in the respective groups.

Step 4: Update the Kafka NF Producer Client ACLs

The NF producer client ACLs need to be updated from the generic ACLs to the specific producer client ACLs:

See the Creating Client ACLs section for creating the specific NF producer client ACLs.
See the Deleting Generic Producer Client ACLs section for deleting the generic NF producer client ACLs.

Step 5: Add the external consumer application users in SCRAM

See the Updating SCRAM Configuration with Users.

Step 7: Create the external Kafka Feed using the UI

Proceed with external Kafka Feed creation using the OCNADD UI. After configuring the external Kafka Feed from the UI, configure the external Kafka consumer application with the following mandatory Kafka consumer configuration details:

Consumer properties:

security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-256
sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required username="extuser1" password="extuser1";
ssl.truststore.location=<truststore location>
ssl.truststore.password=<truststore pass>
ssl.keystore.location=<keystore location>
ssl.keystore.password=<keystore pass>
ssl.key.password=<keystore pass>

The bootstrap server list should be set up using the information provided in the response of feed creation on the UI. Example:

Bootstrap Server List: KAFKABROKER-0_LB_IP:9094, KAFKABROKER-1_LB_IP:9094, KAFKABROKER-2_LB_IP:9094

Other required configurations:

Topic Name: Extract this from the UI after successfully creating the feed.
Number of Partitions: Retrieve this from the UI after successfully creating the feed.
Consumer Group Name: Obtain this from the UI after successfully creating the feed; it should match the Kafka feed name.
ACL User Name: Utilize the same ACL username as provided during feed creation, for example, extuser1.

12.1.4 Updating JAAS Configuration with Users

Perform this on the worker group in which the Kafka feed should be enabled:

Updating JAAS Config File

Edit <chart-path-worker-group>/helm-charts/charts/ocnaddkafka/config/kafka_server_jaas.conf for both relayagent and mediation groups

Update the user JAAS configuration as described below:

 =================Existing File Content===================
KafkaServer {
org.apache.kafka.common.security.plain.PlainLoginModule  required
username="ocnadd"
password="ocnadd"
user_ocnadd="ocnadd";
};
Client {
org.apache.zookeeper.server.auth.DigestLoginModule required
username="ocnadd"
password="ocnadd";
};


=================Updated File Content===================
# This is only needed for the mediation group and not for the relayagent group
# After Adding ACL User as extuser1 (password: extuser1) inside SCRAM Login Module for external application1
# After Adding ACL User as extuser2 (password: extuser2) inside SCRAM Login Module for external application2

# These below NF specific should only be updated for the relayagent group jaas config and not needed for the mediation group
# After Adding ACL User as scpuser(password: scp) inside PLAIN Login Module for Oracle NF SCP, assuming that SCP has configured "scpuser" as SASL user in its producer configuration
# After Adding ACL User as nrfuser(password: nrf) inside PLAIN Login Module for Oracle NF NRF, assuming that NRF has configured "nrfuser" as SASL user in its producer configuration
# After Adding ACL User as seppuser(password: sepp) inside PLAIN Login Module for Oracle NF SEPP, assuming that SEPP has configured "seppuser" as SASL user in its producer configuration
# After Adding ACL User as bsfuser(password: bsf) inside PLAIN Login Module for Oracle NF BSF, assuming that BSF has configured "bsfuser" as SASL user in its producer configuration
# After Adding ACL User as pcfuser(password: pcf) inside PLAIN Login Module for Oracle NF PCF, assuming that PCF has configured "pcfuser" as SASL user in its producer configuration


KafkaServer {
org.apache.kafka.common.security.plain.PlainLoginModule  required
username="ocnadd"
password="ocnadd"
user_ocnadd="ocnadd"
# These below NF specific should only be updated for the relayagent group jaas config and not needed for the mediation group
user_scpuser="scp"
user_nrfuser="nrf"
user_seppuser="sepp"
user_nrfuser="bsf"
user_nrfuser="pcf";

# This is only needed for the mediation group and not for the relayagent group
org.apache.kafka.common.security.scram.ScramLoginModule  required
user_extuser1="extuser1"
user_extuser2="extuser2";
};
Client {
org.apache.zookeeper.server.auth.DigestLoginModule required
username="ocnadd"
password="ocnadd";
};

12.1.5 Updating SCRAM Configuration with Users

Perform the below steps inside the worker group in which the SCRAM user configuration should be added to the corresponding Kafka cluster.

Access the Kafka Pod from the OCNADD deployment. For example, kafka-broker-0:
```
kubectl exec -it kafka-broker-0 -n <namespace> -- bash
```
Extract the SSL parameters from the Kafka broker environments, by running the following command:
```
env | grep -i pass
```

Use the truststore and keystore passwords from above command output to create the admin.properties file as below:

	security.protocol=SASL_SSL
	sasl.mechanism=PLAIN
	sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="ocnadd" password="ocnadd";
	ssl.truststore.location=/var/securityfiles/keystore/trustStore.p12
	ssl.truststore.password=<truststore pass>
	ssl.keystore.location=/var/securityfiles/keystore/keyStore.p12
	ssl.keystore.password=<keystore pass>
	ssl.key.password=<keystore pass>

Copy admin.properties to any of the Kafka broker containers. For example, Kafka-broker-0:
```
kubectl cp admin.properties <med-group-namespace>/kafka-broker-0:/home/ocnadd/
```

Create the SCRAM User configuration for the external consumer application users, run the below commands from inside the Kafka Broker container For example, kafka-broker-0:

cd  /home/ocnadd/kafka/bin

for user "extuser1"
./kafka-configs.sh --bootstrap-server kafka-broker:9094 --alter --add-config 'SCRAM-SHA-512=[password=extuser1]' --entity-type users --entity-name extuser1 --command-config ../../admin.properties

./kafka-configs.sh --bootstrap-server kafka-broker:9094 --alter --add-config 'SCRAM-SHA-256=[iterations=8192,password=extuser1]' --entity-type users --entity-name extuser1 --command-config ../../admin.properties

for user "extuser2"
./kafka-configs.sh --bootstrap-server kafka-broker:9094 --alter --add-config 'SCRAM-SHA-512=[password=extuser2]' --entity-type users --entity-name extuser2 --command-config ../../admin.properties

./kafka-configs.sh --bootstrap-server kafka-broker:9094 --alter --add-config 'SCRAM-SHA-256=[iterations=8192,password=extuser2]' --entity-type users --entity-name extuser2 --command-config ../../admin.properties

To verify if the users are created in SCRAM, run the below command:

./kafka-configs.sh --bootstrap-server kafka-broker:9094 --describe --entity-type users --command-config ../../admin.properties

Sample output:

. / kafka - configs.sh--bootstrap - server kafka - broker: 9094--describe--entity - type users--command - config.. / .. / admin.properties
SCRAM credential configs
for user - principal 'extuser1'
are SCRAM - SHA - 256 = iterations = 8192, SCRAM - SHA - 512 = iterations = 4096
SCRAM credential configs
for user - principal 'extuser2'
are SCRAM - SHA - 256 = iterations = 8192, SCRAM - SHA - 512 = iterations = 4096

12.1.6 Creating Client ACLs

This section describes the steps to create client ACLs (Access Control Lists) using different methods.

12.1.6.1 Creating Client ACL with SASL username

Access the management gateway pod within the deployment, for example, ocnaddmanagementgateway-x-x-x. Use the following command:
```
kubectl exec -it ocnaddmanagementgateway-x-x-x -n <mgmt-namespace> -- bash
```

Run the command to create an ACL with SASL username. Provide the name of the <relayAgentGroup> in the command below, where <relayAgentGroupName> = <siteName>:<workerGroupName>:<relayAgentNamespace>:<relayAgentClusterName>:

curl -k --location --cert-type P12 --cert /var/securityfiles/keystore/serverKeyStore.p12:$OCNADD_SERVER_KS_PASSWORD --request POST 'https://ocnaddmanagementgateway.<mgmt-ns>:12889/ocnadd-configuration/v3/client-acl?relayAgentGroup=<relayAgentGroup>' --header 'Content-Type: application/json' --data-raw '{
    "principal": "<aclUser>",
    "resourceName": "<topic_name>", # topic name has to be provided
    "aclOperation": "WRITE"
}'

Examples:

Create an ACL for the scpuser to permit WRITE access on the SCP topic: management namespace is ddmgmt and relayAgentGroup is BLR:ddworker1:dd-relay-ns:dd-relay-cluster

curl -k --location --cert-type P12 --cert /var/securityfiles/keystore/serverKeyStore.p12:$OCNADD_SERVER_KS_PASSWORD --request POST 'https://ocnaddmanagementgateway.ddmgmt:12889/ocnadd-configuration/v3/client-acl?relayAgentGroup=BLR:ddworker1:dd-relay-ns:dd-relay-cluster' --header 'Content-Type: application/json' --data-raw '{
    "principal": "scpuser",
    "resourceName": "SCP",
    "aclOperation": "WRITE"
}'

Create an ACL for the nrfuser to grant WRITE access on the NRF topic: management namespace is ddmgmt and relayAgentGroup is BLR:ddworker1:dd-relay-ns:dd-relay-cluster

curl -k --location --cert-type P12 --cert /var/securityfiles/keystore/serverKeyStore.p12:$OCNADD_SERVER_KS_PASSWORD --request POST 'https://ocnaddmanagementgateway.ddmgmt:12889/ocnadd-configuration/v3/client-acl?relayAgentGroup=BLR:ddworker1:dd-relay-ns:dd-relay-cluster' --header 'Content-Type: application/json' --data-raw  '{
    "principal": "nrfuser",
    "resourceName": "NRF",
    "aclOperation": "WRITE"
}'

Create an ACL for the seppuser allowing WRITE access on the SEPP topic: management namespace is ddmgmt and relayAgentGroup is BLR:ddworker1:dd-relay-ns:dd-relay-cluster

curl -k --location --cert-type P12 --cert /var/securityfiles/keystore/serverKeyStore.p12:$OCNADD_SERVER_KS_PASSWORD --request POST 'https://ocnaddmanagementgateway.ddmgmt:12889/ocnadd-configuration/v3/client-acl?relayAgentGroup=BLR:ddworker1:dd-relay-ns:dd-relay-cluster' --header 'Content-Type: application/json' --data-raw '{
    "principal": "seppuser",
    "resourceName": "SEPP",
    "aclOperation": "WRITE"
}'

Create an ACL for the bsfuser allowing WRITE access on the BSF topic: management namespace is ddmgmt and relayAgentGroup is BLR:ddworker1:dd-relay-ns:dd-relay-cluster

curl -k --location --cert-type P12 --cert /var/securityfiles/keystore/serverKeyStore.p12:$OCNADD_SERVER_KS_PASSWORD --request POST 'https://ocnaddmanagementgateway.ddmgmt:12889/ocnadd-configuration/v3/client-acl?relayAgentGroup=BLR:ddworker1:dd-relay-ns:dd-relay-cluster' --header 'Content-Type: application/json' --data-raw '{
    "principal": "bsfuser",
    "resourceName": "BSF",
    "aclOperation": "WRITE"
}'

Create an ACL for the pcfuser allowing WRITE access on the PCF topic: management namespace is ddmgmt and relayAgentGroup is BLR:ddworker1:dd-relay-ns:dd-relay-cluster

curl -k --location --cert-type P12 --cert /var/securityfiles/keystore/serverKeyStore.p12:$OCNADD_SERVER_KS_PASSWORD --request POST 'https://ocnaddmanagementgateway.ddmgmt:12889/ocnadd-configuration/v3/client-acl?relayAgentGroup=BLR:ddworker1:dd-relay-ns:dd-relay-cluster' --header 'Content-Type: application/json' --data-raw '{
    "principal": "pcfuser",
    "resourceName": "PCF",
    "aclOperation": "WRITE"
}'

12.1.6.2 Creating Client ACL with CN Name from SSL Client Certificate

Access the management gateway pod within the deployment, for example, ocnaddmanagementgateway-x-x-x. Use the following command:
```
kubectl exec -it ocnaddmanagementgateway-x-x-x -n <mgmt-namespace> -- bash
```

Run the command below to create a client ACL with CN Name from the SSL client certificate. Provide the name of the <relayAgentGroup> in the command below, where <relayAgentGroupName> = <siteName>:<workerGroupName>:<relayAgentNamespace>:<relayAgentClusterName>:

curl -k --location --cert-type P12 --cert /var/securityfiles/keystore/serverKeyStore.p12:$OCNADD_SERVER_KS_PASSWORD --request POST 'https://ocnaddmanagementgateway.<mgmt-ns>:12889/ocnadd-configuration/v3/client-acl?relayAgentGroup=<relayAgentGroup>' --header 'Content-Type: application/json' --data-raw '{
    "principal": "<aclUser>",
    "resourceName": "<topic_name>", # topic name has to be provided
    "aclOperation": "WRITE"
}'

Here, the <aclUser> is the CN Name configured in the Client SSL certificate. Extract the CN Name from the SCP, NRF, BSF, PCF, and SEPP client SSL certificates used between NF and Kafka communication. The commands below are examples; the actual CN Name may differ in the Client SSL certificate.

Examples:

Create an ACL for the CN name scp-worker, allowing WRITE access on the SCP topic:

curl -k --location --cert-type P12 --cert /var/securityfiles/keystore/serverKeyStore.p12:$OCNADD_SERVER_KS_PASSWORD --request POST 'https://ocnaddmanagementgateway.ddmgmt:12889/ocnadd-configuration/v3/client-acl?relayAgentGroup=BLR:ddworker1:dd-relay-ns:dd-relay-cluster' --header 'Content-Type: application/json' --data-raw '{
    "principal": "scp-worker",
    "resourceName": "SCP",
    "aclOperation": "WRITE"
}'

Create an ACL for the CN name nrf-gw, granting WRITE access on the NRF topic:

curl -k --location --cert-type P12 --cert /var/securityfiles/keystore/serverKeyStore.p12:$OCNADD_SERVER_KS_PASSWORD --request POST 'https://ocnaddmanagementgateway.ddmgmt:12889/ocnadd-configuration/v3/client-acl?relayAgentGroup=BLR:ddworker1:dd-relay-ns:dd-relay-cluster' --header 'Content-Type: application/json' --data-raw '{
    "principal": "nrf-gw",
    "resourceName": "NRF",
    "aclOperation": "WRITE"
}'

Create an ACL for the CN name sepp-gw, permitting WRITE access on the SEPP topic:

curl -k --location --cert-type P12 --cert /var/securityfiles/keystore/serverKeyStore.p12:$OCNADD_SERVER_KS_PASSWORD --request POST 'https://ocnaddmanagementgateway.ddmgmt:12889/ocnadd-configuration/v3/client-acl?relayAgentGroup=BLR:ddworker1:dd-relay-ns:dd-relay-cluster' --header 'Content-Type: application/json' --data-raw '{
    "principal": "sepp-gw",
    "resourceName": "SEPP",
    "aclOperation": "WRITE"
}'

Create an ACL for the CN name bsf-gw, permitting WRITE access on the BSF topic:

curl -k --location --cert-type P12 --cert /var/securityfiles/keystore/serverKeyStore.p12:$OCNADD_SERVER_KS_PASSWORD --request POST 'https://ocnaddmanagementgateway.ddmgmt:12889/ocnadd-configuration/v3/client-acl?relayAgentGroup=BLR:ddworker1:dd-relay-ns:dd-relay-cluster' --header 'Content-Type: application/json' --data-raw '{
    "principal": "bsf-gw",
    "resourceName": "BSF",
    "aclOperation": "WRITE"
}'

Create an ACL for the CN name pcf-gw, permitting WRITE access on the PCF topic:

curl -k --location --cert-type P12 --cert /var/securityfiles/keystore/serverKeyStore.p12:$OCNADD_SERVER_KS_PASSWORD --request POST 'https://ocnaddmanagementgateway.ddmgmt:12889/ocnadd-configuration/v3/client-acl?relayAgentGroup=BLR:ddworker1:dd-relay-ns:dd-relay-cluster' --header 'Content-Type: application/json' --data-raw '{
    "principal": "pcf-gw",
    "resourceName": "PCF",
    "aclOperation": "WRITE"
}'

12.1.7 Deleting Generic Producer Client ACLs

Access the management gateway pod within the deployment, for example, ocnaddmanagementgateway-x-x-x. Use the following command:
```
kubectl exec -it ocnaddmanagementgateway-x-x-x -n <mgmt-namespace> -- bash
```

Run the commands below and provide the name of the <relayAgentGroup> in the command, where <relayAgentGroupName> = <siteName>:<workerGroupName>:<relayAgentNamespace>:<relayAgentClusterName>:

curl -k --location --cert-type P12 --cert /var/securityfiles/keystore/serverKeyStore.p12:$OCNADD_SERVER_KS_PASSWORD --request DELETE 'https://ocnaddmanagementgateway.<mgmt-ns>:12889/ocnadd-configuration/v3/client-acl?relayAgentGroup=<relayAgentGroup>' --header 'Content-Type: application/json' --data-raw '{
    "principal": "*",
    "resourceName": "<topic_name>", # provide topic name
    "aclOperation": "WRITE"
}'

Examples:

Delete ACL for the SCP topic:

curl -k --location --cert-type P12 --cert /var/securityfiles/keystore/serverKeyStore.p12:$OCNADD_SERVER_KS_PASSWORD --request DELETE 'https://ocnaddmanagementgateway.ddmgmt:12889/ocnadd-configuration/v3/client-acl?relayAgentGroup=BLR:ddworker1:dd-relay-ns:dd-relay-cluster' --header 'Content-Type: application/json' --data-raw '{
    "principal": "*",
    "resourceName": "SCP",
    "aclOperation": "WRITE"
}'

Delete ACL for the NRF topic:

curl -k --location --cert-type P12 --cert /var/securityfiles/keystore/serverKeyStore.p12:$OCNADD_SERVER_KS_PASSWORD --request DELETE 'https://ocnaddmanagementgateway.ddmgmt:12889/ocnadd-configuration/v3/client-acl?relayAgentGroup=BLR:ddworker1:dd-relay-ns:dd-relay-cluster' --header 'Content-Type: application/json' --data-raw '{
    "principal": "*",
    "resourceName": "NRF",
    "aclOperation": "WRITE"
}'

Delete ACL for the SEPP topic:

curl -k --location --cert-type P12 --cert /var/securityfiles/keystore/serverKeyStore.p12:$OCNADD_SERVER_KS_PASSWORD --request DELETE 'https://ocnaddmanagementgateway.ddmgmt:12889/ocnadd-configuration/v3/client-acl?relayAgentGroup=BLR:ddworker1:dd-relay-ns:dd-relay-cluster' --header 'Content-Type: application/json' --data-raw '{
    "principal": "*",
    "resourceName": "SEPP",
    "aclOperation": "WRITE"
}'

Delete ACL for the BSF topic:

curl -k --location --cert-type P12 --cert /var/securityfiles/keystore/serverKeyStore.p12:$OCNADD_SERVER_KS_PASSWORD --request DELETE 'https://ocnaddmanagementgateway.ddmgmt:12889/ocnadd-configuration/v3/client-acl?relayAgentGroup=BLR:ddworker1:dd-relay-ns:dd-relay-cluster' --header 'Content-Type: application/json' --data-raw '{
    "principal": "*",
    "resourceName": "BSF",
    "aclOperation": "WRITE"
}'

Delete ACL for the PCF topic:

curl -k --location --cert-type P12 --cert /var/securityfiles/keystore/serverKeyStore.p12:$OCNADD_SERVER_KS_PASSWORD --request DELETE 'https://ocnaddmanagementgateway.ddmgmt:12889/ocnadd-configuration/v3/client-acl?relayAgentGroup=BLR:ddworker1:dd-relay-ns:dd-relay-cluster' --header 'Content-Type: application/json' --data-raw '{
    "principal": "*",
    "resourceName": "PCF",
    "aclOperation": "WRITE"
}'

12.2 Disabling Kafka Feed Configuration Support

This section defines the procedure to be executed in the case external Kafka feeds are no longer used in the Data Director deployment.

The external Kafka feed requires TLS and access control in the Kafka server. If external Kafka feed support is not required, then access control in Kafka can be disabled.

The steps in this procedure should only be executed in the group (relayagent or mediation) where Kafka feed support is to be disabled.

Note:

If rolling back to a release where Kafka feed support was not present, it is mandatory to delete the Producer Client ACLs and Kafka feeds before initiating the rollback. Follow steps 1 and 3 for deleting the feeds and ACLs.
If rolling back to a revision where Kafka feeds were supported and configured, there is no need to delete Kafka feeds and Producer Client ACLs.
If it is not possible to delete the ACLs and feeds before the rollback, contact Oracle Support using MOS.

Step 1: Delete all the Kafka feeds from the UI

See the Deleting Kafka Feed section to delete the Kafka feeds.

Note:

Ensure that the producer Client ACL and generic ACL are deleted if not already removed. If already deleted, ignore and continue with the next steps.

Step 2: Perform Helm Upgrade

Note:

This step should be performed on the worker group where feed support is to be disabled. This could be the default group or any other worker group. For the default group, use the corresponding charts and custom values.

Helm Upgrade for Disabling ACL Support

Edit the ocnadd-common-custom-values.yaml file and make the following updates in the global section:

global:
    ssl:
        mTLS: true           ## This should remain true 
    acl:
        kafkaClientAuth: required       ## Update the kafkaClientAuth to none
        aclNotAllowed: false            ## Update the aclNotAllowed to true

Perform Helm upgrade of Management Group, Relay Agent Group, and Mediation Group:

Upgrade Management Group

helm upgrade ocnadd-mgmt -f ocnadd-common-custom-values.yaml -f ocnadd-mgmt-custom-values-mgmt-group.yaml --namespace ocnadd-mgmt ocnadd

Upgrade Relayagent Group

helm upgrade ocnadd-relay -f ocnadd-common-custom-values.yaml -f ocnadd-relayagent-custom-values-relayagent-group.yaml --namespace ocnadd-relay ocnadd --set global.acl.genericAclAllowed=true

Upgrade Mediation Group

helm upgrade ocnadd-med -f ocnadd-common-custom-values.yaml -f ocnadd-mediation-custom-values-med-group.yaml --namespace ocnadd-med ocnadd --set global.acl.genericAclAllowed=true,global.ocnaddmediation.env.admin.OCNADD_ADAPTER_UPGRADE_ENABLE=true,global.ocnaddmediation.env.admin.OCNADD_CORR_UPGRADE_ENABLE=true

After the Helm upgrade, ensure that all pods are in a running state in the respective groups.

Step 3: Remove all the specific producer client ACLs from the group where Kafka feed support should be disabled

Access the management gateway pod within the deployment, for example, ocnaddmanagementgateway-x-x-x:
```
kubectl exec -it ocnaddmanagementgateway-x-x-x -n <mgmt-namespace> -- bash
```

Run the command below and provide the name of the <relayAgentGroup>, where <relayAgentGroupName> = <siteName>:<workerGroupName>:<relayAgentNamespace>:<relayAgentClusterName>:

curl -k --location --cert-type P12 --cert /var/securityfiles/keystore/serverKeyStore.p12:$OCNADD_SERVER_KS_PASSWORD --request DELETE 'https://ocnaddmanagementgateway.<mgmt-ns>:12889/ocnadd-configuration/v3/client-acl?relayAgentGroup=<relayAgentGroup>' --header 'Content-Type: application/json' --data-raw '{
    "principal": "<aclUser>",
    "resourceName": "<topic_name>",   # provide topic name
    "aclOperation": "WRITE"
}'

Examples:

Delete ACL for the SCP topic, assuming the SCP producer's <aclUser> name is scpuser:

curl -k --location --cert-type P12 --cert /var/securityfiles/keystore/serverKeyStore.p12:$OCNADD_SERVER_KS_PASSWORD --request DELETE 'https://ocnaddmanagementgateway.ddmgmt:12889/ocnadd-configuration/v3/client-acl?relayAgentGroup=BLR:ddworker1:dd-relay-ns:dd-relay-cluster' --header 'Content-Type: application/json' --data-raw '{
    "principal": "scpuser",
    "resourceName": "SCP",
    "aclOperation": "WRITE"
}'

Delete ACL for the NRF topic, assuming the NRF producer ACL user name is nrfuser:

curl -k --location --cert-type P12 --cert /var/securityfiles/keystore/serverKeyStore.p12:$OCNADD_SERVER_KS_PASSWORD --request DELETE 'https://ocnaddmanagementgateway.ddmgmt:12889/ocnadd-configuration/v3/client-acl?relayAgentGroup=BLR:ddworker1:dd-relay-ns:dd-relay-cluster' --header 'Content-Type: application/json' --data-raw '{
    "principal": "nrfuser",
    "resourceName": "NRF",
    "aclOperation": "WRITE"
}'

Delete ACL for the SEPP topic, assuming the SEPP producer ACL user name is seppuser:

curl -k --location --cert-type P12 --cert /var/securityfiles/keystore/serverKeyStore.p12:$OCNADD_SERVER_KS_PASSWORD --request DELETE 'https://ocnaddmanagementgateway.ddmgmt:12889/ocnadd-configuration/v3/client-acl?relayAgentGroup=BLR:ddworker1:dd-relay-ns:dd-relay-cluster' --header 'Content-Type: application/json' --data-raw '{
    "principal": "seppuser",
    "resourceName": "SEPP",
    "aclOperation": "WRITE"
}'

Delete ACL for the BSF topic, assuming the BSF producer ACL user name is bsfuser:

curl -k --location --cert-type P12 --cert /var/securityfiles/keystore/serverKeyStore.p12:$OCNADD_SERVER_KS_PASSWORD --request DELETE 'https://ocnaddmanagementgateway.ddmgmt:12889/ocnadd-configuration/v3/client-acl?relayAgentGroup=BLR:ddworker1:dd-relay-ns:dd-relay-cluster' --header 'Content-Type: application/json' --data-raw '{
    "principal": "bsfuser",
    "resourceName": "BSF",
    "aclOperation": "WRITE"
}'

Delete ACL for the PCF topic, assuming the PCF producer ACL user name is pcfuser:

curl -k --location --cert-type P12 --cert /var/securityfiles/keystore/serverKeyStore.p12:$OCNADD_SERVER_KS_PASSWORD --request DELETE 'https://ocnaddmanagementgateway.ddmgmt:12889/ocnadd-configuration/v3/client-acl?relayAgentGroup=BLR:ddworker1:dd-relay-ns:dd-relay-cluster' --header 'Content-Type: application/json' --data-raw '{
    "principal": "pcfuser",
    "resourceName": "PCF",
    "aclOperation": "WRITE"
}'

Note:

Delete Generic ACLs if not already deleted, see Deleting Generic Producer Client ACLs section.