Bir geliştirici ayrıcalıklı çalışan bir Pod, izin verilmeyen bir container image’ı veya güvenlik standartlarına uymayan bir Deployment oluşturmaya çalışabilir. Bu tür yapılandırmalar yalnızca çalışma zamanında tespit edilirse riskli workload zaten cluster içerisinde çalışmaya başlamış olabilir.
Admission Control yaklaşımı ise güvenlik politikasını kaynak oluşturma sürecinin daha erken bir aşamasına taşır. Böylece hatalı veya riskli kaynakların Kubernetes ortamına kabul edilmeden önce değiştirilmesi, uyarılması veya tamamen reddedilmesi mümkün olabilir.
Kubernetes Admission Controller Nedir ve Nasıl Çalışır?
Kubernetes Admission Controller nedir sorusuna kısaca; Kubernetes API Server’a gelen kaynak oluşturma ve değiştirme isteklerini authentication ve authorization aşamalarından sonra, kaynak kalıcı hâle gelmeden önce inceleyen kontrol mekanizması şeklinde cevap verilebilir.
Bir kullanıcı örneğin yeni bir Deployment oluşturmak istediğinde istek genel olarak şu güvenlik akışından geçer:
- Kullanıcı veya uygulama Kubernetes API Server’a istek gönderir.
- Authentication işlemiyle isteği gönderen kimlik doğrulanır.
- Authorization işlemiyle bu kimliğin işlemi yapmaya yetkili olup olmadığı kontrol edilir.
- Mutating admission kontrolleri gerekiyorsa kaynak üzerinde değişiklik yapabilir.
- Validating admission kontrolleri son durumun politikalara uygun olup olmadığını doğrular.
- Kurallar uygunsa kaynak Kubernetes içerisinde oluşturulur.
- Politika ihlali varsa istek reddedilebilir.
Bu yapı sayesinde güvenlik kontrolleri yalnızca geliştiricilerin dikkatine veya manuel kod incelemesine bırakılmadan cluster seviyesinde uygulanabilir.
Kubernetes Admission Controller Nedir? Temel Türleri
| Admission Türü | Görevi |
|---|---|
| Mutating Admission | API isteğindeki nesneyi kaynak oluşturulmadan önce değiştirebilir. |
| Validating Admission | Kaynağı kontrol eder ve uygun değilse isteği reddedebilir. |
| Built-in Admission Controller | Kubernetes API Server içerisinde bulunan yerleşik controller’lardır. |
| Mutating Admission Webhook | Harici bir webhook üzerinden kaynak üzerinde değişiklik yapılmasına imkân verir. |
| Validating Admission Webhook | Harici politika veya güvenlik sisteminin isteği doğrulamasını sağlar. |
| ValidatingAdmissionPolicy | CEL ifadeleriyle API Server içerisinde deklaratif doğrulama politikaları çalıştırır. |
| Pod Security Admission | Pod Security Standards politikalarının namespace seviyesinde uygulanmasına yardımcı olur. |
Mutating ve Validating Admission Arasındaki Fark Nedir?
Admission Control mimarisini anlamak için mutating ve validating işlemlerinin farkını bilmek önemlidir.
Mutating Admission
Mutating mekanizmalar API isteğindeki nesneyi değiştirebilir. Örneğin belirli label’ların eklenmesi, sidecar container eklenmesi veya bazı varsayılan yapılandırmaların uygulanması için kullanılabilir.
Validating Admission
Validating mekanizmalar kaynak üzerinde değişiklik yapmak yerine kaynağın belirlenen güvenlik veya operasyon politikasına uygun olup olmadığını kontrol eder.
Örneğin aşağıdaki kurallar uygulanabilir:
- Privileged container oluşturulmasını engellemek
- Belirli registry dışındaki image’ları reddetmek
- Root kullanıcıyla çalışan container’ları sınırlamak
- Gerekli label bulunmayan kaynakları reddetmek
- Host network kullanımını sınırlamak
- Belirli namespace’lerde özel güvenlik kuralları uygulamak
Kubernetes Admission Controller Nedir? 10 Güçlü Güvenlik Kontrolü
1. Pod Security Admission Kullanın
Kubernetes içerisinde yerleşik olarak bulunan Pod Security Admission mekanizması, Pod Security Standards kurallarının namespace seviyesinde uygulanmasına yardımcı olur.
Pod Security Standards üç temel güvenlik seviyesine sahiptir:
- Privileged: En az kısıtlamaya sahip seviyedir.
- Baseline: Bilinen tehlikeli ayrıcalıkları sınırlayan temel güvenlik seviyesidir.
- Restricted: Daha sıkı Pod güvenlik gereksinimleri uygular.
Üretim ortamlarında hangi seviyenin kullanılacağı workload gereksinimlerine göre belirlenmeli ve güvenlik seviyesi mümkün olduğunca kontrollü şekilde artırılmalıdır.
2. Enforce Öncesinde Audit ve Warn Modlarını Kullanın
Yeni bir güvenlik politikasını doğrudan engelleme modunda kullanmak mevcut uygulamaların dağıtımını bozabilir.
Pod Security Admission içerisinde kullanılabilen temel modlar şunlardır:
- enforce: Politika ihlalinde Pod reddedilir.
- audit: İhlal audit kayıtlarına eklenir ancak kaynak engellenmez.
- warn: Kullanıcıya uyarı gösterilir ancak işlem devam edebilir.
Kubernetes Admission Controller nedir yaklaşımında yeni politikaları önce gözlemlemek, hangi workloadların etkileneceğini anlamak ve ardından enforce moduna geçmek operasyonel sorunları azaltabilir.
3. ValidatingAdmissionPolicy ile Basit Kuralları API Server İçinde Çalıştırın
Kubernetes ValidatingAdmissionPolicy, Common Expression Language yani CEL kullanarak deklaratif doğrulama politikaları yazılmasına imkân verir.
Basit bir doğrulama için ayrıca ayrı bir webhook sunucusu çalıştırmak yerine ValidatingAdmissionPolicy tercih edilebilir.
Örneğin Deployment replica sayısını sınırlamak, gerekli label’ı kontrol etmek veya belirli alanların istenen koşulu karşılamasını sağlamak için CEL ifadeleri oluşturulabilir.
Bu yaklaşım harici webhook bağımlılığını azaltabileceği için basit doğrulama senaryolarında operasyonel avantaj sağlayabilir.
4. Admission Webhook Kapsamını Gereksiz Geniş Tutmayın
Bir admission webhook cluster içerisindeki tüm kaynaklara uygulanmak zorunda değildir.
Webhook yalnızca gerçekten kontrol etmesi gereken:
- API gruplarına
- Kaynak türlerine
- CREATE veya UPDATE işlemlerine
- Belirli namespace’lere
- Belirli label’lara sahip kaynaklara
uygulanmalıdır.
namespaceSelector, objectSelector, resource rules ve match conditions gibi filtreleme mekanizmaları gereksiz webhook çağrılarını azaltmaya yardımcı olabilir.
Bu yöntem hem performans hem de yanlış bir politikanın cluster’ın tamamını etkileme riskini azaltabilir.
5. Kritik Webhook’larda Failure Policy’yi Bilinçli Seçin
Admission webhook’a ulaşılamadığı durumda API Server’ın ne yapacağı failurePolicy ayarıyla belirlenebilir.
Temel seçenekler:
- Fail: Webhook hatasında istek reddedilir.
- Ignore: Webhook hatası görmezden gelinerek işlem devam ettirilebilir.
Burada tek bir doğru seçenek yoktur. Güvenlik açısından kritik doğrulama kontrolünde fail-closed tercih edilebilirken, mutating webhook’ın geçici olarak çalışmaması nedeniyle bütün cluster dağıtımlarının durması ciddi kullanılabilirlik problemi oluşturabilir.
Kubernetes’in webhook iyi uygulama rehberi, mutating webhook’larda bazı senaryolarda fail-open yaklaşımını ve son durumun ayrıca validating kontrol tarafından doğrulanmasını önerir.
6. Webhook Timeout Süresini Kısa Tutun
Admission webhook API request yolunun doğrudan bir parçasıdır. Webhook’ın yavaş çalışması Kubernetes API işlemlerinin de yavaşlamasına neden olabilir.
Bu nedenle:
- Webhook işlemleri mümkün olduğunca hızlı olmalıdır.
- Gereksiz harici API çağrıları yapılmamalıdır.
- Timeout süresi kontrol edilmelidir.
- Webhook servisi yüksek erişilebilir şekilde dağıtılmalıdır.
- Performans metrikleri düzenli izlenmelidir.
Bir güvenlik kontrolünün cluster API’si için tek hata noktası hâline gelmesi önlenmelidir.
7. Webhook TLS Güvenliğini Doğru Yapılandırın
Admission webhook iletişimi güvenilir bir TLS bağlantısıyla korunmalıdır.
Webhook yapılandırmasındaki CA bilgisi, API Server’ın bağlandığı webhook servisine güvenmesini sağlar.
Sertifikaların:
- Güvenilir CA tarafından oluşturulması
- Süresinin izlenmesi
- Zamanında yenilenmesi
- Özel anahtarlarının güvenli saklanması
- Doğru servis kimliği için oluşturulması
önemlidir.
Süresi dolmuş veya yanlış yapılandırılmış webhook sertifikası admission işlemlerinin başarısız olmasına ve dağıtımların etkilenmesine neden olabilir.
8. Mutating Webhook’larda Side Effect Oluşturmayın
Kubernetes Admission Controller nedir konusunda kritik tasarım kurallarından biri webhook’ın admission isteğinin dışında beklenmeyen değişiklikler oluşturmamasıdır.
Admission webhook yalnızca aldığı AdmissionReview isteği üzerinde karar üretmeye odaklanmalıdır.
Örneğin bir Pod oluşturma isteği sırasında webhook’ın başka bağımsız kaynakları değiştirmesi karmaşık hata senaryolarına yol açabilir.
Yan etkisi bulunmayan webhook’larda sideEffects: None kullanılabilir. Dry-run işlemlerinde yan etkiler engellenebiliyorsa uygun yapılandırma dikkatli şekilde yapılmalıdır.
9. Webhook’ın Kendi Kaynaklarını Engellemesini Önleyin
Kötü tasarlanmış bir admission webhook kendi Deployment’ının yeniden oluşturulmasını engelleyebilir.
Örneğin webhook bütün Pod CREATE isteklerini kontrol ediyor ve webhook’ın kendi Pod’u yeni politikaya uygun değilse mevcut Pod kaybolduğunda yeni webhook Pod’u oluşturulamayabilir.
Bu durum bir bağımlılık döngüsü meydana getirebilir.
Bunu önlemek için:
- Webhook’ın çalıştığı namespace dikkatli seçilmelidir.
- Gerekli system namespace’leri kapsam dışında tutulmalıdır.
- Object selector kullanılabilir.
- Webhook kendi kaynaklarını tetiklememelidir.
- Kritik cluster add-on’ları için kapsam dikkatli belirlenmelidir.
10. Admission Politikalarını Sürekli Test Edin ve Audit Loglarını İzleyin
Admission politikası oluşturulup unutulmamalıdır.
Kubernetes sürümleri, API alanları ve workload gereksinimleri zaman içerisinde değişebilir. Daha önce çalışan bir webhook veya politika yeni kaynaklarla beklenmeyen sonuç oluşturabilir.
Bu nedenle:
- Politikalar test cluster’ında denenmelidir.
- CI/CD sürecinde politika testleri çalıştırılmalıdır.
- Admission reddetme oranları izlenmelidir.
- Audit logları düzenli analiz edilmelidir.
- Yanlış pozitifler takip edilmelidir.
- Politika değişiklikleri sürüm kontrolünde tutulmalıdır.
Bu yaklaşım Kubernetes Admission Controller nedir konusunu tek seferlik yapılandırma yerine sürekli çalışan bir güvenlik programına dönüştürür.
Pod Security Admission Nasıl Kullanılır?
Pod Security Admission, namespace üzerine belirli label’lar eklenerek yapılandırılabilir.
Örneğin bir namespace içerisinde Restricted seviyesini enforce etmek için aşağıdaki mantık kullanılabilir:
apiVersion: v1
kind: Namespace
metadata:
name: production
labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/warn: restricted
Gerçek üretim ortamında kullanılan Kubernetes sürümüne ve workload gereksinimlerine göre Pod Security Standards dokümantasyonu ayrıca kontrol edilmelidir.
ValidatingAdmissionPolicy Nedir?
ValidatingAdmissionPolicy, Kubernetes API Server içerisinde CEL ifadeleri kullanarak kaynakları doğrulamaya yarayan deklaratif bir admission mekanizmasıdır.
Örneğin Deployment’ın en fazla belirli sayıda replica kullanmasına izin veren bir politika oluşturulabilir.
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
name: replica-limit.example.com
spec:
failurePolicy: Fail
matchConstraints:
resourceRules:
- apiGroups:
- apps
apiVersions:
- v1
operations:
- CREATE
- UPDATE
resources:
- deployments
validations:
- expression: "object.spec.replicas <= 10"
message: "Deployment en fazla 10 replica kullanabilir."
Politikanın gerçekten uygulanabilmesi için gerekli ValidatingAdmissionPolicyBinding yapılandırması da oluşturulmalıdır.
Admission Webhook ve ValidatingAdmissionPolicy Arasındaki Fark
| ValidatingAdmissionPolicy | Admission Webhook |
|---|---|
| API Server içerisinde çalışır | Harici webhook servisine çağrı yapar |
| CEL kullanır | Farklı programlama dilleri kullanılabilir |
| Deklaratif doğrulama için uygundur | Daha karmaşık mantık uygulanabilir |
| Harici servis bağımlılığı yoktur | Webhook erişilebilir olmak zorundadır |
| Validating işlemler içindir | Mutating veya validating olabilir |
| Daha basit operasyonel yapı sağlayabilir | Daha esnek fakat daha karmaşık olabilir |
Kubernetes Admission Controller ile Policy as Code İlişkisi
Admission Control mekanizmaları Policy as Code yaklaşımının Kubernetes içerisindeki önemli uygulama noktalarından biridir.
Güvenlik kuralları insanların okuyacağı dokümanlarda kalmak yerine cluster tarafından otomatik olarak uygulanabilir.
Örneğin şirket güvenlik politikası:
“Production namespace içerisinde privileged container çalıştırılamaz.”
şeklindeyse bu kontrol yalnızca dokümana yazılmak yerine admission policy üzerinden teknik olarak uygulanabilir.
Böylece insan hatasına bağlı güvenlik riski azaltılabilir.
Kubernetes Admission Controller ile Secure by Design İlişkisi
Secure by Design yaklaşımında güvenlik kontrollerinin sistem tasarımına sonradan eklenmesi yerine ürünün veya altyapının normal çalışma biçiminin parçası hâline getirilmesi önemlidir.
Admission Control bu yaklaşımı Kubernetes ortamında destekler.
Riskli bir workload oluşturulduktan sonra güvenlik ekibinin alarm almasını beklemek yerine güvenli olmayan yapılandırma daha cluster’a kabul edilmeden engellenebilir.
Kubernetes Admission Controller Hangi Güvenlik Kurallarında Kullanılabilir?
- Privileged container’ları engelleme
- Root container kullanımını kısıtlama
- HostPath kullanımını kontrol etme
- HostNetwork kullanımını sınırlandırma
- Belirli container registry’lerine izin verme
- Gerekli label ve annotation’ları zorunlu tutma
- Resource request ve limit kullanımını kontrol etme
- SecurityContext gereksinimleri uygulama
- Belirli image politikalarını doğrulama
- Namespace bazlı güvenlik politikaları uygulama
- Deployment ayarlarını doğrulama
- Şirket güvenlik standartlarını otomatik uygulama
Kubernetes Admission Controller Kullanırken Yapılan Yaygın Hatalar
- Webhook’ı cluster içerisindeki bütün kaynaklara uygulamak
- Gereksiz uzun timeout kullanmak
- Tek webhook replica’sı çalıştırmak
- Webhook sertifika yenilemesini takip etmemek
- Yan etki oluşturan mutating işlemler yapmak
- Webhook’ın kendi Pod’larını engellemesine izin vermek
- System namespace’lerini kontrolsüz biçimde kapsama almak
- Politikayı audit yapmadan doğrudan enforce etmek
- Basit kontrollerde gereksiz harici webhook kullanmak
- Admission reddetme olaylarını izlememek
- Politikaları sürüm kontrolünde tutmamak
Kubernetes Admission Controller Nedir: Sık Sorulan Sorular
Admission Controller firewall mıdır?
Hayır. Admission Controller Kubernetes API isteklerinin kaynak oluşturma veya değiştirme aşamasında politikalara uygunluğunu kontrol eder. Ağ trafiği güvenlik duvarı değildir.
Admission Controller authentication yerine geçer mi?
Hayır. Authentication kullanıcının kimliğini, authorization ise kullanıcının işlemi yapma yetkisini değerlendirir. Admission Controller bu aşamalardan sonra kaynak ve politika kontrollerini gerçekleştirir.
Admission Controller çalışan Pod’u durdurur mu?
Admission Control temel olarak API istekleri sırasında çalışır. Çalışma zamanındaki saldırı ve davranışların tespiti için runtime security kontrolleri ayrıca gerekir.
Pod Security Admission nedir?
Kubernetes’in Pod Security Standards kurallarını namespace seviyesinde uygulamasına yardımcı olan yerleşik admission controller’dır.
ValidatingAdmissionPolicy webhook gerektirir mi?
Hayır. ValidatingAdmissionPolicy CEL tabanlı deklaratif doğrulamayı Kubernetes API Server içerisinde gerçekleştirebilir.
Admission webhook cluster’ı yavaşlatabilir mi?
Evet. Webhook API request yolunda çalıştığı için yavaş veya çok geniş kapsamlı webhook’lar API gecikmesini artırabilir. Bu nedenle kapsam, timeout ve webhook performansı dikkatli yönetilmelidir.
Admission Controller bütün Kubernetes saldırılarını önler mi?
Hayır. Admission Control yalnızca savunmanın bir katmanıdır. RBAC, NetworkPolicy, Secrets Management, image güvenliği, runtime security, audit logging ve workload identity gibi kontrollerle birlikte kullanılmalıdır.
İlgili İçerikler
Resmî ve Güvenilir Kaynaklar
Kubernetes — Admission Control
Kubernetes — Dynamic Admission Control
Kubernetes — Validating Admission Policy
Kubernetes — Pod Security Admission
Kubernetes — Admission Webhook Good Practices
Sonuç
Kubernetes Admission Controller nedir sorusuna; Kubernetes API isteklerini authentication ve authorization işlemlerinden sonra fakat kaynak cluster içerisinde kalıcı hâle gelmeden önce inceleyen, değiştiren veya doğrulayan güvenlik ve politika mekanizması şeklinde cevap verilebilir.
Pod Security Admission, ValidatingAdmissionPolicy ve admission webhook’lar sayesinde privileged container, hatalı güvenlik ayarı, izin verilmeyen image veya şirket politikasına uymayan Kubernetes kaynaklarının daha erken aşamada tespit edilmesi mümkün olabilir.
Ancak başarılı bir Kubernetes Admission Controller nedir stratejisi yalnızca çok sayıda kural yazmaktan oluşmaz. Webhook kapsamının sınırlandırılması, timeout yönetimi, TLS güvenliği, audit ve warn modlarıyla test, dependency loop’larının önlenmesi ve politikaların sürekli izlenmesi birlikte uygulanmalıdır.
Bu şekilde Admission Control; Policy as Code, Secure by Design ve Kubernetes Zero Trust yaklaşımının güçlü güvenlik katmanlarından biri hâline gelebilir.
