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 sakubectl get roles.rbac.authorization.k8s.iokubectl get rolebindings.rbac.authorization.k8s.iokubectl 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.

--

--

Medium independent DevOps publication. Join thousands of aspiring developers and DevOps enthusiasts

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store