1. GİRİŞ

Kubernetes ekosisteminde hızla artan uygulama ve operasyonel kompleksite, cluster giriş noktalarındaki (API Server) karar mekanizmalarını güçlendirme ihtiyacını doğurdu. Admission controllers, API Server'a ulaşan nesne (resource) yaratma/güncelleme/delete istekleri üzerinde politika, güvenlik ve gözlem kuralları uygulayan kritik bir katmandır. Bu yapı sayesinde organizasyonlar kod değişikliklerini otomatik olarak doğrulayabilir, standartlaştırabilir ve güvenlik‑uyum süreçlerini otomatikleştirebilir.

Neden bugün önemli?

• Policy as Code yaklaşımıyla uygulama konfigürasyonları pipeline'lara taşınıyor; admission controller'lar runtime'da son savunma hattı oluyor.
• Supply‑chain saldırıları, hatalı konfigürasyon ve yanlış yetkilendirme operasyonel riskleri büyütüyor; admission controller'lar bu riskleri azaltmaya yardımcı oluyor.
• Regülasyon ve uyumluluk gereksinimleri üretim pipeline'larına yerleştirilmek isteniyor; admission controller'lar bunu runtime aşamasında enforce edebiliyor.

Kimler için önemli?

• Platform mühendisleri ve SRE ekipleri
• Güvenlik mühendisleri — policy enforcement ve audit
• Uygulama geliştiricileri — güvenli deploy ve konfigürasyon rehberliği

Hangi problemleri çözüyor?

• Yanlış veya tehlikeli konfigürasyonların prod'a gitmesini engelleme
• Otomatik etiketleme, default değer atama ve standartlaştırma
• Uyumluluk, güvenlik ve operasyon kurallarının merkezi uygulanması

2. KAVRAMSAL TEMELLER

2.1 Admission controller nedir?

Admission controller'lar, Kubernetes API Server'a gelen istekleri doğrulayan veya değiştiren modüllerdir. İki ana kategori vardır: "mutating" (değiştiren) ve "validating" (doğrulayan) admission controller'lar. Kubernetes varsayılan bir dizi yerleşik admission controller ile gelir; bunun yanında webhook tabanlı uzantılar (admission webhooks) sayesinde özel kurallar eklenebilir.

2.2 Terminoloji

• Admission Webhook: API Server'dan HTTP(S) üzerinden çağrılan ve gelen nesne üzerinde işlem yapan dış servis.
• MutatingAdmissionWebhook: Nesne üzerinde değişiklik (ör. label ekleme, default ekleme) yapan webhook türü.
• ValidatingAdmissionWebhook: Nesnenin istenen kurallara uyup uymadığını kontrol eden webhook türü; uymuyorsa isteği reddeder.
• FailurePolicy: Webhook'un çağrı başarısız olduğunda API Server'ın nasıl davranacağını belirler (Ignore veya Fail).
• Side effects: Webhook'un dış sistemler üzerinde yan etkiler yapıp yapmadığı bilgisi; güvenlik ve idempotency açısından önemlidir.
• Idempotency: Webhook'un tekrar çağrıldığında aynı sonucu üretme yeteneği; mutating webhook'lar için önemlidir.

2.3 Yerleşik vs webhook tabanlı controller'lar

Kubernetes, örneğin "NamespaceLifecycle", "LimitRanger", "ServiceAccount" gibi yerleşik admission controller'lara sahiptir. Ancak kurumsal ihtiyaçların çoğu için webhook'lar (Mutating/Validating Admission Webhook) daha esnek ve tercih edilir; çünkü dış politika motorları ile (OPA/Gatekeeper, Kyverno) entegre olmayı kolaylaştırır.

3. NASIL ÇALIŞIR? — Teknik Mimari ve Veri Akışı

3.1 API Server akışı

Yüksek seviyede işlem şu şekilde gerçekleşir: API Server isteği alır → authentication (kimlik doğrulama) → authorization (RBAC vb.) → admission controller sırası. Admission aşamasında önce mutating admission controller'lar çağrılır (gerekirse nesne değiştirilir), ardından validating admission controller'lar gelen son nesneyi doğrular. Bu sıra önemlidir: mutating controller'lar nesneyi validasyon kurallarına uygun hâle getirebilir.

3.2 Mutating vs Validating sıradüzeni

1. MutatingAdmissionWebhook çağrılır ve nesne üzerinde değişiklikler yapabilir.
2. Değişen nesne API Server içinde güncellenir.
3. Tekrar mutating webhook'lar veya diğer mutating plugin'ler tetiklenebilir (multiple rounds in some cases).
4. Son olarak ValidatingAdmissionWebhook'lar çalışır; nesneyi kabul veya reddeder.

3.3 Webhook konfigürasyonu: servis, CA ve timeouts

Webhook'lar Kubernetes API Server tarafından HTTPS olarak çağrılır; API Server webhook sunucusunun sertifikasını doğrulamak için CA bundle'ı alır. Ayrıca timeout, failurePolicy (Fail/Ignore), match criteria (side effects, namespaceSelector, objectSelector) gibi parametreler ile isteklerin hangi durumlarda hangi webhook'lara gideceği kontrol edilir. Timeout ve failurePolicy, availability ve güvenlik arasında trade‑off oluşturur.

3.4 Performance ve scalabilite etkileri

Admission webhook'lar API çağrı yoluna eklenen network ve işlem gecikmesi anlamına gelir. Yüksek sorgu hacimli cluster'larda webhook sunucularını HA şeklinde çalıştırmak, timeout'ları ve retry'leri doğru ayarlamak, ve gereksiz validation'ları CI aşamasına taşıyarak runtime yükünü azaltmak önemlidir.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Netflix — Güvenlik ve Otomatik hardening

Netflix benzeri organizasyonlar admission controller'ları güvenlik guardrail'ları için kullanır: container'larda runAsNonRoot zorunlu kılma, hostPath/privileged kullanımını engelleme, resource limit zorunlu kılma gibi kurallar admission aşamasında enforce edilir. Ayrıca mutating webhook'lar ile eksik label veya annotation'ların otomatik eklenmesi sağlanır.

4.2 Uber — Multi‑team policy enforcement

Çok sayıda ekip ve tenant'ı barındıran platformlarda admission controller'lar isim alanı (namespace) bazlı politika uygulamak için kullanılır. Örneğin belirli ekipler için özel networkPolicy kuralları veya bildirimler tetiklenir.

4.3 Amazon — Managed Kubernetes ve admission

Managed Kubernetes sağlayıcıları (EKS, AKS, GKE) genelde admission controller konfigürasyonlarında ek kontrollere izin verir veya kendi managed policy mekanizmalarını sunar. Ayrıca güvenli default'lar ve OIDC entegrasyonu ile kimlik‑yetki zinciri admission politikaları ile uyumlu hâle getirilir.

4.4 OpenAI — Model serving ve resource gating

ML/AI firmalarında admission controller'lar GPU taleplerini doğrulamak, node tolerations/taints gereksinimlerini enforce etmek ve model serving ortamlarında erişim kontrollerini sağlamak için kullanılır. Ayrıca cost‑control (GPU kullanım onayı) gibi iş akışları admission aşamasında değerlendirilebilir.

4.5 Stripe — Compliance ve audit

Finansal uygulamalarda admission controller'lar veri erişimi ve gizlilik kurallarının uygulanmasında kritik rol oynar. Örneğin secrets kullanımını sınırlayan, encryption at rest zorunlu kılan veya belirli image registry'lerini whitelist'leyen validasyon kuralları admission ile enforce edilir.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Runtime policy enforcement: CI aşamasında atlanan hataları prod'da yakalamak için son savunma hattı sağlar.
• Otomatik standartlaştırma: eksik metadata, label veya annotation'ların otomatik doldurulması ile tutarlılık sağlanır.
• Entegre güvenlik: PodSecurity ve OPA/Gatekeeper gibi çözümlerle merkezi güvenlik politikaları uygulanabilir.

Sınırlamalar

• Runtime gecikme: Her admission webhook çağrısı network ve CPU gecikmesi getirir; yüksek trafikte performans sorununa yol açabilir.
• Availability riski: Webhook sunucusunun hata vermesi veya yavaşlaması cluster operasyonlarını etkileyebilir (failurePolicy önemlidir).
• Complexity: Çok sayıda ve karmaşık policy'lar yönetimi zorlaştırır; versioning ve testing gerektirir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

7.1 Konfigürasyon ve güvenlik

• Webhook sunucularını HA modunda çalıştırın; load balancing ve readiness probe'lar ile availability yönetin.
• CA bundle ve TLS sertifika yönetimini otomatikleştirin; sertifika rotasyon politikaları belirleyin.
• FailurePolicy'yi dikkatle seçin: kritik güvenlik kuralları için Fail, ops toleranslı kurallar için Ignore tercih edilebilir.

7.2 Policy design ve testing

• Policy as Code: Tüm admission policy'lerini YAML/rego/kyverno formatında versiyonlayın ve PR/CI sürecinden geçirin.
• Unit ve integration test'leri oluşturun: webhook'ların beklenen davranışı üretim öncesi test edin (mock API Server, e2e testler).
• Canary rollout: Yeni policy'leri önce staging'de, sonra kademeli olarak prod'a uygulayın.

7.3 Observability

• Webhook çağrı metrikleri, latency, error rate ve rejection oranlarını Prometheus/Grafana ile izleyin.
• Audit log'larını merkezi SIEM'e gönderin ve policy violation için alert'ler oluşturun.

8. SIK YAPILAN HATALAR

• Webhook'un failurePolicy'sini default Fail olarak bırakmak ve sunucunun HA olmaması — cluster bozulma riski.
• Policy'leri test etmeden doğrudan prod'a uygulamak — kritik iş akışları bloke olabilir.
• Mutating webhook'un idempotent olmaması — isteklerin tekrarı sonucu veri bozulması.
• Audit ve metrik eksikliği — policy etkisinin izlenmemesi ve hataların gecikmeli fark edilmesi.

9. GELECEK TRENDLER

1. Policy as a Service: Merkezi, paylaşılan policy yönetim platformları kuruluşlar tarafından daha sık kullanılacak.
2. AI destekli politika önerileri: Telemetry verilerinden öğrenen modeller önerilerde bulunabilecek; anomali tespiti ve policy tuning otomatikleşecek.
3. eBPF ile daha hızlı enforcement: Kernel seviyesinde policy enforcement ile webhook gecikmesi azaltılabilir; eBPF destekli local decision makineleri artacak.
4. Standardizasyon: Rego, Kyverno ve benzeri dillerde ortak best practice'lerin standart hale gelmesi bekleniyor.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. Admission controller ile webhook arasındaki fark nedir?

   Admission controller, API Server içindeki genel kavramdır; webhook ise API Server'ın dışa çağırdığı bir mekanizmadır. Webhook'lar mutating veya validating admission controller'ların uygulama şeklidir.

2. Mutating webhook ile validasyon webhook'ı aynı anda kullanıyorsam sıra nasıl işler?

   API Server önce mutating admission webhook'ları çağırır ve nesne üzerinde değişiklik yaptırabilir; değişiklikler uygulandıktan sonra validating webhook'lar çağrılır ve son nesne doğrulanır.

3. Webhook failurePolicy ne anlama gelir ve nasıl seçilmelidir?

   failurePolicy, webhook çağrısı başarısız olduğunda API Server'ın davranışını belirler: Fail (istek reddedilir) veya Ignore (istek devam eder). Kritik güvenlik kuralları için Fail tercih edilebilir, ancak webhook sunucusu HA değilse Fail cluster availability'ı etkileyebilir.

4. OPA/Gatekeeper ile Kyverno arasındaki temel farklar nelerdir?

   OPA/Gatekeeper Rego tabanlı policy engine'dir ve güçlü, deklaratif kural yazımı sunar; Kyverno ise Kubernetes native YAML dönüşümleri yapmayı kolaylaştırır ve mutating özellikleri doğrudan YAML temelli tanımlamaya uygundur. Seçim organizasyonel ihtiyaçlara göre değişir.

5. Mutating webhook'ları nerede kullanmalıyım?

   Otomatik label/annotation ekleme, default resource limits atama, image registry prefix ekleme gibi standardizasyon ve convenience amaçlı mutating webhook'lar uygundur.

6. Admission webhook'lar performansı nasıl etkiler?

   Webhook çağrıları API yoluna ek network ve işlem gecikmesi getirir. Yüksek hacimli API kullanımı olan cluster'larda webhook sunucularının ölçeklenmesi ve timeout yönetimi gerekir.

7. Webhook'ların side effect'leri ne demektir?

   Side effect, webhook'un çağrıldığında dış sistemlerde kalıcı değişiklik yapıp yapmadığıdır. Side effect'li webhook'lar idempotent olmalı ve retry durumlarına karşı güvenli tasarlanmalıdır.

8. Admission policy'leri nasıl test etmeliyim?

   Unit test'ler, mock API Server kullanan integration test'ler ve staging e2e test'leri ile policy davranışlarını test edin. Ayrıca policy değişikliklerini canary olarak küçük scope'da (belirli namespace) uygulayın.

Anahtar Kavramlar

MutatingAdmissionWebhook

Nesneleri değiştirmek için API Server tarafından çağrılan webhook türü.

ValidatingAdmissionWebhook

Nesneleri doğrulayan ve kabul/reject eden webhook türü.

FailurePolicy

Webhook çağrısı başarısız olursa API Server'ın davranışını belirler (Fail/Ignore).

Side effects

Webhook'un dış sistemlerde yarattığı yan etkiler; idempotency ve güvenlik açısından değerlendirilir.

Policy as Code

Policy'lerin kod olarak yönetilmesi, versiyonlanması ve CI ile test edilmesi pratiği.

Öğrenme Yol Haritası

1. 0–1 ay: Kubernetes admission kavramlarını, API Server akışını ve temel yerleşik admission controller'ları öğrenin.
2. 1–3 ay: Mutating ve Validating webhook'lar ile basit policy'ler yazın; Kyverno veya OPA/Gatekeeper deneyimleri edinin.
3. 3–6 ay: Webhook security (TLS, CA bundle), failurePolicy ve timeout tuning, HA deployment pratikleri ve test stratejileri üzerinde çalışın.
4. 6–12 ay: Policy as Code süreçlerini kurun, audit/observability entegrasyonlarını tamamlayın ve AI/telemetry destekli policy tuning deneyleri yapın.