Koray Oksay, CNCF elçisi olarak, kurumların Kyverno’yu çoğunlukla güvenlik ekiplerinin sorumluluğuna verdiğini; Kubernetes yapılandırmalarını doğrulamak, kök yetkileriyle çalışan container’ları engellemek veya container güvenliği standartlarını zorunlu kılmak için kullandığını ve ardından yeteneklerinin büyük bölümünü bir kenara bıraktığını belirtiyor. Oksay’ın yaklaşımına göre bu zihinsel sınıflandırma, Kyverno’yu kötü yapılandırmaları engelleyen bir “geçit” rolüne hapsediyor. Oysa Kyverno, platform ekiplerinin hizmetlerini ve işletim kurallarını üzerine inşa edebileceği temel bir yapı taşı olarak kullanılabilir.
Bu görüş, yazarın 2023 yılında KCD Munich konferansında “Kyverno ile Kubernetes iş yüklerinin güvenliğini sağlamak” başlıklı bir sunumla başlayan deneyimine dayanıyor. Üretim ortamlarında üç yıl çalıştıktan sonra ilgisinin yönetişim, CEL ve platformların self-servis kullanımına kaydığını belirten yazar, Kyverno’yu “politika motoru” olarak tanımlamanın kapsamını açıklamak için artık yeterli olmadığını söylüyor.
Güvenlik sınıflandırması neden yeterli değil?
Oksay, Kyverno’nun güvenlik işlevlerini inkâr etmiyor. Platform güvenli olmayan yapılandırmaları engelleyebilir, Pod Security Standards’ı zorunlu kılabilir ve container imzalarını doğrulayabilir. Ancak yalnızca güvenlikle ilişkilendirilmesi, politikayı temel amacı reddetmek olan bir bariyer olarak gören modeli pekiştirir; bu modelde başarı, engellenen dağıtımların sayısıyla ölçülür.
Buna karşılık yazar, Kyverno için dört temel işlev belirliyor: doğrulama, değiştirme, oluşturma ve görüntülerin doğrulanması. Doğrulama işlevi doğrudan bariyer modeline aittir; değiştirme, kaynakları cluster’a alınmadan önce değiştirir; oluşturma, belirli olaylara yanıt olarak yeni kaynaklar meydana getirir; görüntülerin doğrulanması ise yalnızca tehditleri engellemeye değil, bunlara duyulan güveni oluşturmaya odaklanır. Bu nedenle dört işlevden üçünün yapıcı nitelikte olduğunu, ancak birçok kurumun yalnızca doğrulama politikalarını kullandığını düşünüyor.
Platformun temel bir bileşeni ne demektir?
Oksay “temel bileşen” ifadesini, programlama dillerindeki kullanımına yakın bir anlamda kullanıyor: daha büyük sistemler oluşturmak üzere bir araya getirilebilen, küçük ve anlaşılır bir yapı taşı. Bu yapı taşının platformda gerçek bir rol oynayabilmesi için karmaşıklığı geliştiricilerden gizlemesi, otomatik güvenceler sunması, diğer yapı taşlarıyla bütünleşmesi ve manuel taleplere veya destek kuyruklarına bağlı kalmak yerine self-servis olarak kullanılabilmesi gerekir.
Bu anlamda Kyverno politikaları, Pods, Services, ConfigMaps ve Crossplane bileşimleri gibi bileşenlere benzer. Kurumun benimsediği kuralları platform içinde otomatik davranışa dönüştürürler.
Platform ekipleri onu nasıl kullanır?
- İsim alanlarının hazırlanması: Bir isim alanı oluşturulduğunda Kyverno, varsayılan NetworkPolicy, ResourceQuota, LimitRange ve RoleBindings kaynaklarını üretebilir. Böylece geliştiriciden bir dizi manuel adımı hatırlaması beklenmeden isim alanı kullanıma hazır hâle gelir.
- Yan container’ların enjekte edilmesi: İzleme ajanları, ağ ajanları veya sır senkronizasyon container’ları, kabul aşamasında Pod özelliklerine eklenebilir; böylece Deployment dosyası basit tutulur.
- Görüntü referanslarının yeniden yazılması: nginx:1.25 gibi bir referans, çekme işlemlerinin dahili bir mirror üzerinden geçmesi için mirror.internal/nginx:1.25 biçimine dönüştürülebilir. Böylece her geliştiricinin öneki manuel olarak eklemesi gerekmez.
- Varsayılan kaynak taleplerinin eklenmesi: CPU ve bellek taleplerini belirtmeyen Pods’ları engellemek yerine uygun değerler enjekte edilebilir ve gerektiğinde değiştirilebilir.
- Sahiplik etiketlerinin atanması: Değerler açık olduğunda ekip, maliyet merkezi ve ortam etiketleri eklenebilir; belirsizliğin etkili olduğu durumlarda ise bu etiketler zorunlu kılınabilir.
Uygulamada ne değişir?
Bu kullanımlar tek bir fikri bir araya getiriyor: kurumsal bir inancı görünmez bir otomatik güvenceye dönüştürmek. Kural, yüksek yetkili container’ları engellemek gibi güvenlik amaçlı; kaynak sınırlarını zorunlu kılmak gibi operasyonel; ya da her kaynağı bir maliyet merkezi etiketiyle ilişkilendirmek gibi finansal olabilir. Bu kuralların wiki’lerde, kontrol listelerinde veya tek bir mühendisin bilgisinde kalması yerine kod olarak yazılmış, Git’te saklanan ve GitOps araçları ile Kyverno üzerinden uygulanan politikalara dönüşmesi sağlanır.
Bu bakış açısı, politikayı kurumun niyetini ifade etmek için platformun arayüzü olarak ele almayı öneriyor. Uygulandığında Kyverno’nun işlevleri farklı seviyelere dönüşür: doğrulama koruma bariyerleri sağlar, değiştirme geliştiriciler için “kullanıma hazır yollar” çizer, oluşturma şablonlar veya başlangıç hazırlıkları sunar, görüntülerin doğrulanması ise güven oluşturur.
Ekipler ayrıca politikaları; sürümleri, kullanıcıları, kullanımdan kaldırma döngüleri ve izlenebilir istisnaları olan ürünler olarak ele alacaktır. Politikanın yayımlanması denetimle başlayabilir, ardından uyarı ve kademeli zorunlu kılma aşamalarına geçilebilir. Yazar, bir politikanın Argo CD veya Flux tarafından sahiplenildiği kabul edilen bir kaynağı değiştirmesi durumunda ortaya çıkabilecek koordinasyon zorluklarına da dikkat çekiyor; bu durum senkronizasyon döngülerine yol açabilir.
Oksay’ın vardığı sonuç, Kyverno’yu yalnızca bir güvenlik kılavuzu olarak okumanın arayüzünün ve yeteneklerinin büyük bir bölümünü gizlediğidir. Ona göre Kyverno, cluster’ın girişinde duran bir bekçi değil; platform ekibinin görüşlerini kaynakların ve uygulamaların gerçek davranışına bağlayan bir katmandır.