{"id":30454,"date":"2025-09-28T02:01:32","date_gmt":"2025-09-27T23:01:32","guid":{"rendered":"https:\/\/fatihsoysal.com\/blog\/kuberneteste-cok-kiracili-ortam-ve-guvenlik-temelleri\/"},"modified":"2025-09-28T02:01:32","modified_gmt":"2025-09-27T23:01:32","slug":"kuberneteste-cok-kiracili-ortam-ve-guvenlik-temelleri","status":"publish","type":"post","link":"https:\/\/fatihsoysal.com\/blog\/kuberneteste-cok-kiracili-ortam-ve-guvenlik-temelleri\/","title":{"rendered":"Kubernetes’te \u00c7ok Kirac\u0131l\u0131 Ortam ve G\u00fcvenlik Temelleri"},"content":{"rendered":"

<\/p>\n

Modern bulut tabanl\u0131 uygulamalar\u0131n h\u0131zla yayg\u0131nla\u015fmas\u0131yla birlikte, \u015firketler genellikle ayn\u0131 Kubernetes k\u00fcmesi \u00fczerinde farkl\u0131 ekiplerin veya uygulamalar\u0131n bir arada bar\u0131nd\u0131r\u0131lmas\u0131 ihtiyac\u0131yla kar\u015f\u0131la\u015f\u0131yor. Peki, bu karma\u015f\u0131k yap\u0131y\u0131 y\u00f6netirken kaynaklar\u0131 nas\u0131l adil da\u011f\u0131tabilir, ekipler aras\u0131 izolasyonu nas\u0131l sa\u011flayabilir ve g\u00fcvenlik risklerini en aza indirebiliriz? Bu makalede, Kubernetes’in sundu\u011fu g\u00fc\u00e7l\u00fc ara\u00e7lar olan Namespaces, Resource Quotas, NetworkPolicies ve Pod Security Admission mekanizmalar\u0131n\u0131 kullanarak \u00e7ok kirac\u0131l\u0131 (multi-tenancy) bir ortamda sa\u011flam bir g\u00fcvenlik temeli olu\u015fturman\u0131n inceliklerini ad\u0131m ad\u0131m ke\u015ffedece\u011fiz. Amac\u0131m\u0131z, hem yeni ba\u015flayanlar\u0131n konuyu temelden anlamas\u0131n\u0131 sa\u011flamak hem de deneyimli kullan\u0131c\u0131lar i\u00e7in pratik ipu\u00e7lar\u0131 sunmakt\u0131r.<\/p>\n

\u00c7ok kirac\u0131l\u0131 ortam (multi-tenancy), tek bir altyap\u0131 k\u00fcmesi \u00fczerinde birden fazla m\u00fc\u015fteri, ekip veya uygulama \u00f6rne\u011finin ayn\u0131 anda bar\u0131nd\u0131r\u0131lmas\u0131 anlam\u0131na gelir. Kubernetes ba\u011flam\u0131nda, bu durum genellikle farkl\u0131 departmanlar\u0131n (\u00f6rne\u011fin, geli\u015ftirme, test, \u00fcretim), farkl\u0131 projelerin veya hatta farkl\u0131 d\u0131\u015f m\u00fc\u015fterilerin ayn\u0131 Kubernetes k\u00fcmesini payla\u015fmas\u0131 \u015feklinde kar\u015f\u0131m\u0131za \u00e7\u0131kar. Bu yakla\u015f\u0131m\u0131n temel amac\u0131, donan\u0131m kaynaklar\u0131n\u0131n daha verimli kullan\u0131lmas\u0131, operasyonel maliyetlerin d\u00fc\u015f\u00fcr\u00fclmesi ve y\u00f6netim y\u00fck\u00fcn\u00fcn azalt\u0131lmas\u0131d\u0131r. Ancak bu avantajlarla birlikte, ciddi g\u00fcvenlik ve kaynak y\u00f6netimi zorluklar\u0131n\u0131 da beraberinde getirir. Bir kirac\u0131n\u0131n (tenant) kaynaklar\u0131 a\u015f\u0131r\u0131 t\u00fcketmesi di\u011fer kirac\u0131lar\u0131n performans\u0131n\u0131 etkileyebilirken, g\u00fcvenlik ihlalleri bir kirac\u0131dan di\u011ferine s\u0131\u00e7rayarak domino etkisi yaratabilir. Bu nedenle, \u00e7ok kirac\u0131l\u0131 bir ortamda g\u00fc\u00e7l\u00fc bir izolasyon ve g\u00fcvenlik stratejisi hayati \u00f6nem ta\u015f\u0131r.<\/p>\n

G\u00fcvenlik perspektifinden bak\u0131ld\u0131\u011f\u0131nda, \u00e7ok kirac\u0131l\u0131 yap\u0131lar kendi i\u00e7inde bir risk bar\u0131nd\u0131r\u0131r. Kirac\u0131lar aras\u0131 veri s\u0131z\u0131nt\u0131s\u0131, yetkisiz eri\u015fim veya kaynak t\u00fcketimindeki dengesizlikler, i\u015f s\u00fcreklili\u011fini ve veri gizlili\u011fini tehlikeye atabilir. \u00d6zellikle birden fazla ekibin ayn\u0131 k\u00fcmede \u00e7al\u0131\u015ft\u0131\u011f\u0131 b\u00fcy\u00fck kurulu\u015flarda, her ekibin kendi izolasyonuna ve g\u00fcvenlik politikalar\u0131na sahip olmas\u0131 kritik \u00f6neme sahiptir. Bu, sadece kaynak tahsisiyle s\u0131n\u0131rl\u0131 kalmay\u0131p, a\u011f eri\u015fim kontrollerinden pod’lar\u0131n \u00e7al\u0131\u015fma zaman\u0131 g\u00fcvenlik ayarlar\u0131na kadar geni\u015f bir yelpazeyi kapsar. \u00d6rne\u011fin, bir geli\u015ftirme ekibinin test ama\u00e7l\u0131 olu\u015fturdu\u011fu zay\u0131f bir yap\u0131land\u0131rma, bir \u00fcretim ortam\u0131na s\u0131zarak ciddi sonu\u00e7lar do\u011furabilir. \u0130\u015fte tam da bu noktada, Kubernetes’in sundu\u011fu yerle\u015fik g\u00fcvenlik ve izolasyon mekanizmalar\u0131 devreye girer. Bu mekanizmalar sayesinde, her kirac\u0131 kendi “sandbox” i\u00e7inde \u00e7al\u0131\u015f\u0131r ve di\u011fer kirac\u0131lar \u00fczerinde istenmeyen bir etki yaratmas\u0131 engellenir. Kaynaklar\u0131n adil da\u011f\u0131t\u0131lmas\u0131 ve g\u00fcvenlik duvarlar\u0131n\u0131n do\u011fru bir \u015fekilde in\u015fa edilmesi, \u00e7ok kirac\u0131l\u0131 bir Kubernetes k\u00fcmesinin omurgas\u0131n\u0131 olu\u015fturur. Bu makalenin ilerleyen b\u00f6l\u00fcmlerinde, bu mekanizmalar\u0131n her birini derinlemesine inceleyecek ve pratik \u00f6rneklerle nas\u0131l uyguland\u0131klar\u0131n\u0131 g\u00f6sterece\u011fiz. B\u00f6ylece, kurulu\u015flar g\u00fcvenli ve verimli \u00e7ok kirac\u0131l\u0131 Kubernetes ortamlar\u0131 olu\u015fturabilirler.<\/p>\n

\n Uzman \u0130pucu: \u00c7ok kirac\u0131l\u0131 ortamlarda, her kirac\u0131ya \u00f6zel izleme ve loglama (monitoring & logging) \u00e7\u00f6z\u00fcmleri sa\u011flamak, sorun giderme ve g\u00fcvenlik denetimleri i\u00e7in kritik \u00f6neme sahiptir. Bu, performans d\u00fc\u015f\u00fc\u015flerinin veya g\u00fcvenlik ihlallerinin kayna\u011f\u0131n\u0131 h\u0131zl\u0131ca tespit etmenize yard\u0131mc\u0131 olur.\n <\/div>\n

Kubernetes Namespace’leri ile Mant\u0131ksal \u0130zolasyon Nas\u0131l Sa\u011flan\u0131r?<\/h2>\n

Kubernetes’te \u00e7ok kirac\u0131l\u0131 bir ortam olu\u015fturman\u0131n ilk ve en temel ad\u0131m\u0131, Namespaces (isim uzaylar\u0131) kullanmakt\u0131r. Namespaces, Kubernetes k\u00fcmesi i\u00e7indeki kaynaklar\u0131 (Pod’lar, Servisler, Deployments, vb.) mant\u0131ksal olarak b\u00f6l\u00fcmlere ay\u0131rmak i\u00e7in kullan\u0131lan bir mekanizmad\u0131r. Her Namespace, kendi i\u00e7inde ba\u011f\u0131ms\u0131z bir sanal k\u00fcme gibi hareket eder. Bu sayede, farkl\u0131 ekipler veya uygulamalar, kendi Namespace’leri i\u00e7inde \u00e7al\u0131\u015farak birbirlerinin kaynaklar\u0131n\u0131 do\u011frudan etkilemez ve isim \u00e7ak\u0131\u015fmalar\u0131n\u0131n \u00f6n\u00fcne ge\u00e7ilir. \u00d6rne\u011fin, bir “dev” Namespace’i ile bir “prod” Namespace’i olu\u015fturabilir ve bu iki ortam\u0131 birbirinden tamamen ay\u0131rabilirsiniz. Bu ayr\u0131m, hem y\u00f6netim kolayl\u0131\u011f\u0131 hem de g\u00fcvenlik a\u00e7\u0131s\u0131ndan b\u00fcy\u00fck avantajlar sunar.<\/p>\n

Namespaces, kaynaklar\u0131n kimlik do\u011frulamas\u0131 (authentication) ve yetkilendirme (authorization) s\u00fcre\u00e7lerinde de merkezi bir rol oynar. Role-Based Access Control (RBAC) kurallar\u0131 genellikle Namespace baz\u0131nda uygulan\u0131r. Bu, belirli bir kullan\u0131c\u0131n\u0131n veya hizmet hesab\u0131n\u0131n yaln\u0131zca belirli bir Namespace i\u00e7indeki kaynaklara eri\u015febilmesini veya bunlar\u0131 y\u00f6netebilmesini sa\u011flar. B\u00f6ylece, geli\u015ftirme ekibinin sadece kendi “dev” Namespace’indeki kaynaklar\u0131 de\u011fi\u015ftirmesine izin verirken, \u00fcretim Namespace’ine eri\u015fimini k\u0131s\u0131tlayabilirsiniz. Bu katmanl\u0131 g\u00fcvenlik yakla\u015f\u0131m\u0131, yetkisiz eri\u015fim riskini \u00f6nemli \u00f6l\u00e7\u00fcde azalt\u0131r. \u00d6rne\u011fin, bir geli\u015ftiricinin yanl\u0131\u015fl\u0131kla \u00fcretim ortam\u0131ndaki bir veritaban\u0131n\u0131 silmesini engellemek i\u00e7in, ona sadece kendi geli\u015ftirme ortam\u0131 Namespace’inde yetki tan\u0131mlars\u0131n\u0131z.<\/p>\n

Bir Namespace olu\u015fturmak olduk\u00e7a basittir. A\u015fa\u011f\u0131daki YAML tan\u0131m\u0131 ile “gelistirme” ad\u0131nda yeni bir Namespace olu\u015fturabiliriz:<\/p>\n

\napiVersion: v1\nkind: Namespace\nmetadata:\n  name: gelistirme\n    <\/pre>\n
<\/code><\/p>\n
Bu tan\u0131m\u0131 kaydettikten sonra, kubectl apply -f gelistirme-namespace.yaml<\/code> komutu ile uygulayabiliriz. Namespaces'leri listelemek i\u00e7in ise kubectl get namespaces<\/code> komutunu kullan\u0131r\u0131z. Mevcut Namespaces'leri kontrol etmek, yeni bir ortam kurarken at\u0131lmas\u0131 gereken ilk ad\u0131md\u0131r. Bir Namespace i\u00e7indeki Pod'lar\u0131 veya di\u011fer kaynaklar\u0131 y\u00f6netmek i\u00e7in kubectl -n gelistirme get pods<\/code> gibi komutlar kullan\u0131r\u0131z. Buradaki -n<\/code> parametresi, hangi Namespace \u00fczerinde i\u015flem yapaca\u011f\u0131m\u0131z\u0131 belirtir. Bu temel izolasyon katman\u0131, \u00e7ok kirac\u0131l\u0131 bir Kubernetes k\u00fcmesinde d\u00fczeni sa\u011flaman\u0131n anahtar\u0131d\u0131r. Ancak yaln\u0131zca Namespaces ile tam bir izolasyon ve kaynak kontrol\u00fc sa\u011flanamaz. Bu nedenle, sonraki ad\u0131mlarda di\u011fer g\u00fcvenlik mekanizmalar\u0131n\u0131 da devreye alaca\u011f\u0131z.<\/p>\n
Kaynak Kotas\u0131 (Resource Quotas) ile Kaynak Y\u00f6netimi Nas\u0131l Yap\u0131l\u0131r?<\/h3>\n
Namespaces ile mant\u0131ksal izolasyonu sa\u011flad\u0131ktan sonra, bir sonraki \u00f6nemli ad\u0131m kaynaklar\u0131n adil ve kontroll\u00fc bir \u015fekilde da\u011f\u0131t\u0131lmas\u0131n\u0131 sa\u011flamakt\u0131r. \u0130\u015fte burada Kaynak Kotalar\u0131 (Resource Quotas) devreye girer. Resource Quotas, bir Namespace i\u00e7indeki toplam kaynak t\u00fcketimine (CPU, bellek, depolama alan\u0131) s\u0131n\u0131rlar koyman\u0131za olanak tan\u0131r. Ayr\u0131ca, o Namespace i\u00e7inde olu\u015fturulabilecek Pod'lar, Servisler veya Persistent Volume Claims (PVC'ler) gibi nesnelerin say\u0131s\u0131n\u0131 da s\u0131n\u0131rlayabilirsiniz. Bu, bir kirac\u0131n\u0131n veya uygulaman\u0131n k\u00fcmenin tamam\u0131n\u0131 ele ge\u00e7irmesini (resource starvation) engeller ve di\u011fer kirac\u0131lar i\u00e7in performans garanti alt\u0131na al\u0131nmas\u0131na yard\u0131mc\u0131 olur. \u00d6rne\u011fin, bir geli\u015ftirme ekibinin testleri s\u0131ras\u0131nda a\u015f\u0131r\u0131 CPU veya bellek t\u00fcketmesi, \u00fcretim ortam\u0131ndaki kritik uygulamalar\u0131 etkilememelidir. Resource Quotas tam da bu senaryolarda kurtar\u0131c\u0131 bir rol oynar.<\/p>\n
Resource Quotas ile iki ana kategoride s\u0131n\u0131rlama yapabiliriz:<\/p>\n
    \n
  1. Compute Resources (Hesaplama Kaynaklar\u0131):<\/strong> CPU ve bellek (memory) limitleri belirleyebilirsiniz. Bu limitler, her bir Pod'un isteyece\u011fi (requests) ve maksimum kullanabilece\u011fi (limits) miktarlar\u0131 etkiler. Bu sayede, bir Namespace'e toplamda ne kadar CPU ve bellek tahsis edildi\u011fini kontrol edersiniz.<\/li>\n
  2. Object Count (Nesne Say\u0131s\u0131):<\/strong> Bir Namespace i\u00e7inde olu\u015fturulabilecek belirli tipteki Kubernetes nesnelerinin (Pod'lar, ConfigMap'ler, Servisler, PVC'ler, vb.) say\u0131s\u0131n\u0131 s\u0131n\u0131rlayabilirsiniz. Bu, \u00f6zellikle kontrols\u00fcz kaynak yarat\u0131m\u0131n\u0131 engellemek i\u00e7in kullan\u0131\u015fl\u0131d\u0131r.<\/li>\n<\/ol>\n
    A\u015fa\u011f\u0131da, \"gelistirme\" Namespace'i i\u00e7in bir Resource Quota tan\u0131m\u0131 \u00f6rne\u011fi bulunmaktad\u0131r. Bu kota, bu Namespace i\u00e7indeki t\u00fcm Pod'lar\u0131n toplamda 2 CPU \u00e7ekirde\u011fini ve 4 GB belle\u011fi ge\u00e7emeyece\u011fini, ayr\u0131ca en fazla 10 Pod ve 5 PVC olu\u015fturulabilece\u011fini belirtir:<\/p>\n
    \napiVersion: v1\nkind: ResourceQuota\nmetadata:\n  name: gelistirme-kaynak-kotasi\n  namespace: gelistirme\nspec:\n  hard:\n    requests.cpu: \"2\"\n    requests.memory: \"4Gi\"\n    limits.cpu: \"4\"\n    limits.memory: \"8Gi\"\n    pods: \"10\"\n    persistentvolumeclaims: \"5\"\n    <\/pre>\n
    <\/code><\/p>\n
    Bu YAML dosyas\u0131n\u0131 kubectl apply -f gelistirme-resource-quota.yaml<\/code> komutuyla uygulad\u0131\u011f\u0131m\u0131zda, \"gelistirme\" Namespace'indeki kaynak t\u00fcketimi belirtilen s\u0131n\u0131rlar i\u00e7inde kalacakt\u0131r. E\u011fer bir Pod olu\u015fturulmak istenir ve bu Pod mevcut kotalar\u0131 a\u015farsa, Kubernetes Pod'un olu\u015fturulmas\u0131na izin vermeyecek ve bir hata mesaj\u0131 d\u00f6necektir. Bu proaktif kontrol mekanizmas\u0131, kaynaklar\u0131n adil da\u011f\u0131t\u0131m\u0131n\u0131 ve k\u00fcmenin istikrar\u0131n\u0131 garanti alt\u0131na almak i\u00e7in vazge\u00e7ilmezdir. \u00d6zellikle maliyet kontrol\u00fc ve performans garantisi sa\u011flamak istedi\u011finiz \u00e7ok kirac\u0131l\u0131 ortamlar i\u00e7in Resource Quotas kritik bir rol oynar. Kaynak Kotalar\u0131, sadece israfa engel olmakla kalmaz, ayn\u0131 zamanda her kirac\u0131n\u0131n kaynaklar\u0131n\u0131 \u00f6nceden planlamas\u0131n\u0131 ve optimize etmesini te\u015fvik eder.<\/p>\n
    NetworkPolicy'ler ile A\u011f G\u00fcvenli\u011fi S\u0131n\u0131rlar\u0131 Nas\u0131l \u00c7izilir?<\/h2>\n
    Namespaces ile mant\u0131ksal izolasyonu ve Resource Quotas ile kaynak y\u00f6netimini sa\u011flad\u0131ktan sonra, \u00e7ok kirac\u0131l\u0131 bir ortam\u0131n g\u00fcvenlik omurgas\u0131n\u0131 g\u00fc\u00e7lendirmek i\u00e7in en kritik ad\u0131mlardan biri a\u011f izolasyonudur. NetworkPolicy'ler, Kubernetes i\u00e7indeki Pod'lar\u0131n birbirleriyle ve d\u0131\u015f d\u00fcnya ile nas\u0131l ileti\u015fim kurabilece\u011fini tan\u0131mlayan kurallar\u0131 belirlemenizi sa\u011flar. Varsay\u0131lan olarak, Kubernetes'te bir NetworkPolicy uygulanmad\u0131\u011f\u0131 s\u00fcrece, t\u00fcm Pod'lar birbirleriyle serbest\u00e7e ileti\u015fim kurabilir. Bu durum, \u00f6zellikle hassas verilerin bulundu\u011fu veya farkl\u0131 g\u00fcvenlik seviyelerine sahip uygulamalar\u0131n ayn\u0131 k\u00fcmede bar\u0131nd\u0131r\u0131ld\u0131\u011f\u0131 \u00e7ok kirac\u0131l\u0131 ortamlarda kabul edilemez bir g\u00fcvenlik riski olu\u015fturur. NetworkPolicy'ler sayesinde, Pod'lar aras\u0131ndaki trafi\u011fi kontrol alt\u0131na alabilir, yetkisiz eri\u015fimi engelleyebilir ve \"en az ayr\u0131cal\u0131k\" (least privilege) ilkesini a\u011f katman\u0131nda uygulayabilirsiniz.<\/p>\n
    NetworkPolicy'ler, ingress (i\u00e7eri gelen) ve egress (d\u0131\u015far\u0131 \u00e7\u0131kan) trafik kurallar\u0131n\u0131 tan\u0131mlaman\u0131za olanak tan\u0131r. Bir NetworkPolicy, bir veya daha fazla Pod'u hedefleyebilir ve bu Pod'lara hangi di\u011fer Pod'lar\u0131n, Namespaces'lerin veya IP adres aral\u0131klar\u0131n\u0131n eri\u015febilece\u011fini (ingress) ya da bu Pod'lar\u0131n hangi hedeflere eri\u015febilece\u011fini (egress) belirler. Bu esneklik, \u00e7ok katmanl\u0131 bir a\u011f g\u00fcvenli\u011fi stratejisi olu\u015fturmak i\u00e7in g\u00fc\u00e7l\u00fc bir ara\u00e7t\u0131r. \u00d6rne\u011fin, bir veritaban\u0131 Pod'unun sadece belirli bir uygulama Pod'undan gelen ba\u011flant\u0131lar\u0131 kabul etmesini sa\u011flarken, internete \u00e7\u0131k\u0131\u015f\u0131n\u0131 tamamen engelleyebilirsiniz. Bu sayede, olas\u0131 bir g\u00fcvenlik ihlalinde, sald\u0131rgan\u0131n yanal hareket kabiliyeti k\u0131s\u0131tlanm\u0131\u015f olur.<\/p>\n
    A\u015fa\u011f\u0131da, \"gelistirme\" Namespace'indeki \"backend\" etiketine sahip Pod'lar\u0131n sadece \"frontend\" etiketine sahip Pod'lardan ve ayn\u0131 Namespace i\u00e7indeki DNS Pod'lar\u0131ndan gelen trafiklere izin veren bir NetworkPolicy \u00f6rne\u011fi bulunmaktad\u0131r:<\/p>\n
    \napiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: gelistirme-backend-networkpolicy\n  namespace: gelistirme\nspec:\n  podSelector:\n    matchLabels:\n      app: backend\n  policyTypes:\n  - Ingress\n  - Egress\n  ingress:\n  - from:\n    - podSelector:\n        matchLabels:\n          app: frontend\n    - namespaceSelector:\n        matchLabels:\n          kubernetes.io\/metadata.name: kube-system # DNS i\u00e7in gerekli\n      podSelector:\n        matchLabels:\n          k8s-app: kube-dns\n    ports:\n    - protocol: TCP\n      port: 8080\n  egress:\n  - to:\n    - ipBlock:\n        cidr: 0.0.0.0\/0 # T\u00fcm d\u0131\u015far\u0131 \u00e7\u0131k\u0131\u015fa izin ver (opsiyonel, k\u0131s\u0131tlanabilir)\n    ports:\n    - protocol: TCP\n      port: 443 # HTTPS \u00e7\u0131k\u0131\u015f\u0131na izin ver\n    <\/pre>\n
    <\/code><\/p>\n
    Bu NetworkPolicy'yi kubectl apply -f gelistirme-networkpolicy.yaml<\/code> ile uygulad\u0131\u011f\u0131n\u0131zda, \"gelistirme\" Namespace'indeki \"backend\" Pod'lar\u0131 art\u0131k sadece tan\u0131mlanan kurallara g\u00f6re ileti\u015fim kurabilecektir. NetworkPolicy'ler, \u00e7ok kirac\u0131l\u0131 ortamlarda farkl\u0131 g\u00fcvenlik seviyelerine sahip uygulamalar\u0131 veya departmanlar\u0131 birbirinden izole etmek i\u00e7in kritik bir rol oynar. Unutmamak gerekir ki, NetworkPolicy'lerin \u00e7al\u0131\u015fabilmesi i\u00e7in k\u00fcmenizde bir Container Network Interface (CNI)<\/a> eklentisinin (\u00f6rne\u011fin Calico, Cilium, Weave Net) y\u00fckl\u00fc ve NetworkPolicy'leri desteklemesi gerekmektedir. Bu politikalar\u0131n do\u011fru yap\u0131land\u0131r\u0131lmas\u0131, bir sald\u0131r\u0131n\u0131n k\u00fcme i\u00e7inde yay\u0131lmas\u0131n\u0131 engelleyen g\u00fc\u00e7l\u00fc bir savunma hatt\u0131 olu\u015fturur.<\/p>\n
    Pod G\u00fcvenlik Kabul\u00fc (Pod Security Admission - PSA) ile G\u00fcvenlik Politikalar\u0131 Nas\u0131l Uygulan\u0131r?<\/h3>\n
    Kubernetes k\u00fcmelerinde g\u00fcvenlik, sadece kaynak izolasyonu ve a\u011f kontrol\u00fcyle s\u0131n\u0131rl\u0131 kalmaz; Pod'lar\u0131n \u00e7al\u0131\u015fma zaman\u0131 davran\u0131\u015flar\u0131n\u0131 ve ayr\u0131cal\u0131klar\u0131n\u0131 da d\u00fczenlemek gerekir. \u0130\u015fte burada Pod G\u00fcvenlik Kabul\u00fc (Pod Security Admission - PSA) devreye girer. PSA, Kubernetes Pod Security Standards (PSS) ad\u0131 verilen \u00f6nceden tan\u0131mlanm\u0131\u015f g\u00fcvenlik profillerini (Privileged, Baseline, Restricted) uygulayarak, Pod'lar\u0131n g\u00fcvenlik \u00f6zelliklerini kontrol eden bir Admission Controller'd\u0131r. Bu standartlar, Pod'lar\u0131n g\u00fcvenlik seviyelerini kategorize eder ve potansiyel riskleri azaltmaya y\u00f6nelik en iyi uygulamalar\u0131 i\u00e7erir. PSA, bir Pod'un k\u00fcmede olu\u015fturulmadan \u00f6nce bu standartlara uygun olup olmad\u0131\u011f\u0131n\u0131 denetler ve uygun de\u011filse reddedebilir.<\/p>\n
    PSA, \u00fc\u00e7 temel modda \u00e7al\u0131\u015f\u0131r:<\/p>\n
      \n
    1. Enforce (Zorunlu K\u0131lma):<\/strong> Belirlenen PSS seviyesini ihlal eden Pod'lar\u0131n olu\u015fturulmas\u0131n\u0131 engeller. Bu, en y\u00fcksek g\u00fcvenlik seviyesini sa\u011flar ve politikalar\u0131n kesinlikle uygulanmas\u0131n\u0131 ister.<\/li>\n
    2. Audit (Denetleme):<\/strong> Politikay\u0131 ihlal eden Pod'lar\u0131n olu\u015fturulmas\u0131na izin verir, ancak bir denetim g\u00fcnl\u00fc\u011f\u00fc (audit log) kayd\u0131 olu\u015fturur. Bu mod, mevcut i\u015f y\u00fcklerinin uyumlulu\u011funu de\u011ferlendirmek ve politika uygulamas\u0131na ge\u00e7i\u015f yapmak i\u00e7in kullan\u0131\u015fl\u0131d\u0131r.<\/li>\n
    3. Warn (Uyarma):<\/strong> Politikay\u0131 ihlal eden Pod'lar\u0131n olu\u015fturulmas\u0131na izin verir, ancak kullan\u0131c\u0131ya bir uyar\u0131 mesaj\u0131 d\u00f6ner. Bu mod da denetleme gibi ge\u00e7i\u015f s\u00fcre\u00e7lerinde veya sadece bilgilendirme ama\u00e7l\u0131 kullan\u0131labilir.<\/li>\n<\/ol>\n
      PSA, genellikle Namespace baz\u0131nda uygulan\u0131r. Bu, her bir Namespace'in farkl\u0131 g\u00fcvenlik gereksinimlerine sahip olabilece\u011fi \u00e7ok kirac\u0131l\u0131 ortamlarda inan\u0131lmaz bir esneklik sa\u011flar. \u00d6rne\u011fin, bir \"gelistirme\" Namespace'inde \"Baseline\" PSS seviyesini uygularken, daha hassas bir \"uretim\" Namespace'inde \"Restricted\" seviyesini zorunlu k\u0131labilirsiniz. Bu, geli\u015ftiricilere daha fazla esneklik tan\u0131rken, \u00fcretim ortam\u0131n\u0131n en y\u00fcksek g\u00fcvenlik standartlar\u0131na uymas\u0131n\u0131 sa\u011flar.<\/p>\n
      Bir Namespace'e PSA kural\u0131 uygulamak, Namespace'e belirli etiketler ekleyerek yap\u0131l\u0131r. A\u015fa\u011f\u0131daki \u00f6rnek, \"gelistirme\" Namespace'ine \"Baseline\" Pod Security Standard'\u0131n\u0131 \"enforce\" modunda uygulayan etiketleri g\u00f6stermektedir:<\/p>\n
      \nkubectl label namespace gelistirme pod-security.kubernetes.io\/enforce=baseline --overwrite\nkubectl label namespace gelistirme pod-security.kubernetes.io\/enforce-version=latest --overwrite\n    <\/pre>\n
      <\/code><\/p>\n
      Bu komutlar\u0131 uygulad\u0131ktan sonra, \"gelistirme\" Namespace'inde olu\u015fturulacak t\u00fcm Pod'lar \"Baseline\" PSS seviyesi kurallar\u0131na g\u00f6re denetlenecektir. \"Baseline\" standard\u0131, bilinen ayr\u0131cal\u0131k y\u00fckseltme a\u00e7\u0131klar\u0131n\u0131 ve ciddi g\u00fcvenlik risklerini engelleyen, yine de \u00e7o\u011fu uygulama i\u00e7in yeterli esnekli\u011fi sa\u011flayan bir politikad\u0131r. \u00d6rne\u011fin, bir Pod'un hostPath<\/code> birimleri kullanmas\u0131n\u0131 veya ayr\u0131cal\u0131kl\u0131 modda (privileged mode) \u00e7al\u0131\u015fmas\u0131n\u0131 engelleyebilir. Bu sayede, k\u00f6t\u00fc niyetli veya yanl\u0131\u015f yap\u0131land\u0131r\u0131lm\u0131\u015f Pod'lar\u0131n k\u00fcme g\u00fcvenli\u011fini tehlikeye atmas\u0131 \u00f6nlenir. PSA, \u00e7ok kirac\u0131l\u0131 Kubernetes ortamlar\u0131nda g\u00fcvenlik duru\u015funu g\u00fc\u00e7lendirmek i\u00e7in g\u00fc\u00e7l\u00fc ve kullan\u0131m\u0131 kolay bir mekanizmad\u0131r.<\/p>\n
      Ger\u00e7ek D\u00fcnya Senaryosu: Geli\u015ftirme Ortam\u0131 \u0130\u00e7in \u00c7ok Kirac\u0131l\u0131 Yap\u0131land\u0131rma<\/h2>\n
      \u015eimdiye kadar ele ald\u0131\u011f\u0131m\u0131z t\u00fcm kavramlar\u0131 bir araya getirerek, ger\u00e7ek bir senaryo \u00fczerinden \u00e7ok kirac\u0131l\u0131 bir Kubernetes k\u00fcmesinin nas\u0131l yap\u0131land\u0131r\u0131labilece\u011fini inceleyelim. Diyelim ki, \"InnovateTech\" ad\u0131nda bir teknoloji \u015firketi, farkl\u0131 \u00fcr\u00fcn ekiplerinin (\u00f6rne\u011fin \"Proje A\" ve \"Proje B\") ayn\u0131 Kubernetes k\u00fcmesi \u00fczerinde kendi uygulamalar\u0131n\u0131 geli\u015ftirip test etmesini istiyor. \u015eirket, hem kaynaklar\u0131n adil da\u011f\u0131t\u0131m\u0131n\u0131 sa\u011flamak hem de ekipler aras\u0131 g\u00fcvenlik izolasyonunu garanti alt\u0131na almak istiyor. \u0130\u015fte ad\u0131m ad\u0131m nas\u0131l ilerleyebiliriz:<\/p>\n
      Ad\u0131m 1: Namespace'lerin Olu\u015fturulmas\u0131<\/h3>\n
      \u0130lk olarak, her proje ekibi i\u00e7in ayr\u0131 Namespaces olu\u015fturaca\u011f\u0131z. Bu, ekiplerin kaynaklar\u0131n\u0131 mant\u0131ksal olarak ay\u0131racak ve isim \u00e7ak\u0131\u015fmalar\u0131n\u0131 \u00f6nleyecektir.<\/p>\n
      \napiVersion: v1\nkind: Namespace\nmetadata:\n  name: proje-a-dev\n---\napiVersion: v1\nkind: Namespace\nmetadata:\n  name: proje-b-dev\n    <\/pre>\n
      <\/code><\/p>\n
      Bu YAML dosyas\u0131n\u0131 uygulad\u0131ktan sonra, Proje A ve Proje B'nin ayr\u0131 ayr\u0131 \u00e7al\u0131\u015fma alanlar\u0131 olacakt\u0131r.<\/p>\n
      Ad\u0131m 2: Kaynak Kotalar\u0131n\u0131n Uygulanmas\u0131<\/h3>\n
      Her ekibin k\u00fcmenin t\u00fcm kaynaklar\u0131n\u0131 t\u00fcketmesini engellemek i\u00e7in Resource Quotas tan\u0131mlayaca\u011f\u0131z. Proje A i\u00e7in daha yo\u011fun bir kaynak kotas\u0131 belirlerken, Proje B i\u00e7in biraz daha k\u0131s\u0131tl\u0131 bir kota uygulayabiliriz.<\/p>\n
      \napiVersion: v1\nkind: ResourceQuota\nmetadata:\n  name: proje-a-kota\n  namespace: proje-a-dev\nspec:\n  hard:\n    requests.cpu: \"3\"\n    requests.memory: \"6Gi\"\n    limits.cpu: \"6\"\n    limits.memory: \"12Gi\"\n    pods: \"15\"\n---\napiVersion: v1\nkind: ResourceQuota\nmetadata:\n  name: proje-b-kota\n  namespace: proje-b-dev\nspec:\n  hard:\n    requests.cpu: \"1\"\n    requests.memory: \"2Gi\"\n    limits.cpu: \"2\"\n    limits.memory: \"4Gi\"\n    pods: \"8\"\n    <\/pre>\n
      <\/code><\/p>\n
      Bu kotalar, her projenin kullanabilece\u011fi CPU, bellek ve Pod say\u0131s\u0131n\u0131 s\u0131n\u0131rlar.<\/p>\n
      Ad\u0131m 3: A\u011f Politikalar\u0131n\u0131n Belirlenmesi (NetworkPolicies)<\/h3>\n
      Proje A'n\u0131n uygulama Pod'lar\u0131n\u0131n sadece kendi Namespace'i i\u00e7inde ileti\u015fim kurmas\u0131n\u0131 ve d\u0131\u015far\u0131dan gelen trafi\u011fi sadece belirli bir ingress controller'dan kabul etmesini istiyoruz. Proje B ise kendi i\u00e7indeki Pod'lar aras\u0131 ileti\u015fimi serbest b\u0131rak\u0131rken, d\u0131\u015far\u0131ya sadece HTTPS \u00e7\u0131k\u0131\u015f\u0131na izin verecek.<\/p>\n
      \n# Proje A i\u00e7in NetworkPolicy\napiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: proje-a-app-isolation\n  namespace: proje-a-dev\nspec:\n  podSelector:\n    matchLabels:\n      app: proje-a-app\n  policyTypes:\n  - Ingress\n  - Egress\n  ingress:\n  - from:\n    - namespaceSelector:\n        matchLabels:\n          name: ingress-nginx # veya kendi ingress Namespace'iniz\n      podSelector:\n        matchLabels:\n          app: ingress-nginx-controller\n    ports:\n    - protocol: TCP\n      port: 80\n  egress:\n  - to:\n    - ipBlock:\n        cidr: 0.0.0.0\/0\n    ports:\n    - protocol: TCP\n      port: 443\n\n# Proje B i\u00e7in NetworkPolicy (Basit \u0130\u00e7 \u0130leti\u015fim ve HTTPS \u00e7\u0131k\u0131\u015f\u0131)\napiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: proje-b-default-deny-egress\n  namespace: proje-b-dev\nspec:\n  podSelector: {} # T\u00fcm Pod'lar i\u00e7in ge\u00e7erli\n  policyTypes:\n  - Ingress\n  - Egress\n  ingress:\n  - from:\n    - podSelector: {} # Ayn\u0131 namespace i\u00e7indeki t\u00fcm Pod'lardan gelen trafi\u011fe izin ver\n  egress:\n  - to:\n    - ipBlock:\n        cidr: 0.0.0.0\/0\n    ports:\n    - protocol: TCP\n      port: 443\n    <\/pre>\n
      <\/code><\/p>\n
      Bu politikalar sayesinde, ekiplerin uygulamalar\u0131 aras\u0131nda ve d\u0131\u015f d\u00fcnya ile kontroll\u00fc bir a\u011f ileti\u015fimi sa\u011flanm\u0131\u015f olur.<\/p>\n
      Ad\u0131m 4: Pod G\u00fcvenlik Kabul\u00fc (PSA) Uygulanmas\u0131<\/h3>\n
      Son olarak, Proje A'n\u0131n Namespace'inde \"Baseline\" Pod Security Standard'\u0131n\u0131 zorunlu k\u0131laca\u011f\u0131z. Proje B'ye ise denetleme modunda \"Restricted\" seviyesini uygulayaca\u011f\u0131z, b\u00f6ylece uyumsuzluklar\u0131 tespit edip zamanla d\u00fczeltme imkan\u0131 sunaca\u011f\u0131z.<\/p>\n
      \nkubectl label namespace proje-a-dev pod-security.kubernetes.io\/enforce=baseline --overwrite\nkubectl label namespace proje-a-dev pod-security.kubernetes.io\/enforce-version=latest --overwrite\n\nkubectl label namespace proje-b-dev pod-security.kubernetes.io\/audit=restricted --overwrite\nkubectl label namespace proje-b-dev pod-security.kubernetes.io\/audit-version=latest --overwrite\n    <\/pre>\n
      <\/code><\/p>\n
      Bu etiketlemelerle, Proje A'n\u0131n Pod'lar\u0131 g\u00fcvenli bir yap\u0131land\u0131rmada \u00e7al\u0131\u015fmak zorunda kal\u0131rken, Proje B'deki olas\u0131 g\u00fcvenlik ihlalleri hakk\u0131nda bilgi sahibi olunacakt\u0131r. Bu senaryo, Namespaces, Resource Quotas, NetworkPolicies ve PSA'n\u0131n birlikte nas\u0131l \u00e7al\u0131\u015farak \u00e7ok kirac\u0131l\u0131 bir Kubernetes ortam\u0131 i\u00e7in sa\u011flam bir g\u00fcvenlik ve izolasyon temeli olu\u015fturdu\u011funu g\u00f6stermektedir. Bu y\u00f6ntem, \u015firketlerin karma\u015f\u0131k bulut altyap\u0131lar\u0131n\u0131 daha y\u00f6netilebilir, g\u00fcvenli ve verimli hale getirmelerine yard\u0131mc\u0131 olur.<\/p>\n
      \u0130leri D\u00fczey \u0130pu\u00e7lar\u0131 ve En \u0130yi Uygulamalar<\/h2>\n
      \u00c7ok kirac\u0131l\u0131 bir Kubernetes ortam\u0131 kurmak sadece temel yap\u0131land\u0131rmalarla bitmez. Deneyimli kullan\u0131c\u0131lar i\u00e7in daha da ileri giderek k\u00fcme g\u00fcvenli\u011fini ve y\u00f6netilebilirli\u011fini art\u0131racak baz\u0131 ileri d\u00fczey ipu\u00e7lar\u0131 ve en iyi uygulamalar bulunmaktad\u0131r:<\/p>\n