Redpanda’s security posture is more about proactive hardening than reactive auditing.
Let’s watch Redpanda in action, securing itself. Imagine a cluster running across three nodes: redpanda-01, redpanda-02, and redpanda-03.
# On redpanda-01
rpk cluster config get
# Expected output snippet:
# admin_api_tls: { enabled: true, cert_file: "/etc/redpanda/certs/admin.crt", key_file: "/etc/redpanda/certs/admin.key" }
# security: { enable_token_auth: true, enable_sasl_plain: false, enable_sasl_ssl: true }
# tls: { cert_file: "/etc/redpanda/certs/server.crt", key_file: "/etc/redpanda/certs/server.key" }
This output tells us TLS is enabled for both admin APIs and client connections. It also shows token authentication is on, while SASL/PLAIN is off (good, as it’s unencrypted) and SASL/SSL is on. This is the baseline: encrypted communication and a modern auth mechanism.
Now, let’s consider a common hardening step: disabling anonymous access. By default, some systems might allow unauthenticated connections. Redpanda, however, needs explicit configuration for this.
The Problem Redpanda Solves: Secure Data Ingestion and Streaming
At its core, Redpanda is a streaming data platform. It needs to be secure because it’s often handling sensitive data. This means controlling who can connect, what they can do, and ensuring the data in transit and at rest is protected. Redpanda achieves this through a combination of TLS for encryption and robust authentication/authorization mechanisms.
Internal Mechanics: How Redpanda Enforces Security
Redpanda uses mTLS (mutual TLS) for inter-node communication, ensuring that only authenticated Redpanda nodes can join the cluster. For client connections, it supports TLS-based authentication (using client certificates) or token-based authentication. Authorization is handled via Access Control Lists (ACLs) that define permissions for specific users on topics and consumer groups.
Levers for Control: Your Security Configuration
The primary configuration file for Redpanda is redpanda.yaml. Key security settings include:
admin_api_tls: Controls TLS for the administrative API.enabled:trueorfalse.cert_file,key_file: Paths to the server certificate and private key.
tls: Controls TLS for client connections.enabled:trueorfalse.cert_file,key_file: Paths to the server certificate and private key.ca_file: Path to the Certificate Authority (CA) bundle for client certificate validation.
security: Global security settings.enable_token_auth:trueorfalse. Enables Redpanda’s native token authentication.enable_sasl_plain:trueorfalse. Enables SASL PLAIN, which sends credentials in clear text over the network. Should generally befalseunless used over an already TLS-encrypted connection.enable_sasl_ssl:trueorfalse. Enables SASL over TLS.enable_authorization:trueorfalse. Enables ACLs for fine-grained access control.
Let’s say you’ve just set up Redpanda and want to ensure only authenticated clients can access it.
# On your Redpanda node(s), edit redpanda.yaml
vim /etc/redpanda/redpanda.yaml
You’d ensure sections look like this:
admin_api_tls:
enabled: true
cert_file: /etc/redpanda/certs/admin.crt
key_file: /etc/redpanda/certs/admin.key
tls:
enabled: true
cert_file: /etc/redpanda/certs/server.crt
key_file: /etc/redpanda/certs/server.key
ca_file: /etc/redpanda/certs/ca.crt # For client auth via mTLS
security:
enable_token_auth: true
enable_sasl_plain: false # Keep this false for plain text security
enable_sasl_ssl: true # Use SASL over TLS if not using token auth
enable_authorization: true # Crucial for controlling access
After modifying redpanda.yaml, you’d restart the Redpanda service.
# On systemd-based systems
sudo systemctl restart redpanda
With enable_authorization: true, you then need to create users and grant them permissions using rpk.
# Create a user 'app_user'
rpk user add app_user --password "supersecretpassword"
# Grant read access to 'my_topic' for 'app_user'
rpk topic acl permit -a read -t my_topic -u app_user
# Grant read access to 'my_topic' for 'app_user' on consumer group 'my_consumer_group'
rpk consumer-group acl permit -a read -c my_consumer_group -t my_topic -u app_user
This layered approach, from cluster-wide TLS to per-topic ACLs, ensures a robust security posture.
The primary mechanism Redpanda uses for inter-node communication, beyond initial bootstrapping, is a form of gossip protocol that relies on TLS for encryption and authentication. When a new node attempts to join a cluster, it presents its certificate to existing nodes, which are validated against the cluster’s CA. This prevents rogue nodes from infiltrating the cluster. For client connections, Redpanda can be configured to require client certificates (mTLS) or rely on its token authentication system, which itself is secured over TLS. The authorization layer, enabled by enable_authorization: true, acts as the gatekeeper, consulting ACLs stored within the cluster’s raft log to determine if a validated user has the necessary permissions for a requested operation.
Once you’ve secured your Redpanda cluster with TLS and ACLs, the next logical step is to implement auditing to track who is doing what.