Kubernetes v1.36: Silinemeyen Politikaların Sessiz Gücü
Bir Kubernetes kümesini ayağa kaldırırken insanı en çok geren şeylerden biri şu oluyor: güvenlik politikasını kurduğunu sanıyorsun, ama arada minicik bir boşluk kalıyor. Küme daha tam doğrulmadan, ilk istekler gelmeye başlamışken, o politika ortada yoksa iş biraz tatsızlaşıyor. Hani “güvendeyiz” dersin ya, sonra bootstrap sırasında kısa bir pencere açılır ve tam oradan sızarlar (inanın bana). Evet.
Kubernetes v1.36 ile gelen manifest-based admission control tam bu boşluğa göz dikmiş gibi dürüyor. İlk duyduğumda ben de “iyi hoş da, sahada ne kadar iş görür?” diye düşündüm açıkçası. Sonra 2024’ün sonlarında bir finans müşterisinde benzer bir açıklık görünce taşlar yerine oturdu: recovery senaryosunda admission politikaları geç geliyor, cluster da o sırada biraz fazla serbest davranıyordu. Güvenlik ekibi de hâliyle buna pek sevinmedi.
Evet, doğru duydunuz.
Benim gözümde bu yenilik küçük bir detay değil; operasyonel güveni yukarı çekiyor. Hele kurumsal tarafta, politika var mı yok mu sorusu bazen uygulamanın kendisinden bile kilit oluyor. Çünkü mesele sadece kural yazmak değil, o kuralın her durumda yerinde kalmasını sağlamak (ciddiyim)
Neden Bu Değişiklik Önemli?
Klasik admission tarafında ValidatingAdmissionPolicy ya da webhook konfigürasyonu API üzerinden yönetiliyor. Kolay tarafı belli; YAML veriyorsun, controller alıyor, çalışıyor gidiyor. Ama steady state dışına çıkınca işler öyle akmıyor. Cluster yeni kurulurken ya da etcd’den dönüş yapılırken kısa süreli bir korumasız alan oluşabiliyor.
Geçen yıl Ankara’da bir müşteri ortamında bunu baya net gördük. Yedekten dönüş sonrası birkaç dakika boyunca policy’ler aktif olmayınca beklenmeyen namespace nesneleri oluşmuştu. Kritik veri kaybı olmadı ama mesaj sertti: “policy gecikirse güvenlik de gecikir.” Böyle anlar bana hep şunu hatırlatıyor; cloud tarafında asıl mesele özellik sayısı değil, davranışın tutarlı kalması.
Bir de self-protection kısmı var ki, işte orası ayrı dert. Admission webhook’ları kendi yapılandırmalarını denetleyemiyor; Kubernetes circular dependency çıkmasın diye bazı kaynaklarda onları devre dışı bırakıyor. Yanı güçlü yetkisi olan biri hayatı policy objesini silebiliyor ve zincirde kimse önü durduramıyor. Kağıt üstünde düzgün görünen modelin pratikte böyle bir deliği olması insanı biraz düşünduruyor doğrusu.
Bunu biraz açayım.
Nasıl Çalışıyor?
Mantık aslında basit: AdmissionConfiguration dosyasına staticManifestsDir alanını ekliyorsunuz ve API server’a hangi dizinden manifest okuyacağını söylüyorsunuz. Sonra YAML dosyalarını o klasöre koyuyorsunuz; server ayağa kalkarken bunları yüklüyor ve istekleri dinlemeye başlamadan önce politikalara sahip oluyor.
Bence en hoş taraflardan biri şu: politika artık “önce gelir sonra çalışır” mantığıyla ele alınıyor. Normalde servislerle uğraşırken sonradan gelen güvenliği konuşuruz; burada işe sıra tersine dönüyor — önce kural geliyor, sonra trafik başlıyor. Açık konuşayım, bu yaklaşım bana baya mantıklı geldi.
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: ValidatingAdmissionPolicy
configuration:
apiVersion: apiserver.config.k8s.io/v1
kind: ValidatingAdmissionPolicyConfiguration
staticManifestsDir: "/etc/kubernetes/admission/validating-policies/"
Buradaki küçük ama can sıkıcı ayrıntıyı atlamamak lazım: manifest içindeki kaynak adlarının .static.k8s.io ile bitmesi gerekiyor. Ufak ayrıntı gibi dürüyor ama operasyonda fark yaratıyor; hem çakışmayı azaltıyor hem de log’a bakınca kaynağın nereden geldiği daha net görünüyor.
| Bileşen | Klasik Model | Sabit Manifest Modeli |
|---|---|---|
| Yükleme zamanı | API üzerinden sonradan | API server başlangıcında |
| Silinebilirlik | Evet | Daha zor / tasarım gereği sabit |
| Kritik boşluk riski | Daha yüksek | Daha düşük |
| Acil kurtarma senaryosu | Zayıf halka olabilir | Daha güvenli zemin sağlar |
Örnek kullanım nerede işe yarar?
Şunu fark ettim: Kube-system dışındaki namespace’lerde privileged container engellemek istiyorsanız bu model gayet yerinde dürüyor. En çok da regülasyon baskısı olan sektörlerde — banka, sigorta, kamu — policy’nın sadece tanımlı olması yetmiyor; aynı zamanda yerinde kalması da gerekiyor.
Bunu 2019’da kendi lab ortamımda klasik webhook ile denemiştim; minicik bir RBAC hatası yüzünden test policy’si silinmişti ve ben bunu ancak audit log’da fark etmiştim… O gün öğrendiğim ders şuydu: security by convention yetmez, security by construction gerekir. Daha fazla bilgi için
Maliyet ve işletme gözüyle bakınca…
Vallahi, AWS veya başka bulutlarda olduğu gibi burada da maliyet sadece servisin fiyat etiketi değil; insan saati ve hata maliyeti de işin içine giriyor (hani görünmeyen bütçe kalemi). Azure tarafında benzer korumayı başka katmanlarla kurmaya çalışsanız bile operasyon yükü artabiliyor bazen. Bu model işe mevcut control plane üzerine oturduğu için ekstra ürün yığmadan iş görüyor.
İtiraf edeyim, Ama dürüst olayım: her çözüm gibi bunun da sınırı var. Alpha aşamasında olması önemli bir çizgi çekiyor; yanı bugün üretime koyayım deyip kör dalmak doğru olmazdı benim gözümde. Güzel fikir ama henüz ham… Hani ne farkı var diyorsunuz, değil mi? Biraz daha pişmesi lazım.
Nerede Dikkatli Olmalı?
Neyse uzatmayalım—bu modelin iyi yanları kadar dikkat isteyen tarafları da var. İlk olarak alpha etiketi hafife alınmamalı. İkinci olarak static — kendi adıma konuşayım — manifest yönetimi DevOps akışınıza iyi oturtulmazsa manuel dosya dağıtımı kaosa dönebilir. Üçüncü olarak isimlendirme kuralını ihmal ederseniz debug süresi gereksiz uzar. Baya sıradan hatalar bile hayatı sistemlerde büyüyebiliyor. Tahmin eder mısınız? Tam da öyle.
No single source of truth! cümlesini burada özellikle vurgulamak isterim. Hani ne farkı var diyorsunuz, değil mi? Türkçesiyle söyleyelim: tek doğruluk kaynağı net olmalı.
Eğer bazı politikalar API’dan geliyor bazıları diskten geliyorsa ekipler karışabilir.
Benim tavsiyem şu olurdu:
kilit policy setini GitOps mantığıyla versionlayın,
manifest dizinini kontrollü yayınlayın,
değişiklikleri CI/CD üzerinden geçirip sonra cluster’a itin.
Bu noktada plansız el müdahalesi istemezsiniz! (ilk duyduğumda inanamadım)
Peki ilk adım ne olsun?
- Kritik admission kurallarınızı listeleyin. (bu kritik)
- Bunların hangisinin silinemez olması gerektiğine karar verin.
- Ayrı bir static manifests dizini açın.
- Name suffix standardınızı belirleyin (.static.k8s.io).
- Bunu test cluster’da deneyip audit log’u izleyin. — ciddi fark yaratıyor
Kurumsal dünyada asıl soru “politikayı yazabildik mi?” değil; “o politika bootstraptan felaket kurtarmaya kadar her an ayakta kalıyor mu?” sorusu.
Peki neden?
Çünkü bazen tek satırlık gecikme bütün resmî bozuyor.
Neyse ki bu yaklaşım tam oraya dokunuyor.
Kendi Deneyimlerimden Kalan Dersler
Zaman zaman AZ-305 çalışırken mimarı kararların ne kadar küçük detaylara dayandığını tekrar görürüm ya… bu konu tam öyle çıktı karşıma yine.
Kâğıt üzerinde iki satırlık ayar gibi duran şeyler,
gerçekte cluster davranışını ciddi biçimde değiştiriyor.
AZ-104 hazırlığında öğrendiğim disiplin burada da aynı işe yaradı:
“önce dayanıklılık,
sonra konfor.”
Kısacası sıra önemliymiş meğer (bu konuda ikircikliyim)
2025’in Kasım ayında İzmir’de bir üretim ortamında benzer mantıkla çalışan sıkılaştırılmış güvenlik kontrolleri tasarlamıştık.
Orada asıl problem teknik değildi;
ekibin değişiklikleri hızlı yapabilmesi için kapıları fazla açık bırakmış olmalarıydı.
Sonra sınırı biraz daraltınca hayat düzeldi…
Geceleri telefon çalmadı!
Bazen en iyi iyileştirme yeni özellik eklemek değil,
bir şeyi yerinden kıpırdatmamaktır.
Açık konuşayım, Ayrıca şu noktayı önemsiyorum:
Bu tarz yenilikler sadece Kubernetes uzmanlarını ilgilendirmiyor. Platform ekibi,
DevOps mühendisi,
güvenlik analisti —
hepsi aynı masaya oturmalı. Çünkü böyle değişikliklerde yanlış karar genelde teknik eksikten değil,
takımlar arası kopukluktan çıkıyor. Bir yerde izin veriliyor,
öbür tarafta kimsenin haberi olmuyor — dürüst olayım, biraz hayal kırıklığı —. Sonra sabah toplantısında herkes birbirine bakıyor…
Sıkça Sorulan Sorular
Kubernetes v1.36’daki manifest-based admission control nedir?
Kısaca şöyle açıklayayım:
Admission webhook’ları veya policy’leri, hani diskteki statik manifestlerden yükleme yöntemi bu. API server ayağa kalkar kalkmaz bu kuralları okuyup istekleri onlarla birlikte karşılıyor. Yanı politika sonradan eklenen bir obje olmuyor, aslında işin başından orada oluyor.
Bunu neden kullanmalıyım?
Mesela hayatı politikaların yanlışlıkla silinmesini istemiyorsanız ya da bootstrap sırasındaki o korumasız pencereyi kapatmak istiyorsanız oldukça işe yarıyor.
Bilhassa kurumsal ortamlarda tutarlılığı sağlıyor ve açıkçası operasyon riskini ciddi ölçüde azaltıyor.
Tüm policy’leri bununla mı yönetmeliyim?
Bence hayır.
Her şeyi buraya taşımak yerine gerçekten kritik olanları seçmek daha doğru olur.
Esnek kalmanız gereken yerlerde klasik API tabanlı yönetim hâlâ gayet iyi iş görüyor.
.static.k8s.io suffix’i neden gerekli?
Dürüst olmak gerekirse, Çakışmayı önlemek için gerekli.
Yanı aynı isimle hem API’den gelen hem diskten gelen kaynaklar birbirine karışmasın diye böyle bir kural koyulmuş.
Tecrübeme göre log ve metrik tarafında iz sürmek de bu sayede çok kolaylaşıyor.
Kaynaklar ve İleri Okuma
Kubernetes v1.36 Resmî Blog Yazısı
Kubernetes Admission Controllers Dokümantasyonu
API Server Konfigürasyon Referansı
İlgili Yazılar
Kubernetes’te ExternalIPs Neden Gidiyor: Güvenlik ve Geçiş
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
3 comments