RBAC

rbac

rbac is the grant-evidence command in HarrierOps Kube.

Use it when you need to inspect who is bound to what, at what scope, and why a later capability or identity story might matter.

What This Command Answers

• Which role bindings and cluster role bindings are visible?
• Which users, groups, and service accounts are attached to them?
• Is the grant namespace-scoped or cluster-wide?
• Does the role reference suggest a stronger or more unusual path than expected?

Run It

harrierops-kube rbac --output table

If you want a saved structured artifact:

harrierops-kube rbac --output json --outdir ./harrierops-kube-demo

Example Table Output

priority	scope	subject	role	binding	signal
high	cluster-wide	ServiceAccount default/fox-admin	cluster-admin*	harrierops-kube-lab-cluster-admin	admin-like wildcard access
medium	namespace/storefront	ServiceAccount storefront/web	edit*	web-edit	change workloads
low	namespace/storefront	User analyst@example.com	view*	view-only	direct

When To Use It

• after service-accounts or permissions raises a meaningful identity path
• when you need the exact grant evidence behind a summary row
• when a cluster-wide or unusual binding already looks important

What To Look For

• cluster-wide grants before namespace-local grants
• service-account subjects attached to powerful roles
• signals such as admin-like wildcard access, change workloads, or visibility blocked
• the lightweight * built-in role marker on known Kubernetes role names

Why It Matters

Kubernetes access stories are easy to oversimplify if you never look at the underlying bindings.

rbac grounds later claims in real assignment evidence. It shows whether an identity path matters because the grant is actually broad, actually risky, or only looks suspicious in summary.

What Should Stand Out First

• cluster-wide bindings
• service accounts bound to stronger roles
• impersonation, secret-read, workload-change, or wildcard-style signals
• visibility gaps where the binding is readable but the referenced role detail is not

If You See..., Go Next To...

• If you see the current identity on a broad or unusual binding, go next to Permissions because the next question is what that grant means in practice.
• If you see a strong service-account binding, go next to Service Accounts because the next question is which workloads use that identity path.
• If the grant sits behind an already interesting workload, go next to Workloads because the execution context may matter as much as the binding.

What To Do Next

• Use rbac to confirm the evidence behind a capability or identity story.
• Treat built-in role markers as a reading aid, not as a trust guarantee.
• Pivot into permissions, service-accounts, or workloads based on whether the next question is current capability, workload linkage, or runtime consequence.

Boundary

rbac is an evidence command.

It shows assignment truth, not full effective-permission proof, escalation analysis, or defended multi-hop attack paths.