Logo Event-Driven Architecture Live

Seguridad y Gobierno

Autenticación

Todos los componentes del pipeline se protegen con autenticación a nivel de plataforma (OpenShift OAuth vía Keycloak) y a nivel de workload (SCRAM-SHA-512 para clientes Kafka).

KafkaUser con 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 — autenticación basada en credenciales gestionadas por Strimzi

  • ACLs restringen qué topics y consumer groups puede acceder cada cliente

  • Strimzi provisiona automáticamente los Secrets de Kubernetes con las credenciales

Encriptación

TLS en Listeners de Kafka

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 entre Brokers

La comunicación inter-broker usa TLS mutuo automáticamente cuando se configuran listeners TLS. Strimzi gestiona los certificados CA y los keystores.

Private Endpoints

Todos los servicios son internos al cluster OpenShift. El acceso externo se provee únicamente mediante OpenShift Routes con terminación TLS edge:

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

Ningún puerto de Kafka broker se expone fuera del cluster.

How it Works

Autenticación SCRAM-SHA-512 en Kafka

SCRAM (Salted Challenge Response Authentication Mechanism) funciona como un handshake de 4 pasos entre el cliente y el broker:

  1. El cliente envía su username al broker.

  2. El broker responde con un salt aleatorio y el iteration count almacenado para ese usuario.

  3. El cliente genera un salted password usando PBKDF2 con SHA-512, calcula una client proof criptográfica, y la envía al broker.

  4. El broker verifica la proof contra las credenciales almacenadas y envía una server signature que el cliente valida.

En ningún momento la contraseña viaja en texto plano. Strimzi automatiza todo el ciclo de vida: al crear un KafkaUser CR, el User Operator genera las credenciales SCRAM, las almacena en Kafka, y crea un Secret de Kubernetes con la contraseña para que los clientes la monten como variable de entorno.

TLS: encriptación en tránsito

  • Client → Broker: el listener TLS (port 9093) termina TLS en el broker. Strimzi genera certificados automáticamente usando una CA interna (cdc-cluster-cluster-ca-cert).

  • Broker → Broker: la comunicación inter-broker usa TLS mutuo (mTLS). Cada broker tiene su propio certificado firmado por la CA del cluster.

  • Service Mesh (mTLS ambient): Istio ambient mode agrega una segunda capa de mTLS a nivel L4 (ztunnel), encriptando todo el tráfico TCP entre pods del namespace kafka-cdc — incluso el tráfico al listener plain (9092) queda encriptado a nivel de red.

ACLs: autorización granular

Las ACLs de Kafka operan como listas blancas — todo está denegado por default:

  1. Cada ACL define un principal (usuario SCRAM), un recurso (topic, group, cluster), un pattern (literal o prefix), y las operaciones permitidas.

  2. El authorizer del broker evalúa las ACLs en cada request del cliente.

  3. Pattern prefix permite reglas flexibles: name: cdc, patternType: prefix autoriza acceso a todos los topics que empiecen con cdc (incluyendo cdc.public.customers, cdc.public.orders).

  4. Si ninguna ACL matchea, el request se deniega con un error de autorización.

Gobierno y Compliance

Schema Registry — Reglas de Validación

Apicurio Registry enforza contratos de esquema. Las reglas globales previenen cambios breaking:

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

  • VALIDITY: FULL — los esquemas deben ser sintácticamente válidos

  • COMPATIBILITY: BACKWARD — los esquemas nuevos deben ser legibles por consumidores con la versión anterior

Audit Trail

  • Kafka retiene todos los eventos por el periodo de retención configurado (7 días por defecto)

  • Debezium captura el estado completo before/after de cada cambio en la base de datos

  • Los audit logs de OpenShift rastrean el acceso API al cluster

  • Schema Registry mantiene historial de versiones de cada esquema

Explorar esquemas registrados en Apicurio Registry.

Documentación Oficial