auditing-kubernetes-rbac-permissions
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
What this skill does
# 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
| Resource | Scope | Purpose |
|----------|-------|---------|
| Role | Namespace | Grants permissions within a namespace |
| ClusterRole | Cluster | Grants permissions cluster-wide |
| RoleBinding | Namespace | Binds Role/ClusterRole to subjects in namespace |
| ClusterRoleBinding | Cluster | Binds ClusterRole to subjects cluster-wide |
### Dangerous Permission Combinations
| Permission | Risk | Impact |
|-----------|------|--------|
| `*` on `*` resources | Critical | Equivalent to cluster-admin |
| create pods | High | Can deploy privileged pods |
| create pods/exec | High | Can exec into any pod |
| get secrets | High | Can read all secrets |
| create clusterrolebindings | Critical | Can escalate to cluster-admin |
| impersonate users | Critical | Can act as any user |
| escalate on roles | Critical | Can grant permissions beyond own |
| bind on roles | High | Can create new role bindings |
## Implementation Steps
### Step 1: Enumerate All RBAC Resources
```bash
# 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
```bash
# 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
```bash
# 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
```bash
# 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
```bash
# 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
```bash
# 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
```bash
# 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
- [Kubernetes RBAC Documentation](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
- [rbac-tool GitHub](https://github.com/alcideio/rbac-tool)
- [KubiScan - Risky Permissions Scanner](https://github.com/cyberark/KubiScan)
- [CIS Kubernetes Benchmark - Section 5.1](https://www.cisecurity.org/benchmark/kubernetes)
Related in Cloud & DevOps
appbuilder-action-scaffolder
IncludedCreate, implement, deploy, and debug Adobe Runtime actions with consistent layout, validation, and error handling. Use this skill whenever the user needs to add actions to an App Builder project, understand action structure (params, response format, web/raw actions), configure actions in the manifest, use App Builder SDKs (State, Files, Events, database), deploy and invoke actions via CLI, debug action issues, or implement patterns such as webhook receivers, custom event providers, journaling consumers, large payload redirects, action sequence pipelines, and Asset Compute workers. Also trigger when users mention serverless functions in Adobe context, action logging, IMS authentication for actions, or cron-style scheduled actions.
orchestrating-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. Use this skill when the user needs a multi-step Data Cloud pipeline, cross-phase troubleshooting, or data space and data kit management. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase sf data360 workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching phase-specific skill), the task is STDM/session tracing/parquet telemetry (use observing-agentforce), standard CRM SOQL (use querying-soql), or Apex implementation (use generating-apex).
github-project-automation
IncludedAutomate GitHub repository setup with CI/CD workflows, issue templates, Dependabot, and CodeQL security scanning. Includes 12 production-tested workflows and prevents 18 errors: YAML syntax, action pinning, and configuration. Use when: setting up GitHub Actions CI/CD, creating issue/PR templates, enabling Dependabot or CodeQL scanning, deploying to Cloudflare Workers, implementing matrix testing, or troubleshooting YAML indentation, action version pinning, secrets syntax, runner versions, or CodeQL configuration. Keywords: github actions, github workflow, ci/cd, issue templates, pull request templates, dependabot, codeql, security scanning, yaml syntax, github automation, repository setup, workflow templates, github actions matrix, secrets management, branch protection, codeowners, github projects, continuous integration, continuous deployment, workflow syntax error, action version pinning, runner version, github context, yaml indentation error
sf-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase `sf data360` workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching sf-datacloud-* skill), the task is STDM/session tracing/parquet telemetry (use sf-ai-agentforce-observability), standard CRM SOQL (use sf-soql), or Apex implementation (use sf-apex).
fabric-cli
IncludedUse this skill for Fabric.so CLI workflows with the `fabric` terminal command: diagnose/install/login, search or browse a Fabric library, save notes/links/files, create folders, ask the Fabric AI assistant, manage tasks/workspaces, generate shell completion, check subscription usage, produce JSON output, and use Fabric as persistent agent memory. Do not use for Microsoft Fabric/Azure/Power BI `fab`, Daniel Miessler's Fabric framework, Python Fabric SSH, Fabric.js, or textile/fashion fabric.
lark
IncludedLark/Feishu CLI skills: lark-cli operations for docs, markdown, sheets, base, calendar, im, mail, task, okr, drive, wiki, slides, whiteboard, apps, approval, attendance, contact, vc, minutes, event. Use when the user needs to operate Lark/Feishu resources via lark-cli, send messages, manage documents, spreadsheets, calendars, tasks, OKRs, deploy web pages, or any Feishu/Lark workspace operations.