Skip to main content

rakkess

rakkess (Review Access - kubectl plugin) displays an access matrix for Kubernetes resources, showing at a glance which resources a given subject can access. It provides a comprehensive overview of effective permissions, making it easier to audit RBAC configurations and identify potential security issues.

Unlike kubectl auth can-i which checks individual permissions, rakkess shows all permissions across all resource types in a single matrix view.

Use Cases​

  • Quickly audit effective permissions for users, groups, or service accounts.
  • Identify resources that a subject should not have access to.
  • Compare permissions across different subjects or namespaces.
  • Validate RBAC configurations during security reviews.
  • Document access controls for compliance requirements.

Installation​

Install rakkess using krew (the kubectl plugin manager):

kubectl krew install access-matrix

Or download directly from GitHub releases:

curl -LO https://github.com/corneliusweig/rakkess/releases/download/v0.5.0/rakkess-amd64-linux.tar.gz
tar xzf rakkess-amd64-linux.tar.gz
chmod +x rakkess-amd64-linux
sudo mv rakkess-amd64-linux /usr/local/bin/kubectl-access_matrix

Usage Examples​

Show Access Matrix for Current User​

kubectl access-matrix

Example output:

NAME                                  LIST  CREATE  UPDATE  DELETE
bindings                                          ✔
configmaps                            ✔     ✔       ✔       ✔
endpoints                             ✔     ✔       ✔       ✔
events                                ✔
limitranges                           ✔
namespaces                            ✔
nodes                                 ✔
persistentvolumeclaims                ✔     ✔       ✔       ✔
persistentvolumes                     ✔
pods                                  ✔     ✔       ✔       ✔
pods/exec                                   ✔
pods/log                              ✔
secrets                               ✔     ✔       ✔       ✔
serviceaccounts                       ✔     ✔       ✔       ✔
services                              ✔     ✔       ✔       ✔

Check Access for a Specific Service Account​

kubectl access-matrix --as system:serviceaccount:my-namespace:my-sa

Check Access in a Specific Namespace​

kubectl access-matrix -n production

Check Access for a User​

kubectl access-matrix --as jane@example.com

Check Access for a Group​

kubectl access-matrix --as-group developers

Include All Verbs​

kubectl access-matrix --verbs=get,list,watch,create,update,patch,delete,deletecollection

Filter by Resource​

kubectl access-matrix --resource secrets

Output Formats​

# JSON output
kubectl access-matrix -o json

# Wide output (shows all verbs)
kubectl access-matrix -o wide

Understanding the Access Matrix​

The matrix displays:

  • Rows: Kubernetes resource types (pods, secrets, configmaps, etc.)
  • Columns: Verbs (list, create, update, delete, etc.)
  • Cells: Checkmarks indicate allowed actions

Verb Meanings​

VerbDescription
getRead a specific resource by name
listList all resources of a type
watchWatch for changes to resources
createCreate new resources
updateReplace existing resources
patchPartially modify resources
deleteDelete specific resources
deletecollectionDelete multiple resources at once

Common Audit Scenarios​

Audit Service Account Permissions​

# Check default service account in each namespace
for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do
  echo "=== Namespace: $ns ==="
  kubectl access-matrix --as system:serviceaccount:$ns:default -n $ns
done

Compare User Permissions​

# Developer access
kubectl access-matrix --as developer@example.com -n development

# Admin access
kubectl access-matrix --as admin@example.com -n development

Check Cluster-Wide Access​

kubectl access-matrix --all-namespaces

Best Practices​

  • Regular audits: Run access-matrix checks regularly to detect permission drift.
  • Focus on sensitive resources: Pay special attention to secrets, RBAC resources, and pod execution permissions.
  • Compare against baseline: Document expected permissions and compare against actual access.
  • Check service accounts: Audit service accounts in all namespaces, especially the default service account.
  • Combine with other tools: Use alongside kubectl-who-can for bidirectional RBAC analysis.

References​

This article is based on information from the following official sources:

  1. rakkess GitHub Repository - GitHub
  2. Using RBAC Authorization - Kubernetes Documentation
  3. Checking API Access - Kubernetes Documentation

Related Articles

RBAC Security→RBAC→kubectl-who-can→