K8s: RBAC feature#3385
Conversation
🛡️ Jit Security Scan Results
✅ No security findings were detected in this PR
Security scan by Jit
|
There was a problem hiding this comment.
I reviewed this PR last night while it was a draft with no reviewers assigned. I guess I was bored. Anyway, language LGTM. Therre are, however, a few bad links. Here's the output from hugo serve on your branch:
WARN [en] REF_NOT_FOUND: Ref "/operate/kubernetes/security/access-control/manage-users": "/Users/david.dougherty/src/docs/content/operate/kubernetes/security/access-control/_index.md:63:18": page not found
WARN [en] REF_NOT_FOUND: Ref "/operate/kubernetes/security/access-control/manage-roles": "/Users/david.dougherty/src/docs/content/operate/kubernetes/security/access-control/_index.md:64:18": page not found
WARN [en] REF_NOT_FOUND: Ref "/operate/kubernetes/security/access-control/manage-acls": "/Users/david.dougherty/src/docs/content/operate/kubernetes/security/access-control/_index.md:65:17": page not found
WARN [en] REF_NOT_FOUND: Ref "/operate/kubernetes/security/access-control/manage-bindings": "/Users/david.dougherty/src/docs/content/operate/kubernetes/security/access-control/_index.md:66:26": page not found
WARN [en] REF_NOT_FOUND: Ref "/operate/kubernetes/security/access-control/migrate-rolespermissions": "/Users/david.dougherty/src/docs/content/operate/kubernetes/security/access-control/_index.md:67:40": page not found
I'll go ahead and approve so you're not held up.
Postscript: You'll probably want to add the other two reviewers back now that I've approved. Sorry!
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 69897e2. Configure here.
|
|
||
| - **One binding per role, many subjects** — every user with the role lives in one resource. A single apply changes access for every user at once, which can be either a feature or a hazard depending on the change. | ||
| - **One binding per user, multiple roles per binding** — each user has one binding listing the roles they hold. Deleting a user is a single binding delete. Adding a new role to an existing user means editing their binding. | ||
| - **One binding per user-role pair** — most verbose, but each grant is a discrete resource. Useful for attributing changes in GitOps and for scoping Kubernetes RBAC permissions on individual bindings. |
There was a problem hiding this comment.
Wrong multi-role binding pattern
Medium Severity
The “one binding per user, multiple roles per binding” pattern is incorrect because RedisEnterpriseRoleBinding and RedisEnterpriseClusterRoleBinding expose a single roleRef, not a list of roles. Granting several roles to one user requires multiple binding resources, not one edited binding.
Reviewed by Cursor Bugbot for commit 69897e2. Configure here.
|
|
||
| ```sh | ||
| kubectl delete redisenterpriserolebinding --selector app=orders | ||
| kubectl delete redisenterpriserole orders-viewer |
There was a problem hiding this comment.
Wrong binding delete command
Medium Severity
The delete example uses kubectl delete redisenterpriserolebinding --selector app=orders, which removes bindings by label selector, not by the orders-viewer role name. Bindings are not labeled that way in the docs, so the command often deletes nothing and leaves role deletion blocked.
Reviewed by Cursor Bugbot for commit 69897e2. Configure here.
|
|
zcahana
left a comment
zcahana
left a comment
There was a problem hiding this comment.
Thanks @kaitlynmichael. This documentation looks great.
I've made a partial review so far - I still have a couple of more pages to go through - but figured I'll already send the first batch of comments. I'll make sure to complete this soon.
| - **Certificates live in Kubernetes Secrets**, not in `/etc/opt/redislabs/`. The REC spec references them by name. | ||
| - **cert-manager can issue and rotate certificates automatically**, replacing manual rotation steps. | ||
| - **The operator distributes certificates across cluster nodes**; you don't copy files between nodes yourself. |
There was a problem hiding this comment.
1st and 3rd bullets seem inaccurate. Cert may also live in /etc/opt/redislabs/, after the operator applies them to the cluster via the RS API. Also, users anyway don't copy certs between nodes - they apply it to the cluster via the RS API (same as the operator does for them).
The main difference in Kubernetes, is that users capture their certs in secret (cert-manager generated or not), and reference them declaratively via the REC CR.
|
|
||
| ## What's different on Kubernetes | ||
|
|
||
| - **Initial credentials are auto-generated.** You don't choose them at install; you retrieve them from the credentials Secret after the REC is up. |
There was a problem hiding this comment.
Auto-generated credentials are the default behavior, but users can specify them (both the secret name, as well as the actual credentials) at cluster creation time.
| ## What's different on Kubernetes | ||
|
|
||
| - **Initial credentials are auto-generated.** You don't choose them at install; you retrieve them from the credentials Secret after the REC is up. | ||
| - **Change credentials by updating the Kubernetes Secret**, not by editing the user in the Cluster Manager UI. |
There was a problem hiding this comment.
Incorrect for the cluster admin credentials (the initial admin credentials configured at creation time, and used by the operator to tlk with the cluster). These are still changed by modifying the credentials directly in RS, and then mirroring the new credentials to the secret. We have a doc page describing this procedure.
| | `managementRole` values | `DBMember`, `DBViewer`, `None` | `Admin`, `ClusterMember`, `ClusterViewer`, `DBMember`, `DBViewer`, `UserManager`, `None` | | ||
| | Binding kind | `RedisEnterpriseRoleBinding` | `RedisEnterpriseClusterRoleBinding` | | ||
|
|
||
| A `RedisEnterpriseClusterRole` applies to REDBs even when they're represented by resources in other namespaces — the access flows through Redis Software, not through explicit REDB references. |
There was a problem hiding this comment.
2nd part is inaccurate; This configuration does flow via REDBs and not via RS: the operator applies the ClusterRole configuration for every REDB (regardless of its namespace).
OTOH, if the cluster has BDBs managed directly via RS APIs with no matching REDB (some customers still work that way), then ClusterRoles won't apply to these BDBs.
Your phrasing already explicitly states that this apply to every REDB in the cluster - which is correct.
We should considering being even more explicit, and mention that ClusterRole won't apply to BDBs created directly in RS.
| 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.acls`** — a list of `RedisEnterpriseACL` references. Each ACL controls Redis data-path access (commands, key patterns, categories). Duplicate references are rejected; for different ACLs on different databases, create separate roles. |
There was a problem hiding this comment.
A Role (as well as ClusterRole) grants a single ACL (via spec.acl), and not multiple (this was indeed changed rather recently).
|
|
||
| ## Related topics | ||
|
|
||
| - [Redis Software for Kubernetes operator API reference]({{< relref "/operate/kubernetes/reference/api" >}}) — field-by-field specification for every CRD in the `app.redislabs.com/v1alpha1` group. |
There was a problem hiding this comment.
These still don't include the RBAC CRDs reference; Just making sure that we'll have this available by the time of release.
|
|
||
| ## Before you start | ||
|
|
||
| - Requires Redis Software for Kubernetes operator 8.0.24-TBD or later. |
There was a problem hiding this comment.
Do we have a mechanism (or a Jira) to un-TBD this?
| - Requires Redis Software for Kubernetes operator 8.0.24-TBD or later. | ||
| - The `RedisEnterpriseUser` resource and every referenced password Secret must live in the operator namespace. | ||
| - Passwords must satisfy the cluster's [password complexity rules]({{< relref "/operate/rs/security/access-control/manage-passwords/password-complexity-rules" >}}). | ||
| - To assign roles, you need a `RedisEnterpriseRole` or `RedisEnterpriseClusterRole` and a matching binding. See [Manage roles]({{< relref "/operate/kubernetes/security/access-control/manage-roles" >}}). |
There was a problem hiding this comment.
This is not really a prerequisite, so not sure it's a "Before you start" item. You already mention above "To grant a user permissions, see [Manage role bindings]" - maybe it's sufficient?
| kubectl get redisenterpriseuser alice -o jsonpath='{.status.username}' | ||
| ``` | ||
|
|
||
| Use that value when you reference the user from a binding's `subjects` list or when you sign in to Redis Software. |
There was a problem hiding this comment.
"when you sign in to Redis Software" - yes.
"when you reference the user from a binding's subjects list" - no. In that case, the CR name (RedisEnterpriseUser.metadata.name) should be used.
|
|
||
| ## Delete an ACL | ||
|
|
||
| Delete any roles that reference the ACL first, then delete the ACL itself: |
There was a problem hiding this comment.
This could be "Delete or modify any roles" (modify to no longer reference this ACL).
4 participants
Note
Low Risk
Documentation-only changes (new pages, link/path updates, aliases); no application code or runtime behavior.
Overview
Adds Kubernetes-native RBAC documentation for Redis Software on Kubernetes: users, ACLs, database- and cluster-scoped roles, role bindings (including
LDAPGroupsubjects), and a guide to migrate off deprecatedRedisEnterpriseDatabase.spec.rolesPermissionsviaREC.spec.accessControl.policy.allowREDBRolesPermissions.Reorganizes the security doc tree into Access control, Authentication (
manage-rec-credentials, LDAP, SSO, configuration secrets), and Certificates and encryption, with aliases on moved pages so old URLs keep working. Cross-links are updated across Kubernetes topics, the operate security comparison table, and Vault/cert-manager pages.Reviewed by Cursor Bugbot for commit 69897e2. Bugbot is set up for automated code reviews on this repo. Configure here.