What is the least-privilege principle in Kubernetes RBAC and how does this skill apply it?

The least-privilege principle means granting only the minimum permissions necessary for a subject to perform its role. This skill applies it by designing scoped Roles/ClusterRoles with specific verbs (actions), resources, and optional `resourceNames` restrictions, and by using RoleBindings to link subjects only to the roles they need.

How do I test if a user or ServiceAccount has a specific permission in Kubernetes?

Use the `kubectl auth can-i` command, optionally impersonating a user or ServiceAccount, to verify specific permissions. You can also use `kubectl auth reconcile --dry-run` to preview policy changes before applying them.

What is the difference between a Role and a ClusterRole in Kubernetes RBAC?

A Role is namespace-scoped and grants permissions within a single namespace, while a ClusterRole is cluster-wide and grants permissions across all namespaces. Both define rules with verbs, resources, and apiGroups; they are linked to subjects via RoleBinding (namespace-scoped) or ClusterRoleBinding (cluster-wide).

What is a critical security pitfall to avoid when writing Kubernetes RBAC policies?

Never combine `resources: ["*"]` with `verbs: ["*"]` in production, as this grants unrestricted cluster-wide permissions. Instead, use `resourceNames` to narrow scope, separate roles per environment, and regularly audit ClusterRoleBindings for their blast radius.

Skill

Secure Kubernetes Access with RBAC Policies

Name: Kubernetes RBAC Policy Expert
Availability: OnlineOnly
Author: VibeBaza

Designs Kubernetes RBAC policies: least-privilege roles, ServiceAccount bindings, aggregated ClusterRoles, and permission auditing.

Get skill

Works with kubernetes

VibeBaza

Own this? Claim it

Spark score

out of 100

Updated 7 months ago

Fresher alternatives ↓

Version 1.0.0

Models

claude

Add to Favorites

Why it matters

Design and implement robust Role-Based Access Control (RBAC) policies for Kubernetes clusters, ensuring the principle of least privilege and scalable security across environments.

Outcomes

What it gets done

Define secure RBAC roles and bindings for users and service accounts.

Implement namespace-scoped and cluster-wide access controls.

Audit and troubleshoot Kubernetes RBAC configurations.

Develop strategies for multi-environment RBAC and custom resource access.

Install

Add it to your toolbox

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/vb-kubernetes-rbac-policy | bash

Overview

Kubernetes RBAC Policy Expert

Guides Kubernetes RBAC policy design - least-privilege Roles and ClusterRoles, ServiceAccount bindings, multi-environment access structuring, aggregated ClusterRoles, and validation/auditing. Reach for this when designing or auditing Kubernetes RBAC, scoping least-privilege access, or troubleshooting forbidden/permission errors.

What it does

This skill designs secure, scalable Kubernetes RBAC policies around the least-privilege principle. It covers the RBAC hierarchy - Subjects (Users, Groups, ServiceAccounts), Roles/ClusterRoles (verbs + resources + apiGroups), and RoleBindings/ClusterRoleBindings linking subjects to roles. A namespace-scoped pod-reader Role shows read access to pods/logs plus a narrowly scoped pods/exec create permission restricted to a specific pod via resourceNames, while a ClusterRole example grants cluster-wide node and metrics read access.

rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["pods/exec"]
  verbs: ["create"]
  resourceNames: ["specific-pod-name"]

A dedicated ServiceAccount pattern disables automatic token mounting when not needed and scopes a Role to get access on one named ConfigMap and one named Secret, bound via a RoleBinding - the standard shape for application-level least privilege. Multi-environment strategy contrasts a permissive developer Role in a non-production namespace (broad access but explicitly empty verbs for cluster-level resources like nodes and PVs) against a strict read-only production-viewer Role limited to a handful of resource types. Advanced patterns cover aggregated ClusterRoles (a base ClusterRole labeled for aggregation, automatically merged into a parent ClusterRole via aggregationRule.clusterRoleSelectors) and custom-resource access rules covering the resource, its /status subresource, and /finalizers for controller-style access.

Security best practices flag common pitfalls: never combining resources: ["*"] with verbs: ["*"] in production, regularly auditing ClusterRoleBindings for their cluster-wide blast radius, using resourceNames to narrow scope, and separating roles per environment. Validation and troubleshooting use kubectl auth can-i (optionally impersonating a user or ServiceAccount) to test specific permissions, kubectl auth reconcile --dry-run to preview policy changes, and standard debug commands for inspecting current context, role bindings, and ServiceAccount tokens when hitting "forbidden" errors. Monitoring guidance covers an audit Policy logging RBAC-related requests at RequestResponse level for rbac.authorization.k8s.io resources.

When to use - and when NOT to

Use this skill when designing or auditing Kubernetes RBAC - scoping least-privilege roles for applications and users, structuring multi-environment access (permissive dev, restrictive prod), building aggregated ClusterRoles for composable permission sets, granting controller-style access to custom resources, or troubleshooting "forbidden" errors.

It is not the right tool for authentication (identity verification) itself, which RBAC assumes is already handled upstream (OIDC, client certs, service account tokens) - RBAC only governs what an authenticated subject is authorized to do, or for admission control/policy enforcement (OPA/Gatekeeper, Kyverno) which governs resource content rather than subject permissions.

Inputs and outputs

Input: the subjects (users, groups, ServiceAccounts) needing access, the resources and actions they require, and the environment/namespace scope. Output: least-privilege Role/ClusterRole definitions with scoped verbs and optional resourceNames restrictions, RoleBinding/ClusterRoleBinding linking subjects to roles, aggregated ClusterRoles for composable permission sets where applicable, and validation commands (kubectl auth can-i) confirming the intended access.

Integrations

Built on native Kubernetes RBAC (rbac.authorization.k8s.io/v1) and the Kubernetes audit logging API (audit.k8s.io/v1) for tracking RBAC decisions, validated via kubectl auth subcommands.

Who it's for

Platform and security engineers designing or auditing Kubernetes access control - particularly those enforcing least privilege across multi-environment clusters, building custom-resource operator permissions, or investigating RBAC-related access denials.

FAQ

Common questions

Discussion