Securing Redpanda APIs on Kubernetes

Introduction

To secure your Redpanda cluster on Kubernetes, you must configure authentication to the cluster. Authentication is how you verify that the users and clients that access the API endpoints in your cluster are who they say they are. There are a variety of ways to do this, such as SASL, which is an authentication framework, and TLS, in which the client verifies the authenticity of the server and also encrypts communication between endpoints. mTLS, which is short for mutual TLS, is essentially TLS in both directions, where the client authenticates the server (as in one-way TLS) and the server also authenticates the client.

The Redpanda custom resource definition (CRD) is a customization of the Kubernetes installation. It contains the Redpanda APIs, which you use to communicate with the client. This blog outlines the ways that you can enable authentication on each of the APIs to secure your Redpanda cluster that is running on Kubernetes.

Note: For information about role-based access control (RBAC), see the Encryption, authorization, and authentication documentation.

Redpanda APIs

The CRD of a Redpanda cluster includes four APIs: Kafka API, HTTP Proxy, Schema Registry, and Admin API. Each API uses a listener to communicate with the client. Authentication guarantees that when the server and the client establish a connection, they can trust each other. We recommend that you enable authentication on each API to secure your cluster. You can configure authentication individually with each API, which provides flexibility for customizing authentication in your cluster.

We recommend that you enable authentication on each API for a production environment. TLS authenticates the server and encrypts communication between the server and the client, while SASL and mTLS provide client authentication.

The table below shows the types of client authentication that Redpanda supports on each API:

In general, the guidelines put in place by your organization will determine the type of authentication that you will use. SASL authentication with TLS encryption provides flexibility with respect to authentication, along with the added layer of security provided by TLS encryption. mTLS includes an additional layer of authentication in which the server authenticates the client. mTLS is the most secure type of authentication, but also requires the most overhead to implement.

TLS

Transport Layer Security (TLS), previously SSL, provides authentication of the server as well as encryption for client-server communication, for example when consuming from a topic or producing. You can configure TLS inside a Kubernetes cluster to establish encrypted communication between a client and a broker.

TLS is available for all four APIs.

For information on how to enable TLS, see the Configuring Redpanda TLS on Kubernetes documentation.

SASL authentication

Simple Authentication Security Layer (SASL) is an authentication framework that allows you to choose the authentication mechanism. Redpanda currently supports the Salted Challenge Response Authentication Mechanism (SCRAM) authentication method.

SASL authentication is available for the Kafka API.

SASL provides authentication, but not encryption. You can, however, configure TLS to only handle encryption, and use SASL authentication. This is useful if you require flexibility in the authorization mechanisms that you use.

For information on how to enable SASL authentication, see the Configuring Redpanda SASL authentication on Kubernetes documentation.

mTLS authentication

Mutual TLS (mTLS) is a method of authentication in which the client authenticates the server and the server authenticates the client. This provides an additional layer of security to TLS, where the client is not authenticated. When mTLS is enabled, the server decides whether the client can be trusted.

mTLS requires the client to give a certificate in addition to the usual server certificate. This involves more overhead to implement, but can be useful for environments that require maximum security and only have a small number of verified clients.

mTLS authentication is available for all four APIs.

For information on how to enable TLS, see the Configuring Redpanda mTLS authentication on Kubernetes documentation.

Certificates

The Redpanda operator uses cert-manager to generate certificates for TLS and mTLS authentication (SASL does not use certificates). When the client opens a connection to Redpanda, Redpanda sends the client a certificate and the client verifies the certificate with the Certificate Authority. If mTLS is enabled, the client then sends its own certificate to the server and the server verifies that certificate with the Certificate Authority.

In addition, for the Kafka API and Schema Registry, Redpanda also gives you the option of providing a trusted certificate issuer or certificate with the issuerRef and nodeSecretRef parameters in the configuration file.

Next steps

For a detailed explanation of each of the types of authentication and how to configure authentication with external connectivity, see the Redpanda security on Kubernetes documentation. The documentation also includes tutorials that you can follow to easily create a cluster that uses SASL, TLS, or mTLS authentication.

In the Redpanda GitHub repository, you can find sample sasl.yaml, tls.yaml, and mtls.yaml files that make enabling authentication as easy as saving the file locally and running kubectl apply to start your cluster.

We welcome any feedback you have about our documentation. If something didn’t work for you or you have questions that weren’t answered in the documentation, let us know. Chat with us on Slack or create a GitHub issue. Thank you for participating!