Security
Learn how to configure authentication, authorization, encryption, listeners, and other security features.
This section does not cover ways you can protect your Redpanda cluster externally; for example, through network ACLs or private networks.
Secure a new cluster
| By default, Redpanda doesn’t require authentication. The Admin API listens on all network interfaces, and any client that can reach it has superuser access: it can create and delete users and change cluster configuration. Secure your cluster before you allow network access to it. |
Before you expose a Redpanda cluster to a network:
-
Require authentication on the Admin API by setting
admin_api_require_authtotrueand listing your administrators insuperusers. Enabling SASL for the Kafka API doesn’t secure the Admin API on its own. See Secure the Admin API before first start (Linux) or Authentication (Kubernetes). -
Enable SASL authentication and authorization for the Kafka API.
-
Require authentication on the Schema Registry and HTTP Proxy listeners.
-
Enable TLS on every listener.
-
Restrict network access to the Admin API port (9644 by default) to the hosts that administer the cluster.
To check these settings on a running cluster, see the production readiness checklist.
Redpanda supports multiple forms of authentication including SASL/SCRAM, mTLS with principal mapping, and basic authentication.
Redpanda provides mechanisms for controlling user permissions, including ACLs, role-based access control, and group-based access control.
Configure Redpanda to operate in FIPS-compliant mode.
Enable encryption with TLS or mTLS.
Use listeners to advertise the location of the broker, so other brokers in the cluster can be found.
For Redpanda Streaming clusters deployed on a public cloud platform, cloud provider IAM roles and managed identities provide a safer alternative to the less secure static credential system, which is based on access keys.