0Pricing
Security+ Academy · Ders

Kubernetes Güvenliği: RBAC, Ağ Politikaları ve Pod Güvenliği

Kubernetes RBAC rollerini yapılandırın, pod'lar arası trafiği sınırlayan ağ politikalarını uygulayın ve ayrıcalık yükseltmeyi kısıtlamak için pod güvenlik standartlarını kullanın.

Kubernetes Güvenliği: RBAC, Ağ Politikaları ve Pod Güvenliği, CoddyKit'te ücretsiz bir Security+ Academy dersidir. Bu, 4 dersinin 2. dersidir. Aşağıdan dersin tamamını ücretsiz okuyabilir, sonra tarayıcıda yerleşik kod editörü ve 7/24 yapay zeka koçu ile uygulamalı olarak pratik yapabilirsin. Bu, Security+ Academy öğrenme yolunun bir parçasıdır ve ilerlemeniz web ve CoddyKit uygulaması arasında senkronize olur. Security+ Academy kursu toplamda 4 dersten oluşur.

Kubernetes Saldırı Yüzeyine Genel Bakış

Kubernetes, container'laştırılmış iş yüklerini geniş ölçekte düzenler, ancak karmaşıklığı geniş bir saldırı yüzeyi oluşturur. Güvenliği sağlanması gereken başlıca bileşenler şunlardır: API Sunucusu (merkezi denetim düzlemi — buradaki ihlal tüm kümenin denetimini ele geçirir), etcd (küme durum veritabanı — gizli bilgileri base64 biçiminde depolar ve bekleme sırasında şifrelenmelidir), kubelet (düğüm aracısı — kimlik doğrulaması yapılmayan kubelet API'si, istenen herhangi bir pod'un çalıştırılmasına izin verir), container çalışma zamanı (Docker/containerd) ve tüm pod'ları birbirine bağlayan ağ altyapısı. Security+ adayları, Kubernetes yanlış yapılandırmalarının en yaygın bulut güvenliği bulguları arasında olduğunu anlamalıdır.

RBAC: Kubernetes'te Rol Tabanlı Erişim Denetimi

Kubernetes RBAC (Rol Tabanlı Erişim Denetimi), hangi kullanıcıların, hizmet hesaplarının ve işlemlerin hangi API kaynakları üzerinde hangi eylemleri gerçekleştirebileceğini denetler. Modelde dört nesne vardır: Role (isim alanı kapsamındaki izinler), ClusterRole (küme genelindeki izinler), RoleBinding (bir isim alanı içinde bir Role'ü bir özneye verir) ve ClusterRoleBinding (bir ClusterRole'ü küme genelinde bir özneye verir). Her kubectl komutu, RBAC kurallarına göre denetlenen bir API çağrısına dönüşür. RBAC yapılandırılmamışsa, kimliği doğrulanmış herhangi bir kullanıcı (veya hizmet hesabı) yönetici erişimine sahip olabilir.

# Create a role allowing only pod reads in 'default' namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: default
rules:
- apiGroups: [''] 
  resources: ['pods']
  verbs: ['get', 'list', 'watch']

Hizmet Hesapları ve En Az Ayrıcalık

Kubernetes'teki her pod bir hizmet hesabı altında çalışır — bu, API kimlik doğrulaması için kullanılan bir kimliktir. Varsayılan olarak pod'lar, isim alanlarındaki default hizmet hesabını kullanır ve bu hesap geniş izinlere sahip olabilir. En az ayrıcalık ilkesi, her uygulama için yalnızca ihtiyaç duyduğu izinlere sahip özel hizmet hesapları oluşturmayı gerektirir. Ayrıca API erişimine ihtiyaç duymayan pod'larda automountServiceAccountToken: false ayarının yapılması, hizmet hesabı belirtecinin pod dosya sistemine bağlanmasını önler; aksi hâlde güvenliği ihlal edilmiş bir uygulama bu belirteci API çağrıları yapmak için kullanabilir.

# Pod spec: disable service account token auto-mount
apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  serviceAccountName: myapp-sa
  automountServiceAccountToken: false
  containers:
  - name: myapp
    image: myapp:v1.0

Ağ İlkeleri: Varsayılan Olarak Reddet

Kubernetes'te varsayılan olarak tüm pod'lar herhangi bir isim alanındaki diğer tüm pod'larla iletişim kurabilir. Güvenliği ihlal edilmiş bir pod, veritabanlarına, dahili API'lere ve diğer mikro hizmetlere hemen ulaşmayı deneyebilir. Kubernetes NetworkPolicy kaynakları; etiketlere, isim alanlarına ve bağlantı noktalarına göre pod'lar arası trafiği kısıtlayan kuralları tanımlar. Önerilen yaklaşım, her isim alanında 'varsayılan olarak tümünü reddet' ağ ilkesi kullanmak ve ardından gerekli iletişim yolları için açık izin kuralları eklemektir. NetworkPolicy'nin bunu destekleyen bir CNI eklentisi gerektirdiğine dikkat edin (Calico, Cilium, Weave) — uyumlu bir CNI olmadan standart Kubernetes NetworkPolicy'yi yok sayar.

# Default deny all ingress and egress in a namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Pod Güvenlik Standartları: PSP'nin Yerine

Kubernetes 1.23'te tanıtılan ve 1.25'te kararlı hâle gelen Pod Security Standards (PSS), kullanımdan kaldırılmış Pod Security Policy'nin (PSP) yerini alır. Bunlar, isim alanı düzeyinde uygulanan üç yerleşik profilden oluşur: Privileged (kısıtlamasız, sistem bileşenleri için), Baseline (ayrıcalıklı container'lar ve ana makine ağı erişimi gibi bilinen ayrıcalık yükseltmelerini önler) ve Restricted (güçlendirilmiş, kök olmayan kullanıcılar gerektirir, tüm yetenekleri kaldırır ve salt okunur kök dosya sistemlerini zorunlu kılar). Bir ilke düzeyini uygulamak için isim alanlarına etiket verilir ve bunu ihlal eden pod'lar kabul aşamasında reddedilir.

# Label namespace to enforce 'restricted' pod security
kubectl label namespace production \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted

Kubernetes'te Gizli Bilgilerin Yönetimi

Kubernetes Secrets, parolalar, belirteçler ve TLS sertifikaları gibi hassas verileri depolar. Varsayılan olarak Secrets, etcd içinde base64 ile kodlanmış değerler olarak depolanır — şifrelenmez. etcd'yi okuyabilen veya yeterli RBAC izinlerine sahip olan herkes bunların kodunu kolayca çözebilir. En iyi uygulamalar şunları içerir: etcd için bekleme sırasında şifrelemeyi, bir KMS'de depolanan anahtarla AES-GCM kullanarak etkinleştirmek (AWS KMS, GCP KMS); HashiCorp Vault veya AWS Secrets Manager gibi harici bir gizli bilgi yöneticisiyle Secrets Store CSI Driver aracılığıyla tümleştirmek ve Secret erişimini RBAC ile kısıtlayarak yalnızca ihtiyaç duyan hizmet hesaplarının bunları okuyabilmesini sağlamak.

# Enable etcd encryption at rest (encryption configuration)
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
  - secrets
  providers:
  - aescbc:
      keys:
      - name: key1
        secret: <base64-encoded-32-byte-key>

Kabul Denetleyicileri: Güvenlik Geçitleri

Kabul denetleyicileri, kimlik doğrulama ve yetkilendirmeden sonra, ancak nesne kalıcı olarak depolanmadan önce API isteklerini kesen ve istekleri doğrulamalarına, değiştirmelerine veya reddetmelerine olanak tanıyan Kubernetes API sunucusu eklentileridir. Güvenlikle ilgili kabul denetleyicileri şunlardır: PodSecurity (Pod Security Standards'ı uygular), ImagePolicyWebhook (harici imaj imzası doğrulamasına izin verir), AlwaysPullImages (yerel olarak önbelleğe alınmış kötü amaçlı imajların kullanılmasını önlemek için imajların yeniden çekilmesini zorunlu kılar) ve OPA/Gatekeeper (Open Policy Agent — en esnek seçenektir; Rego dilinde ifade edilen özel ilkelerle her türlü kurumsal güvenlik kuralının uygulanmasına izin verir).

Küme Bileşenlerini Güçlendirme

Kubernetes denetim düzlemi bileşenlerinin güçlendirilmesi kritik öneme sahiptir: API sunucusunda kimlik doğrulaması yapılmamış erişimi devre dışı bırakmak için --anonymous-auth=false bulunmalı, tüm API etkinliklerini yakalamak üzere --audit-log-path yapılandırılmalı ve tüm bağlantılar için TLS kullanılmalıdır. kubelet için --authorization-mode=Webhook (AlwaysAllow değil) kullanılmalı ve anonim kimlik doğrulaması devre dışı bırakılmalıdır. etcd için TLS eş ve istemci şifrelemesi, kısıtlanmış ağ erişimi (yalnızca API sunucusu tarafından erişilebilir olma) ve bekleme hâlindeki veriler için şifreleme kullanılmalıdır. CIS Kubernetes Benchmark, tüm bileşen ayarları için kapsamlı bir kontrol listesi sağlar.

# Check kubelet configuration for security issues
kubectl get --raw /api/v1/nodes/nodename/proxy/configz | jq '.kubeletconfig | {anonymousAuth: .authentication.anonymous.enabled, authorization: .authorization.mode}'

İsim Alanı Yalıtımı ve Çok Kiracılı Kullanım

Kubernetes isim alanları, kaynakların mantıksal olarak ayrılmasını sağlar; ancak tek başlarına güçlü bir güvenlik sınırı değildir — öncelikle kurumsal yalıtım sağlarlar. Gerçek çok kiracılı yalıtım için (ör. farklı müşterilerin iş yükleri) ek denetimler gerekir: isim alanları arası trafiği engellemek için ağ ilkeleri, gürültü oluşturan komşunun hizmet engelleme saldırısını önlemek için kaynak kotaları, güçlü biçimde yalıtılmış kiracılar için ayrı düğüm havuzları veya her kiracı için özel kümeler. Birçok kuruluş, tek bir küme içinde daha güçlü çok kiracılı kullanım için Hierarchical Namespaces ya da vCluster gibi ticari çözümler kullanır.

Denetim Günlük Kaydı ve Çalışma Zamanı İzleme

Kubernetes denetim günlük kaydı, her API isteğini kaydeder: isteği kimin yaptığını, nereden yapıldığını, hangi eylemin istendiğini ve hangi Resource'ın hedeflendiğini belirtir. Denetim günlükleri, bir güvenlik olayından sonra adli inceleme yapmak ve olağan dışı rol bağlama işlemleri, gizli bilgilere erişim veya üretim pod'larına yönelik exec komutları gibi anormal davranışları tespit etmek için gereklidir. Denetim günlükleri merkezi bir SIEM sistemine aktarılmalıdır. Falco, kapsayıcı davranışları için çalışma zamanı izleme olanağı sunarken bulut tarafından yönetilen Kubernetes hizmetleri (EKS, GKE, AKS), kendi günlük kaydı platformlarıyla yerel denetim günlüğü entegrasyonu sağlar.

# Check recent kubectl exec events in audit log
grep '"verb":"create".*"resource":"pods".*"subresource":"exec"' /var/log/kubernetes/audit.log | tail -20

Tedarik Zinciri Güvenliği: Görüntü Kökeni

Kubernetes için tedarik zinciri güvenliği, yalnızca güvenilen ve doğrulanmış görüntülerin üretim ortamına ulaşmasını sağlar. CNCF Tedarik Zinciri Güvenliği önerileri şunları içerir: dağıtımdan önce Cosign ile görüntü imzalarını doğrulamak (kabul denetleyicileri aracılığıyla zorunlu kılınır), bileşenlerin kökenini izlemek için tüm kapsayıcı görüntüleri için SBOM'lar (Yazılım Malzeme Listeleri) oluşturup doğrulamak, görüntüleri değiştirilebilir etiketler yerine özetlere (myimage@sha256:abc123) sabitlemek ve tüm üçüncü taraf Helm çizelgelerini dağıtımdan önce yanlış yapılandırmalar ve güvenlik açıkları açısından taramak.

# Pin image to digest for immutability
# Instead of:
image: nginx:latest
# Use:
image: nginx@sha256:a3e2a7a3d7f94e...  # immutable digest

Hızlı Check

Bu dersteki CompTIA Security+ (SY0-701) kavramlarını anlayıp anlamadığınızı sınayın.

Ders Özeti

Bu derste şunları öğrendiniz: Kubernetes RBAC, Roles, ClusterRoles ve Bindings aracılığıyla API erişimini denetler; hizmet hesaplarına her zaman en az ayrıcalık ilkesini uygulayın. NetworkPolicy varsayılan reddetme yapılandırmaları, pod'lar ve ad alanları arasındaki yanal hareketi önler. Pod Security Standards, kapsayıcıların güçlendirilmesini zorunlu kılar ve ad alanı düzeyinde ayrıcalıklı kapsayıcıları, ana bilgisayar ağı erişimini ve kök kullanıcı olarak çalıştırmayı engeller. Sırada sunucusuz güvenliğini ve işlev düzeyindeki saldırı yüzeylerini inceleyeceğiz.

Sıkça Sorulan Sorular

“Kubernetes Güvenliği: RBAC, Ağ Politikaları ve Pod Güvenliği” dersi ücretsiz mi?

Evet — “Kubernetes Güvenliği: RBAC, Ağ Politikaları ve Pod Güvenliği” dersin tüm metni burada web'de ücretsiz olarak okunabilir. Etkileşimli olarak pratik yapmak (yerleşik kod editörü ve 7/24 yapay zeka koçu) ve Security+ Academy kursunun geri kalanını açmak için CoddyKit PRO'ya yükselt. Security+ Academy kursu toplamda 4 dersten oluşur.

“Kubernetes Güvenliği: RBAC, Ağ Politikaları ve Pod Güvenliği” dersinde ne öğreneceğim?

Kubernetes RBAC rollerini yapılandırın, pod'lar arası trafiği sınırlayan ağ politikalarını uygulayın ve ayrıcalık yükseltmeyi kısıtlamak için pod güvenlik standartlarını kullanın. Security+ Academy ile uygulamalı kodu tarayıcıda doğrudan çalıştırarak pratik yaparsın ve 7/24 yapay zeka koçu dersi çalışırken sorularını yanıtlar.

Security+ Academy öğrenmeye başlamak için deneyim gerekli mi?

Önceden deneyim gerekmez. CoddyKit'te Security+ Academy, başlangıçtan ileri seviyeye kadar yapılandırıldığı için buradan başlayabilir veya başından başlayıp kendi hızında ilerleme yapabilirsin. Bu, 4 dersinin 2. dersidir.

“Kubernetes Güvenliği: RBAC, Ağ Politikaları ve Pod Güvenliği” dersi ne kadar sürer?

Çoğu CoddyKit dersi yaklaşık 5–10 dakika sürer. Her biri kısa ve etkileşimli olduğu için sabit ilerleme yaparsın ve web ile uygulama arasında tam olarak bıraktığın yerden devam edebilirsin.

Bu Security+ Academy dersinde kod yazıp çalıştırabilir miyim?

Evet. Her Security+ Academy dersi yerleşik bir kod editörü içerir, bu sayede tarayıcıda gerçek kod yazıp çalıştırabilir ve anlık yapay zeka geri bildirimi alırsın — yerel kurulum gerekli değildir.

Bu kursun tüm dersleri

  1. Kapsayıcı Güvenliği: İmajları Sağlamlaştırma ve Çalışma Zamanı Koruması
  2. Kubernetes Güvenliği: RBAC, Ağ Politikaları ve Pod Güvenliği
  3. Sunucusuz Sistem ve İşlev Güvenliği
  4. Kod Olarak Altyapı Güvenlik Taraması
← Security+ Academy Sayfasına Dön