Security

Protecting backup data, configurations, and operations through identity management, encryption, access controls, and audit logging — with the same rigour applied to production Kafka data.

Backups contain a complete copy of your Kafka data. A compromised backup is as damaging as a compromised production cluster. The Security pillar ensures that every layer of your backup architecture — from credentials and network paths to storage buckets and audit trails — is hardened, monitored, and regularly reviewed.

Design Principles

1. Implement strong identity foundation — Apply the principle of least privilege to every service account, IAM role, and operator that interacts with backup infrastructure.
2. Enable traceability — Audit-log every backup, restore, and configuration change so you can answer who did what, when, where, and with what outcome.
3. Apply security at all layers — Secure data in transit, at rest, at the access layer, and inside configuration files. No single control should be the only line of defence.
4. Automate security best practices — Rotate credentials on a schedule, scan configurations for drift, and enforce policies via code rather than manual checklists.
5. Protect data at rest with encryption — Encrypt all backup data using customer-managed keys where compliance demands it, and verify encryption status continuously.
6. Prepare for security events — Maintain runbooks for credential revocation, backup quarantine, and forensic investigation so the team can respond quickly to incidents.

---

Best Practices

SEC-01: Identity & Access Management

Effective IAM starts with dedicated service accounts scoped to the minimum permissions each operation requires.

Least-Privilege Role Separation

Role	Storage Access	Kafka Access
Backup	Write-only to storage	Read-only from source Kafka
Restore	Read-only from storage	Write to target Kafka
Validate	Read-only from storage	None

tip

Use IAM roles (AWS), managed identities (Azure), or workload identity (GCP) instead of static credentials. These provide automatic credential rotation and eliminate the risk of leaked long-lived keys.

Enterprise: Role-Based Access Control

Enterprise editions support RBAC for multi-team environments, allowing administrators to grant granular permissions per team, topic pattern, or environment.

Configuration: AWS IAM Policy

Backup role — write-only storage with read-only Kafka:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "BackupWriteOnly",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:PutObjectAcl",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-kafka-backups",
        "arn:aws:s3:::my-kafka-backups/*"
      ]
    }
  ]
}

Restore role — read-only storage:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RestoreReadOnly",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-kafka-backups",
        "arn:aws:s3:::my-kafka-backups/*"
      ]
    }
  ]
}

Anti-Patterns

Anti-Patterns

• Admin credentials for backup operations — Over-privileged accounts increase blast radius if compromised.
• Same IAM role for backup and restore — Violates least privilege; a compromised backup process could overwrite or delete data.
• Static access keys — Long-lived keys are a top cause of cloud security incidents.
• No environment separation — Production and staging sharing credentials or storage accounts.

---

SEC-02: Data Protection at Rest

All backup data must be encrypted at rest, with key management appropriate to your compliance requirements.

Server-Side Encryption Options

Cloud	Default	Customer-Managed Key
AWS S3	SSE-S3 (AES-256)	SSE-KMS / SSE-C
Azure Blob	Microsoft-managed keys	Customer-managed keys (CMK)
GCS	Google-managed keys	Customer-managed encryption keys (CMEK)

Enterprise: Client-Side Encryption

Enterprise editions support client-side AES-256 encryption, ensuring data is encrypted before it leaves the backup process — providing defence-in-depth even if storage-layer encryption is misconfigured.

tip

For regulated industries (finance, healthcare), use customer-managed keys (CMK/CMEK) with automatic key rotation. Combine with S3 Object Lock or Azure immutable storage to protect against tampering and ransomware.

Configuration: S3 with KMS Encryption

storage:
  type: s3
  s3:
    bucket: my-kafka-backups
    region: eu-west-1
    encryption:
      type: aws:kms
      kms_key_id: arn:aws:kms:eu-west-1:123456789012:key/abcd-1234

Configuration: Enterprise Client-Side Encryption

storage:
  type: s3
  s3:
    bucket: my-kafka-backups
    region: eu-west-1
  encryption:
    enabled: true
    algorithm: AES-256
    key_provider: aws-kms
    kms_key_id: arn:aws:kms:eu-west-1:123456789012:key/abcd-1234

Anti-Patterns

Anti-Patterns

• Unencrypted storage buckets — Backup data readable by anyone with network access to the storage layer.
• Default S3 encryption without key management — SSE-S3 encrypts data but Amazon manages the keys; insufficient for regulatory requirements that mandate customer-controlled keys.
• Public buckets — S3 buckets or Azure containers with public access enabled, exposing backup data to the internet.

---

SEC-03: Data Protection in Transit

Encrypt all data moving between Kafka, the backup process, and cloud storage.

Kafka Connections

• Use TLS for all Kafka connections; mTLS is preferred for mutual authentication.
• Minimum TLS 1.2; prefer TLS 1.3 where supported.
• Validate broker certificates against a trusted CA.

Storage Backend Connections

HTTPS is the default for S3, Azure Blob, and GCS. Ensure custom or on-premises storage endpoints also enforce TLS.

Private Network Paths

Cloud	Service	Benefit
AWS	S3 Gateway Endpoint	Traffic stays within VPC
Azure	Private Endpoint	Private IP for storage account
GCP	Private Google Access	No public IP required

warning

VPC endpoints and private links prevent backup data from traversing the public internet, reducing exposure to man-in-the-middle attacks and data exfiltration.

Configuration: Kafka TLS / mTLS

source:
  bootstrap_servers:
    - kafka:9093
  security:
    security_protocol: SASL_SSL
    ssl_ca_location: /certs/ca.crt
    ssl_certificate_location: /certs/client.crt
    ssl_key_location: /certs/client.key

kafka-backup supports the following security properties:

Property	Description
security_protocol	SASL_SSL, SSL, SASL_PLAINTEXT, PLAINTEXT
ssl_ca_location	Path to CA certificate
ssl_certificate_location	Path to client certificate
ssl_key_location	Path to client private key

Anti-Patterns

Anti-Patterns

• PLAINTEXT connections — Data and credentials sent in the clear on the network.
• Backup traffic over the public internet — Without VPC endpoints, data traverses public networks unnecessarily.
• Self-signed certificates without a trust chain — Disabling certificate verification removes protection against MITM attacks.
• TLS 1.0 / 1.1 — Deprecated protocols with known vulnerabilities.

---

SEC-04: Secrets Management

Credentials must never appear in plain text inside configuration files or source control.

Recommended Secrets Backends

Backend	Use Case
AWS Secrets Manager / SSM Parameter Store	AWS-native workloads
Azure Key Vault	Azure-native workloads
HashiCorp Vault	Multi-cloud or on-premises
Kubernetes Secrets (encrypted with KMS)	Kubernetes-native deployments

tip

Use short-lived credentials wherever possible — AWS STS tokens, federated identities, or OIDC-based workload identity. These expire automatically, limiting the window of exposure if intercepted.

Environment Variable Substitution

kafka-backup supports ${VAR_NAME} environment variable substitution in configuration files, allowing secrets to be injected at runtime from any secrets backend:

source:
  bootstrap_servers:
    - ${KAFKA_BOOTSTRAP_SERVERS}
  security:
    security_protocol: SASL_SSL
    sasl_mechanism: ${SASL_MECHANISM}
    sasl_username: ${SASL_USERNAME}
    sasl_password: ${SASL_PASSWORD}

Configuration: Kubernetes Secret

apiVersion: v1
kind: Secret
metadata:
  name: kafka-backup-credentials
  namespace: kafka-backup
type: Opaque
stringData:
  SASL_USERNAME: backup-service-account
  SASL_PASSWORD: changeme-use-sealed-secrets
  AWS_ACCESS_KEY_ID: AKIAIOSFODNN7EXAMPLE
  AWS_SECRET_ACCESS_KEY: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

warning

The example above uses stringData for readability. In production, use SealedSecrets, External Secrets Operator, or Vault Agent to inject secrets securely rather than storing them directly in Kubernetes manifests committed to Git.

Anti-Patterns

Anti-Patterns

• Plaintext credentials in YAML committed to Git — Secrets in version control are exposed to anyone with repository access and persist in Git history.
• Long-lived static access keys — Keys that never rotate accumulate risk over time.
• Shared credentials across environments — A compromise in staging exposes production.

---

SEC-05: Audit & Compliance

Maintain a tamper-evident record of every backup operation to support compliance audits and incident investigations.

Enterprise: Audit Logging

Enterprise editions emit structured audit events capturing:

• Who — service account or user identity
• What — operation performed (backup, restore, validate, configure)
• When — timestamp with timezone
• Where — source cluster, target storage, topic(s)
• Outcome — success, failure, partial completion

Cloud Storage Access Logging

Cloud	Service	Captures
AWS	S3 Server Access Logging + CloudTrail	Object-level reads/writes, API calls
Azure	Storage Analytics Logging	Read/write/delete operations
GCP	Cloud Audit Logs	Data access and admin activity

tip

Align log retention periods with your compliance framework (SOC 2, PCI-DSS, HIPAA). Configure alerts for anomalous operations such as unexpected restore activity, bulk deletes, or access from unfamiliar IP ranges.

Configuration: Enterprise Audit Logging

audit:
  enabled: true
  destination:
    type: datadog
    api_key: ${DATADOG_API_KEY}
    site: datadoghq.eu
  events:
    - backup.started
    - backup.completed
    - backup.failed
    - restore.started
    - restore.completed
    - restore.failed
    - config.changed
    - credentials.rotated
  retention:
    days: 365

Anti-Patterns

Anti-Patterns

• No audit trail for restore operations — Restores modify production data; without logging, you cannot trace who restored what or diagnose issues.
• Audit logs co-located with backups — An attacker who compromises backup storage can also tamper with logs. Store logs in a separate, append-only destination.
• No log retention policy — Logs that expire before an audit window closes leave gaps in compliance evidence.

---

SEC-06: Data Masking & Privacy

Backup data often contains personally identifiable information (PII) subject to privacy regulations such as GDPR, CCPA, and HIPAA.

Enterprise: Field-Level Data Masking

Enterprise editions support schema-aware, field-level data masking that integrates with Schema Registry to identify and redact sensitive fields before data is written to storage.

Capabilities include:

• Right to be forgotten — Delete or mask specific records to satisfy GDPR erasure requests.
• Masking policies per topic and field — Define rules such as mask email in user-events or hash ssn in customer-records.
• Schema Registry integration — Automatically detect new fields and apply default masking policies.

Tiered Backup Strategy

Separate backup data into tiers based on sensitivity:

Tier	Access	Retention	Content
Full (unmasked)	Restricted — security/compliance team only	Short (regulatory minimum)	Complete data for disaster recovery
Masked	Broader — development, analytics teams	Longer	PII redacted for safe use in non-production

warning

Masking must be applied at backup time, not at restore time. Once unmasked PII is written to storage, it is subject to the same data protection obligations as the original Kafka topic.

Anti-Patterns

Anti-Patterns

• Backing up PII without masking — Creates a shadow copy of sensitive data outside the controls applied to production systems.
• No GDPR deletion process for backups — Failing to honour erasure requests in backup data is a compliance violation.
• Assuming backups are exempt from privacy regulations — Regulators consider backups as part of the data lifecycle; all obligations apply.

---

Review Questions

Use the following questions during architecture reviews to assess your backup security posture:

1. Are dedicated, least-privilege service accounts used for backup, restore, and validate operations?
2. Is IAM role assumption or workload identity used instead of static access keys?
3. Is all backup data encrypted at rest with appropriate key management (SSE-KMS, CMK, CMEK)?
4. Are all Kafka connections secured with TLS 1.2+ or mTLS?
5. Does backup traffic stay within private network paths (VPC endpoints, private links)?
6. Are secrets managed through a dedicated secrets backend rather than stored in configuration files?
7. Are credentials short-lived and rotated automatically?
8. Is there an audit trail for every backup, restore, and configuration change?
9. Are audit logs stored separately from backup data with appropriate retention policies?
10. Is PII identified, masked, or encrypted before being written to backup storage?

---

Resources

• Security Setup Guide — Step-by-step TLS, SASL, and encryption configuration
• Encryption (Enterprise) — Client-side encryption and key management
• RBAC (Enterprise) — Role-based access control for multi-team environments
• Audit Logging (Enterprise) — Structured audit events and compliance reporting
• Schema Registry (Enterprise) — Schema-aware masking and data governance