Access Controls

Kafka access controls are divided into two pieces: Authentication and Authorization.

Authentication

Client authentication with Kafka is managed by the Strimzi Operator, which looks for a KafkaUser custom resource definition (CRD) for the user attempting to authenticate with Kafka.

KafkaUser
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaUser
metadata:
  labels:
    strimzi.io/cluster: df
  name: 346bb0f4-c8f6-46de-a3c5-6b06c7e4ce81                            (1)
  namespace: data-fabric
spec:
  authentication:
    password:
      valueFrom:
        secretKeyRef:
          key: password
          name: df-kafka-client-346bb0f4-c8f6-46de-a3c5-6b06c7e4ce81    (2)
    type: scram-sha-512
1 The user ID, which matches the user’s principal ID in Keycloak.
2 Name of the Secret containing the user’s auto-generated password for Kafka.

Matching the user’s principal is key to performing fine access controls, in which the user’s attributes and group memberships are looked up in Keycloak using their principal.

Managing Users

All management of the KafkaUser and his associated Secret are managed by the Kafka Administrator, which handles creating them when granting access to a user.

Reflexively, the admin API also handles removing the KafkaUser and his Secret when the user’s access is revoked.

Accessing Kafka

To access Kafka as a client, see Clients.

Authorization

Kafka is configured to defer all authorization decisions to OPA.

Per-Topic Authorization

The OPA policies for Kafka control access at the topic level. That is, topics can be controlled individually but their individual messages within the same topic cannot be differentiated.

If a user has access to a particular topic, they have access to all messages on that topic.

Topic authorization can change dynamically, either by updating policies or by modifying the user’s attributes in Keycloak.

If a user has an active session with a topic, and the policy for that topic changes such that the user should no longer have access, the user’s session will be terminated by Kafka.

Classification Controls

Each topic can be (optionally) marked with a classification marking using IC Classification and Control Markings.

Diagram

Set Classification Marking

To set a classification marking for a topic, a user issues a PUT request to the /topics/{topic}/classification endpoint.

Request
curl -X 'PUT' \
  'http://localhost/api/v1/kafka/topics/test-topic/classification?classification=S%2F%2FNF' \  (1)
  -H 'accept: application/json' \
  -H 'Authorization: Basic YWRtaW46eUNITHBDaG12dDRuTVUwNWpaZTZBbGl0'  (2)
1 Provide the marking in the classification URL arg (be sure to url-escape the value). Here we set it to S//NF.
2 Can use Basic (username/password) or Bearer token.

To successfully set (or change) a topic’s classification,

  1. The invoking user must be cleared for the marking they are providing (cannot mark beyond their own clearance).

  2. If the topic has an existing marking (changing marking), the user must also be cleared for the existing marking.

Get Classification Marking

To see the current classification marking for a topic, a user issues a GET request to the /topics/{topic}/classification endpoint.

Request
curl -X 'GET' \
  'http://localhost/api/v1/kafka/topics/test-topic/classification' \
  -H 'accept: application/json' \
  -H 'Authorization: Basic YWRtaW46eUNITHBDaG12dDRuTVUwNWpaZTZBbGl0'

This will return the normalized form of the marking, which includes a "raw" attribute containing the originally provided marking.

Response
{
  "raw": "S//NF",
  "components": {
    "classification": "S",
    "disseminationControls": [
      "NF"
    ],
    "ownerProducer": [
      "USA"
    ],
    "releasableTo": []
  }
}

To explore the full API, download the OpenAPI or view it in the Swagger docs.