agentsclimarketplace

Auditing kubernetes rbac permissions

Skill autohandai/community-skills/auditing-kubernetes-rbac-permissions

A collection of curated, useful, and safe skills for Autohand Code CLI Agent

Install
npx -y skills add autohandai/community-skills --skill auditing-kubernetes-rbac-permissions

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 9 stars9 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Kubernetes Role-Based Access Control (RBAC) auditing systematically reviews roles, cluster roles, bindings, and service account permissions to identify overly permissive access, privilege escalation p

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

6.0 KB, as published. Nobody here has run it

Auditing Kubernetes RBAC Permissions

Overview

Kubernetes Role-Based Access Control (RBAC) auditing systematically reviews roles, cluster roles, bindings, and service account permissions to identify overly permissive access, privilege escalation paths, and violations of least-privilege principles. Tools like rbac-tool, KubiScan, and rakkess automate discovery of dangerous permission combinations.

Prerequisites

  • Kubernetes cluster with RBAC enabled (default since 1.6)
  • kubectl with cluster-admin access for full audit
  • rbac-tool, rakkess, or KubiScan installed

Core Concepts

RBAC Components

ResourceScopePurpose
RoleNamespaceGrants permissions within a namespace
ClusterRoleClusterGrants permissions cluster-wide
RoleBindingNamespaceBinds Role/ClusterRole to subjects in namespace
ClusterRoleBindingClusterBinds ClusterRole to subjects cluster-wide

Dangerous Permission Combinations

PermissionRiskImpact
* on * resourcesCriticalEquivalent to cluster-admin
create podsHighCan deploy privileged pods
create pods/execHighCan exec into any pod
get secretsHighCan read all secrets
create clusterrolebindingsCriticalCan escalate to cluster-admin
impersonate usersCriticalCan act as any user
escalate on rolesCriticalCan grant permissions beyond own
bind on rolesHighCan create new role bindings

Implementation Steps

Step 1: Enumerate All RBAC Resources

# List all ClusterRoles
kubectl get clusterroles -o name | wc -l
kubectl get clusterroles --no-headers | grep -v "system:"

# List all ClusterRoleBindings
kubectl get clusterrolebindings -o wide

# List all Roles per namespace
kubectl get roles -A

# List all RoleBindings per namespace
kubectl get rolebindings -A -o wide

# Export all RBAC for offline analysis
kubectl get clusterroles,clusterrolebindings,roles,rolebindings -A -o yaml > rbac-export.yaml

Step 2: Identify Wildcard Permissions

# Find ClusterRoles with wildcard verbs on all resources
kubectl get clusterroles -o json | jq -r '
  .items[] |
  select(.rules[]? |
    (.verbs | index("*")) and
    (.resources | index("*"))
  ) |
  .metadata.name'

# Find roles that can create pods
kubectl get clusterroles -o json | jq -r '
  .items[] |
  select(.rules[]? |
    (.verbs | index("create") or index("*")) and
    (.resources | index("pods") or index("*"))
  ) |
  .metadata.name'

# Find roles that can read secrets
kubectl get clusterroles -o json | jq -r '
  .items[] |
  select(.rules[]? |
    (.verbs | index("get") or index("list") or index("*")) and
    (.resources | index("secrets") or index("*"))
  ) |
  .metadata.name'

Step 3: Check Service Account Permissions

# List all service accounts
kubectl get serviceaccounts -A

# Check permissions for default service accounts
for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do
  echo "=== $ns/default ==="
  kubectl auth can-i --list --as=system:serviceaccount:$ns:default 2>/dev/null | grep -v "no"
done

# Check for service accounts with cluster-admin
kubectl get clusterrolebindings -o json | jq -r '
  .items[] |
  select(.roleRef.name == "cluster-admin") |
  {binding: .metadata.name, subjects: [.subjects[]? | {kind, name, namespace}]}'

Step 4: Use rbac-tool for Automated Analysis

# Install rbac-tool
kubectl krew install rbac-tool

# Visualize RBAC
kubectl rbac-tool viz --outformat dot | dot -Tpng > rbac-graph.png

# Find who can perform specific actions
kubectl rbac-tool who-can get secrets -A
kubectl rbac-tool who-can create pods -A
kubectl rbac-tool who-can '*' '*'

# Analyze all permissions
kubectl rbac-tool analysis

# Generate RBAC policy report
kubectl rbac-tool auditgen > rbac-audit.yaml

Step 5: Check for Privilege Escalation Paths

# Check if any role can escalate privileges
kubectl get clusterroles -o json | jq -r '
  .items[] |
  select(.rules[]? |
    (.verbs | index("escalate") or index("bind") or index("impersonate")) and
    (.resources | index("clusterroles") or index("roles") or index("clusterrolebindings") or index("rolebindings") or index("users") or index("groups") or index("serviceaccounts"))
  ) |
  .metadata.name'

# Check for impersonation permissions
kubectl get clusterroles -o json | jq -r '
  .items[] |
  select(.rules[]? |
    (.verbs | index("impersonate"))
  ) |
  {name: .metadata.name, rules: .rules}'

Step 6: Audit with KubiScan

# Install KubiScan
pip install kubiscan

# Find risky roles
kubiscan --risky-roles

# Find risky ClusterRoles
kubiscan --risky-clusterroles

# Find risky subjects
kubiscan --risky-subjects

# Find pods with risky service accounts
kubiscan --risky-pods

# Full report
kubiscan --all

Validation Commands

# Verify specific permission
kubectl auth can-i create pods --as=system:serviceaccount:default:myapp

# Check all permissions for a user
kubectl auth can-i --list [email protected]

# Validate RBAC with kubescape
kubescape scan framework nsa --controls-config rbac-controls.json

# Test least privilege
kubectl auth can-i delete nodes --as=system:serviceaccount:app:web-server
# Expected: no

References

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.