Redpanda recommends that you always configure encryption, authentication, and authorization for production environments.
Different components of Redpanda support different authentication methods. You can configure multiple listeners with
redpanda.yaml, and with each listener, you can configure the
authentication_methodand optionally TLS or mTLS.
Authorization works in tandem with authentication. Access-control lists (ACLs) provide a way to configure fine-grained access to provisioned users. ACLs work with SASL/SCRAM and with mTLS with principal mapping for authentication.
By default, Redpanda data is sent unencrypted. A security best practice is to enable encryption with TLS or mTLS.
For self-hosted clusters deployed on a public cloud platform, cloud provider IAM roles provide a safer alternative to the less secure static credential system, which is based on access keys. With static credentials, the access key and secret key are stored in plaintext in the configuration file.
Integrating Redpanda Console with GitHub allows your users to use their GitHub identities to sign-in to Console.
Integrating Redpanda Console with Google allows your users to use their Google identities to sign in to Console.
Integrating Redpanda Console with Okta allows your users to use their Okta identities to sign in to Redpanda Console.
If you would like to integrate an OpenID Connect (OIDC) compatible identity provider that is not yet natively supported in Console, you can configure the generic OIDC provider.
All concepts described in this section are compatible with Kafka and its client libraries and CLIs. This section does not cover ways you can protect your Redpanda cluster externally; for example, through network ACLs or private networks.