Implementing RBAC Hardening for Kubernetes

Overview

Kubernetes RBAC regulates access to cluster resources based on roles assigned to users, groups, and service accounts. Default configurations often grant excessive permissions, and without active hardening, RBAC becomes a primary attack vector for privilege escalation, lateral movement, and data exfiltration. Hardening requires implementing least-privilege principles, eliminating unnecessary ClusterRole bindings, separating service accounts, integrating external identity providers, and continuous auditing.

Prerequisites

• Kubernetes cluster v1.24+ with RBAC enabled (default since v1.6)
• kubectl access with cluster-admin for initial audit
• External identity provider (OIDC) for user authentication
• Audit logging enabled on the API server

Core Hardening Principles

1. Eliminate cluster-admin Sprawl

Audit and remove unnecessary cluster-admin bindings:

# List all cluster-admin bindings
kubectl get clusterrolebindings -o json | jq -r '
  .items[] |
  select(.roleRef.name == "cluster-admin") |
  "\(.metadata.name) -> \(.subjects[]? | "\(.kind)/\(.name) (\(.namespace // "cluster"))")"
'

2. Namespace-Scoped Roles Over ClusterRoles

Use Role and RoleBinding instead of ClusterRole and ClusterRoleBinding:

# Good: Namespace-scoped role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: application
  name: app-developer
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: application
  name: app-developer-binding
subjects:
  - kind: Group
    name: dev-team
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: app-developer
  apiGroup: rbac.authorization.k8s.io

3. Dedicated Service Accounts Per Workload

apiVersion: v1
kind: ServiceAccount
metadata:
  name: payment-processor
  namespace: payments
automountServiceAccountToken: false  # Disable auto-mount
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-processor
  namespace: payments
spec:
  template:
    spec:
      serviceAccountName: payment-processor
      automountServiceAccountToken: true  # Only mount when explicitly needed
      containers:
        - name: processor
          image: payments/processor:v2.1@sha256:abc...

4. Restrict Dangerous Permissions

Block permissions that enable privilege escalation:

# Dangerous verbs/resources to restrict:
# - secrets: get, list, watch (exposes all secrets in namespace)
# - pods/exec: create (enables command execution in pods)
# - pods: create with privileged securityContext
# - serviceaccounts/token: create (generates new tokens)
# - clusterroles/clusterrolebindings: create, update (self-escalation)
# - nodes/proxy: create (bypasses API server authorization)

# Safe read-only role example
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: security-viewer
rules:
  - apiGroups: [""]
    resources: ["pods", "services", "namespaces", "nodes"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["apps"]
    resources: ["deployments", "daemonsets", "statefulsets"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["networking.k8s.io"]
    resources: ["networkpolicies"]
    verbs: ["get", "list", "watch"]

5. OIDC Integration for User Authentication

# API server flags for OIDC integration
apiVersion: v1
kind: Pod
metadata:
  name: kube-apiserver
spec:
  containers:
    - name: kube-apiserver
      command:
        - kube-apiserver
        - --oidc-issuer-url=https://idp.company.com
        - --oidc-client-id=kubernetes
        - --oidc-username-claim=email
        - --oidc-groups-claim=groups
        - --oidc-ca-file=/etc/kubernetes/pki/oidc-ca.crt

RBAC Audit Process

Step 1: Enumerate All Bindings

# All ClusterRoleBindings with subjects
kubectl get clusterrolebindings -o json | jq -r '
  .items[] | select(.subjects != null) |
  .subjects[] as $s |
  "\(.metadata.name) | \(.roleRef.name) | \($s.kind)/\($s.name)"
' | sort | column -t -s '|'

# All RoleBindings across namespaces
kubectl get rolebindings --all-namespaces -o json | jq -r '
  .items[] | select(.subjects != null) |
  .subjects[] as $s |
  "\(.metadata.namespace) | \(.metadata.name) | \(.roleRef.name) | \($s.kind)/\($s.name)"
' | sort | column -t -s '|'

Step 2: Identify Overprivileged Service Accounts

# Find service accounts with cluster-admin or admin roles
kubectl get clusterrolebindings -o json | jq -r '
  .items[] |
  select(.roleRef.name == "cluster-admin" or .roleRef.name == "admin") |
  select(.subjects[]?.kind == "ServiceAccount") |
  "\(.subjects[] | select(.kind == "ServiceAccount") | "\(.namespace)/\(.name)")"
'

Step 3: Check Default Service Account Usage

# Find pods using the default service account
kubectl get pods --all-namespaces -o json | jq -r '
  .items[] |
  select(.spec.serviceAccountName == "default" or .spec.serviceAccountName == null) |
  "\(.metadata.namespace)/\(.metadata.name)"
'

Step 4: Verify Token Auto-Mount

# Find pods with auto-mounted service account tokens
kubectl get pods --all-namespaces -o json | jq -r '
  .items[] |
  select(.spec.automountServiceAccountToken != false) |
  "\(.metadata.namespace)/\(.metadata.name) sa=\(.spec.serviceAccountName // "default")"
'

Tooling

rbac-lookup

# Install rbac-lookup
kubectl krew install rbac-lookup

# View RBAC for a specific user
kubectl rbac-lookup developer@company.com

# View all RBAC bindings wide format
kubectl rbac-lookup --kind user -o wide

rakkess (Review Access)

# Install rakkess
kubectl krew install access-matrix

# Show access matrix for current user
kubectl access-matrix

# Show access for a specific service account
kubectl access-matrix --sa payments:payment-processor

Verification Criteria

Confirm successful execution by validating:

• [ ] All prerequisite tools and access requirements are satisfied
• [ ] Each workflow step completed without errors
• [ ] Output matches expected format and contains expected data
• [ ] No security warnings or misconfigurations detected
• [ ] Results are documented and evidence is preserved for audit

Compliance Framework Mapping

This skill supports compliance evidence collection across multiple frameworks:

• SOC 2: CC6.1 (Logical Access), CC7.1 (Monitoring), CC8.1 (Change Management)
• ISO 27001: A.14.2 (Secure Development), A.12.6 (Technical Vulnerability Mgmt)
• NIST 800-53: CM-7 (Least Functionality), SI-2 (Flaw Remediation), SC-28 (Protection at Rest)
• NIST CSF: PR.IP (Information Protection), PR.DS (Data Security)

Claw GRC Tip: When this skill is executed by a registered agent, compliance evidence is automatically captured and mapped to the relevant controls in your active frameworks.

Deploying This Skill with Claw GRC

Agent Execution

Register this skill with your Claw GRC agent for automated execution:

# Install via CLI
npx claw-grc skills add implementing-rbac-hardening-for-kubernetes

# Or load dynamically via MCP
grc.load_skill("implementing-rbac-hardening-for-kubernetes")

Audit Trail Integration

When executed through Claw GRC, every step of this skill generates tamper-evident audit records:

• SHA-256 chain hashing ensures no step can be modified after execution
• Evidence artifacts (configs, scan results, logs) are automatically attached to relevant controls
• Trust score impact — successful execution increases your agent's trust score

Continuous Compliance

Schedule this skill for recurring execution to maintain continuous compliance posture. Claw GRC monitors for drift and alerts when re-execution is needed.

References

• Kubernetes RBAC Documentation
• CIS Kubernetes Benchmark - RBAC Controls
• Kubernetes Security Hardening Guide 2025
• OWASP Kubernetes Security Cheat Sheet