implementing-rbac-hardening-for-kubernetes

Harden Kubernetes Role-Based Access Control by implementing least-privilege policies, auditing role bindings, eliminating cluster-admin sprawl, and integrating external identity providers.

インストールへ移動

リポジトリ: xalgord/xalgorix
ソースの最終更新活動: 2026年6月6日 16:41
検出された SKILL.md の言語: 英語
スター: 813
フォーク: 146

インストール方法

デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。

npx skills add https://github.com/xalgord/xalgorix --skill implementing-rbac-hardening-for-kubernetes

コマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。

ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。

ソースファイルを確認

インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。

SKILL.md

ソースの指示 · 読み取り専用プレビュー

検索に戻るインストールに戻る

exploiting-http-request-smuggling

Detecting and exploiting HTTP request smuggling vulnerabilities caused by Content-Length and Transfer-Encoding parsing discrepancies between front-end and back-end servers.

2026-07-20

exploiting-oauth-misconfiguration

Identifying and exploiting OAuth 2.0 and OpenID Connect misconfigurations including redirect URI manipulation, token leakage, and authorization code theft during security assessments.

2026-07-20

exploiting-subdomain-takeover-vulnerabilities

Identifying and exploiting dangling DNS records pointing to unclaimed cloud services, enabling subdomain takeover for phishing, cookie stealing, and authentication bypass during authorized penetration tests.

2026-06-19

このリポジトリのすべてを見る

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

Common Misconfigurations & Verification

These are the RBAC grants that look harmless but hand over the cluster. Grep every Role/ClusterRole before signing off:

Wildcard verbs/resources: verbs: ["*"] or resources: ["*"] on any apiGroup is effectively admin. Find them:

kubectl get clusterroles,roles -A -o json | jq '.items[]|select(.rules[]?|(.verbs[]?=="*") or (.resources[]?=="*"))|.metadata.name'

Escalation verbs: escalate and bind on roles/clusterroles let a subject grant themselves any permission - a namespace escalate is equivalent to cluster-admin. impersonate on users/groups/serviceaccounts bypasses their own RBAC entirely.

Token/exec paths: create on pods/exec, pods/attach, serviceaccounts/token, or secrets get/list are lateral-movement primitives even without admin.

Aggregated ClusterRoles: roles with aggregationRule silently inherit new permissions when matching-labeled roles are added.

Verify, don't assume: confirm the effective access with kubectl auth can-i <verb> <resource> --as=system:serviceaccount:<ns>:<sa> rather than reading YAML, and cross-check with rbac-lookup / access-matrix. A binding that references a non-existent role is inert; a binding to system:authenticated or system:anonymous applies to everyone. Re-run after every change - RBAC is additive and never subtracts.