Configure Authentication for Redpanda in Kubernetes

Authentication verifies the identity of users and applications that connect to Redpanda clusters.

Different Redpanda APIs support different authentication methods. You can configure multiple listeners for each API, and you can configure each listener with an authentication method. Redpanda APIs support these authentication methods:

API Supported Authentication Methods

Kafka API

  • SASL

    • SASL/SCRAM

    • SASL/OAUTHBEARER (OIDC)

Admin API

  • Basic authentication

  • OIDC

HTTP Proxy (PandaProxy)

  • Basic authentication

  • OIDC

Schema Registry

  • Basic authentication

  • OIDC

Prerequisites

You must have the following:

  • Kubernetes cluster. Ensure you have a running Kubernetes cluster, either locally, such as with minikube or kind, or remotely.

  • Kubectl. Ensure you have the kubectl command-line tool installed and configured to communicate with your cluster.

Enable authentication

When you enable authentication in the Redpanda Helm chart:

  • SASL authentication is enabled for the Kafka API listeners

  • Basic authentication is enabled for the HTTP Proxy and Schema Registry listeners

  • Authorization is enabled

When enabling authentication, you must create at least one superuser. A superuser is a special user that has all permissions on the cluster. They can grant permissions to other users through access control lists (ACLs).

Without a superuser, you can create other users, but you can’t grant them permissions to the cluster.

Enabling authorization without a superuser can result in being locked out of the cluster, as you would not have the necessary permissions to manage the cluster’s settings or users.

Create superusers

To create one or more superusers, you must define a username and password. You can also set the SASL/SCRAM authentication mechanism for each superuser. Redpanda supports the following SASL/SCRAM authentication mechanisms for the Kafka API:

  • SCRAM-SHA-256

  • SCRAM-SHA-512

You can use the following to store superuser credentials:

For default values and documentation for configuration options, see the values.yaml file.

Use a Secret resource

To use a Secret resource to store superuser credentials:

  1. Create a file in which to store the credentials.

    echo '<superuser-name>:<superuser-password>:<superuser-authentication-mechanism>' >> superusers.txt
    bash

    Replace the following placeholders with your own values for the superuser:

    • <superuser-name>: The name of the superuser.

    • <superuser-password>: The superuser’s password.

    • <superuser-authentication-mechanism>: The authentication mechanism. Valid values are SCRAM-SHA-256 or SCRAM-SHA-512.

      Or, leave this placeholder empty to set it to the default authentication mechanism. The default is SCRAM-SHA-512. This default is applied to all superusers that don’t include an explicit authentication mechanism.

  2. Use the file to create a Secret resource in the same namespace as your Redpanda cluster.

    kubectl --namespace <namespace> create secret generic redpanda-superusers --from-file=superusers.txt
    bash

  3. Enable SASL and create the superuser using your Secret:

    redpanda-cluster.yaml
    apiVersion: cluster.redpanda.com/v1alpha1
kind: Redpanda
metadata:
  name: redpanda
spec:
  chartRef: {}
  clusterSpec:
    auth:
      sasl:
        enabled: true
        secretRef: "redpanda-superusers"
        users: []
    yaml
    kubectl apply -f redpanda-cluster.yaml --namespace <namespace>
    bash

    • auth.sasl.enabled: Enable authentication.

    • auth.sasl.secretRef: The name of the Secret that contains the superuser credentials. The Secret must be in the same namespace as the Redpanda cluster.

    • auth.sasl.users: Make sure that this list is empty. Otherwise, the chart will try to create a new Secret with the same name as the one set in auth.sasl.secretRef and fail because it already exists.

Use a YAML list

You can use a YAML list item to store superuser credentials in configuration settings.

Replace the following placeholders with your own values for the superuser:

  • <superuser-name>: The name of the superuser.

  • <superuser-password>: The superuser’s password.

  • <superuser-authentication-mechanism>: The authentication mechanism. Valid values are SCRAM-SHA-256 or SCRAM-SHA-512.

    If you leave this placeholder empty, the Helm chart uses the default authentication mechanism. The default is SCRAM-SHA-512. This default is applied to all superusers that don’t include an explicit authentication mechanism.

redpanda-cluster.yaml
apiVersion: cluster.redpanda.com/v1alpha1
kind: Redpanda
metadata:
  name: redpanda
spec:
  chartRef: {}
  clusterSpec:
    auth:
      sasl:
        enabled: true
        secretRef: redpanda-superusers
        users:
          - name: <superuser-name>
            password: <superuser-password>
            mechanism: <superuser-authentication-mechanism>
yaml
kubectl apply -f redpanda-cluster.yaml --namespace <namespace>
bash

  • auth.sasl.enabled: Enable authentication.

  • auth.sasl.secretRef: The name of the Secret that the Redpanda Helm chart will create and use to store the superuser credentials listed in auth.sasl.users. This Secret must not already exist in the cluster.

  • auth.sasl.users: A list of superusers.

As a security best practice:

  • Don’t use the superuser to interact with the cluster.

  • Don’t delete the superuser (in case you need to grant permissions to new users later).

    When you create the superuser, you specify a password, which adds a level of security. If you delete the user, someone else could re-create the user with a different password.

Edit superusers

You can add new superusers to the cluster or update existing users. For example, if you wanted to rotate credentials for superusers, you could update the username or password of an existing superuser.

You cannot delete superusers by changing the Helm values or updating the Secret.

  • If you created superusers using a Secret, you can edit the superusers.txt file and reapply the Secret resource:

    kubectl create secret generic redpanda-superusers \
  --namespace <namespace> \
  --from-file=superusers.txt \
  --save-config \
  --dry-run=client -o yaml | kubectl apply -f -
    bash

    The config-watcher sidecar in the Pod polls the Secret resource for changes and triggers a rolling upgrade to add the new superusers to the Redpanda cluster.

  • If you created superusers using a YAML list, you can update the list:

    redpanda-cluster.yaml
    apiVersion: cluster.redpanda.com/v1alpha1
kind: Redpanda
metadata:
  name: redpanda
spec:
  chartRef: {}
  clusterSpec:
    auth:
      sasl:
        enabled: true
        secretRef: redpanda-superusers
        users:
          - name: <superuser-name>
            password: <new-superuser-password>
            mechanism: <superuser-authentication-mechanism>
    yaml
    kubectl apply -f redpanda-cluster.yaml --namespace <namespace>
    bash

Authentication for the Kafka API

Redpanda supports the following authentication methods for the Kafka API:

  • SASL (Simple Authentication and Security Layer)

SASL

SASL provides a flexible and adaptable framework for implementing various authentication mechanisms. Redpanda supports these SASL mechanisms:

Enable SASL

To enable SASL authentication for the Kafka API, set the authentication_method property of the Kafka listeners to sasl.

The Redpanda Helm chart sets the authentication_method property to sasl for all Kafka listeners by default when you enable authentication.

Enable SASL with TLS encryption

SASL provides authentication, but not encryption. To provide encryption, you can enable TLS in addition to SASL. See TLS for Redpanda in Kubernetes.

TLS is enabled in the Helm chart by default.

SASL/SCRAM

SASL/SCRAM does not require sending passwords over the network, even in an encrypted form. It uses a challenge-response mechanism, ensuring that the password is not directly accessible to the server. It works with hashed passwords, providing additional security against dictionary attacks.

Create SCRAM users

When you have SASL authentication enabled for your Redpanda cluster, you can create SCRAM users. Redpanda supports the following SASL/SCRAM authentication mechanisms for the Kafka API:

  • SCRAM-SHA-256

  • SCRAM-SHA-512

By default, SCRAM users don’t have any permissions in the cluster. Only superusers can grant permissions to new users through ACLs.

  1. To create the SCRAM user <my-user> with a password <change-this-password>, run rpk security user create:

    rpk security user create <my-user> \
  -p '<change-this-password>' \
  --mechanism SCRAM-SHA-256
    bash
    Enclose passwords in single quotes to avoid conflicts with special characters. Enclosing characters in single quotes preserves the literal value of each character.

  2. Use the rpk security acl create command to grant create and describe permissions to myuser in the cluster:

    rpk security acl create --allow-principal User:myuser \
  --operation create,describe \
  --cluster \
  -X user=<superuser-name> \
  -X pass='<superuser-password>' \
  -X sasl.mechanism=<superuser-authentication-mechanism>
    bash

  3. Grant the new user describe privileges for a topic called myfirsttopic:

    rpk security acl create --allow-principal User:myuser \
  --operation describe \
  --topic myfirsttopic \
  -X user=<superuser-name> \
  -X pass='<superuser-password>' \
  -X sasl.mechanism=<superuser-authentication-mechanism>
    bash
    You must grant privileges for specific topics. Even if a user has describe privileges for a cluster, it does not mean that the user is granted describe privileges for topics.

See also: User create.

Connect to Redpanda

This section provides examples of connecting to Redpanda as a SCRAM user when SASL/SCRAM authentication is enabled.

Create a topic as the myuser user by running rpk topic create:

rpk topic create myfirsttopic \
  -X user=myuser \
  -X pass='changethispassword' \
  -X sasl.mechanism=SCRAM-SHA-256
bash

To describe the topic, run rpk topic describe:

rpk topic describe myfirsttopic \
  -X user=myuser \
  -X pass='changethispassword' \
  -X sasl.mechanism=SCRAM-SHA-256
bash

For more details on connecting to Redpanda, see Connect to Redpanda in Kubernetes.

Configure Schema Registry and HTTP Proxy to connect to Redpanda with SASL

Schema Registry and HTTP Proxy connect to Redpanda over the Kafka API. For the Kafka username and password, Redpanda uses ephemeral credentials internal to the cluster. Ephemeral credentials are regular SCRAM credentials, but they’re only stored in memory and are lost when a broker restarts. When the Schema Registry or HTTP Proxy start up, they broadcast an ephemeral credential to other brokers over the internal RPC. If authentication fails to a particular broker, new ephemeral credentials are sent to that broker, and the service reconnects.

Schema Registry and HTTP Proxy support only the SASL/SCRAM mechanism.

OAUTHBEARER (OIDC)

OpenID Connect (OIDC) authentication requires an Enterprise license. To upgrade, contact Redpanda sales.

When you enable OIDC, Redpanda and Redpanda Console can delegate the authentication process to an external identity provider (IdP) such as Okta, Azure AD, or on-premise Active Directory Federation Service (AD FS). With OIDC enabled, Redpanda does not need to manage user credentials directly, but can instead rely on the trusted authentication capabilities of established IdPs.

Redpanda’s implementation of OIDC provides SASL/OAUTHBEARER support for the Kafka API, and supports standard OIDC authentication across all other HTTP APIs, including Schema Registry, HTTP Proxy, and the Admin API.

OIDC is not supported by rpk or Redpanda Cloud. While rpk does not support OIDC, it does support configuring Redpanda with OIDC as a SASL mechanism.
OIDC credentials flow and access token validation

Before configuring OIDC, you should understand the credentials flow, and in particular, the validation claims included in the access token, as you will need to provide them in the OIDC configuration.

Redpanda’s implementation of OIDC adheres to the client credentials flow defined in OAuth 2.0 RFC 6749, section 4.4 in which a client obtains an access token from the authorization server, and provides this access token to Redpanda, either using SASL/OAUTHBEARER for the Kafka API, or an HTTP Authorization (Bearer) header.

The access token is a bearer token. A bearer token is used for authentication and authorization in web applications and APIs, and holds user credentials, usually in the form of random strings of characters. Bearer tokens are generated based on protocols and specifications such as JWT (JSON Web Token), which has a header, payload, and signature. The signature must be verified according to the JWK. Claims inside the token and the token signature must both be validated. After validation, a configurable claim from the token payload is extracted as the principal and attached to the connection, as with any other authentication method.

Following is an example JWT header:

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "tMQzailSAdaW4nojXxES9"
}
json

Following is an example JWT payload:

{
  "iss": "https://dev-ltxchcls4igzho78.us.auth0.com/",
  "sub": "3JJeI4tmMC6v8mCVCSDnAGVf2vrnJ0BT@clients",
  "aud": "localhost",
  "iat": 1694430088,
  "exp": 1694516488,
  "azp": "3JJeI4tmMC6v8mCVCSDnAGVf2vrnJ0BT",
  "scope": "email2",
  "gty": "client-credentials"
}
json

Following are additional validation claims (JWT properties) that are included in the access token:

  • alg: The signature algorithm. The extension point in the JWT header is the signature algorithm used to sign the token, and cannot contain the value none.

  • aud: Audience. Must match the configuration specified in oidc_token_audience. Cannot contain the value none.

  • kid: Key identifier. Must match any of the public JWK listed in the jwks_uri endpoint.

  • exp: Expiration. The timestamp listed is greater than current time. Must validate within acceptable bounds of the value specified in oidc_clock_skew_tolerance. A clock skew tolerance period may be configured by an Admin to account for clock drift between Redpanda and the OIDC Identity Provider (IdP).

  • iss: Issuer. Must exactly match the issuer property of the JSON returned from the URL specified in oidc_discovery_url.

  • scope: Scope. Must include the value openid.

  • sub: Subject. This default claim identifies the principal subject. While sub is the default mapping ($.sub) in Redpanda, any claim within the JWT can be mapped to a Redpanda principal.

Enable OIDC

  1. Register a client application with your IdP.

    A client application, in this context, refers to any application or service that will authenticate against the Redpanda cluster using OIDC. This registration process involves creating a new entry in the IdP’s management console for the application, sometimes called a client. During this process, you’ll specify details about your application, such as the type of application, the callback URLs, and any other required information as per your IdP’s requirements. In an enterprise environment, OIDC integration typically requires coordination with your organization’s security team.

  2. Enable SASL authentication if it’s not already enabled.

  3. Configure ACLs for your users so they can access Redpanda resources.

  4. Configure OIDC:

    redpanda-cluster.yaml
    apiVersion: cluster.redpanda.com/v1alpha1
kind: Redpanda
metadata:
  name: redpanda
spec:
  chartRef: {}
  clusterSpec:
    auth:
      sasl:
        enabled: true
      secretRef: redpanda-superusers
    config:
      cluster:
        sasl_mechanisms:
          - "SCRAM"
          - "OAUTHBEARER"
        oidc_discovery_url: "<discovery-url>"
        oidc_token_audience: "<token-audience>"
        oidc_principal_mapping: "<json-path>"
        oidc_clock_skew_tolerance: <tolerance>
        oidc_token_expire_disconnect: <true-or-false>
        oidc_keys_refresh_interval: <interval>
    yaml
    kubectl apply -f redpanda-cluster.yaml --namespace <namespace>
    bash

    • config.cluster.sasl_mechanisms: Enable SCRAM and OIDC SASL mechanisms.

    • config.cluster.oidc_discovery_url: The discovery URL of your identity provider (IdP). The default is https://auth.prd.cloud.redpanda.com/.well-known/openid-configuration.

    • config.cluster.oidc_token_audience: The intended audience of the token. The default is redpanda.

    • config.cluster.oidc_principal_mapping: The principal mapping, which is a JSON path that extracts a principal from any claim in the access token payload. The default is $.sub.

    • config.cluster.oidc_clock_skew_tolerance: The amount of time (in seconds) to allow for when validating the expiration claim in the token.

    • config.cluster.oidc_token_expire_disconnect: Whether to enable OIDC to disconnect clients when their token expires.

    • config.cluster.oidc_keys_refresh_interval: The amount of time keys from the jwks_uri are cached.

Authentication for the HTTP APIs

The following HTTP APIs support basic authentication and OIDC authentication:

  • Admin API

  • Schema Registry

  • HTTP Proxy

Basic authentication

Basic authentication provides a method for securing HTTP endpoints. With basic authentication enabled, HTTP user agents, such as web browsers, must provide a username and password when making a request.

Before you can enable basic authentication for these HTTP APIs, you must enable SASL authentication for the Kafka API. Then, both SCRAM users and superusers can use their credentials to access them:

  • HTTP Proxy: Access to the Kafka API impersonates the user whose credentials were used to authenticate to HTTP Proxy, and the user is subject to authorization restrictions by Redpanda ACLs. To support this design, Redpanda passes the username/password in memory to a SASL-enabled Kafka client.

  • Schema Registry: Authorization is "all or nothing": if the user presents a valid user account, then they have full read/write access.

To add users to the Redpanda credential store that HTTP basic authentication uses, create users with rpk security user create.

When you enable authentication in the Redpanda Helm chart, the Schema Registry API and the HTTP Proxy API are configured with basic authentication by default.

To enable basic authentication for the Admin API:

redpanda-cluster.yaml
apiVersion: cluster.redpanda.com/v1alpha1
kind: Redpanda
metadata:
  name: redpanda
spec:
  chartRef: {}
  clusterSpec:
    auth:
      sasl:
        enabled: true
      secretRef: redpanda-superusers
    config:
      cluster:
        admin_api_require_auth: true
yaml
kubectl apply -f redpanda-cluster.yaml --namespace <namespace>
bash

Connect to the HTTP API

By default, the Redpanda Helm chart configures an internal and external listener for the HTTP Proxy API.

To access the internal listener:

kubectl exec <pod-name> --namespace <namespace> -- curl http://redpanda-0.redpanda.redpanda.svc.cluster.local:8082/topics -u <username>:<password> -sS
bash

If TLS is enabled, specify the HTTPS protocol and pass the path to the ca.crt file:

kubectl exec <pod-name> --namespace <namespace> -- curl https://redpanda-0.redpanda.redpanda.svc.cluster.local:8082/topics --cacert /etc/tls/certs/default/ca.crt -u <username>:<password> -sS
bash
If the broker’s certificate is signed by a well-known, trusted CA, and you’re confident about the integrity of your system’s CA trust store, you don’t need the --cacert flag.

For all available endpoints, see HTTP Proxy API.

Connect to the Schema Registry API

By default, the Redpanda Helm chart configures an internal and external listener for the Schema Registry API.

To access the internal listener:

kubectl exec <pod-name> --namespace <namespace> -- curl http://redpanda-0.redpanda.redpanda.svc.cluster.local:8081/subjects -u <username>:<password> -sS
bash

If TLS is enabled, specify the HTTPS protocol and pass the path to the ca.crt file:

kubectl exec <pod-name> --namespace <namespace> -- curl https://redpanda-0.redpanda.redpanda.svc.cluster.local:8081/subjects --cacert /etc/tls/certs/default/ca.crt -u <username>:<password> -sS
bash
If the broker’s certificate is signed by a well-known, trusted CA, and you’re confident about the integrity of your system’s CA trust store, you don’t need the --cacert flag.

For all available endpoints, see Redpanda Schema Registry API.

OIDC

You can configure the HTTP APIs to authenticate users with the OIDC bearer token. By using OIDC, you can centralize credentials and provide a password-free SSO experience.

See Enable OIDC to configure the required OIDC cluster configuration properties before enabling OIDC for the HTTP APIs. You can configure OIDC without enabling it for the Kafka API.

If you enable OIDC authentication for the Admin API, you must also create a SCRAM superuser so that you can use rpk to create ACLs. rpk supports only basic authentication for the Admin API. See Authentication for the HTTP APIs.

To enable OIDC for the HTTP API listeners as well as basic authentication, include OIDC in the http_authentication cluster property list:

redpanda-cluster.yaml
apiVersion: cluster.redpanda.com/v1alpha1
kind: Redpanda
metadata:
  name: redpanda
spec:
  chartRef: {}
  clusterSpec:
    auth:
      sasl:
        enabled: true
    config:
      cluster:
        sasl_mechanisms:
          - "SCRAM"
          - "OAUTHBEARER"
        http_authentication:
          - "BASIC"
          - "OIDC"
yaml
kubectl apply -f redpanda-cluster.yaml --namespace <namespace>
bash

Connect to the HTTP API

By default, the Redpanda Helm chart configures an internal and external listener for the HTTP Proxy API.

To access the internal listener:

kubectl exec <pod-name> --namespace <namespace> -- curl http://redpanda-0.redpanda.redpanda.svc.cluster.local:8082/topics -H "Authorization: Bearer <bearer-token>" -sS
bash

If TLS is enabled, specify the HTTPS protocol and pass the path to the ca.crt file:

kubectl exec <pod-name> --namespace <namespace> -- curl https://redpanda-0.redpanda.redpanda.svc.cluster.local:8082/topics --cacert /etc/tls/certs/default/ca.crt -H "Authorization: Bearer <bearer-token>" -sS
bash
If the broker’s certificate is signed by a well-known, trusted CA, and you’re confident about the integrity of your system’s CA trust store, you don’t need the --cacert flag.

For all available endpoints, see HTTP Proxy API.

Connect to the Schema Registry API

By default, the Redpanda Helm chart configures an internal and external listener for the Schema Registry API.

To access the internal listener:

kubectl exec <pod-name> --namespace <namespace> -- curl http://redpanda-0.redpanda.redpanda.svc.cluster.local:8081/subjects -H "Authorization: Bearer <bearer-token>" -sS
bash

If TLS is enabled, specify the HTTPS protocol and pass the path to the ca.crt file:

kubectl exec <pod-name> --namespace <namespace> -- curl https://redpanda-0.redpanda.redpanda.svc.cluster.local:8081/subjects --cacert /etc/tls/certs/default/ca.crt -H "Authorization: Bearer <bearer-token>" -sS
bash
If the broker’s certificate is signed by a well-known, trusted CA, and you’re confident about the integrity of your system’s CA trust store, you don’t need the --cacert flag.

For all available endpoints, see Redpanda Schema Registry API.

Disable authentication

To disable authentication for a listener, set authentication_method to none:

redpanda-cluster.yaml
apiVersion: cluster.redpanda.com/v1alpha1
kind: Redpanda
metadata:
  name: redpanda
spec:
  chartRef: {}
  clusterSpec:
    auth:
      sasl:
        enabled: true
    listeners:
      http:
        authentication_method: "none"
      schemaRegistry:
        authentication_method: "none"
      kafka:
        authentication_method: "none"
yaml
kubectl apply -f redpanda-cluster.yaml --namespace <namespace>
bash

Troubleshoot

This section lists error messages and provides ways to diagnose and solve issues. For more troubleshooting steps, see Troubleshoot Redpanda in Kubernetes.

Is SASL missing?

This error appears when you try to interact with a cluster that has SASL enabled without passing a user’s credentials.

unable to request metadata: broker closed the connection immediately after a request was issued, which happens when SASL is required but not provided: is SASL missing?

If you’re using rpk, ensure to specify the -X user, -X pass, and -X sasl.mechanism flags.

For all available flags, see the rpk command reference.

Unable to continue with update: Secret

When you use a YAML list to specify superusers, the Helm chart creates a Secret using the value of auth.sasl.secretRef as the Secret’s name, and stores those superusers in the Secret. If the Secret already exists in the namespace when you deploy Redpanda, the following error is displayed:

Error: UPGRADE FAILED: rendered manifests contain a resource that already exists. Unable to continue with update: Secret

To fix this error, ensure that you use only one of the following methods to create superusers:

  • auth.sasl.secretRef

  • auth.sasl.users

Next steps

Suggested reading