Conversation
… needs The RBAC section named the Operator API resources but never showed the exact minimal rule set, so security teams evaluating mirrord couldn't tell what the actual floor is. Enumerate the cluster-scoped and namespace-scopeable rules with per-capability annotations, the rendered role as the authoritative per-installation reference, and the native Kubernetes permissions checked on the target via impersonation. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Contributor
|
| Filename | Overview |
|---|---|
| docs/managing-mirrord/security.md | Adds detailed RBAC rule examples and target authorization guidance consistent with the current Operator chart templates and access-review behavior. |
Reviews (1): Last reviewed commit: "docs: spell out the minimum RBAC permiss..." | Re-trigger Greptile
Three of the annotations on the minimum rule sets would mislead a security team trimming their own role: - `copytargets` was marked optional, but Job and CronJob targets auto-enable copy target, so dropping it breaks those targets. - The `sessions` verbs were described as stopping the caller's own sessions. They are not scoped to the caller. - The feature-gated rules were sketched with an example rather than enumerated, so a hand-built role comes out short. Also state that queue splitting adds nothing to the user roles, which is the question enterprise reviewers actually ask, and spell out what the roles deliberately do not carry. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
The prose list packed apiGroup, resource, and verbs into one sentence per feature, which is the part a security team transcribes into a role. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Expands the "How do I configure Role Based Access Control" section of the security doc to answer the question a prospect's security team actually asks: what is the exact minimum set of permissions a developer needs to run mirrord?
The section previously named four Operator API resources and pointed at the Helm chart template, which is hard to read (feature conditionals, split across helpers). During a recent POC evaluation the customer said they found this page but still couldn't work out the exact permissions required (context: PRD-151).
Changes
geton the target workload (impersonation check).geton the workload,geton the namespace for targetless,listpods for label selectors), verified against the operator's SubjectAccessReview logic.kubectl get clusterrole mirrord-operator-user -o yamlas the authoritative per-installation reference, since the chart templates rules per enabled feature.Rule sets were taken from the current chart templates (
mirrord-operator.rules/mirrord-operator.clusterRulesin_helpers.tpl) and the operator's target access-review code.🤖 Generated with Claude Code