Kubernetes Role Base Access and Cluster Role Binding

Kimlik Doğrulama ve Yetkilendirme

Merhabalar,

Bu yazımda Kubernetes Authentication(Kimlik Doğrulama) & Authorization (Yetki )nasıl tanımladığımızı öğreneceğiz.

RBAC: Kubernetes içerisinde yetkilendirme için çeşitli yöntemler bulunmaktadır. Role Based Access Control bunlardan biridir. Örneğin belirli bir service account için resource listeleme,silme,değiştime işlemi için yetki verip bu resource’ları yönetebiliriz.

RBAC için 3 önemli bileşeni vardır;

• Subject: Kullanıcılar, gruplar veya service accountları temsil eder.
• Resource: Üzerinde yetkilendirme yapılacak kubernetes api objelerini temsil eder. (Pods, services, configMap etc)
• Verbs: Yapılacak işlemi temsil eder.

Note: Role namespace bazında çalışır.

ClusterRole: ClusterRole belirli bir namespace için değil tüm kümedeki kaynaklara izin verir ve uygular. Yani tüm kubernetes altındaki tüm namespaceler için yetkilendirilmiş oluruz.

Note: ClusterRole ise cluster bazında çalışır. Tüm Cluster içinde yetkili olur.

Service Account: Podlar tarafından kullanılır ve ilgili podun yetkilerini belirler.

Kubernetes User oluşturma Sertifikaya ile yapılır. Sonrada bu oluşturulan sertifikaya yetki tanımlaması yapılır. İlk olarak OPENSSL ile bir sertifika oluşturalım.

İlk olarak bir tane key oluşturalım.

openssl genrsa -out denizturkmen.key 2048

Key ile birlikte bir tane Certificate Signing Request oluşturalım.

openssl req -new -key denizturkmen.key -out denizturkmen.csr -subj “/CN=denizturkmen/O=DevOpsTeam”

• req: request
• csr: certificate signing request
• CN: Kullanıcı adı
• O: Groups

Note: Oluşturduğuz “.key” ve “.crt” cat ile açıp bakabilirsiniz.

Oluşturduğumuz Certificate Signing Request’i kubernetes objes ile oluşturnmak için .crt dosyasının bulunduğu klasörde;

• CertificateSigningRequest Listelemek için,

kubectl get certificatesigningrequests.certificates.k8s.io

Görüldüğü gibi certificate şuan pendind’de bekliyor.

• CertificateSigningRequest Onaylama

kubectl certificate approve certificate_name

• Certificate detaylarına bakmak için,

kubectl get certificatesigningrequests.certificates.k8s.io denizturkmen -o yaml

Note: Certificate base64 türündedir. Bu Certificate decode etmeliyiz. Bunun için,

kubectl get certificatesigningrequests.certificates.k8s.io denizturkmen -o jsonpath={‘.status.certificate’} | base64 --decode

• Bu sertifikayı .crt olarak kaydediyoruz.

kubectl get certificatesigningrequests.certificates.k8s.io denizturkmen -o jsonpath={‘.status.certificate’} | base64 --decode >> crt_name.crt

Certificate oluşturduğumuza göre şimdi bunu kubectl ile context olarak eklemeye geldi. Bunun için,

kubectl config set-credentials kullanıcı_ismi --client-certificate=decode ettiğimiz .crt --client-key=kullanıcının oluşturduğumuz key

• Kubeconfig için Context oluşturma

kubectl config set-context context_name --cluster=cluster_ismi -- user=kullanıcı adı

• Context listeleme.

kubectl config get-contexts

• User listleme.

kubectl config get-users

• Context değiştirme.

kubectl config use-context context_name

• Podlari listeleme

kubectl get pods

Note: Görüldüğü gibi user, context oluşturldu. Fakat Kubernetes Userlar SIFIR yetki ile gelir. Bu yüzden pod listeleme yetkisi yoktur. Bunun için Authorization yapmamız gerekir.

İlk olarak ROLE objemize bakalım.

• apiGroups: “*” olursa tüm api geçerli olur. “ “ boş bırakılırsa sadece core api yani “v1” geçerli olur.
• resources: k8s objelerin hangileri üzerinde erişim olmasını istiyorsak
• verbs: Bu K8s objeleri üzerindeki hangi yetkilerin olacağı tanımlanır.

Oluşturduğumuz Role objesini rolebinding ile bağlarız.

• subjects: Oluşturulan user tanımlarız.
• roleRef: Hangi role bind edeceğimizi söylüyoruz.

ClusterRole ve ClusterRole Binding objelerine bakalım.

• Birebir role objesi ile tanımdır sadece kind türü değişir.

• Birebir rolebinding objesi ile tanımdır sadece kind türü değişir.

Note: Role namespace bazlı, ClusterRole ise tüm cluster geçerlidir. Ama ClusterRole, RoleBinding objesi ile bind edilirse bu seferde namespace bazlı yetki tanımlamış oluruz.

Son olarak da default namespace sadece pod ve secret objesini için yetki tanımlaması yapalım. Bunun için,

ilk olarak admin context geçiyoruz.

kubectl get sa
kubectl get roles.rbac.authorization.k8s.io
kubectl get rolebindings.rbac.authorization.k8s.io
kubectl get pods

Note: Service Account detaylarına bakalım. Bu arada oluşturmadığımız bir secret objesi yani secret kendisi otomatik oluşturur.

• En önemlisi ise bu oluşturduğumuz service account bir k8s pod objesinde geçerli olması için , serviceAccountName: sa_name vermemiz gerekir. Eğer bu verilmezse kendisi default service account’u görür.

Son olarak bu secret objesindeki token ile dashboard’umuza bağlanalım.

kubectl describe secrets deniz-token-5kkwl

Buradaki token’ı alıp k8s dahboard token’a yapıştırıp login oluyoruz.

Yukarıda görüldüğü gibi sadece default namespace pod objesini listeleme yetkimiz tanımlanmış oldu.

Test etmek için CLI’dan;

kubectl get ns

Görüldüğü gibi admin context’imizde bir den fazla namespace alanı vardır. Fakat bizim RBAC ile yetki verdiğimiz user sadece default namespace’sindeki podları görme yetkisi tanımlanmıştır. k8s dashboard’undan da namespace sekmesine geçersek,

Görüldüğü gibi listelenmemektedir.

Bu yazımızın da sonuna gelmiş bulunmaktayız. Araştırmalarım ve sektörde karşılaştığım senaryolar üzerine yazılarımı yazmaya devam edeceğim. Umarım faydalı bir yazı olmuştur. Yazımı okuduğunuz için teşekkürler.

Deniz Türkmen

Deniz Türkmen — Turkey | Professional Profile | LinkedIn

denizturkmen — Overview

Referanslar;

Using RBAC Authorization