RBAC w Kubernetes – kontrola dostępu i zarządzanie uprawnieniami w klastrze

W środowisku Kubernetes bezpieczeństwo nie kończy się na zabezpieczeniu kontenerów. Nawet najlepiej skonfigurowany Pod może stać się zagrożeniem, jeżeli użytkownicy lub aplikacje posiadają zbyt szerokie uprawnienia.

Przykład niebezpiecznej sytuacji:

Developer

↓

cluster-admin

↓

Cały klaster Kubernetes

Jeżeli konto developera zostanie przejęte, atakujący otrzymuje możliwość:

• odczytu wszystkich Secretów,
• tworzenia uprzywilejowanych Podów,
• usuwania aplikacji,
• modyfikacji konfiguracji klastra.

Rozwiązaniem jest RBAC (Role-Based Access Control) – mechanizm kontroli dostępu oparty na rolach.

Czym jest RBAC?

RBAC pozwala definiować:

• kto może wykonać operację,
• na jakich zasobach,
• jakie działania są dozwolone.

Model:

Subject

(User / Group / ServiceAccount)

          |

          ↓

       Role

          |

          ↓

    Permissions

          |

          ↓

 Kubernetes Resources

Przykład:

Developer

↓

Może:

get Pods

create Deployments

Nie może:

delete Namespace

czytać Secrets

Dlaczego RBAC jest ważny?

Domyślna zasada bezpieczeństwa:

Użytkownik powinien posiadać tylko minimalne wymagane uprawnienia.

Jest to zasada Least Privilege.

Bez RBAC często powstaje problem:

Mały problem

↓

Za szerokie uprawnienia

↓

Duży incydent bezpieczeństwa

Elementy RBAC w Kubernetes

RBAC składa się z czterech głównych obiektów:

1. User

Reprezentuje użytkownika.

Przykład:

marek

developer

administrator

Kubernetes sam nie przechowuje użytkowników. Zazwyczaj korzysta z:

• certyfikatów TLS,
• LDAP,
• Active Directory,
• OAuth,
• OIDC.

2. Group

Grupa użytkowników.

Przykład:

developers

security-team

admins

Zamiast nadawać uprawnienia każdej osobie:

Marek

Anna

Piotr

tworzymy:

developers

↓

jedna polityka dostępu

3. ServiceAccount

Konto dla aplikacji działających w Kubernetes.

Przykład:

Application Pod

↓

ServiceAccount

↓

API Kubernetes

Przykład:

Aplikacja monitorująca może potrzebować prawa:

get nodes

get pods

ale nie:

delete deployments

4. Role i ClusterRole

Definiują uprawnienia.

Role vs ClusterRole

To jedna z najważniejszych różnic.

Role

Działa tylko w jednym Namespace.

Przykład:

Namespace:

production

Uprawnienia:

czytaj Pody

restartuj Deployment

ClusterRole

Działa globalnie w całym klastrze.

Przykład:

Wszystkie Namespace

+

zasoby klastra

Schemat:

ClusterRole

├── Namespace A
├── Namespace B
└── Namespace C

Role – przykład

Załóżmy, że developer ma mieć dostęp tylko do Podów.

Tworzymy:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role

metadata:
  name: pod-reader
  namespace: development

rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list
  - watch

Co oznacza?

Użytkownik może:

✅ pobierać informacje o Podach
✅ wyświetlać listę Podów
✅ obserwować zmiany

Nie może:

❌ usuwać Podów
❌ tworzyć Deploymentów
❌ zmieniać Secretów

RoleBinding – przypisanie uprawnień

Sama Role nic nie daje.

Musimy ją połączyć z użytkownikiem.

Robi to RoleBinding.

Przykład:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding

metadata:
  name: developer-pod-access
  namespace: development

subjects:
- kind: User
  name: marek

roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Efekt:

Marek

↓

Role pod-reader

↓

Dostęp do Podów

ClusterRoleBinding

Działa podobnie, ale dla całego klastra.

Przykład:

Security Team

↓

ClusterRole

↓

Audit access

↓

Cały Kubernetes Cluster

Przykład niebezpiecznej konfiguracji

Najczęstszy błąd:

kind: ClusterRoleBinding

roleRef:
  name: cluster-admin

Efekt:

User

↓

cluster-admin

↓

Pełna kontrola klastra

To odpowiednik:

root

na całym Kubernetes

Cluster-admin – dlaczego jest groźny?

Rola:

cluster-admin

pozwala na:

• tworzenie Namespace,
• usuwanie aplikacji,
• odczyt Secretów,
• zmianę RBAC,
• dostęp do wszystkich zasobów.

Przykład ataku:

Przejęcie konta developera

↓

Dostęp cluster-admin

↓

Eksport Secretów

↓

Przejęcie usług

Sprawdzanie uprawnień

Kubernetes posiada narzędzie:

kubectl auth can-i

Przykład:

Czy użytkownik może usuwać Pody?

kubectl auth can-i delete pods

Wynik:

yes

lub:

no

Sprawdzenie konkretnego użytkownika:

kubectl auth can-i get secrets \
--as=marek

Audyt istniejących uprawnień

Lista Role:

kubectl get roles -A

ClusterRole:

kubectl get clusterroles

Binding:

kubectl get rolebindings -A

oraz:

kubectl get clusterrolebindings

RBAC dla aplikacji

Bardzo częsty scenariusz:

Mamy aplikację:

Monitoring Agent

która potrzebuje:

czytać:

Nodes

Pods

Metrics

Tworzymy:

ServiceAccount

↓

Role

↓

RoleBinding

↓

Application Pod

Przykład:

apiVersion: v1
kind: ServiceAccount

metadata:
  name: monitoring-agent

Następnie:

kind: Role

rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list

RBAC i Secrets

Jedna z najważniejszych zasad:

Dostęp do Secretów powinien być mocno ograniczony.

Dlaczego?

Secret może zawierać:

• hasła,
• tokeny API,
• certyfikaty,
• klucze SSH.

Nie:

resources:
- "*"

i:

verbs:
- "*"

To praktycznie pełny dostęp.

RBAC + Namespace Isolation

Dobra architektura:

Production Namespace

├── Backend Team

├── Database Team

└── Security Team

Każdy zespół otrzymuje tylko swoje uprawnienia.

RBAC w DevSecOps

RBAC powinien być częścią procesu CI/CD.

Przykład:

Developer

↓

Git Commit

↓

Pipeline

↓

Validation

↓

Deployment

↓

RBAC Check

↓

Production

Pipeline nie powinien działać z:

cluster-admin

Najczęstsze błędy RBAC

❌ używanie cluster-admin dla wszystkich

❌ brak audytu RoleBindingów

❌ aplikacje z nadmiernymi uprawnieniami

❌ dostęp do wszystkich Secretów

❌ brak separacji Namespace

❌ używanie wildcard:

resources:
- "*"

verbs:
- "*"

Najlepsze praktyki RBAC

✅ stosuj zasadę Least Privilege

✅ używaj Namespace do izolacji zespołów

✅ unikaj cluster-admin

✅ twórz osobne ServiceAccount dla aplikacji

✅ regularnie audytuj RoleBinding

✅ ogranicz dostęp do Secretów

✅ używaj OIDC/LDAP dla użytkowników

✅ testuj uprawnienia przez kubectl auth can-i

Bezpieczna architektura dostępu Kubernetes

                 Identity Provider

                LDAP / AD / OIDC

                       |

                       ↓

                     User

                       |

                       ↓

                   RBAC Layer

                       |

        +--------------+--------------+

        |                             |

      Role                      ClusterRole

        |                             |

        ↓                             ↓

 Namespace Resources          Cluster Resources

        |

        ↓

       Pods

Podsumowanie

RBAC jest jednym z fundamentów bezpieczeństwa Kubernetes.

Sam Kubernetes zapewnia izolację kontenerów, ale bez odpowiedniej kontroli dostępu jeden błędnie skonfigurowany użytkownik lub ServiceAccount może zagrozić całemu klastrowi.

Profesjonalne środowisko Kubernetes powinno stosować:

• minimalne uprawnienia,
• separację zespołów,
• ograniczone ServiceAccount,
• kontrolę dostępu do Secretów,
• regularny audyt RBAC.

Najważniejsza zasada:

W Kubernetes nie pytamy „czy użytkownik ma dostęp?”, tylko „jaki najmniejszy dostęp jest mu naprawdę potrzebny?”.

Polecane wpisy

Komputer się przegrzewa

Komputer się przegrzewa - Przyczyny, Objawy i Rozwiązania Komputer się przegrzewa Komputer to nieodłączne narzędzie we Czytaj dalej

Pozycjonowanie a strona mobilna

Polityka Google od dłuższego czasu jest coraz bardziej nieprzyjazna stronom internetowym, które nie działają najlepiej w wersji mobilnej.Jeżeli jesteśmy właścicielami Czytaj dalej