Kubernetes’te yetkilendirme ve eri\u015fim kontrol\u00fc nas\u0131l sa\u011flan\u0131r? RBAC (Rol Tabanl\u0131 Eri\u015fim Kontrol\u00fc), kullan\u0131c\u0131lar\u0131n ve servis hesaplar\u0131n\u0131n k\u00fcme kaynaklar\u0131na eri\u015fimini g\u00fcvenli bir \u015fekilde y\u00f6netmek i\u00e7in merkezi bir y\u00f6ntem sunar. Bu makalede, Kubernetes RBAC’\u0131n temel ta\u015flar\u0131 olan Roller ve Rol Ba\u011flamalar\u0131 kavramlar\u0131n\u0131 detayl\u0131ca inceleyerek, k\u00fcme g\u00fcvenli\u011finizi nas\u0131l g\u00fc\u00e7lendirebilece\u011finizi \u00f6\u011freneceksiniz.<\/p>\n
Kubernetes, modern uygulama geli\u015ftirme ve da\u011f\u0131t\u0131m s\u00fcre\u00e7lerinin vazge\u00e7ilmez bir par\u00e7as\u0131 haline gelmi\u015f, konteyner tabanl\u0131 i\u015f y\u00fcklerini y\u00f6netmek i\u00e7in g\u00fc\u00e7l\u00fc bir platform sunar. Ancak bu g\u00fcc\u00fcn beraberinde getirdi\u011fi en \u00f6nemli sorumluluklardan biri de g\u00fcvenliktir. \u00d6zellikle \u00e7ok kullan\u0131c\u0131l\u0131 veya \u00e7ok tak\u0131ml\u0131 ortamlarda, kimin neye eri\u015febilece\u011fini, hangi i\u015flemleri ger\u00e7ekle\u015ftirebilece\u011fini kontrol etmek hayati \u00f6nem ta\u015f\u0131r. \u0130\u015fte tam da bu noktada RBAC (Role-Based Access Control – Rol Tabanl\u0131 Eri\u015fim Kontrol\u00fc) devreye girer. RBAC, Kubernetes k\u00fcmesindeki kullan\u0131c\u0131lara (ger\u00e7ek kullan\u0131c\u0131lar, servis hesaplar\u0131 veya gruplar) belirli kaynaklar \u00fczerinde belirli eylemleri ger\u00e7ekle\u015ftirme yetkisi tan\u0131mlaman\u0131n standart ve en g\u00fcvenli yoludur.<\/p>\n
Eri\u015fim kontrol\u00fc olmadan, herhangi bir kullan\u0131c\u0131n\u0131n veya uygulaman\u0131n k\u00fcmedeki t\u00fcm kaynaklara s\u0131n\u0131rs\u0131z eri\u015fimi olabilir ki bu, ciddi g\u00fcvenlik zafiyetlerine yol a\u00e7ar. \u00d6rne\u011fin, geli\u015ftirme ekibinden birinin yanl\u0131\u015fl\u0131kla \u00fcretim veritaban\u0131n\u0131 silmesi veya k\u00f6t\u00fc niyetli bir akt\u00f6r\u00fcn kritik k\u00fcme bile\u015fenlerine eri\u015fim sa\u011flamas\u0131 gibi senaryolar felaketle sonu\u00e7lanabilir. RBAC, bu t\u00fcr riskleri ortadan kald\u0131rmak i\u00e7in “en az ayr\u0131cal\u0131k prensibi”ni uygulaman\u0131za olanak tan\u0131r. Bu prensibe g\u00f6re, bir kullan\u0131c\u0131ya veya servise yaln\u0131zca g\u00f6revlerini yerine getirebilmeleri i\u00e7in kesinlikle gerekli olan minimum yetkiler verilmelidir. Bu yakla\u015f\u0131m, yetki y\u00fckseltme sald\u0131r\u0131lar\u0131n\u0131n ve istenmeyen eri\u015fimlerin \u00f6n\u00fcne ge\u00e7erek k\u00fcmenizin genel g\u00fcvenlik duru\u015funu \u00f6nemli \u00f6l\u00e7\u00fcde g\u00fc\u00e7lendirir.<\/p>\n
Ge\u00e7mi\u015fte Kubernetes’te ABAC (Attribute-Based Access Control) gibi yetkilendirme y\u00f6ntemleri de kullan\u0131lm\u0131\u015f olsa da, RBAC \u00e7ok daha esnek, okunabilir ve y\u00f6netilebilirdir. ABAC, politikalar\u0131n karma\u015f\u0131k ve \u00f6l\u00e7eklendirmesi zor olmas\u0131na neden olurken, RBAC’\u0131n declarative (bildirimsel) yap\u0131s\u0131 sayesinde politikalar\u0131 YAML dosyalar\u0131yla kolayca tan\u0131mlayabilir, versiyon kontrol sistemlerinde izleyebilir ve GitOps prensipleriyle otomatikle\u015ftirebilirsiniz. Bu sayede, g\u00fcvenlik politikalar\u0131n\u0131z kod gibi ele al\u0131n\u0131r ve s\u00fcrekli entegrasyon\/s\u00fcrekli da\u011f\u0131t\u0131m (CI\/CD) s\u00fcre\u00e7lerine dahil edilebilir. K\u0131sacas\u0131, RBAC sadece bir g\u00fcvenlik mekanizmas\u0131 de\u011fil, ayn\u0131 zamanda k\u00fcme y\u00f6netimi ve otomasyonunun da temel bir yap\u0131 ta\u015f\u0131d\u0131r.<\/p>\n
RBAC, \u00fc\u00e7 ana bile\u015fen etraf\u0131nda \u015fekillenir: Subject (Kim – kullan\u0131c\u0131, grup veya servis hesab\u0131), Verb (Ne Yapabilir – get, create, delete gibi eylemler) ve Resource (Ne \u00dczerinde – podlar, servisler, deploylar gibi k\u00fcme kaynaklar\u0131). Bu makalenin devam\u0131nda, bu bile\u015fenleri kullanarak nas\u0131l etkili RBAC politikalar\u0131 olu\u015fturaca\u011f\u0131n\u0131z\u0131, Roller ve Rol Ba\u011flamalar\u0131 ile k\u00fcmenizi nas\u0131l g\u00fcvence alt\u0131na alaca\u011f\u0131n\u0131z\u0131 ad\u0131m ad\u0131m ke\u015ffedece\u011fiz. Unutmay\u0131n, iyi yap\u0131land\u0131r\u0131lm\u0131\u015f bir RBAC, Kubernetes k\u00fcmenizin hem g\u00fcvenli\u011fini hem de operasyonel verimlili\u011fini art\u0131ran temel bir yat\u0131r\u0131md\u0131r.<\/p>\n
RBAC’\u0131n kalbinde “Roller” bulunur. Roller, belirli bir API grubundaki belirli kaynaklar \u00fczerinde hangi fiillerin (verbs) ger\u00e7ekle\u015ftirilebilece\u011fini tan\u0131mlayan bir dizi kural koleksiyonudur. Yani, bir rol, “kimin ne yapabilece\u011fini” de\u011fil, “ne t\u00fcr eylemlerin yap\u0131labilece\u011fini” belirler. Roller, yetkilendirme sisteminin temelini olu\u015fturur ve kullan\u0131c\u0131lar\u0131n veya servis hesaplar\u0131n\u0131n hangi ayr\u0131cal\u0131klara sahip olaca\u011f\u0131n\u0131 belirleyen soyut kurallar k\u00fcmesini temsil eder. Kubernetes’te iki ana Rol tipi vard\u0131r ve bunlar, yetki kapsamlar\u0131na g\u00f6re farkl\u0131l\u0131k g\u00f6sterir:<\/p>\n
Role<\/code> nesnesi, yetkileri yaln\u0131zca belirli bir Kubernetes namespace’i (ad alan\u0131) ile s\u0131n\u0131rlar. Bu, geli\u015ftirme, test veya \u00fcretim gibi farkl\u0131 ortamlar i\u00e7in ayr\u0131 ayr\u0131, izole yetkilendirme politikalar\u0131 olu\u015fturmak istedi\u011finizde olduk\u00e7a kullan\u0131\u015fl\u0131d\u0131r. \u00d6rne\u011fin, “dev” namespace’inde pod olu\u015fturma ve loglar\u0131n\u0131 okuma yetkisi veren bir Role<\/code> tan\u0131mlayabilirsiniz. Bu Role<\/code>, “prod” namespace’indeki kaynaklar \u00fczerinde herhangi bir etkiye sahip olmayacakt\u0131r.\n <\/li>\n- \n ClusterRole (Cluster Scope):<\/strong> Bir
ClusterRole<\/code> nesnesi ise yetkileri t\u00fcm Kubernetes k\u00fcmesi genelinde tan\u0131mlar. Bu t\u00fcr roller, namespace’e ba\u011fl\u0131 olmayan kaynaklar (\u00f6rne\u011fin, Node’lar, PersistentVolume’lar) \u00fczerinde yetki vermek veya k\u00fcme genelindeki t\u00fcm namespace’lerde ge\u00e7erli olacak yetkileri tan\u0131mlamak i\u00e7in kullan\u0131l\u0131r. \u00d6rne\u011fin, t\u00fcm namespace’lerde podlar\u0131 listeleyebilen veya k\u00fcme genelinde yeni namespace’ler olu\u015fturabilen bir ClusterRole<\/code> tan\u0131mlayabilirsiniz. ClusterRole<\/code>ler genellikle y\u00f6netici (admin) veya k\u00fcme g\u00f6zlemcisi (cluster-viewer) gibi geni\u015f kapsaml\u0131 roller i\u00e7in tercih edilir.\n <\/li>\n<\/ol>\nBir rol tan\u0131mlarken, rules<\/code> alan\u0131 alt\u0131nda apiGroups<\/code>, resources<\/code> ve verbs<\/code> belirtilir. apiGroups<\/code>, yetki verilen API grubunu belirtir (\u00f6rn. \"\"<\/code> core API grubunu, apps<\/code> Deployment’lar\u0131 vb. temsil eder). resources<\/code>, \u00fczerinde i\u015flem yap\u0131labilecek kaynaklar\u0131 (\u00f6rn. pods<\/code>, deployments<\/code>, services<\/code>), verbs<\/code> ise yap\u0131labilecek eylemleri (\u00f6rn. get<\/code>, list<\/code>, watch<\/code>, create<\/code>, update<\/code>, delete<\/code>, patch<\/code>) ifade eder. Bu \u00fc\u00e7l\u00fcy\u00fc do\u011fru bir \u015fekilde bir araya getirerek, \u00e7ok hassas yetkilendirme kurallar\u0131 olu\u015fturabilirsiniz. \u00d6rne\u011fin, “okuyucu” rol\u00fc sadece get<\/code>, list<\/code>, watch<\/code> fiillerini i\u00e7erebilirken, “y\u00f6netici” rol\u00fc t\u00fcm fiilleri (*<\/code>) i\u00e7erebilir.<\/p>\nA\u015fa\u011f\u0131daki \u00f6rnekte, dev<\/code> isimli namespace i\u00e7inde podlar\u0131 ve pod loglar\u0131n\u0131 okuma yetkisi veren bir Role<\/code> tan\u0131mlanm\u0131\u015ft\u0131r. Bu rol, bir geli\u015ftiricinin kendi uygulama podlar\u0131n\u0131n durumunu izlemesi veya loglar\u0131n\u0131 g\u00f6r\u00fcnt\u00fclemesi i\u00e7in yeterli olacakt\u0131r, ancak herhangi bir de\u011fi\u015fiklik yapmas\u0131na izin vermeyecektir.<\/p>\n\napiVersion: rbac.authorization.k8s.io\/v1\nkind: Role\nmetadata:\n namespace: dev # Bu rol sadece 'dev' namespace'inde ge\u00e7erlidir\n name: pod-okuyucu\nrules:\n- apiGroups: [\"\"] # \"\" core API grubu anlam\u0131na gelir\n resources: [\"pods\", \"pods\/log\"] # Pod kaynaklar\u0131 ve pod loglar\u0131na eri\u015fim\n verbs: [\"get\", \"list\", \"watch\"] # Okuma yetkileri: Getir, Listele, \u0130zle\n<\/pre>\n<\/code><\/p>\n
\n Uzman \u0130pucu: Roller olu\u015ftururken her zaman \"en az ayr\u0131cal\u0131k\" (least privilege) prensibini uygulay\u0131n. Kullan\u0131c\u0131lara veya servis hesaplar\u0131na yaln\u0131zca g\u00f6revlerini yerine getirmeleri i\u00e7in gereken minimum yetkileri verin. Geni\u015f kapsaml\u0131 ClusterRole<\/code>ler yerine, m\u00fcmk\u00fcn oldu\u011funca Role<\/code>leri ve belirli namespace'leri hedefleyen yetkileri tercih edin. Bu, g\u00fcvenlik a\u00e7\u0131\u011f\u0131 riskini minimize eder ve yetkisiz eri\u015fimlerin etkisini s\u0131n\u0131rlar.\n <\/div>\nClusterRole<\/code> tan\u0131m\u0131 da benzerdir, ancak metadata.namespace<\/code> alan\u0131 belirtilmez, \u00e7\u00fcnk\u00fc k\u00fcme genelinde ge\u00e7erlidir. \u00d6rne\u011fin, t\u00fcm namespace'lerde servisleri listeleyebilen bir ClusterRole<\/code> \u015f\u00f6yle tan\u0131mlanabilir:<\/p>\n\napiVersion: rbac.authorization.k8s.io\/v1\nkind: ClusterRole\nmetadata:\n name: servis-listeleyici\nrules:\n- apiGroups: [\"\"]\n resources: [\"services\"]\n verbs: [\"list\", \"watch\"]\n<\/pre>\n<\/code><\/p>\n
Bu yetkilendirme tan\u0131mlar\u0131, k\u00fcmenizin g\u00fcvenlik mimarisini olu\u015ftururken temel yap\u0131 ta\u015flar\u0131d\u0131r. Rolleri do\u011fru bir \u015fekilde tan\u0131mlamak, sonraki ad\u0131mda bu rolleri belirli \"kimliklere\" nas\u0131l atayaca\u011f\u0131m\u0131z\u0131 belirleyece\u011fimiz Rol Ba\u011flamalar\u0131 i\u00e7in sa\u011flam bir zemin haz\u0131rlar. Unutmay\u0131n, g\u00fc\u00e7l\u00fc bir g\u00fcvenlik, iyi d\u00fc\u015f\u00fcn\u00fclm\u00fc\u015f ve ince ayarlanm\u0131\u015f rol tan\u0131mlar\u0131yla ba\u015flar.<\/p>\n
Rol Ba\u011flamalar\u0131 ile Yetkileri Atamak: Kimlere Ne Kadar Yetki Veriyoruz?<\/h2>\n
Rolleri tan\u0131mlamak, yetkilendirme bulmacas\u0131n\u0131n yaln\u0131zca ilk par\u00e7as\u0131d\u0131r. Tan\u0131mlad\u0131\u011f\u0131m\u0131z bu yetki kurallar\u0131n\u0131 ger\u00e7ek kullan\u0131c\u0131lar, servis hesaplar\u0131 veya kullan\u0131c\u0131 gruplar\u0131na atamam\u0131z gerekir. \u0130\u015fte tam da bu noktada \"Rol Ba\u011flamalar\u0131\" (RoleBindings) devreye girer. Rol Ba\u011flamalar\u0131, bir Role'\u00fc veya ClusterRole'\u00fc belirli \"subject\"lere (konulara) ba\u011flayan Kubernetes kaynaklar\u0131d\u0131r. Bu sayede, \"kimin\" hangi Role'\u00fcn tan\u0131mlad\u0131\u011f\u0131 \"ne yapma yetkisine\" sahip oldu\u011funu belirlemi\u015f oluruz. T\u0131pk\u0131 Rollerde oldu\u011fu gibi, Rol Ba\u011flamalar\u0131 da kapsamlar\u0131na g\u00f6re ikiye ayr\u0131l\u0131r:<\/p>\n
\n- \n RoleBinding (Namespace Scope):<\/strong> Bir
RoleBinding<\/code> nesnesi, bir Role<\/code>'\u00fc (veya bir ClusterRole<\/code>'\u00fc) belirli bir namespace i\u00e7indeki subject'lere ba\u011flar. E\u011fer bir RoleBinding<\/code> bir ClusterRole<\/code>'e at\u0131fta bulunuyorsa, bu ClusterRole<\/code>'\u00fcn k\u00fcme genelindeki t\u00fcm yetkileri yaln\u0131zca RoleBinding<\/code>'in tan\u0131mland\u0131\u011f\u0131 namespace i\u00e7inde ge\u00e7erli olacakt\u0131r. Bu, ClusterRole<\/code>'leri daha gran\u00fcler bir \u015fekilde kullanma esnekli\u011fi sa\u011flar. \u00d6rne\u011fin, \"dev\" namespace'inde pod olu\u015fturma yetkisi veren bir Role<\/code>'\u00fc belirli bir geli\u015ftiriciye atamak i\u00e7in RoleBinding<\/code> kullan\u0131l\u0131r.\n <\/li>\n- \n ClusterRoleBinding (Cluster Scope):<\/strong> Bir
ClusterRoleBinding<\/code> nesnesi, bir ClusterRole<\/code>'\u00fc k\u00fcme genelindeki subject'lere ba\u011flar. Bu, ClusterRole<\/code>'\u00fcn tan\u0131mlad\u0131\u011f\u0131 yetkilerin t\u00fcm k\u00fcmede ve t\u00fcm namespace'lerde ge\u00e7erli olaca\u011f\u0131 anlam\u0131na gelir. ClusterRoleBinding<\/code> genellikle k\u00fcme y\u00f6neticilerine veya k\u00fcme \u00e7ap\u0131nda yetkilere ihtiya\u00e7 duyan servis hesaplar\u0131na geni\u015f eri\u015fim vermek i\u00e7in kullan\u0131l\u0131r. \u00d6rne\u011fin, t\u00fcm namespace'lerde podlar\u0131 listeleyebilen ClusterRole<\/code>'\u00fc bir izleme arac\u0131n\u0131n servis hesab\u0131na atamak i\u00e7in ClusterRoleBinding<\/code> kullan\u0131l\u0131r.\n <\/li>\n<\/ol>\nBir Rol Ba\u011flamas\u0131 tan\u0131mlarken, subjects<\/code> ve roleRef<\/code> olmak \u00fczere iki ana alan\u0131 belirtiriz. subjects<\/code> alan\u0131, yetkilendirilecek ki\u015fiyi veya varl\u0131\u011f\u0131 (kullan\u0131c\u0131, grup veya servis hesab\u0131) belirtir. Kubernetes'te bu subject t\u00fcrleri \u015funlard\u0131r:<\/p>\n\n- User:<\/strong> Harici bir kimlik do\u011frulama sistemi (\u00f6rn. OIDC, sertifika) taraf\u0131ndan do\u011frulanm\u0131\u015f ger\u00e7ek kullan\u0131c\u0131lar. Genellikle
name<\/code> alan\u0131nda kullan\u0131c\u0131n\u0131n ad\u0131 belirtilir.<\/li>\n- Group:<\/strong> Bir grup kimlik do\u011frulama sistemi taraf\u0131ndan do\u011frulanm\u0131\u015f kullan\u0131c\u0131 gruplar\u0131. Bir gruba yetki vermek, o gruptaki t\u00fcm kullan\u0131c\u0131lara otomatik olarak ayn\u0131 yetkileri sa\u011flar.<\/li>\n
- ServiceAccount:<\/strong> Kubernetes i\u00e7inde \u00e7al\u0131\u015fan uygulamalar\u0131n kendilerini kimlik do\u011frulamas\u0131 ve k\u00fcme API'si ile etkile\u015fim kurmas\u0131 i\u00e7in kullan\u0131lan \u00f6zel hesaplard\u0131r. Genellikle botlar, uygulamalar ve kontrol\u00f6rler taraf\u0131ndan kullan\u0131l\u0131rlar.<\/li>\n<\/ul>\n
roleRef<\/code> alan\u0131 ise ba\u011flanacak Role'\u00fcn veya ClusterRole'\u00fcn ad\u0131n\u0131 ve t\u00fcr\u00fcn\u00fc belirtir. Bu alan, Rol Ba\u011flamas\u0131n\u0131n hangi yetki k\u00fcmesine at\u0131fta bulundu\u011funu a\u00e7\u0131k\u00e7a g\u00f6sterir.<\/p>\nA\u015fa\u011f\u0131daki \u00f6rnek, daha \u00f6nce tan\u0131mlad\u0131\u011f\u0131m\u0131z pod-okuyucu<\/code> isimli Role'\u00fc alice<\/code> ad\u0131nda bir kullan\u0131c\u0131ya dev<\/code> namespace'inde atayan bir RoleBinding<\/code> YAML'\u0131 g\u00f6sterir:<\/p>\n\napiVersion: rbac.authorization.k8s.io\/v1\nkind: RoleBinding\nmetadata:\n name: pod-okuyucu-binding\n namespace: dev # Bu ba\u011flama sadece 'dev' namespace'inde ge\u00e7erlidir\nsubjects:\n- kind: User # Yetki verilecek subject'in t\u00fcr\u00fc: Kullan\u0131c\u0131\n name: alice # Kullan\u0131c\u0131n\u0131n ad\u0131\n apiGroup: rbac.authorization.k8s.io # RBAC API grubu\nroleRef:\n kind: Role # Ba\u011flanacak referans\u0131n t\u00fcr\u00fc: Role\n name: pod-okuyucu # Ba\u011flanacak Role'\u00fcn ad\u0131\n apiGroup: rbac.authorization.k8s.io # RBAC API grubu\n<\/pre>\n<\/code><\/p>\n
Benzer \u015fekilde, bir ClusterRoleBinding<\/code> \u00f6rne\u011fi:<\/p>\n\napiVersion: rbac.authorization.k8s.io\/v1\nkind: ClusterRoleBinding\nmetadata:\n name: cluster-admin-bob\nsubjects:\n- kind: User\n name: bob\n apiGroup: rbac.authorization.k8s.io\nroleRef:\n kind: ClusterRole\n name: cluster-admin # Kubernetes'in varsay\u0131lan, t\u00fcm yetkilere sahip ClusterRole'\u00fc\n apiGroup: rbac.authorization.k8s.io\n<\/pre>\n<\/code><\/p>\n
Bu ClusterRoleBinding<\/code>, bob<\/code> isimli kullan\u0131c\u0131ya Kubernetes k\u00fcmesinde tam y\u00f6netici yetkileri verir. G\u00f6r\u00fcld\u00fc\u011f\u00fc gibi, Rol Ba\u011flamalar\u0131 sayesinde, tan\u0131mlad\u0131\u011f\u0131m\u0131z yetki kurallar\u0131n\u0131 esnek ve mod\u00fcler bir \u015fekilde farkl\u0131 kimliklere atayabiliriz. Bu, k\u00fcmenizin g\u00fcvenli\u011fini sa\u011flaman\u0131n temel direklerinden biridir ve do\u011fru kullan\u0131m\u0131, yetkisiz eri\u015fim riskini \u00f6nemli \u00f6l\u00e7\u00fcde azalt\u0131r.<\/p>\nGer\u00e7ek D\u00fcnya Senaryosu: Geli\u015ftirici Ortam\u0131 \u0130\u00e7in Detayl\u0131 RBAC Uygulamas\u0131<\/h2>\n
Teorik bilgileri peki\u015ftirmek i\u00e7in \u015fimdi ger\u00e7ek bir senaryo \u00fczerinden ilerleyelim. Bir \u015firket d\u00fc\u015f\u00fcnelim; bu \u015firketin \"Frontend Tak\u0131m\u0131\" ad\u0131nda bir geli\u015ftirici ekibi var. Bu ekip, Kubernetes k\u00fcmesindeki frontend-dev<\/code> isimli namespace'te kendi mikroservislerini da\u011f\u0131tacak, y\u00f6netecek ve hata ay\u0131klamas\u0131 yapacak. Ancak, bu tak\u0131m\u0131n backend-prod<\/code> veya system<\/code> gibi di\u011fer kritik namespace'lere eri\u015fimi olmamal\u0131. Ayr\u0131ca, geli\u015ftiricilerin sadece kendi namespace'leri i\u00e7inde Deployment'lar olu\u015fturmas\u0131na, Pod'lar\u0131 ve Servisleri listelemesine izin verilmeli, ancak kritik k\u00fcme kaynaklar\u0131 \u00fczerinde herhangi bir de\u011fi\u015fiklik yapamamal\u0131lar. \u0130\u015fte bu k\u0131s\u0131tlamalar\u0131 RBAC ile nas\u0131l uygulayaca\u011f\u0131m\u0131z\u0131 ad\u0131m ad\u0131m g\u00f6relim:<\/p>\nAd\u0131m 1: Geli\u015ftirici Namespace'ini Olu\u015fturma<\/h3>\n
\u0130lk olarak, Frontend Tak\u0131m\u0131 i\u00e7in \u00f6zel bir namespace olu\u015ftural\u0131m. Bu, yetkilendirmeyi izole etmemizi sa\u011flar.<\/p>\n
\napiVersion: v1\nkind: Namespace\nmetadata:\n name: frontend-dev\n<\/pre>\n<\/code><\/p>\n
Bu YAML dosyas\u0131n\u0131 uygulayarak namespace'i olu\u015fturun: kubectl apply -f namespace.yaml<\/code><\/p>\nAd\u0131m 2: Geli\u015ftiricilerin \u0130htiyac\u0131 Olan Yetkileri Tan\u0131mlayan Bir Rol Olu\u015fturma<\/h3>\n
\u015eimdi, frontend-dev<\/code> namespace'inde ge\u00e7erli olacak, geli\u015ftiricilere Deployments<\/code>, Pods<\/code> ve Services<\/code> \u00fczerinde get<\/code>, list<\/code>, watch<\/code>, create<\/code>, update<\/code>, patch<\/code>, delete<\/code> yetkilerini veren bir Role<\/code> olu\u015ftural\u0131m. Pods\/log<\/code> i\u00e7in de okuma yetkisi ekleyelim.<\/p>\n\napiVersion: rbac.authorization.k8s.io\/v1\nkind: Role\nmetadata:\n namespace: frontend-dev # Bu rol sadece bu namespace'te ge\u00e7erlidir\n name: frontend-developer\nrules:\n- apiGroups: [\"apps\"] # Deployment'lar bu API grubundad\u0131r\n resources: [\"deployments\"]\n verbs: [\"get\", \"list\", \"watch\", \"create\", \"update\", \"patch\", \"delete\"]\n- apiGroups: [\"\"] # Core API grubu\n resources: [\"pods\", \"pods\/log\", \"services\"]\n verbs: [\"get\", \"list\", \"watch\", \"create\", \"update\", \"patch\", \"delete\"]\n<\/pre>\n<\/code><\/p>\n
Bu YAML dosyas\u0131n\u0131 uygulay\u0131n: kubectl apply -f frontend-developer-role.yaml<\/code><\/p>\nAd\u0131m 3: Geli\u015ftirici Grubu \u0130\u00e7in Rol Ba\u011flamas\u0131 Olu\u015fturma<\/h3>\n
\u015eirketimizin kimlik do\u011frulama sistemi, Frontend Tak\u0131m\u0131 \u00fcyelerini frontend-team<\/code> ad\u0131nda bir grup alt\u0131nda y\u00f6netiyor olsun. Bu gruba yukar\u0131da tan\u0131mlad\u0131\u011f\u0131m\u0131z frontend-developer<\/code> Rol'\u00fcn\u00fc atayan bir RoleBinding<\/code> olu\u015ftural\u0131m.<\/p>\n\napiVersion: rbac.authorization.k8s.io\/v1\nkind: RoleBinding\nmetadata:\n name: frontend-team-binding\n namespace: frontend-dev\nsubjects:\n- kind: Group # Bir kullan\u0131c\u0131 grubu\n name: frontend-team # Grubun ad\u0131\n apiGroup: rbac.authorization.k8s.io\nroleRef:\n kind: Role\n name: frontend-developer\n apiGroup: rbac.authorization.k8s.io\n<\/pre>\n<\/code><\/p>\n
Bu YAML dosyas\u0131n\u0131 uygulay\u0131n: kubectl apply -f frontend-team-rolebinding.yaml<\/code><\/p>\nYetkileri Do\u011frulama ve Test Etme<\/h3>\n
\u015eimdi, kubectl auth can-i<\/code> komutu ile bu politikalar\u0131n do\u011fru \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 test edebiliriz. Bu komut, belirli bir kullan\u0131c\u0131 veya grup i\u00e7in belirli bir eylemin m\u00fcmk\u00fcn olup olmad\u0131\u011f\u0131n\u0131 kontrol etmenizi sa\u011flar.<\/p>\n\nfrontend-team<\/code> grubundaki bir \u00fcyenin frontend-dev<\/code> namespace'inde pod olu\u015fturup olu\u015fturamayaca\u011f\u0131n\u0131 kontrol edelim:\n\nkubectl auth can-i create pods --namespace frontend-dev --as-group frontend-team\n# Sonu\u00e7: yes\n <\/pre>\n<\/code>\n <\/li>\n
- Ayn\u0131 grubun
backend-prod<\/code> namespace'inde deployment olu\u015fturup olu\u015fturamayaca\u011f\u0131n\u0131 kontrol edelim:\n\nkubectl auth can-i create deployments --namespace backend-prod --as-group frontend-team\n# Sonu\u00e7: no\n <\/pre>\n<\/code>\n <\/li>\n
- Bir y\u00f6neticinin (varsay\u0131lan olarak
system:masters<\/code> grubuna dahil olanlar) frontend-dev<\/code> namespace'inde her \u015feyi yap\u0131p yapamayaca\u011f\u0131n\u0131 kontrol edelim:\n\nkubectl auth can-i '*' '*' --namespace frontend-dev --as-group system:masters\n# Sonu\u00e7: yes\n <\/pre>\n<\/code>\n <\/li>\n<\/ul>\n
Bu senaryo, RBAC'\u0131n nas\u0131l kullan\u0131labilece\u011fini ve ekiplerin k\u00fcme kaynaklar\u0131na eri\u015fimini nas\u0131l g\u00fcvenli bir \u015fekilde y\u00f6netebilece\u011finizi g\u00f6stermektedir. Geli\u015ftiriciler art\u0131k kendi ortamlar\u0131nda ba\u011f\u0131ms\u0131z \u00e7al\u0131\u015fabilirken, di\u011fer kritik sistemlere veya \u00fcretim ortamlar\u0131na yanl\u0131\u015fl\u0131kla eri\u015fimlerinin \u00f6n\u00fcne ge\u00e7ilmi\u015f olur. Bu t\u00fcr detayl\u0131 planlama ve uygulama, Kubernetes k\u00fcmelerinizin g\u00fcvenli\u011fini sa\u011flamak i\u00e7in vazge\u00e7ilmezdir. Ger\u00e7ek d\u00fcnya senaryolar\u0131 genellikle daha karma\u015f\u0131k olsa da, bu temel ad\u0131mlar her zaman ba\u015flang\u0131\u00e7 noktas\u0131 olacakt\u0131r.<\/p>\n
\u0130leri D\u00fczey RBAC Y\u00f6netimi ve G\u00fcvenlik En \u0130yi Uygulamalar\u0131<\/h2>\n
Kubernetes RBAC'\u0131 do\u011fru bir \u015fekilde anlamak ve temel yap\u0131 ta\u015flar\u0131n\u0131 kullanmak \u00f6nemlidir, ancak k\u00fcmenizin g\u00fcvenli\u011fini ger\u00e7ekten peki\u015ftirmek i\u00e7in ileri d\u00fczey konular\u0131 ve en iyi uygulamalar\u0131 da g\u00f6z \u00f6n\u00fcnde bulundurmal\u0131s\u0131n\u0131z. Bu b\u00f6l\u00fcm, daha deneyimli kullan\u0131c\u0131lar i\u00e7in RBAC'\u0131 daha etkin ve g\u00fcvenli bir \u015fekilde y\u00f6netme konusunda ipu\u00e7lar\u0131 ve ek bilgiler sunacakt\u0131r.<\/p>\n
En Az Ayr\u0131cal\u0131k Prensibini Uygulamak<\/h3>\n
Daha \u00f6nce de bahsetti\u011fimiz gibi, bu prensip RBAC'\u0131n temelidir. Bir kullan\u0131c\u0131ya veya servis hesab\u0131na, g\u00f6revini yerine getirmesi i\u00e7in yaln\u0131zca kesinlikle gerekli olan minimum yetkiyi verin. \u00d6rne\u011fin, bir uygulama sadece podlar\u0131 listeleyecekse, ona pod olu\u015fturma veya silme yetkisi vermeyin. *<\/code> (t\u00fcm yetkiler) veya \"*\"<\/code> (t\u00fcm kaynaklar) kullanmaktan ka\u00e7\u0131n\u0131n. Bu, sald\u0131r\u0131 y\u00fczeyini daralt\u0131r ve olas\u0131 g\u00fcvenlik ihlallerinin etkisini s\u0131n\u0131rlar.<\/p>\nVarsay\u0131lan RBAC Rollerini Anlamak<\/h3>\n
Kubernetes, kurulum s\u0131ras\u0131nda bir dizi varsay\u0131lan ClusterRole<\/code> ve ClusterRoleBinding<\/code> ile birlikte gelir. Bunlar\u0131 bilmek, k\u00fcmenizin ba\u015flang\u0131\u00e7taki yetkilendirme durumunu anlaman\u0131za yard\u0131mc\u0131 olur:<\/p>\n\ncluster-admin<\/code>: S\u00fcper kullan\u0131c\u0131 yetkileri verir, t\u00fcm kaynaklar \u00fczerinde her \u015feyi yapabilir. Yaln\u0131zca g\u00fcvenilir y\u00f6neticilere atay\u0131n.<\/li>\nadmin<\/code>: Bir namespace i\u00e7inde neredeyse tam yetkilere sahiptir, ancak k\u00fcme genelindeki kaynaklara eri\u015femez.<\/li>\nedit<\/code>: Bir namespace i\u00e7inde \u00e7o\u011fu \u015feyi de\u011fi\u015ftirebilir (deployment'lar, servisler vb.), ancak rol ba\u011flamalar\u0131 veya kota gibi g\u00fcvenlik\/altyap\u0131 ayarlar\u0131n\u0131 de\u011fi\u015ftiremez.<\/li>\nview<\/code>: Bir namespace i\u00e7indeki kaynaklar\u0131 yaln\u0131zca okuyabilir (get, list, watch). Hi\u00e7bir de\u011fi\u015fiklik yapma yetkisi yoktur.<\/li>\n<\/ul>\nBu varsay\u0131lan rolleri do\u011frudan kullanmak yerine, ba\u015flang\u0131\u00e7 noktas\u0131 olarak al\u0131p kendi \u00f6zel rollerinizi olu\u015fturmak genellikle daha g\u00fcvenlidir, b\u00f6ylece tam olarak hangi yetkileri verdi\u011finizi bilirsiniz.<\/p>\n
ServiceAccount'lar ve RBAC \u0130li\u015fkisi<\/h3>\n
Kubernetes'te \u00e7al\u0131\u015fan uygulamalar, k\u00fcme API'si ile etkile\u015fim kurmak i\u00e7in ServiceAccount<\/code>'lar\u0131 kullan\u0131r. Her pod, varsay\u0131lan olarak bir default<\/code> ServiceAccount<\/code>'a ba\u011flan\u0131r, ancak kendi ServiceAccount<\/code>'\u0131n\u0131z\u0131 olu\u015fturup podunuza ataman\u0131z en iyi uygulamad\u0131r. Daha sonra, bu ServiceAccount<\/code>'a belirli Role<\/code>'ler veya ClusterRole<\/code>'ler ba\u011flayarak uygulaman\u0131z\u0131n ihtiya\u00e7 duydu\u011fu yetkileri verirsiniz. Bu, uygulamalar\u0131n\u0131z\u0131n sadece gerekli ayr\u0131cal\u0131klara sahip olmas\u0131n\u0131 sa\u011flar ve uygulamalar aras\u0131 yetki ka\u00e7aklar\u0131n\u0131 \u00f6nler.<\/p>\n\napiVersion: v1\nkind: ServiceAccount\nmetadata:\n namespace: my-app-ns\n name: my-app-service-account\n<\/pre>\n<\/code><\/p>\n
Ard\u0131ndan bu ServiceAccount<\/code>'a \u00f6zel bir RoleBinding<\/code> olu\u015fturulur.<\/p>\nRBAC Denetimi ve G\u00f6zetimi<\/h3>\n
RBAC politikalar\u0131n\u0131z\u0131n do\u011fru \u00e7al\u0131\u015ft\u0131\u011f\u0131ndan ve istenmeyen bir yetki verilmedi\u011finden emin olmak i\u00e7in d\u00fczenli denetimler yap\u0131n. kubectl auth can-i<\/code> komutu, anl\u0131k kontroller i\u00e7in m\u00fckemmeldir. Ayr\u0131ca, k\u00fcmenizin audit loglar\u0131n\u0131 (denetim kay\u0131tlar\u0131n\u0131) etkinle\u015ftirerek ve d\u00fczenli olarak inceleyerek, kimin hangi i\u015flemi ne zaman ger\u00e7ekle\u015ftirdi\u011fini izleyebilirsiniz. Bu, g\u00fcvenlik olaylar\u0131n\u0131 tespit etmek ve k\u00f6k neden analizini yapmak i\u00e7in kritik \u00f6neme sahiptir.<\/p>\n\n Uzman \u0130pucu: RBAC politikalar\u0131n\u0131z\u0131 ve ServiceAccount'lar\u0131n\u0131z\u0131 GitOps yakla\u015f\u0131mlar\u0131yla y\u00f6netin. T\u00fcm RBAC YAML dosyalar\u0131n\u0131z\u0131 bir Git deposunda saklay\u0131n ve de\u011fi\u015fiklikleri otomatik olarak k\u00fcmenize uygulay\u0131n. Bu, s\u00fcr\u00fcm kontrol\u00fc, denetlenebilirlik ve tekrarlanabilirlik sa\u011flar. Ayr\u0131ca, OPA (Open Policy Agent) Gatekeeper gibi ara\u00e7larla RBAC politikalar\u0131n\u0131z\u0131n \u00f6tesine ge\u00e7erek daha karma\u015f\u0131k g\u00fcvenlik kurallar\u0131 uygulayabilirsiniz.\n <\/div>\nYetki Y\u00fckseltme Sald\u0131r\u0131lar\u0131n\u0131 \u00d6nleme<\/h3>\n
RBAC politikalar\u0131n\u0131z\u0131 tasarlarken, yetki y\u00fckseltme sald\u0131r\u0131lar\u0131n\u0131 dikkate al\u0131n. \u00d6rne\u011fin, bir kullan\u0131c\u0131n\u0131n RoleBinding<\/code> olu\u015fturma yetkisi varsa, kendisine cluster-admin<\/code> ClusterRole<\/code>'\u00fcn\u00fc ba\u011flayarak k\u00fcmede tam yetki kazanabilir. Bu t\u00fcr sald\u0131r\u0131lar\u0131 \u00f6nlemek i\u00e7in, RoleBinding<\/code> veya ClusterRoleBinding<\/code> olu\u015fturma yetkisini yaln\u0131zca \u00e7ok g\u00fcvendi\u011finiz y\u00f6neticilere verin ve bu yetkinin kapsam\u0131n\u0131 s\u0131n\u0131rlay\u0131n. Kaynaklar\u0131 verbs: [\"*\"]<\/code> ile yetkilendirmek yerine, m\u00fcmk\u00fcn oldu\u011funca spesifik fiiller kullan\u0131n.<\/p>\nBu ileri d\u00fczey konular ve en iyi uygulamalar, Kubernetes RBAC y\u00f6netimini daha g\u00fc\u00e7l\u00fc, daha g\u00fcvenli ve daha y\u00f6netilebilir hale getirmenize yard\u0131mc\u0131 olacakt\u0131r. Unutmay\u0131n, g\u00fcvenlik dinamik bir s\u00fcre\u00e7tir ve RBAC politikalar\u0131n\u0131z\u0131n s\u00fcrekli olarak g\u00f6zden ge\u00e7irilmesi ve g\u00fcncellenmesi gerekir.<\/p>\n
S\u0131k\u00e7a Sorulan Sorular: Kubernetes RBAC Hakk\u0131nda Merak Edilenler<\/h2>\n
Kubernetes RBAC, k\u00fcme g\u00fcvenli\u011finin temelini olu\u015fturur ve do\u011fru anla\u015f\u0131ld\u0131\u011f\u0131nda \u00e7ok g\u00fc\u00e7l\u00fc bir ara\u00e7t\u0131r. Ancak bu karma\u015f\u0131k konu hakk\u0131nda s\u0131k\u00e7a sorulan baz\u0131 sorular olabilir. \u0130\u015fte onlardan birka\u00e7\u0131 ve cevaplar\u0131:<\/p>\n
\n- \n RBAC neden ABAC'tan daha iyidir?<\/strong><\/p>\n
RBAC (Rol Tabanl\u0131 Eri\u015fim Kontrol\u00fc), ABAC'a (Nitelik Tabanl\u0131 Eri\u015fim Kontrol\u00fc) g\u00f6re \u00f6nemli avantajlara sahiptir. ABAC, politikalar\u0131 karma\u015f\u0131k ve okunmas\u0131 zor JSON dosyalar\u0131 olarak tan\u0131mlarken, RBAC daha deklaratif ve insan taraf\u0131ndan okunabilir YAML tan\u0131mlamalar\u0131 kullan\u0131r. RBAC'\u0131n mod\u00fcler yap\u0131s\u0131 (Roller ve Rol Ba\u011flamalar\u0131), politikalar\u0131n daha kolay y\u00f6netilmesini, \u00f6l\u00e7eklendirilmesini ve denetlenmesini sa\u011flar. Ayr\u0131ca, ABAC'\u0131n aksine RBAC, Kubernetes API'si taraf\u0131ndan yerel olarak desteklenir ve k\u00fcme i\u00e7indeki kaynaklar\u0131 do\u011fal olarak entegre eder. Bu \u00f6zellikler, RBAC'\u0131 modern Kubernetes yetkilendirmesi i\u00e7in tercih edilen ve standart hale gelen y\u00f6ntem yapar, b\u00f6ylece geli\u015ftirme ve operasyonel s\u00fcre\u00e7lerde \u00e7ok daha esneklik ve g\u00fcvenlik sunar.<\/p>\n<\/li>\n
- \n ClusterRole kullan\u0131rken nelere dikkat etmeliyim?<\/strong><\/p>\n
ClusterRole'ler, k\u00fcme genelinde yetkiler tan\u0131mlad\u0131\u011f\u0131 i\u00e7in dikkatli kullan\u0131lmal\u0131d\u0131r. Bir ClusterRole, t\u00fcm namespace'lerde veya namespace'e ba\u011fl\u0131 olmayan kaynaklar \u00fczerinde (Node'lar, PersistentVolume'lar gibi) yetki verir. Bu nedenle, ClusterRole'leri olabildi\u011fince spesifik tutmal\u0131 ve yaln\u0131zca ger\u00e7ekten k\u00fcme genelinde yetkiye ihtiya\u00e7 duyan durumlarda kullanmal\u0131s\u0131n\u0131z. A\u015f\u0131r\u0131 geni\u015f yetkilere sahip ClusterRole'ler, g\u00fcvenlik risklerini art\u0131rabilir. Bir ClusterRole'\u00fc bir RoleBinding ile belirli bir namespace'e ba\u011flayarak, ClusterRole'\u00fcn yetkilerini daha dar bir kapsamda kullanabilirsiniz. Bu, esneklik sa\u011flarken, potansiyel riskleri azaltmaya yard\u0131mc\u0131 olur.<\/p>\n<\/li>\n
- \n Bir kullan\u0131c\u0131n\u0131n hangi yetkilere sahip oldu\u011funu nas\u0131l kontrol ederim?<\/strong><\/p>\n
Bir kullan\u0131c\u0131n\u0131n (veya servis hesab\u0131n\u0131n\/grubunun) belirli bir namespace'te veya k\u00fcme genelinde hangi yetkilere sahip oldu\u011funu kontrol etmek i\u00e7in kubectl auth can-i<\/code> komutunu kullanabilirsiniz. \u00d6rne\u011fin:<\/p>\n\nkubectl auth can-i create pods --namespace my-app-ns --as alice\nkubectl auth can-i delete nodes --as bob --as-group cluster-admins\n <\/pre>\n<\/code>
\n Bu komut, belirli bir eylemin (create pods<\/code>, delete nodes<\/code>) belirli bir kimlik (alice<\/code>, bob<\/code> ve cluster-admins<\/code> grubu) taraf\u0131ndan ger\u00e7ekle\u015ftirilip ger\u00e7ekle\u015ftirilemeyece\u011fini yes<\/code> veya no<\/code> olarak d\u00f6nd\u00fcr\u00fcr. Daha kapsaml\u0131 bir yetki listesi g\u00f6rmek i\u00e7in kubectl auth reconcile -f <\/code> veya \u00fc\u00e7\u00fcnc\u00fc taraf ara\u00e7lar\u0131 (\u00f6rne\u011fin rbac-manager<\/code>) kullanabilirsiniz.<\/p>\n<\/li>\n- \n Role ve RoleBinding silinirse ne olur?<\/strong><\/p>\n
Bir Role<\/code> silindi\u011finde, o Role'e at\u0131fta bulunan t\u00fcm RoleBinding<\/code>ler ve ClusterRoleBinding<\/code>ler ge\u00e7ersiz hale gelir. Yani, bu ba\u011flamalar arac\u0131l\u0131\u011f\u0131yla yetki alm\u0131\u015f subject'ler art\u0131k yetkilerini kaybeder. RoleBinding<\/code> veya ClusterRoleBinding<\/code> silinirse, ilgili subject'ler art\u0131k o Role'\u00fcn veya ClusterRole'\u00fcn tan\u0131mlad\u0131\u011f\u0131 yetkilere sahip olamazlar. Bu, yetkilendirme politikalar\u0131n\u0131z\u0131 g\u00fcncellerken veya geri al\u0131rken dikkatli olman\u0131z gerekti\u011fi anlam\u0131na gelir. Silme i\u015flemleri, kullan\u0131c\u0131n\u0131n eri\u015fimini an\u0131nda etkileyece\u011fi i\u00e7in dikkatli bir planlama gerektirir.<\/p>\n<\/li>\n- \n Servis hesaplar\u0131 neden \u00f6nemlidir?<\/strong><\/p>\n
Servis hesaplar\u0131 (ServiceAccounts), Kubernetes k\u00fcmesi i\u00e7inde \u00e7al\u0131\u015fan uygulamalar\u0131n kendilerini kimlik do\u011frulamas\u0131 ve Kubernetes API'si ile etkile\u015fim kurmas\u0131 i\u00e7in kullan\u0131lan \u00f6zel kimliklerdir. \u0130nsan kullan\u0131c\u0131lar\u0131 i\u00e7in kullan\u0131lan hesaplardan farkl\u0131d\u0131rlar. Uygulamalar\u0131n genellikle do\u011frudan k\u00fcme API'si ile etkile\u015fime girmesi gerekti\u011finden, her uygulaman\u0131n belirli ve s\u0131n\u0131rl\u0131 yetkilere sahip kendi ServiceAccount'\u0131na sahip olmas\u0131 \u00f6nemlidir. Bu, uygulamalar\u0131n sadece ihtiya\u00e7 duyduklar\u0131 kaynaklara eri\u015fmesini sa\u011flar ve g\u00fcvenlik ihlali durumunda yetkisiz eri\u015fimin kapsam\u0131n\u0131 s\u0131n\u0131rlar. Default ServiceAccount kullanmaktan ka\u00e7\u0131narak, her uygulama i\u00e7in \u00f6zel ServiceAccount'lar ve bunlara ba\u011fl\u0131 RoleBinding'ler olu\u015fturmak en iyi g\u00fcvenlik uygulamas\u0131d\u0131r.<\/p>\n<\/li>\n<\/ul>\n
<\/p>\n