implementing-rbac-hardening-for-kubernetes

通过实施最小权限策略、审计角色绑定、消除 cluster-admin 权限蔓延并集成外部身份提供商,加固 Kubernetes 基于角色的访问控制(RBAC)。

9 stars

Best use case

implementing-rbac-hardening-for-kubernetes is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

通过实施最小权限策略、审计角色绑定、消除 cluster-admin 权限蔓延并集成外部身份提供商,加固 Kubernetes 基于角色的访问控制(RBAC)。

Teams using implementing-rbac-hardening-for-kubernetes should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/implementing-rbac-hardening-for-kubernetes/SKILL.md --create-dirs "https://raw.githubusercontent.com/killvxk/cybersecurity-skills-zh/main/skills/implementing-rbac-hardening-for-kubernetes/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/implementing-rbac-hardening-for-kubernetes/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How implementing-rbac-hardening-for-kubernetes Compares

Feature / Agentimplementing-rbac-hardening-for-kubernetesStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

通过实施最小权限策略、审计角色绑定、消除 cluster-admin 权限蔓延并集成外部身份提供商,加固 Kubernetes 基于角色的访问控制(RBAC)。

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# 实施 Kubernetes RBAC 加固

## 概述

Kubernetes 基于角色的访问控制(RBAC,Role-Based Access Control)根据分配给用户、组和服务账户的角色来管理对集群资源的访问。默认配置通常会授予过多权限,若不主动加固,RBAC 会成为权限提升(Privilege Escalation)、横向移动(Lateral Movement)和数据外泄(Exfiltration)的主要攻击入口。加固工作需要实施最小权限原则(Least Privilege)、消除不必要的 ClusterRole 绑定、隔离服务账户、集成外部身份提供商,并持续进行审计。

## 前置条件

- Kubernetes 集群 v1.24+,已启用 RBAC(v1.6 起默认开启)
- 具有 cluster-admin 权限的 kubectl 访问(用于初始审计)
- 用于用户认证的外部身份提供商(OIDC)
- API server 已启用审计日志

## 核心加固原则

### 1. 消除 cluster-admin 权限蔓延

审计并移除不必要的 cluster-admin 绑定:

```bash
# 列出所有 cluster-admin 绑定
kubectl get clusterrolebindings -o json | jq -r '
  .items[] |
  select(.roleRef.name == "cluster-admin") |
  "\(.metadata.name) -> \(.subjects[]? | "\(.kind)/\(.name) (\(.namespace // "cluster"))")"
'
```

### 2. 优先使用命名空间范围的 Role 而非 ClusterRole

使用 Role 和 RoleBinding 替代 ClusterRole 和 ClusterRoleBinding:

```yaml
# 推荐:命名空间范围的角色
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. 为每个工作负载使用专用服务账户

```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: payment-processor
  namespace: payments
automountServiceAccountToken: false  # 禁用自动挂载
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-processor
  namespace: payments
spec:
  template:
    spec:
      serviceAccountName: payment-processor
      automountServiceAccountToken: true  # 仅在明确需要时挂载
      containers:
        - name: processor
          image: payments/processor:v2.1@sha256:abc...
```

### 4. 限制危险权限

阻止可导致权限提升的权限:

```yaml
# 需要限制的危险动词/资源:
# - secrets: get, list, watch(暴露命名空间内所有密钥)
# - pods/exec: create(允许在 Pod 内执行命令)
# - pods: create(带特权 securityContext)
# - serviceaccounts/token: create(生成新令牌)
# - clusterroles/clusterrolebindings: create, update(自我提权)
# - nodes/proxy: create(绕过 API server 授权)

# 安全的只读角色示例
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 实现用户认证

```yaml
# OIDC 集成的 API server 参数
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 审计流程

### 步骤 1:枚举所有绑定

```bash
# 列出所有带主体的 ClusterRoleBinding
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 '|'

# 列出所有命名空间的 RoleBinding
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 '|'
```

### 步骤 2:识别过度授权的服务账户

```bash
# 查找具有 cluster-admin 或 admin 角色的服务账户
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)")"
'
```

### 步骤 3:检查默认服务账户使用情况

```bash
# 查找使用默认服务账户的 Pod
kubectl get pods --all-namespaces -o json | jq -r '
  .items[] |
  select(.spec.serviceAccountName == "default" or .spec.serviceAccountName == null) |
  "\(.metadata.namespace)/\(.metadata.name)"
'
```

### 步骤 4:验证令牌自动挂载

```bash
# 查找自动挂载服务账户令牌的 Pod
kubectl get pods --all-namespaces -o json | jq -r '
  .items[] |
  select(.spec.automountServiceAccountToken != false) |
  "\(.metadata.namespace)/\(.metadata.name) sa=\(.spec.serviceAccountName // "default")"
'
```

## 工具

### rbac-lookup

```bash
# 安装 rbac-lookup
kubectl krew install rbac-lookup

# 查看特定用户的 RBAC 配置
kubectl rbac-lookup developer@company.com

# 以宽格式查看所有 RBAC 绑定
kubectl rbac-lookup --kind user -o wide
```

### rakkess(访问审查)

```bash
# 安装 rakkess
kubectl krew install access-matrix

# 显示当前用户的访问矩阵
kubectl access-matrix

# 显示特定服务账户的访问权限
kubectl access-matrix --sa payments:payment-processor
```

## 参考资料

- [Kubernetes RBAC 文档](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
- [CIS Kubernetes 基准 - RBAC 控制项](https://www.cisecurity.org/benchmark/kubernetes)
- [Kubernetes 安全加固指南 2025](https://sealos.io/blog/a-practical-guide-to-kubernetes-security-hardening-your-cluster-in-2025/)
- [OWASP Kubernetes 安全速查表](https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html)

Related Skills

securing-kubernetes-on-cloud

9
from killvxk/cybersecurity-skills-zh

本技能涵盖通过实施 Pod 安全标准(Pod Security Standards)、网络策略、工作负载身份、RBAC 权限控制、镜像准入控制和运行时安全监控,对 EKS、AKS 和 GKE 上的托管 Kubernetes 集群进行加固。涉及云平台特定安全功能,包括 EKS 的 IRSA、GKE 的工作负载身份(Workload Identity)以及 AKS 的托管身份(Managed Identity)。

scanning-kubernetes-manifests-with-kubesec

9
from killvxk/cybersecurity-skills-zh

使用 Kubesec 对 Kubernetes 资源清单执行安全风险分析,识别错误配置、权限提升风险以及与安全最佳实践的偏差。

performing-kubernetes-penetration-testing

9
from killvxk/cybersecurity-skills-zh

Kubernetes 渗透测试(Penetration Testing)通过对 API server、kubelet、etcd、Pod、RBAC、网络策略和密钥模拟攻击者技术,系统性评估集群安全性。使用 kube-hunter、Kubescape、peirates 等工具识别可能导致集群被攻陷的错误配置。

performing-kubernetes-etcd-security-assessment

9
from killvxk/cybersecurity-skills-zh

通过评估静态加密、TLS 配置、访问控制、备份加密和网络隔离,评估 Kubernetes etcd 集群的安全态势。

performing-kubernetes-cis-benchmark-with-kube-bench

9
from killvxk/cybersecurity-skills-zh

使用 kube-bench 对照 CIS Benchmark 审计 Kubernetes 集群安全态势,对控制平面、工作节点和 RBAC 执行自动化检查。

performing-container-image-hardening

9
from killvxk/cybersecurity-skills-zh

本技能涵盖通过最小化攻击面、移除不必要软件包、实施多阶段构建、配置非 root 用户, 以及应用 CIS Docker 基准建议来加固容器镜像,生成安全的生产就绪镜像。

implementing-zero-trust-with-hashicorp-boundary

9
from killvxk/cybersecurity-skills-zh

使用 HashiCorp Boundary 实现具备动态凭据代理、会话录制和 Vault 集成的身份感知零信任基础设施访问管理。

implementing-zero-trust-with-beyondcorp

9
from killvxk/cybersecurity-skills-zh

使用身份感知代理(IAP,Identity-Aware Proxy)、上下文感知访问策略、设备信任验证和 Access Context Manager,部署 Google BeyondCorp Enterprise 零信任访问控制,对 GCP 资源和内部应用强制执行基于身份和安全态势的访问。

implementing-zero-trust-network-access

9
from killvxk/cybersecurity-skills-zh

通过配置身份感知代理、微分段、基于条件访问策略的持续验证,以及在 AWS、Azure 和 GCP 环境中以 BeyondCorp 风格的架构替代传统 VPN 访问,在云环境中实施零信任网络访问(ZTNA)。

implementing-zero-trust-network-access-with-zscaler

9
from killvxk/cybersecurity-skills-zh

使用 Zscaler 实施零信任网络访问(Zero Trust Network Access,ZTNA),通过 Zscaler Private Access(ZPA)配置应用分段、访问策略和连接器,替代传统 VPN 架构

implementing-zero-trust-in-cloud

9
from killvxk/cybersecurity-skills-zh

本技能指导组织按照 NIST SP 800-207 和 Google BeyondCorp 原则在云环境中实施零信任(Zero Trust)架构,涵盖以身份为中心的访问控制、微分段(Micro-Segmentation)、持续验证、设备信任评估,以及部署身份感知代理(Identity-Aware Proxy)以消除 AWS、Azure 和 GCP 环境中的隐式网络信任。

implementing-zero-trust-for-saas-applications

9
from killvxk/cybersecurity-skills-zh

使用 CASB、SSPM、条件访问策略、OAuth 应用治理和会话控制,为 SaaS 应用实施零信任访问控制, 对云托管服务强制执行身份验证、设备合规性检查和数据保护。