# Manage Users and ACLs with the Redpanda Operator > For the complete documentation index, see [llms.txt](https://docs.redpanda.com/llms.txt). Component-specific: [streaming-full.txt](https://docs.redpanda.com/streaming-full.txt) --- title: Manage Users and ACLs with the Redpanda Operator latest-redpanda-tag: v24.3.9 latest-console-tag: v3.7.3 latest-operator-version: v26.1.4 # EOL = End-of-Life (support lifecycle status) page-is-nearing-eol: "false" page-is-past-eol: "true" page-eol-date: December 3, 2025 latest-connect-version: 4.93.0 docname: kubernetes/security/authentication/k-user-controller page-component-name: streaming page-version: "24.3" page-component-version: "24.3" page-component-title: Streaming page-relative-src-path: kubernetes/security/authentication/k-user-controller.adoc page-edit-url: https://github.com/redpanda-data/docs/edit/v/24.3/modules/manage/pages/kubernetes/security/authentication/k-user-controller.adoc description: Use the User resource to declaratively create and manage users and ACLs as part of a Redpanda deployment. Each User resource is mapped to a user in your Redpanda cluster. The user controller keeps the corresponding user in sync with the User resource. page-git-created-date: "2024-10-30" page-git-modified-date: "2024-12-03" support-status: past end-of-life --- With the Redpanda Operator, you can declaratively create and manage Redpanda users and [access control lists (ACLs)](https://docs.redpanda.com/streaming/24.3/reference/glossary/#access-control-list-acl) using [User custom resources](https://docs.redpanda.com/streaming/24.3/reference/k-crd/#k8s-api-github-com-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-user) (resources) in Kubernetes. Each User resource is mapped to a user in your Redpanda cluster. The user controller, a component of the Redpanda Operator, keeps the corresponding user in sync with the User resource. ## [](#prerequisites)Prerequisites You must have the following: - **Kubectl**: Ensure you have the [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) command-line tool installed and configured to communicate with your cluster. - **Redpanda Operator**: Ensure you have at least version v2.2.2-24.2.4 of the [Redpanda Operator](https://docs.redpanda.com/streaming/24.3/deploy/deployment-option/self-hosted/kubernetes/k-production-deployment/). - **Redpanda cluster with SASL enabled**: Ensure you have a Redpanda resource deployed with [SASL authentication enabled](https://docs.redpanda.com/streaming/24.3/manage/kubernetes/security/authentication/k-authentication/#enable). ## [](#create-a-user)Create a user You can use the User resource to: - [Create a new user and its ACLs](#both) - [Create a new user without any authorization (ACLs)](#no-acl) - [Create only the ACLs for a user](#only-acl) Each User instance is responsible for managing both the user credentials (authentication) and the user’s ACLs within the Redpanda cluster. You cannot use one User resource to manage the user and another resource to manage the ACLs. Only one User instance is allowed per user in the Redpanda cluster. ### [](#no-acl)Create a new user without any ACLs - **Use case**: You want to create and manage user credentials (authentication) without managing ACLs. Use this option if you have a separate process to manage ACLs or if you’re working in an environment where access control is handled externally. - **What happens when deleted**: The user is deleted, but ACLs for that user will remain in the cluster. This example shows how to manage the creation and authentication of a user without configuring ACLs. `new-user.yaml` ```yaml # In this example manifest, a user called "jason" is created in a cluster called "sasl". # The user's password is defined in a Secret called "jason-password". # This example assumes that you will create ACLs for this user separately. --- apiVersion: cluster.redpanda.com/v1alpha2 kind: User metadata: name: jason spec: cluster: clusterRef: name: sasl authentication: type: scram-sha-512 password: valueFrom: secretKeyRef: name: jason-password key: password ``` ### [](#only-acl)Create only ACLs - **Use case**: You want to manage ACLs for an existing user in the Redpanda cluster, but not modify the user’s credentials. Use this option if user credentials are managed by another process or tool, and you only want to control what resources the user can access (authorization). - **What happens when deleted**: The ACLs are removed, but the user remains. This is useful when you want to revoke access but retain the user’s credentials for future use. When you create ACLs with the User resource, the specified ACLs are applied only to the user defined in the `metadata.name` field. For example, if you create ACLs for a user named `data-consumer`, those ACLs apply only to that user. Other users in the Redpanda cluster are not affected by these ACLs. This example shows how to manage only the ACLs for an existing user in the Redpanda cluster. `new-acl.yaml` ```yaml # In this example manifest, an ACL called "travis" is created in a cluster called "sasl". # The ACL give an existing user called "travis" permissions to read from all topics whose names start with some-topic. # This example assumes that you already have a user called "travis" in your cluster. --- apiVersion: cluster.redpanda.com/v1alpha2 kind: User metadata: name: travis spec: cluster: clusterRef: name: sasl authorization: acls: - type: allow resource: type: topic name: some-topic patternType: prefixed operations: [Read] ``` ### [](#both)Create a new user and assign ACLs - **Use case**: You want to manage both user credentials and ACLs within the same resource. - **What happens when deleted**: Both the user and the associated ACLs are removed. This example shows how to manage both authentication and ACLs for a user within the same User resource. `new-user-and-acl.yaml` ```yaml # In this example manifest, the user "full-user" is created and managed for both authentication and authorization. # The user is granted both read and write access to the topic critical-topic. apiVersion: cluster.redpanda.com/v1alpha2 kind: User metadata: name: full-user spec: cluster: clusterRef: name: sasl authentication: type: scram-sha-512 password: valueFrom: secretKeyRef: name: full-user-secret key: password authorization: acls: - type: allow resource: type: topic name: critical-topic patternType: literal operations: [Read,Write] ``` ## [](#configuration)Configuration The following sections provide guidance on setting up user authentication, managing secrets, and defining ACLs within your Kubernetes environment. These recommendations ensure proper user management while minimizing manual interventions and preventing potential security issues. You can find all configuration options for the User resource in the [CRD reference](https://docs.redpanda.com/streaming/24.3/reference/k-crd/#k8s-api-github-com-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-user). ### [](#choose-a-username)Choose a username The `metadata.name` field in the User resource is used to specify the username. Keep in mind the following best practices when choosing a username: - **Unique**: Ensure each user has a unique name to avoid conflicts. The username must be unique within the Redpanda cluster. - **Descriptive**: Choose a name that identifies the purpose or role of the user. For example, use names like `app-consumer` or `admin-user`. - **Stable**: Avoid changing usernames frequently. Usernames are tied to authentication and authorization rules (ACLs). Renaming a user involves deleting and recreating the user. ```yaml metadata: name: full-user ``` In this example, `full-user` is the username, which will be referenced in both authentication and authorization rules. ### [](#configure-authentication)Configure authentication This section provides guidance on configuring authentication for users with the User resource. You can find all configuration options for authentication in the [UserAuthenticationSpec](https://docs.redpanda.com/streaming/24.3/reference/k-crd/#k8s-api-github-com-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-userauthenticationspec) of the CRD reference. #### [](#choose-an-authentication-type)Choose an authentication type You can specify the authentication type for a user using the [`spec.authentication.type`](https://docs.redpanda.com/streaming/24.3/reference/k-crd/#k8s-api-github-com-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-userauthenticationspec) field. Supported values include `scram-sha-256`, `scram-sha-512`, and their uppercase variants. ```yaml spec: authentication: type: scram-sha-512 ``` If no authentication credentials are provided, no user will be created, but ACLs can still be managed for existing users. #### [](#manage-user-secrets)Manage user secrets Redpanda users require a password, which you can provide directly, using the [`spec.password.value`](https://docs.redpanda.com/streaming/24.3/reference/k-crd/#k8s-api-github-com-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-password) field, or through a Kubernetes Secret, using the [`spec.password.valueFrom.secretKeyRef`](https://docs.redpanda.com/streaming/24.3/reference/k-crd/#k8s-api-github-com-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-password). The Redpanda operator offers flexibility in how these secrets are handled: - If the Secret exists and the key exists within that Secret, the existing password will be used. - If the Secret exists but the key does not exist, the Secret will be updated with an autogenerated password. - If the Secret does not exist, a new Secret with the provided key will be created with an autogenerated password. This behavior ensures that you can manage user credentials securely and programmatically, while also automating password generation if necessary. To use an existing Kubernetes Secret, ensure that the Secret and key are both defined. For example: ```yaml spec: authentication: password: valueFrom: secretKeyRef: name: user-secret key: password ``` This example is based on the assumption that a Kubernetes Secret named `user-secret` with a key `password` exists. If the Secret does not exist or the key is missing, the Redpanda Operator will handle it by creating or updating the Secret with an autogenerated password. The autogenerated password will follow best practices for secure password generation. If you need to create a Secret, you can use the following command as an example: ```bash kubectl --namespace create secret generic user-secret --from-file=password.txt ``` In this example, the `password.txt` file contains the password you want to use. ### [](#define-acls)Define ACLs The [`spec.authorization`](https://docs.redpanda.com/streaming/24.3/reference/k-crd/#k8s-api-github-com-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-userauthorizationspec) field allows you to manage ACLs for users. ACLs define the permissions users have over specific resources in Redpanda, such as topics, consumer groups, and clusters. You can define ACLs for a user by specifying which resources they can access and the operations they are permitted to perform. Here’s an example configuration for managing ACLs: ```yaml spec: authorization: acls: - type: allow resource: type: topic name: my-topic patternType: literal operations: [Read, Write] ``` - `type`: Defines whether the ACL is `allow` or `deny`. - `resource.type`: Specifies the resource type. - `patternType`: Specifies if the resource name is treated as a `literal` or a `prefixed` pattern. Default: `literal`. > 💡 **TIP** > > Use specific resource names where possible. Using `literal` names for resources ensures that only the exact resources you intend are accessible. Use `prefixed` patterns cautiously to avoid accidental permission grants. - `operations`: Lists the allowed operations, such as `Read`, `Write`, `Create`, and `Delete`. You can find all configuration options for authorization in the [UserAuthorizationSpec](https://docs.redpanda.com/streaming/24.3/reference/k-crd/#k8s-api-github-com-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-userauthorizationspec) of the CRD reference. For more details about ACLs, including supported operations and resources in Redpanda, see [Access Control Lists](https://docs.redpanda.com/streaming/24.3/manage/security/authorization/acl/). ## [](#deploy-a-user-resource)Deploy a User resource To deploy a User resource, apply the manifest to the same namespace as your Redpanda cluster: ```bash kubectl apply -f .yaml --namespace ``` - Replace `` with the filename of your manifest. - Replace `` with the namespace in which you deployed Redpanda. ## [](#verify-a-user)Verify a user After deploying a User resource, verify that the Redpanda Operator reconciled it: ```bash kubectl logs -l app.kubernetes.io/name=operator -c manager --namespace ``` Example output: ```json { "level": "info", "ts": "2024-09-25T16:20:09.538Z", "logger": "UserReconciler.Reconcile", "msg": "Starting reconcile loop", "controller": "user", "User": { "name": "my-user", "namespace": "" }, "reconcileID": "c0cf9abc-a553-48b7-9b6e-2de3cdfb4432" } { "level": "info", "ts": "2024-09-25T16:20:09.581Z", "logger": "UserReconciler.Reconcile", "msg": "Reconciliation finished in 43.436125ms, next run in 3s", } ``` ## [](#update-a-user)Update a user To update a user, edit the User resource configuration and apply the changes. ```bash kubectl apply -f .yaml --namespace ``` ## [](#delete-a-user)Delete a user To delete a user, delete the User resource: ```bash kubectl delete -f example-user.yaml --namespace ``` When a User resource is deleted, its underlying data is removed as well. If the user has ACLs, those ACLs are also removed. Deleting a User resource will have different impacts depending on how it is configured: - **Authentication-only**: When a User resource that manages only authentication is deleted, the user is removed from the cluster. However, any ACLs not managed by the same resource will remain in place. - **Authorization-only**: When a User resource that manages only ACLs is deleted, the ACLs are removed, but the user remains in the cluster. - **Full user management (both authentication and authorization)**: When the resource manages both users and ACLs, the user and its associated ACLs are removed. ## [](#suggested-reading)Suggested reading - [User resource](https://docs.redpanda.com/streaming/24.3/reference/k-crd/#k8s-api-github-com-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-user) - [UserList resource](https://docs.redpanda.com/streaming/24.3/reference/k-crd/#k8s-api-github-com-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-userlist) - [Configure Authentication for Redpanda in Kubernetes](https://docs.redpanda.com/streaming/24.3/manage/kubernetes/security/authentication/k-authentication/)