Kafka authorization ensures that an external client can only access known Kafka topic IDs, and to ensure that the events that a client has access to align with the access control specified for the APIs that they use. Kafka authorization ensures that NSP data security can be enforced according to the policies of a customer's security organization, thereby lowering the risk of a security attack and avoiding the process required to obtain security exceptions to deploy NSP.

Kafka events include internal NSP functions that use events to drive system behaviour and external clients (e.g., OSSes), that use events to reflect the state of NSP resources within their own systems.

There are currently several types of topics on the Kafka bus:

• Internal topics that are not exposed to the external clients.

• External topics that are created through the Kafka notification service and are intended for the sole use of the authenticated client that subscribed to them.

• External topics that are created through the Kafka notification service and are intended for use by some other user or group of users, e.g., Telemetry.

• Permanent external topics that are provided by the YANG notification service that are well-known and intended for the use of all internal and external authenticated clients.

Port behavior with Kafka Authorization enabled​:

• Internal topics are only visible and consumable via internal ports:​ 9392 for internal client access​ and 9292 for Multi‑NIC secure access.

• On external ports (9192, 9193, 9194), internal topics are fully restricted:​ no consume, list, describe, or any other operations on internal topics.​

Kafka authorization supports dynamic updates to NSP user access control configurations without requiring Kafka cluster restarts.

In a single NIC deployment, NFM-P uses port 9192 by default to communicate with NSP.​ If Kafka authorization is enabled, NFM-P loses access to internal topics on port 9192.​ Therefore, when NFM-P is present in the system, Kafka authorization is supported only in Multi‑NIC deployments. In this case, the internalClientAuth parameter must be set to true in the nsp-config.yml file, NFM-P must connect via the internal/Multi‑NIC port (9292), and mTLS must be configured in the samconfig utility on NFM-P.

This section presents configuration examples for NSP functions with Kafka authorization enabled.

Securing nsp-yang-model.change case 1

Single NIC or multiple NIC, Kafka authorization enabled, no client authentication.

Kafka parameter configuration in nsp-config.yml:

• internalClientAuth: false

• externalClientAuth: false​

• enableAcls: true

No restrictions on nsp-yang-model.change topic. It will always be visible to all users (internal and external)​.

Securing nsp-yang-model.change case 2

Multiple NIC with NFMP, Kafka authorization enabled, internal & external authentication enabled

Kafka parameter configuration in nsp-config.yml:

• internalClientAuth: true​

• externalClientAuth: true​

• enableAcls: true

Access to nsp-yang topics would depend on whether Global Access Control is enabled or disabled.​ If Global Access Control is disabled, external users can still see/consume nsp-yang topics​. If Global Access Control is enabled, external users are restricted according to Kafka ACLs and NSP Notification Services permission defined in Roles.

Securing telemetry topics​ case 1

Single NIC or multiple NIC, Kafka authorization enabled, no client authentication.

Kafka parameter configuration in nsp-config.yml:

• internalClientAuth: false

• externalClientAuth: false​

• enableAcls: true

No restrictions on telemetry topic. It will always be visible to all users/clients (internal and external) regardless of who created the subscriptions topic.​

Securing telemetry topics​ case 2

Multple NIC with NFM-P, Kafka authorization enabled, internal and external authentication enabled

Kafka parameter configuration in nsp-config.yml:

• internalClientAuth: true​

• externalClientAuth: true​

• enableAcls: true

Access to telemetry topics would depend on if Global Access control is enabled or disabled. If Global Access Control is disabled, external users may still see/consume telemetry topics​ If Global Access Control is enabled, external users are restricted according to Kafka ACLs and NSP Notification Services Permission defined in roles.​

Securing subscription-based topics: enforcing subscriber-only access​

Kafka parameter configuration in nsp-config.yml:

• internalClientAuth: true​

• externalClientAuth: true​

• enableAcls: true

Kafka ACLs enforce topic-level authorization​ and subscription topics are mapped to specific user identities.

External users can access only their own subscription topics, except for telemetry topics (full access)​. External users cannot access other users’ topics but can access telemetry topics created by other users if the NSP Notification Service has Read/Read-Write permission.

User roles and access control for subscription-based topics​

An administrative user​ has access to their own subscription topics, telemetry topics, and nsp-yang-notification topics​. They cannot access other administrative or non-administrative users’ topics. Their allowed operations are List, Describe, and Consume​. They can perform GET, POST, and DEL operations on their own NBI subscriptions only.​

A Read/Write user​ has access to their own subscription topics, telemetry topics, and nsp-yang-notification topics. They cannot access other administrative or non-administrative users’ topics. Their allowed operations are List, Describe, and Consume. They can perform GET, POST, and DEL operations on their own NBI subscriptions only.​

A Read user can view subscriptions created before RBAC enforcement​. They have access to their own subscription topics, telemetry topics, and nsp-yang-notification topics. They cannot access other administrative or non-administrative users’ topics. Their allowed operations are List, Describe, and Consume. They cannot perform POST or DEL operations on NBI subscriptions. They can only perform a GET operation on their own subscriptions​.