Logo Event-Driven Architecture & Industrial Edge EN ES

Security and Governance

Authentication

All pipeline components are protected with platform-level authentication (OpenShift OAuth via Keycloak) and workload-level authentication (SCRAM-SHA-512 for Kafka clients).

KafkaUser with ACLs

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaUser
metadata:
  name: cdc-consumer
  labels:
    strimzi.io/cluster: cdc-cluster
spec:
  authentication:
    type: scram-sha-512
  authorization:
    type: simple
    acls:
      - resource:
          type: topic
          name: cdc.public.*
          patternType: prefix
        operations: [Read, Describe]
        host: "*"
      - resource:
          type: group
          name: cdc-consumer-group
        operations: [Read]

  • scram-sha-512 — credential-based authentication managed by Strimzi

  • ACLs restrict which topics and consumer groups each client can access

  • Strimzi automatically provisions Kubernetes Secrets with the credentials

Encryption

TLS on Kafka listeners

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: cdc-cluster
spec:
  kafka:
    listeners:
      - name: tls
        port: 9093
        type: internal
        tls: true
        authentication:
          type: tls
      - name: plain
        port: 9092
        type: internal
        tls: false

mTLS between brokers

Inter-broker communication uses mutual TLS automatically when TLS listeners are configured. Strimzi manages CA certificates and keystores.

Private Endpoints

All services are internal to the OpenShift cluster. External access is provided only through OpenShift Routes with edge TLS termination:

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: kafka-console
spec:
  tls:
    termination: edge
    insecureEdgeTerminationPolicy: Redirect
  to:
    kind: Service
    name: kafka-console-console-service

No Kafka broker port is exposed outside the cluster.

How it Works

SCRAM-SHA-512 authentication in Kafka

SCRAM (Salted Challenge Response Authentication Mechanism) works as a four-step handshake between the client and the broker:

  1. The client sends its username to the broker.

  2. The broker responds with a random salt and the iteration count stored for that user.

  3. The client generates a salted password using PBKDF2 with SHA-512, computes a cryptographic client proof, and sends it to the broker.

  4. The broker verifies the proof against stored credentials and sends a server signature that the client validates.

The password never travels in plain text. Strimzi automates the full lifecycle: when a KafkaUser CR is created, the User Operator generates SCRAM credentials, stores them in Kafka, and creates a Kubernetes Secret with the password so clients can mount it as an environment variable.

TLS: encryption in transit

  • Client → Broker: the TLS listener (port 9093) terminates TLS on the broker. Strimzi generates certificates automatically using an internal CA (cdc-cluster-cluster-ca-cert).

  • Broker → Broker: inter-broker communication uses mutual TLS (mTLS). Each broker has its own certificate signed by the cluster CA.

  • Service Mesh (ambient mTLS): Istio ambient mode adds a second layer of mTLS at L4 (ztunnel), encrypting all TCP traffic between pods in the kafka-cdc namespace — even traffic to the plain listener (9092) is encrypted at the network layer.

ACLs: granular authorization

Kafka ACLs work as allow lists — everything is denied by default:

  1. Each ACL defines a principal (SCRAM user), a resource (topic, group, cluster), a pattern (literal or prefix), and the allowed operations.

  2. The broker authorizer evaluates ACLs on every client request.

  3. The prefix pattern enables flexible rules: name: cdc, patternType: prefix authorizes access to all topics starting with cdc (including cdc.public.customers, cdc.public.orders).

  4. If no ACL matches, the request is denied with an authorization error.

Governance and Compliance

Schema Registry — validation rules

Apicurio Registry enforces schema contracts. Global rules prevent breaking changes:

{
  "rules": {
    "VALIDITY": "FULL",
    "COMPATIBILITY": "BACKWARD"
  }
}

  • VALIDITY: FULL — schemas must be syntactically valid

  • COMPATIBILITY: BACKWARD — new schemas must be readable by consumers on the previous version

Audit trail

  • Kafka retains all events for the configured retention period (7 days by default)

  • Debezium captures full before/after state for each database change

  • OpenShift audit logs track API access to the cluster

  • Schema Registry keeps version history for each schema

Browse registered schemas at Apicurio Registry.

Official Documentation