Access control

Manage Redis Software users, roles, ACLs, and role bindings on Kubernetes with custom resources.

Access control lets you manage Redis Software users, roles, ACLs, and role bindings as Kubernetes custom resources. The operator reconciles each resource into the corresponding Redis Software object, so you can use GitOps workflows and Kubernetes Secrets instead of working only through the Redis Software REST API or Cluster Manager UI.

How access control works on Redis Software for Kubernetes

You declare these app.redislabs.com/v1alpha1 custom resources:

When you apply one of these resources, the operator:

1. Validates the spec.
2. Creates or updates the matching object in Redis Software.
3. Reports the resolved Redis Software UID and other state in the resource's status.
4. Emits Kubernetes events on reconciliation problems.

Roles and bindings

The role and binding CRDs follow the same pattern as Kubernetes' own RBAC: a Role paired with a RoleBinding for the narrower scope, and a ClusterRole paired with a ClusterRoleBinding for cluster-wide access. The narrower scope is the unqualified default — that's why RedisEnterpriseRole (no qualifier) is the database-scoped kind, while RedisEnterpriseClusterRole carries the explicit Cluster prefix.

Database scope vs. cluster scope

A RedisEnterpriseClusterRole applies to every REDB in the cluster, including REDBs represented by resources in other namespaces. The operator applies the role to each REDB individually, so it doesn't reach databases created directly through the Redis Software REST API without a matching REDB resource.

What a role grants

Every role carries permissions on two independent planes. Set either, or both:

• spec.managementRole — Redis Software API and Cluster Manager UI permissions, chosen from the built-in roles listed in the table above. Same set of roles you'd assign in Cluster Manager today.
• spec.acl — a single RedisEnterpriseACL reference. The ACL controls Redis data-path access (commands, key patterns, categories). To apply different data-path access to different databases, create a separate role for each.

How a user gets permissions

RedisEnterpriseUser.spec has no role references. Permissions reach a user through a binding:

1. Create a RedisEnterpriseACL if you need data-path access.
2. Create a RedisEnterpriseRole or RedisEnterpriseClusterRole that sets managementRole, references the ACL, or both.
3. Create a RedisEnterpriseRoleBinding or RedisEnterpriseClusterRoleBinding whose roleRef points at the role and whose subjects list includes the user.

The user's effective roles appear in status.roles. A user with no binding gets the Redis Software none role so it's never roleless, but it has zero permissions until a binding lands.

End-to-end example

End-to-end: an ACL, a database-scoped role that uses it, a binding that hands the role to a user, and the user itself. All four resources live in the operator namespace.

---
apiVersion: app.redislabs.com/v1alpha1
kind: RedisEnterpriseACL
metadata:
  name: read-only
spec:
  acl: "+@read ~*"
---
apiVersion: app.redislabs.com/v1alpha1
kind: RedisEnterpriseRole
metadata:
  name: orders-viewer
spec:
  managementRole: DBViewer
  scopes:
  - name: orders
  acl:
    name: read-only
---
apiVersion: app.redislabs.com/v1alpha1
kind: RedisEnterpriseRoleBinding
metadata:
  name: alice-orders-viewer
spec:
  roleRef:
    name: orders-viewer
  subjects:
  - name: alice
---
apiVersion: app.redislabs.com/v1alpha1
kind: RedisEnterpriseUser
metadata:
  name: alice
spec:
  email: [email protected]
  username: alice
  passwordSecrets:
  - name: alice-password

After applying this and a Secret named alice-password with a password key, Alice can sign in to Redis Software with DBViewer permissions on the orders REDB and run read-only Redis commands on every key in that database.

What's the same as Redis Software

The underlying Redis Software behavior is unchanged. For concepts and reference details, see the existing Redis Software docs:

• Cluster-scoped role definitions — what Admin, ClusterMember, ClusterViewer, and UserManager grant.
• Database-scoped role definitions — what DBMember and DBViewer grant.
• Combined cluster and database roles — when a role grants both planes.
• Redis ACL syntax — rule format for RedisEnterpriseACL resources.
• Login lockout and unlock — how locked users are recovered.
• Password complexity rules and password expiration — applied by Redis Software regardless of how the password is delivered.
• Default user — the built-in cluster admin account.

What's different on Kubernetes

• Resources are declarative. You define users, roles, ACLs, and bindings in YAML and let the operator apply them. The Cluster Manager UI and REST API still work but are no longer the source of truth.
• Role assignment lives on the binding, not the user. In Redis Software, you assign roles by editing the user. On Kubernetes, you create a separate RedisEnterpriseRoleBinding or RedisEnterpriseClusterRoleBinding. See Roles and bindings.
• Database and cluster scope are separate objects. A RedisEnterpriseRole covers database scope and a RedisEnterpriseClusterRole covers cluster scope. In Redis Software, a single role object carries both.
• Passwords live in Kubernetes Secrets. Each RedisEnterpriseUser references one or more Secrets. A Rotatable mode supports two Secrets at once for zero-downtime rotation. The operator marks Kubernetes Secrets immutable to prevent in-place edits.

Known limitations

Access control resources are reconciled only in the operator namespace. Password Secrets must live in the same namespace, and database scopes resolve to REDBs in that namespace.

In this section

• Manage users — create RedisEnterpriseUser resources, rotate passwords, recover from lockouts.
• Manage roles — create database and cluster roles with the right scope and management permissions.
• Manage ACLs — create and update RedisEnterpriseACL resources used by roles.
• Manage role bindings — assign roles to users with RedisEnterpriseRoleBinding and RedisEnterpriseClusterRoleBinding.
• Migrate from REDB rolesPermissions — move from the deprecated RedisEnterpriseDatabase.spec.rolesPermissions field to the new CRD model.

Related topics

• Redis Software for Kubernetes operator API reference — field-by-field specification for every CRD in the app.redislabs.com/v1alpha1 group.
• Redis databases (REDB) — the resources that role scopes resolve against.