Skip to main content
Version: 22.3

Configuring Redpanda SASL on Kubernetes

info

See Configuring Redpanda SASL on Kubernetes for the most up-to-date instructions using the redpanda Helm chart. This page is based on the redpanda-operator Helm chart and is preserved only for backward compatibility.

The Simple Authentication and Security Layer (SASL) is a method for adding authentication support to connection-based protocols. When using the Redpanda Operator, SASL provides authentication between the server and client. To encrypt communication, use TLS encryption. You must use TLS encryption to have secure authentication using SASL.

For general security information, see Redpanda Security on Kubernetes.

Prerequisites

  1. Configure the kubectl context.
  2. Install cert-manager. Although SASL authentication doesn’t use certificates, the Redpanda operator requires that cert-manager is installed.
  3. Install the Redpanda operator.

If you haven’t completed these tasks, follow one of the Install Redpanda guides for Kubernetes to get set up before you configure TLS. Just stop before you install and connect to the Redpanda cluster.

Step 1: Configure the cluster specification file

The Redpanda GitHub repository contains a sasl.yaml sample configuration file you can use to enable SASL authentication.

note

To modify the sample file, save it locally and make the required changes.

The following text is the Redpanda sasl.yaml file with the relevant sections highlighted:

apiVersion: redpanda.vectorized.io/v1alpha1
kind: Cluster
metadata:
name: cluster-sample-sasl
spec:
image: "vectorized/redpanda"
version: "latest"
replicas: 1
enableSasl: true
superUsers:
- username: admin
resources:
requests:
cpu: 1
memory: 1.2G
limits:
cpu: 1
memory: 1.2G
configuration:
rpcServer:
port: 33145
kafkaApi:
- port: 9092
pandaproxyApi:
- port: 8082
adminApi:
- port: 9644
developerMode: true

Complete these steps to configure the cluster specification file. The steps reference the highlighted lines in the file above:

  1. Configure the cluster name. The following property in the file above specifies the name of the cluster. Change this value to the name of your cluster:
name: cluster-sample-sasl
  1. Enable SASL for the cluster. You must include the following property to your configuration file to enable SASL authentication for the cluster:
enableSasl: true
  1. Specify a superuser. You must specify a superuser with this property:
superUsers:
- username: admin

The example allows a user with the name admin full access to the cluster. However, this does not create the user. Next you create this user through the Admin API. You can change the username to any string, but when you create the superuser, you must use the name that you specify here.

  1. Verify the Admin API port. If you’re using the default Redpanda ports, you do not need to change this. However, users are created through the Admin API and in the steps, the commands you use to create users reference the port specified here. If you edit this port, then edit it in the other commands as well:
adminApi:
- port: 9644
  1. If you modified the sasl.yaml file, save it locally. You can also add TLS encryption before you save the file.
info

You can find additional sample configuration files at redpanda-examples/docs/example-config/kubernetes.

SASL with TLS encryption

Optionally, you can use SASL authentication with TLS encryption for the Kafka API. To do that, enable TLS for the Kafka API by adding the highlighted lines below to the kafkaApi property in the configuration file:

kafkaApi:
- port: 9092
tls:
enabled: true

Step 2: Create the Redpanda cluster

After you configure the cluster specification file, you must run the kubectl apply command to create the cluster. You can run the command using a path to the cluster specification file on your local machine or you can use the URL to the sasl.yaml file above.

If you modified the file in the previous step, you have the file saved locally. To create the Redpanda cluster, run:

kubectl apply -f <cluster_specification.yaml>

If you did not modify the example file, you can use the URL to the example file in GitHub to create the cluster:

kubectl apply -f https://raw.githubusercontent.com/redpanda-data/redpanda-examples/main/docs/example-config/kubernetes/sasl.yaml

Step 3: Create the superuser

You must create the superuser through the Admin API. This user has ALL permissions on the cluster and is the user that grants permissions to new users. Without a superuser, you can create other users, but you will not be able to grant them permissions to the cluster.

To create the superuser and specify a password for the user, run:

kubectl exec -c redpanda <cluster_name>-0 -- rpk acl user create <super_user_username> \
-p <super_user_password>

The -0 in this command refers to the first node of the cluster. You can change this integer to specify a different node in the cluster.

The super_user_username is the superuser that you defined in the cluster specification file.

note

If you changed the Admin API port from the default, you must add the following line to each command that creates a new user, in this step and the next step:

--api-urls localhost:<port>

This command executes the rpk command from within a Redpanda cluster container, using the local host. To run the command from another pod, you must include the broker location with the command. The text below shows the full command with the broker location highlighted:

kubectl exec -c redpanda <cluster_name>-0 -- rpk acl user create <super_user_username> \
-p <super_user_password> \
--api-urls localhost:<port>
// highlight-start
--brokers <cluster_name>-0.<cluster_name>.default.svc.cluster.local:<port>
// highlight-end

Step 4: Create additional users

The same command that you used to create the superuser also creates additional users and sets the passwords for the new users. By default, these users don't have any permissions on the cluster.

tip

As a security best practice, you don't want to use the superuser to run commands on the cluster. You can use these additional users to interact with the cluster.

For each user that you want to create, run:

kubectl exec -c redpanda external-connectivity-0 -- rpk acl user create <username> \
-p <password> \

Step 5: Grant permissions

The superuser can grant permissions to additional users through access control lists (ACLs). For details on how ACLs function in Redpanda, see the rpk acl documentation.

  1. Use the superuser to grant create and describe permissions to another user for the cluster. You can edit the rpk acl create command to grant permissions to specific users or groups:
kubectl exec -c redpanda <cluster_name>-0 -- rpk acl create --allow-principal User:<username> --operation create,describe --cluster \
--user <super_user_username> \
--password <super_user_password> \
--sasl-mechanism SCRAM-SHA-256
  1. Optionally, you can use the superuser to grant permissions to a new user for a topic within the cluster. The following command grants describe privileges to a topic that doesn’t exist yet. In the next step, you create the topic that you reference in this command.
kubectl exec -c redpanda <cluster_name>-0 -- rpk acl create --allow-principal User:<username> --operation describe --topic <topic_name> \
--user <super_user_username> \
--password <super_user_password> \
--sasl-mechanism SCRAM-SHA-256

Step 6: Use rpk to interact with Redpanda

Now you can connect to Redpanda with the additional (non-superuser) user and start working with the cluster.

To create a topic, run:

kubectl exec -c redpanda <cluster_name>-0 -- rpk topic create <topic_name> \
--user <username> \
--password <user_password> \
--sasl-mechanism SCRAM-SHA-256

To describe the topic, run:

kubectl exec -c redpanda <cluster_name>-0 -- rpk topic describe <topic_name> \
--user <username> \
--password <user_password> \
--sasl-mechanism SCRAM-SHA-256

Step 7: Clean up

Now that you have your superuser and additional users that can interact with the cluster, use the rpk reference documentation to experiment with the rpk commands and create additional users and ACLs.

When you're ready, to delete the cluster, run:

kubectl delete -f <cluster_specification.yaml>