Skip to content
Skillpedia
Deploy & cloud (DevOps)35k · #5944

implementing-rbac-hardening-for-kubernetes

Teaches your AI agent to ship projects and manage infrastructure.

What it does

This agent helps make your Kubernetes system more secure by controlling who can access what. It ensures that each user or service only has the permissions strictly necessary to perform their tasks, preventing unauthorized access.

When to use it

  • ✓When you want to restrict access to important resources in your Kubernetes cluster.
  • ✓When setting up a new Kubernetes environment and wanting to start securely.
  • ✓If you suspect some service accounts have too many permissions.

Example of what to ask your AI

“How can I restrict a specific service's access to only read pod information in the 'production' namespace?”

Want more? Open the sections below.

How to use

The easiest way: copy the message below and paste it into Claude, ChatGPT, Cursor or any AI. It reads the skill and follows the instructions.

Skill link

https://github.com/mukul975/Anthropic-Cybersecurity-Skills/blob/main/skills/implementing-rbac-hardening-for-kubernetes/SKILL.md

Ready-to-paste message

Use this skill to help me: https://github.com/mukul975/Anthropic-Cybersecurity-Skills/blob/main/skills/implementing-rbac-hardening-for-kubernetes/SKILL.md Read the SKILL.md file at that link and follow its instructions for my task.
How it works

It analyzes existing permissions and suggests or applies more restrictive configurations. This involves creating more specific access rules (Roles) instead of broad permissions (ClusterRoles) and ensuring each service uses a unique identity with minimal privileges.

Installation

Easiest way: copy the skill link and paste it into Claude, ChatGPT or Cursor asking it to follow the instructions.

In the terminal (Claude Code, Codex, Cursor), in your project folder:

npx skills add mukul975/Anthropic-Cybersecurity-Skills --skill implementing-rbac-hardening-for-kubernetes

Or download just the file:

curl -L https://raw.githubusercontent.com/mukul975/Anthropic-Cybersecurity-Skills/main/skills/implementing-rbac-hardening-for-kubernetes/SKILL.md -o SKILL.md
Technical content (original SKILL.md)

Original text by the author, straight from GitHub.

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.

When to Use

  • When deploying or configuring implementing rbac hardening for kubernetes capabilities in your environment
  • When establishing security controls aligned to compliance requirements
  • When building or improving security architecture for this domain
  • When conducting security assessments that require this implementation

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


…
FAQ

What is RBAC?

RBAC (Role-Based Access Control) is a system that defines what users or services can do within Kubernetes based on the 'roles' they are assigned.

Why is 'cluster-admin' dangerous?

The 'cluster-admin' permission grants full control over the entire Kubernetes cluster. Giving it to too many people or services increases the risk of errors or attacks.

What does 'least-privilege' mean?

It means giving each user or service only the minimum permissions needed to do their job, and nothing more. It's a fundamental security principle.

Details

Original description by the author

Hardens Kubernetes RBAC by designing least-privilege Roles and ClusterRoles, auditing RoleBindings, eliminating cluster-admin sprawl, separating service accounts, and integrating an external OIDC identity provider. Use when tightening cluster access control, removing excessive ClusterRoleBindings, or hardening service-account permissions against escalation and lateral movement. Keywords: RBAC, Rol

repo: mukul975/Anthropic-Cybersecurity-Skills

Popularity

GitHub stars
35k
Ranking position
#5944
License
Apache-2.0
Updated
8/31/2026

Is this skill useful?

0

Sign in to vote.

Comments

  • …

More skills from this repository

Similar skills