Kubernetes Role-Based Access Control(RBAC)

Wesprzyj HackTricks

Kontrola dostępu oparta na rolach (RBAC)

Kubernetes posiada moduł autoryzacji o nazwie Kontrola dostępu oparta na rolach (RBAC), który pomaga ustawić uprawnienia do wykorzystania serwera API.

Model uprawnień RBAC składa się z trzech indywidualnych części:

  1. Rola/ClusterRole ­– Faktyczne uprawnienie. Zawiera zasady, które reprezentują zestaw uprawnień. Każda zasada zawiera zasoby i czasowniki. Czasownik to działanie, które zostanie zastosowane do zasobu.

  2. Podmiot (Użytkownik, Grupa lub ServiceAccount) – Obiekt, który otrzyma uprawnienia.

  3. RoleBinding/ClusterRoleBinding – Połączenie między Rolą/ClusterRole a podmiotem.

Różnica między „Rolami” a „ClusterRoles” polega tylko na tym, gdzie rola zostanie zastosowana – „Rola” udzieli dostępu tylko do jednego konkretnego namespace, podczas gdy „ClusterRole” może być używany we wszystkich namespace'ach w klastrze. Ponadto ClusterRoles mogą również udzielać dostępu do:

  • zasobów o zasięgu klastra (np. węzły).

  • punktów końcowych bez zasobów (np. /healthz).

  • zasobów z przestrzeni nazw (np. Pody), we wszystkich namespace'ach.

Od wersji Kubernetes 1.6, polityki RBACdomyślnie włączone. Aby jednak włączyć RBAC, można użyć czegoś w stylu:

kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options

Szablony

W szablonie Roli lub ClusterRole musisz wskazać nazwę roli, przestrzeń nazw (w rolach), a następnie apiGroups, zasoby i czasowniki roli:

  • apiGroups to tablica zawierająca różne przestrzenie nazw API, do których ma zastosowanie ta reguła. Na przykład definicja Pod używa apiVersion: v1. Może mieć wartości takie jak rbac.authorization.k8s.io lub [*].

  • zasoby to tablica definiująca do jakich zasobów ma zastosowanie ta reguła. Możesz znaleźć wszystkie zasoby za pomocą: kubectl api-resources --namespaced=true

  • czasowniki to tablica zawierająca dozwolone czasowniki. Czasownik w Kubernetes definiuje rodzaj działania, które trzeba zastosować do zasobu. Na przykład czasownik list jest używany wobec kolekcji, podczas gdy "get" jest używany wobec pojedynczego zasobu.

Czasowniki Reguł

(Te informacje zostały zaczerpnięte z dokumentacji)

Czasownik HTTPczasownik żądania

POST

create

GET, HEAD

get (dla poszczególnych zasobów), list (dla kolekcji, w tym pełnej zawartości obiektu), watch (do obserwowania pojedynczego zasobu lub kolekcji zasobów)

PUT

update

PATCH

patch

DELETE

delete (dla poszczególnych zasobów), deletecollection (dla kolekcji)

Kubernetes czasami sprawdza autoryzację dla dodatkowych uprawnień, używając specjalizowanych czasowników. Na przykład:

  • czasownik use na zasobach podsecuritypolicies w grupie API policy.

  • czasowniki bind i escalate na zasobach roles i clusterroles w grupie API rbac.authorization.k8s.io.

  • czasownik impersonate na zasobach users, groups i serviceaccounts w grupie API core, oraz userextras w grupie API authentication.k8s.io.

Możesz znaleźć wszystkie czasowniki obsługiwane przez każdy zasób wykonując kubectl api-resources --sort-by name -o wide

Przykłady

Rola
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: defaultGreen
name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]
ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
# "namespace" omitted since ClusterRoles are not namespaced
name: secret-reader
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "watch", "list"]

Na przykład można użyć ClusterRole, aby umożliwić określonemu użytkownikowi uruchamianie:

kubectl get pods --all-namespaces

RoleBinding i ClusterRoleBinding

Z dokumentacji: RoleBinding przyznaje uprawnienia zdefiniowane w roli użytkownikowi lub zestawowi użytkowników. Zawiera listę podmiotów (użytkowników, grup lub kont usług) oraz odwołanie do przyznanej roli. RoleBinding przyznaje uprawnienia w określonej przestrzeni nazw, podczas gdy ClusterRoleBinding przyznaje ten dostęp na poziomie klastra.

piVersion: rbac.authorization.k8s.io/v1
# This role binding allows "jane" to read pods in the "default" namespace.
# You need to already have a Role named "pod-reader" in that namespace.
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
# You can specify more than one "subject"
- kind: User
name: jane # "name" is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
# "roleRef" specifies the binding to a Role / ClusterRole
kind: Role #this must be Role or ClusterRole
name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
apiGroup: rbac.authorization.k8s.io
ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
metadata:
name: read-secrets-global
subjects:
- kind: Group
name: manager # Name is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io

Uprawnienia są dodawane więc jeśli masz clusterRole z "list" i "delete" secrets, możesz dodać go z Role z "get". Bądź więc świadomy i zawsze testuj swoje role i uprawnienia i określ, co jest DOZWOLONE, ponieważ domyślnie WSZYSTKO jest ZABRONIONE.

Wyliczanie RBAC

# Get current privileges
kubectl auth can-i --list
# use `--as=system:serviceaccount:<namespace>:<sa_name>` to impersonate a service account

# List Cluster Roles
kubectl get clusterroles
kubectl describe clusterroles

# List Cluster Roles Bindings
kubectl get clusterrolebindings
kubectl describe clusterrolebindings

# List Roles
kubectl get roles
kubectl describe roles

# List Roles Bindings
kubectl get rolebindings
kubectl describe rolebindings

Nadużywanie ról/ClusterRoles do eskalacji uprawnień

Abusing Roles/ClusterRoles in Kubernetes
Wesprzyj HackTricks

Last updated