Přeskočit na obsah
_CORE
AI & Agentic Systems Core Informační Systémy Cloud & Platform Engineering Data Platforma & Integrace Security & Compliance QA, Testing & Observability IoT, Automatizace & Robotika Mobile & Digital Banky & Finance Pojišťovnictví Veřejná správa Obrana & Bezpečnost Zdravotnictví Energetika & Utility Telco & Média Průmysl & Výroba Logistika & E-commerce Retail & Loyalty
Reference Technologie Blog Knowledge Base O nás Spolupráce Kariéra
Pojďme to probrat

Kubernetes RBAC — řízení přístupu v multi-tenant clusteru

28. 03. 2017 2 min čtení CORE SYSTEMSdevelopment

Kubernetes 1.6 přináší RBAC jako beta feature — a pro nás je to naprosto klíčové. V jednom clusteru máme vývojáře, ops tým i CI/CD pipeline, a každý potřebuje jiná oprávnění.

Proč RBAC potřebujeme

Do verze 1.6 měl Kubernetes v podstatě dva režimy: ABAC (statické politiky v JSON souboru na API serveru) nebo žádnou autorizaci. ABAC bylo nepraktické — každá změna vyžadovala restart API serveru.

RBAC je dynamické. Role, ClusterRole, RoleBinding, ClusterRoleBinding — vše je Kubernetes objekt, spravovatelný přes kubectl a verzovatelný v Gitu.

Náš model: namespace per tým

Každý tým (nebo klient) dostane vlastní namespace. V tom namespace má plná práva — může vytvářet deploymenty, služby, confmapy. Ale nemůže vidět ani měnit nic v jiném namespace.

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  namespace: team-alpha
  name: team-alpha-admin
rules:
- apiGroups: ["", "apps", "batch"]
  resources: ["*"]
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  namespace: team-alpha
  name: team-alpha-binding
subjects:
- kind: Group
  name: "team-alpha"
roleRef:
  kind: Role
  name: team-alpha-admin
  apiGroup: rbac.authorization.k8s.io

Service accounts pro CI/CD

Jenkins potřebuje deploynout do clusteru, ale nechceme mu dávat cluster-admin. Vytvoříme service account s přesně definovanými právy — může vytvářet a updatovat deploymenty a služby v konkrétním namespace, nic víc.

Token service accountu předáme Jenkinsu jako credential. Pokud někdo kompromituje Jenkins, nezíská přístup k celému clusteru.

Integrace s LDAP/Active Directory

Kubernetes sám o sobě nemá user management — autentizaci deleguje na externí systém. My používáme OIDC provider (Dex) napojený na firemní Active Directory. Skupiny z AD se mapují na Kubernetes groups.

Setup není triviální, ale výsledek je elegantní: člověk odejde z firmy, zrušíte mu AD účet, a automaticky přijde o přístup do Kubernetes.

Tipy z praxe

  • Začněte s --authorization-mode=RBAC od začátku — migrovat později je bolestivé
  • Používejte skupiny (Groups), ne jednotlivé uživatele v RoleBindings
  • Auditujte — kubectl auth can-i --list ukáže, co uživatel může
  • Pozor na default service account — má často víc práv, než byste chtěli
  • Network policies + RBAC = defense in depth

RBAC je základ bezpečného clusteru

Bez RBAC je Kubernetes cluster jako dům bez zámků. S verzí 1.6 konečně máme produkčně použitelný autorizační model. Investice do správného RBAC nastavení se vrátí mnohonásobně.

kubernetesrbacsecuritymulti-tenancy