Kubernetes Role-Based Access Control(RBAC)

AWS hackleme konusunda sıfırdan kahramana dönüşün htARTE (HackTricks AWS Kırmızı Takım Uzmanı)ile öğrenin!

HackTricks'i desteklemenin diğer yolları:

Rol Tabanlı Erişim Kontrolü (RBAC)

Kubernetes, API sunucusuna kullanım izinleri belirlemeye yardımcı olan bir yetkilendirme modülü olan Rol Tabanlı Erişim Kontrolü (RBAC) içerir.

RBAC'nin izin modeli üç ayrı parçadan oluşur:

  1. Rol/Küme Rolü - Gerçek izinleri içerir. Bir dizi izni temsil eden kurallar içerir. Her kural, kaynakları ve fiilleri içerir. Fiil, kaynak üzerinde uygulanacak eylemdir.

  2. Özne (Kullanıcı, Grup veya Hizmet Hesabı) - İzinleri alacak nesne.

  3. RolBağlama/KümeRolüBağlama - Rol/Küme Rolü ile özne arasındaki bağlantı.

"Roller" ve "Küme Roller" arasındaki fark, rolün uygulanacağı yerdir - "Rol", yalnızca bir belirli ad alanına erişim sağlarken, "Küme Rolü" kümedeki tüm ad alanlarında kullanılabilir. Dahası, Küme Roller ayrıca şunlara da erişim sağlayabilir:

  • Küme kapsamlı kaynaklar (örneğin düğümler).

  • Kaynak olmayan uç noktalar (örneğin /healthz).

  • Ad alanına ait kaynaklar (örneğin Pod'lar), tüm ad alanlarına yayılan.

Kubernetes 1.6'dan itibaren, RBAC politikaları varsayılan olarak etkinleştirilmiştir. Ancak RBAC'yi etkinleştirmek için şuna benzer bir şey kullanabilirsiniz:

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

Şablonlar

Bir Rol veya ClusterRole şablonunda, rolün adını, namespace'i (roller için) ve ardından rolün apiGroups, resources ve verbs'lerini belirtmeniz gerekecektir:

  • apiGroups, bu kuralın uygulandığı farklı API namespace'lerini içeren bir dizi olarak tanımlanır. Örneğin, bir Pod tanımı apiVersion: v1 kullanır. Değerler arasında rbac.authorization.k8s.io veya [*] olabilir.

  • resources, bu kuralın uygulandığı hangi kaynaklara uygulandığını tanımlayan bir dizi olarak belirtilir. Tüm kaynakları şu komutla bulabilirsiniz: kubectl api-resources --namespaced=true

  • verbs, izin verilen fiilleri içeren bir dizi olarak tanımlanır. Kubernetes'te fiil, kaynağa uygulamanız gereken eylemin türünü tanımlar. Örneğin, list fiili koleksiyonlara karşı kullanılırken "get" tek bir kaynağa karşı kullanılır.

Kuralların Fiilleri

(Bu bilgi dokümantasyondan alınmıştır)

Kubernetes bazen özel fiiller kullanarak ek izinler için yetkilendirme kontrolü yapar. Örneğin:

  • policy API grubundaki podsecuritypolicies kaynakları üzerinde use fiili.

  • rbac.authorization.k8s.io API grubundaki roles ve clusterroles kaynakları üzerinde bind ve escalate fiilleri.

  • Çekirdek API grubundaki users, groups ve serviceaccounts üzerinde impersonate fiili ve authentication.k8s.io API grubundaki userextras üzerinde.

Her kaynağın desteklediği tüm fiilleri kubectl api-resources --sort-by name -o wide komutunu kullanarak bulabilirsiniz.

Örnekler

Rol
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"]

Örneğin, belirli bir kullanıcının şunları çalıştırmasına izin vermek için bir ClusterRole kullanabilirsiniz:

kubectl get pods --all-namespaces

RoleBinding ve ClusterRoleBinding

Dokümantasyondan: Bir role binding, bir kullanıcıya veya kullanıcı grubuna tanımlanan bir role'deki izinleri sağlar. Bu, bir dizi subject (kullanıcılar, gruplar veya servis hesapları) ve verilen role referansı içerir. RoleBinding, belirli bir namespace içinde izinleri sağlarken, ClusterRoleBinding bu erişimi küme genelinde sağlar.

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

İzinler eklenir bu yüzden "list" ve "delete" sırları olan bir clusterRole'u "get" ile bir Role ile ekleyebilirsiniz. Bu yüzden her zaman rollerinizi ve izinlerinizi test edin ve NEYE İZİN VERİLDİĞİNİ belirtin, çünkü varsayılan olarak HER ŞEY REDDEDİLİR.

RBAC Numaralandırma

# 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

Yetkilendirme Rolü/Küme Rollerini İstismar Etme

htARTE (HackTricks AWS Red Team Expert) ile sıfırdan kahraman olmak için AWS hackleme öğrenin!

HackTricks'i desteklemenin diğer yolları:

Last updated