K8s RBAC Generator

Kubernetes RBAC Role & ClusterRoleBinding YAML Generator

Erstellen Sie Kubernetes RBAC Role-, ClusterRole-, RoleBinding- und ClusterRoleBinding-Manifeste mit API-Gruppen, Ressourcen-Verben und Subject-Service-Accounts.

Vorlagen:
RBAC-Rollen- und Subjekt-Konfiguration
RBAC-Geltungsbereich (Role vs. ClusterRole)Namespace-gebunden
RoleBinding
RoleBinding-Subjekte (Benutzer, Gruppen, ServiceAccounts)
rbac.authorization.k8s.io
rbac.authorization.k8s.io
RBAC-Richtlinienregeln (apiGroups, resources, verbs)2
#1Regel #1: pods, pods/log, events
#2Regel #2: deployments, replicasets
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-log-reader
  namespace: staging
  labels:
    app.kubernetes.io/part-of: developer-access
    env: staging
rules:
  - apiGroups:
      - ""
    resources:
      - "pods"
      - "pods/log"
      - "events"
    verbs:
      - "get"
      - "list"
      - "watch"
  - apiGroups:
      - "apps"
    resources:
      - "deployments"
      - "replicasets"
    verbs:
      - "get"
      - "list"
      - "watch"
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-log-reader-binding
  namespace: staging
  labels:
    app.kubernetes.io/part-of: developer-access
    env: staging
subjects:
  - kind: Group
    name: frontend-developers
    apiGroup: rbac.authorization.k8s.io
  - kind: User
    name: [email protected]
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-log-reader
  apiGroup: rbac.authorization.k8s.io
Richtlinienregeln
Role (Namespace: staging)
Gebundene Subjekte
2 Subjekte (0 SA, 2 User/Group)
RBAC-Bereich
Note A: Gehärtet & präzise abgegrenzt

rbac.authorization.k8s.io/v1 Spezifikationsstandard

Strikte Konformität mit rbac.authorization.k8s.io/v1 Spezifikationen für Namespace-gebundene Roles und clusterweite ClusterRoles.

Zero-Knowledge im Browser

Alle RBAC-Richtlinien, Service-Accounts und Cluster-Berechtigungen werden vollständig in Ihrer lokalen Browser-Sandbox berechnet.

Least-Privilege & Produktionsreif

Generiert produktionsreife Manifeste mit automatischer Least-Privilege-Sicherheitsanalyse gegen gefährliche Wildcards und Rechteausweitungen.

Technische Referenz & Architektur-Leitfaden

Kubernetes RBAC Role & ClusterRoleBinding YAML Generator — Referenz-Leitfaden

Erstellen Sie Kubernetes RBAC Role-, ClusterRole-, RoleBinding- und ClusterRoleBinding-Manifeste mit API-Gruppen, Ressourcen-Verben und Subject-Service-Accounts.

Wichtige Parameter & Steuerelemente

kindstring

Definiert den Typ der RBAC-Ressource ('Role', 'ClusterRole', 'RoleBinding' oder 'ClusterRoleBinding').

Standard: Role
rules[].apiGroupsarray[string]

Kubernetes-API-Gruppen der Zielressourcen (verwenden Sie '""' für Core-Ressourcen wie Pods/Services, 'apps' für Deployments).

Standard: [""]
rules[].resourcesarray[string]

Pluralnamen der Kubernetes-Ressourcen, auf die Zugriff gewährt werden soll (z. B. 'pods', 'configmaps', 'deployments', 'secrets').

Standard: ["pods"]
rules[].verbsarray[string]

Zulässige API-Aktionsverben für die Ressourcen ('get', 'list', 'watch', 'create', 'update', 'patch', 'delete').

Standard: ["get", "list"]
subjectsarray[object]

Liste der Entitäten (ServiceAccount, User oder Group), denen in einem RoleBinding Berechtigungen erteilt werden.

Standard: Required for Bindings
roleRefobject

Verweis auf die zugewiesene Role oder ClusterRole innerhalb eines RoleBinding oder ClusterRoleBinding.

Standard: Required for Bindings

Profi-Tipps & Best Practices

Wildcard-Rechte vermeiden

Vermeiden Sie Platzhalter-Sternchen ('*') in Verben und Ressourcen. Vergeben Sie standardmäßig nur Lese-Verben ('get', 'list', 'watch'), es sei denn, Schreibzugriff ist zwingend erforderlich.

ClusterRole im Namespace binden

Definieren Sie allgemeine Berechtigungsregeln einmalig in einer ClusterRole und binden Sie diese mit einem namespaced RoleBinding ein, um die Rechte streng auf einen einzigen Namespace zu beschränken.

RBAC-Rechte mit can-i prüfen

Überprüfen Sie angewendete RBAC-Richtlinien unmittelbar mit 'kubectl auth can-i <verb> <resource> --as=system:serviceaccount:<namespace>:<name>', bevor Anwendungen ausgerollt werden.

Häufige Fallstricke & Fehlerbehebung

Fehlermeldung 'is forbidden: User cannot list resource in API group'

Stellen Sie sicher, dass 'rules[].apiGroups' exakt definiert ist ('' für Core-Ressourcen, 'apps' für Deployments) und die Ressourcennamen im Plural angegeben sind ('services' statt 'service').

RoleBinding gewährt keinen Zugriff auf Ressourcen in anderen Namespaces

Ein RoleBinding kann Berechtigungen niemals über den eigenen Namespace hinaus erteilen. Verwenden Sie für clusterweiten Zugriff ein ClusterRoleBinding oder erstellen Sie separate RoleBindings in jedem Ziel-Namespace.

Häufig gestellte Fragen (FAQ)

Worin besteht der Unterschied zwischen einer Role und einer ClusterRole?▼

Eine Role definiert Berechtigungen ausschließlich innerhalb eines bestimmten Namespaces. Eine ClusterRole gilt clusterweit und ermöglicht auch den Zugriff auf clusterweite Ressourcen wie Nodes, Namespaces oder PersistentVolumes.

Kann ein RoleBinding auf eine ClusterRole verweisen?▼

Ja, dies ist ein gängiges Best Practice. Dadurch werden die in der ClusterRole definierten Rechte ausschließlich innerhalb des Namespaces angewendet, in dem sich das RoleBinding befindet.

Warum nutzen Core-Ressourcen wie Pods und Services einen leeren String als apiGroup?▼

In der Kubernetes-Architektur gehören grundlegende Ressourcen zur sogenannten Core-API-Gruppe, die in YAML-Manifesten historisch bedingt als leerer String ("") repräsentiert wird.

Wie beschränke ich Berechtigungen auf eine bestimmte Ressourceninstanz?▼

Sie können das Feld 'resourceNames' in der Regel definieren (z. B. resourceNames: ['meine-configmap']), um Aktionen nur auf diese explizit benannte Instanz zuzulassen.

Verwandte Werkzeuge & Dienstprogramme

Alle Werkzeuge →