{
  "schema_version": 2,
  "id": "operate/kubernetes/security/access-control/migrate-rolespermissions",
  "title": "Migrate from REDB rolesPermissions",
  "url": "https://redis.io/docs/latest/operate/kubernetes/8.2.0/security/access-control/migrate-rolespermissions/",
  "summary": "Move database role assignments from the deprecated RedisEnterpriseDatabase.spec.rolesPermissions field to the RBAC CRD model.",
  "content": "\n`RedisEnterpriseDatabase.spec.rolesPermissions` assigns Redis Software role and ACL names directly to a database. The field is deprecated, replaced by the RBAC CRDs (`RedisEnterpriseRole`, `RedisEnterpriseACL`, and bindings), which let you manage roles, ACLs, and assignments as Kubernetes resources.\n\nThis page covers moving an existing database from `rolesPermissions` to the CRD model, then disabling the deprecated field at the cluster level.\n\n## Before you start\n\n- Requires Redis Software for Kubernetes operator 8.2.0-12 or later.\n- Every user who currently holds access through `rolesPermissions` must exist as a `RedisEnterpriseUser` resource before you can bind a CRD role to them. If you created users through the Redis Software REST API or Cluster Manager UI, migrate them first. See [Manage users](https://redis.io/docs/latest/operate/kubernetes/security/access-control/manage-users).\n- List which Redis Software users hold each role. The CRD inventory only captures the database side of the assignment; the user-to-role mapping lives in Redis Software. Pull it from the Cluster Manager UI or the [Redis Software users REST API](https://redis.io/docs/latest/operate/rs/references/rest-api/objects/user).\n\n## How the two sources interact\n\nBy default, the operator reconciles both sources of database role permissions:\n\n- The deprecated `RedisEnterpriseDatabase.spec.rolesPermissions` list on each REDB.\n- Permissions derived from `RedisEnterpriseRole` resources that scope to the REDB.\n\nThe operator merges and de-duplicates the two sets before sending them to Redis Software. `RedisEnterpriseDatabase.status.rolesPermissions` shows the merged result:\n\n- Entries from the deprecated field use Redis Software's internal role and ACL names.\n- Entries from CRDs reference `RedisEnterpriseRole` and `RedisEnterpriseACL` resources.\n\nYou can run both sources in parallel during migration. Once every database is completely migrated, disable the deprecated field cluster-wide (see [Disable the deprecated field](#disable-the-deprecated-field)).\n\n## Reference existing Redis Software objects\n\nYou don't have to recreate every database, ACL, and role as a custom resource. When an object was created directly through the Redis Software REST API or Cluster Manager UI, a CRD reference can point at it by name using an internal kind, so you can bring it under CRD-managed bindings without redefining it:\n\n| Field | Internal kind | References |\n| --- | --- | --- |\n| `scopes[].kind` | `bdb` | An internal Redis Software database by name. Name only — no selector. The role grants management access only; its ACL isn't bound to that database. |\n| `acl.kind` | `redis_acl` | An internal Redis Software ACL by name. |\n| `roleRef.kind` | `role` | An internal Redis Software role by name, from a binding. |\n\nThe reference resolves by name against the existing Redis Software object. Use internal references to migrate assignments incrementally, then replace them with full `RedisEnterpriseDatabase`, `RedisEnterpriseACL`, and `RedisEnterpriseRole` resources as you bring each object under the CRD model.\n\n## Migrate a database\n\nFor each database, capture what `rolesPermissions` currently grants, recreate it as CRDs, verify the result, then remove the deprecated field.\n\n### 1. Inventory the existing entries\n\nList the `rolesPermissions` entries on every REDB in the operator namespace:\n\n```sh\nkubectl get redisenterprisedatabase -o yaml | \\\n  yq '.items[] | {name: .metadata.name, rolesPermissions: .spec.rolesPermissions}'\n```\n\nEach entry has a `role` (Redis Software role name) and an `acl` (Redis Software ACL name). The `type` is always `redis-enterprise`.\n\n### 2. Create RedisEnterpriseACL resources\n\nFor every distinct ACL name in the inventory, create a `RedisEnterpriseACL` resource that holds the same rule string. See [Manage ACLs](https://redis.io/docs/latest/operate/kubernetes/security/access-control/manage-acls).\n\n```yaml\napiVersion: app.redislabs.com/v1alpha1\nkind: RedisEnterpriseACL\nmetadata:\n  name: read-only\nspec:\n  acl: \"+@read ~*\"\n```\n\nThe resource `metadata.name` doesn't have to match the original Redis Software ACL name, but matching makes the merged `status.rolesPermissions` easier to read.\n\n### 3. Create RedisEnterpriseRole resources\n\nFor each role-ACL-REDB combination in the inventory, create a `RedisEnterpriseRole` scoped to the target REDB. See [Manage roles](https://redis.io/docs/latest/operate/kubernetes/security/access-control/manage-roles).\n\n```yaml\napiVersion: app.redislabs.com/v1alpha1\nkind: RedisEnterpriseRole\nmetadata:\n  name: orders-viewer\nspec:\n  managementRole: DBViewer\n  scopes:\n  - name: orders\n  acl:\n    name: read-only\n```\n\nSet `managementRole` to match the Redis Software role's management level. If the original entry only granted data-path access, omit `managementRole` — it defaults to `None`.\n\nIf the same role-ACL pair applies to more than one REDB, collapse them into a single `RedisEnterpriseRole` with multiple `scopes` entries instead of creating one role per REDB:\n\n```yaml\nspec:\n  managementRole: DBViewer\n  scopes:\n  - name: orders\n  - name: customers\n  - name: inventory\n  acl:\n    name: read-only\n```\n\n### 4. Create bindings for affected users\n\nFor each user that previously gained access through `rolesPermissions`, create a `RedisEnterpriseRoleBinding` that references the new role. See [Manage role bindings](https://redis.io/docs/latest/operate/kubernetes/security/access-control/manage-bindings).\n\n```yaml\napiVersion: app.redislabs.com/v1alpha1\nkind: RedisEnterpriseRoleBinding\nmetadata:\n  name: alice-orders-viewer\nspec:\n  roleRef:\n    name: orders-viewer\n  subjects:\n  - name: alice\n```\n\n### 5. Verify\n\nConfirm Redis Software still grants the expected access:\n\n```sh\nkubectl get redisenterprisedatabase orders -o yaml | \\\n  yq '.status.rolesPermissions'\n```\n\nThe merged `status.rolesPermissions` shows entries from both sources. Before you remove the deprecated entries, authenticate as one of the affected users and run a Redis command the role allows:\n\n```sh\nredis-cli -h \u003cdb-endpoint\u003e -p \u003cdb-port\u003e --user alice --pass \u003cpassword\u003e GET some:key\n```\n\nReplace the endpoint and port with the values from the REDB's `status.publicService` (or `status.internalService`).\n\n### 6. Remove the deprecated entries\n\nOnce verification passes, remove the migrated entries from `spec.rolesPermissions`:\n\n```sh\nkubectl edit redisenterprisedatabase orders\n```\n\nAfter the next reconcile, `status.rolesPermissions` should contain only CRD-derived entries. Repeat for every REDB.\n\n## Disable the deprecated field\n\nAfter every database is completely migrated, switch the cluster policy to ignore `spec.rolesPermissions` so no one can re-introduce it:\n\n```yaml\napiVersion: app.redislabs.com/v1\nkind: RedisEnterpriseCluster\nmetadata:\n  name: rec\nspec:\n  accessControl:\n    policy:\n      allowREDBRolesPermissions: false\n```\n\nWith `allowREDBRolesPermissions: false`:\n\n- The operator stops reconciling `spec.rolesPermissions` on every REDB.\n- The operator removes from Redis Software any permissions that came only from `spec.rolesPermissions`.\n- The operator emits a `RolesPermissionsIgnored` event on any REDB that still has the deprecated field set.\n\nThe default is `true` (both sources reconciled). Set the flag back to `true` only as a rollback.\n\n## Roll back\n\nTo revert to the deprecated field, set `allowREDBRolesPermissions: true` (or omit it) on the `RedisEnterpriseCluster` and re-add the previous entries to each REDB's `spec.rolesPermissions`. CRD-managed permissions continue to work in parallel.\n\n## Troubleshoot\n\n- **A user is missing access after you remove the deprecated entries** — A `RedisEnterpriseRole` or binding is missing for that user. Check `RedisEnterpriseUser.status.roles` against the original inventory and add the missing CRDs.\n- **`status.rolesPermissions` is empty after migration** — The new roles haven't reconciled. Each `RedisEnterpriseRole` needs `status.uid` populated before it contributes to a REDB. Check the role's events.\n- **`RolesPermissionsIgnored` event on a REDB after disabling the field** — A `spec.rolesPermissions` entry remains on the REDB. Edit the REDB and remove the field entirely.\n\n## Related topics\n\n- [Manage roles](https://redis.io/docs/latest/operate/kubernetes/security/access-control/manage-roles) — full details on `RedisEnterpriseRole` and `RedisEnterpriseClusterRole`.\n- [Manage ACLs](https://redis.io/docs/latest/operate/kubernetes/security/access-control/manage-acls) — define the data-path permissions roles reference.\n- [Manage role bindings](https://redis.io/docs/latest/operate/kubernetes/security/access-control/manage-bindings) — assign the new roles to users.\n- [`RedisEnterpriseDatabase` API reference](https://redis.io/docs/latest/operate/kubernetes/reference/api/redis_enterprise_database_api) — the source schema, including the deprecated `rolesPermissions` field.\n- [`RedisEnterpriseCluster` API reference](https://redis.io/docs/latest/operate/kubernetes/reference/api/redis_enterprise_cluster_api) — the `accessControl.policy.allowREDBRolesPermissions` flag.\n",
  "tags": ["docs","operate","kubernetes"],
  "last_updated": "2026-10-19T14:33:15-05:00"
}