14 Disabling Kafka Feed Configuration Support
The chapter describes the steps to be taken when external Kafka feeds are no longer needed within the Data Director deployment.
For the external Kafka Feed, TLS and access control settings are essential on the Kafka server. However, if external Kafka Feed support becomes unnecessary, access control within Kafka should be disabled.
Note:
- If rolling back to a version without Kafka feed is supported, 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.
- When reverting to a version where Kafka feeds were supported and configured, there is no requirement to delete Kafka feeds and producer client ACLs.
- If deleting the ACLs and feeds before the rollback becomes unfeasible, see the troubleshooting guide for instructions on using the Kafka command line interface to delete the ACLs.
- Delete all the Kafka feeds using the UI. See Deleting Kafka Feed section.
- Perform helm upgrade by following the steps below:
- Edit the
ocnadd-custom-values-23.3.0.yamlfile and make the following updates in the global section:ssl: intraTlsEnabled: true ## Keep as 'true' if intra TLS connections are required; set to 'false' otherwise acl: kafkaClientAuth: none ## Update kafkaClientAuth to 'none' aclNotAllowed: true ## Update aclNotAllowed to 'true' - To upgrade, run the appropriate command based on the conditions:
- If the
intraTlsEnabledflag is changed tofalseand ACL with client authentication is not required:helm upgrade <release_name> <chart_name> -f ocnadd-custom-values.yaml -n <namespace_name> --set global.env.admin.OCNADD_ADAPTER_UPGRADE_ENABLE=trueExample:
helm upgrade ocnadd ocnadd -f ocnadd-custom-values-23.3.0.yaml -n ocnadd-deploy --set global.env.admin.OCNADD_ADAPTER_UPGRADE_ENABLE=true - If the
intraTlsEnabledflag remains unchanged but ACL with client authentication is not required:helm upgrade <release_name> <chart_name> -f ocnadd-custom-values.yaml -n <namespace_name>Example:
helm upgrade ocnadd ocnadd -f ocnadd-custom-values-23.3.0.yaml -n ocnadd-deploy
- If the
- After the helm upgrade, ensure that all pods are in a running state.
- Edit the
- Remove all the specific producer client ACLs using the steps given below:
- Access any pod within the OCNADD deployment, for example, 'kafka-broker-0',
using this
command:
kubectl exec -it kafka-broker-0 -n <namespace> -- bash - Run the command
below:
curl -k --location --request DELETE 'http://ocnaddconfiguration:12590/ocnadd-configuration/v1/client-acl' --header 'Content-Type: application/json' --data-raw '{ "principal": "<aclUser>", "resourceName": "<topic_name>", # Provide the topic name "aclOperation": "WRITE" }'Examples:- Delete ACL for the SCP topic, assuming the SCP producer's
<aclUser> name is
'scpuser':
curl -k --location --request DELETE 'http://ocnaddconfiguration:12590/ocnadd-configuration/v1/client-acl' --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 --request DELETE 'http://ocnaddconfiguration:12590/ocnadd-configuration/v1/client-acl' --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 --request DELETE 'http://ocnaddconfiguration:12590/ocnadd-configuration/v1/client-acl' --header 'Content-Type: application/json' --data-raw '{ "principal": "seppuser", "resourceName": "SEPP", "aclOperation": "WRITE" }'
- Delete ACL for the SCP topic, assuming the SCP producer's
<aclUser> name is
'scpuser':
- Access any pod within the OCNADD deployment, for example, 'kafka-broker-0',
using this
command:
Note:
Delete Generic ACLs if not already deleted, see Deleting Generic Producer Client ACLs section.