Çatışmasız Kyverno Politikaları Tasarımı: Mülkiyet, Kapsam ve Determinizm İçin Desenler

Çatışmasız Kyverno Politikaları Tasarımı: Mülkiyet, Kapsam ve Determinizm İçin Desenler

Kubernetes ortamlarında güvenlik, uyumluluk ve operasyonel tutarlılık sağlamak için politika motorları vazgeçilmezdir. Kyverno, yerel Kubernetes kaynakları olarak politikaları tanımlama yeteneğiyle bu alanda öne çıkar. Ancak, büyük ve dinamik ortamlarda, birden fazla politika uygulandığında istenmeyen çatışmalar ortaya çıkabilir. Bu makale, Kyverno politikalarını mülkiyet, kapsam ve determinizm prensiplerini temel alarak çatışmasız bir şekilde tasarlamak için pratik desenleri ve en iyi uygulamaları ele alacaktır. Amacımız, hem güvenliği artıran hem de operasyonel karmaşıklığı azaltan sağlam politika altyapıları oluşturmaktır.

Kyverno Politikalarında Çatışma Nedenleri ve Önemi

Kyverno politikaları, Kubernetes kaynaklarının oluşturulması, güncellenmesi veya silinmesi sırasında belirli kuralları uygulamak için kullanılır. Bu kurallar, kaynakları doğrulayabilir (validate), değiştirebilir (mutate) veya yeni kaynaklar oluşturabilir (generate). Ancak, birden fazla politikanın aynı kaynak veya alan üzerinde farklı beklentilerle hareket etmesi durumunda çatışmalar kaçınılmaz hale gelir.

Çatışma Türleri ve Etkileri

Çatışmalar genellikle iki ana kategoriye ayrılır:

• Mutasyon Çatışmaları: İki veya daha fazla mutate politikasının aynı kaynak üzerinde aynı alanı farklı değerlerle değiştirmeye çalışması. Örneğin, bir politika bir etiketi env: prod yaparken, diğeri env: dev yapmaya çalışabilir. Bu durum, kaynağın beklenmedik bir duruma gelmesine veya Kyverno’nun hata vermesine neden olabilir.
• Doğrulama (Validation) Çatışmaları: Bir politika bir kaynağa izin verirken, başka bir politikanın aynı kaynağı reddetmesi. Bu genellikle bir kaynağın oluşturulmasını veya güncellenmesini engeller ve geliştiriciler için kafa karışıklığı yaratır.
• Üretim (Generation) Çatışmaları: İki generate politikasının aynı anda aynı kaynağı oluşturmaya çalışması veya oluşturulan kaynaklar üzerinde farklı beklentilere sahip olması.

Bu çatışmalar, dağıtımların başarısız olmasına, uygulamaların kararsız çalışmasına ve hata ayıklama süreçlerinin uzamasına yol açarak operasyonel verimliliği ciddi şekilde düşürür.

Neden Çatışmasız Tasarım Kritik?

Çatışmasız politika tasarımı, Kubernetes ortamlarında öngörülebilirlik ve güvenilirlik sağlar. Geliştiriciler, uygulamalarının hangi kurallara tabi olduğunu bilir ve buna göre hareket edebilirler. Operasyon ekipleri ise politika hatalarından kaynaklanan kesintilerle daha az uğraşır. Bu, DevOps kültürünün temelini oluşturan hızlı geri bildirim döngülerini ve sürekli entegrasyon/sürekli teslimat (CI/CD) süreçlerini destekler.

Mülkiyet (Ownership) Odaklı Politika Tasarımı

Politikaların kimin sorumluluğunda olduğunu ve hangi kaynakları etkilediğini net bir şekilde tanımlamak, çatışmaları önlemenin ilk adımıdır. Mülkiyet, politikaların kapsamını ve hedefini belirlemede kilit rol oynar.

Namespace Bazlı Mülkiyet

En yaygın ve etkili mülkiyet desenlerinden biri, politikaları Kubernetes namespace’lerine göre ayırmaktır. Bir namespace genellikle belirli bir takım, uygulama veya ortamla ilişkilidir.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: enforce-resource-quotas-dev
spec:
  validationFailureAction: Enforce
  rules:
  - name: require-resource-quotas
    match:
      any:
      - resources:
          kinds:
          - Pod
          namespaces:
          - "dev-*" # Sadece 'dev-' ile başlayan namespace'leri hedefler
    validate:
      message: "Pods in dev namespaces must have resource limits and requests."
      pattern:
        spec:
          containers:
          - resources:
              limits:
                memory: "?*"
                cpu: "?*"
              requests:
                memory: "?*"
                cpu: "?*"

Bu örnekte, politika sadece dev- önekiyle başlayan namespace'lerdeki Pod'ları hedefler. Bu sayede, geliştirme ekipleri kendi namespace'lerindeki kaynakları yönetirken, üretim ekipleri kendi politikalarını bağımsızca uygulayabilir.

Takım/Uygulama Bazlı Mülkiyet Etiketleri

Daha granüler kontrol için, politikaları belirli etiketlere sahip kaynaklara uygulamak mümkündür. Bu, farklı takımların veya uygulamaların kendi özel politika setlerine sahip olmasını sağlar.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: enforce-team-a-image-registry
spec:
  validationFailureAction: Enforce
  rules:
  - name: require-team-a-registry
    match:
      any:
      - resources:
          kinds:
          - Pod
          selector:
            matchLabels:
              app.kubernetes.io/team: team-a # Sadece 'team-a' etiketine sahip Pod'ları hedefler
    validate:
      message: "Team A applications must use images from approved-registry.com."
      pattern:
        spec:
          containers:
          - image: "approved-registry.com/*"

Bu yaklaşım, bir kaynağın hangi takıma ait olduğunu belirten bir etiketle politikaları ilişkilendirerek, takımlar arası çatışmaları azaltır.

Küme Geneli ve Namespace Kapsamlı Politikalar

Kyverno, ClusterPolicy ve Policy olmak üzere iki tür politika sunar.

• ClusterPolicy: Tüm kümeyi etkileyen genel kurallar için kullanılır (örneğin, tüm Pod'ların kaynak limitlerine sahip olması).
• Policy (Namespaced Policy): Belirli bir namespace içindeki kaynakları etkileyen kurallar için kullanılır (örneğin, dev namespace'indeki tüm Pod'ların belirli bir görüntü etiketine sahip olması).

Bu ayrım, mülkiyeti netleştirir. Küme yöneticileri ClusterPolicy'leri yönetirken, takım liderleri veya uygulama sahipleri kendi namespace'leri için Policy'leri tanımlayabilir. Genel kurallar genellikle daha kısıtlayıcıdır ve namespace bazlı kurallar tarafından genişletilebilir veya daha spesifik hale getirilebilir.

Kapsam (Scope) Yönetimi ile Çatışmaları Önleme

Bir politikanın ne kadar geniş bir alanı etkileyeceğini belirlemek, çatışmaları önlemede hayati öneme sahiptir. Kapsamı doğru yönetmek, politikaların sadece hedeflenen kaynaklar üzerinde işlem yapmasını sağlar.

Kaynak Seçiciler (match/exclude)

Kyverno'nun match ve exclude blokları, politikaların uygulanacağı kaynakları hassas bir şekilde belirlemek için kullanılır. Bu bloklar, kaynak türü, adı, namespace'i veya etiketleri gibi çeşitli kriterlere göre filtreleme yapabilir.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-privileged-containers
spec:
  validationFailureAction: Enforce
  rules:
  - name: no-privileged-containers
    match:
      any:
      - resources:
          kinds:
          - Pod
          namespaces:
          - "prod-*" # Sadece 'prod-' ile başlayan namespace'lerdeki Pod'ları hedefler
    exclude:
      any:
      - resources:
          selector:
            matchLabels:
              kyverno.io/exempt: "true" # 'kyverno.io/exempt: true' etiketine sahip Pod'ları hariç tutar
    validate:
      message: "Privileged containers are not allowed in production namespaces."
      pattern:
        spec:
          containers:
          - securityContext:
              privileged: "false" # veya yok

Bu örnek, prod- namespace'lerindeki Pod'larda ayrıcalıklı kapsayıcılara izin vermez, ancak kyverno.io/exempt: true etiketine sahip Pod'ları bu kuraldan muaf tutar. Bu, belirli istisnaları yönetmek için güçlü bir mekanizmadır.

Etiket Seçiciler ile Granüler Kontrol

Etiketler, Kubernetes'te kaynakları düzenlemenin temel bir yoludur ve Kyverno politikalarında da güçlü bir filtreleme aracı olarak kullanılabilir.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-cost-center-label
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-cost-center-label
    match:
      any:
      - resources:
          kinds:
          - Deployment
          selector:
            matchLabels:
              environment: production # Sadece 'environment: production' etiketine sahip Deployment'ları hedefler
    validate:
      message: "Production Deployments must have a 'cost-center' label."
      pattern:
        metadata:
          labels:
            cost-center: "?*"

Bu politika, yalnızca environment: production etiketine sahip Deployment'ların cost-center etiketine sahip olmasını zorunlu kılar. Bu, politikaların sadece ilgili kaynak gruplarına uygulanmasını sağlayarak gereksiz çatışmaları önler.

Admission Control Aşamaları (validate/mutate/generate)

Kyverno, Kubernetes'in admission webhook mekanizmasını kullanarak kaynaklar üzerinde işlem yapar. Bu işlemler belirli aşamalarda gerçekleşir:

• Mutate: Kaynak oluşturulmadan veya güncellenmeden önce değiştirilir.
• Validate: Kaynağın belirli kurallara uygun olup olmadığı kontrol edilir. Uyumsuzsa reddedilir.
• Generate: Bir kaynak oluşturulduğunda veya güncellendiğinde, başka bir kaynak oluşturulur.

Bu aşamaların sırasını anlamak önemlidir. Mutate politikaları önce çalışır, ardından validate politikaları. Eğer bir kaynak mutate politikaları tarafından değiştirilirse, validate politikaları bu değiştirilmiş kaynağı değerlendirir. Çatışmaları önlemek için, mutate politikalarının idempotent (birden fazla kez uygulandığında aynı sonucu veren) olması ve validate politikalarının mutate'den sonra beklenen duruma uygun olup olmadığını kontrol etmesi önemlidir.

Determinizm (Determinism) Sağlama Yöntemleri

Determinizm, bir politikanın her zaman öngörülebilir ve tutarlı sonuçlar üretmesini sağlamak anlamına gelir. Kyverno politikalarında determinizmi sağlamak, beklenmedik davranışları ve çatışmaları ortadan kaldırmak için kritik öneme sahiptir.

Politika Sıralaması ve Önceliklendirme

Kyverno, politikaları belirli bir sıraya göre işler. ClusterPolicy'ler ve Namespaced Policy'ler kendi aralarında alfabetik olarak (isimlerine göre) işlenir. Aynı kaynak üzerinde birden fazla politika varsa, bu sıralama sonucu etkileyebilir. Özellikle mutate politikalarında, bir politikanın yaptığı değişikliği başka bir politika bozabilir.

# Politika A: default-labels (isim alfabetik olarak önce gelir)
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: default-labels
spec:
  rules:
  - name: add-default-app-label
    match:
      any:
      - resources:
          kinds:
          - Pod
    mutate:
      patchStrategicMerge:
        metadata:
          labels:
            app: default-app

# Politika B: override-app-label
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: override-app-label
spec:
  rules:
  - name: override-app-label-for-special-pods
    match:
      any:
      - resources:
          kinds:
          - Pod
          selector:
            matchLabels:
              type: special
    mutate:
      patchStrategicMerge:
        metadata:
          labels:
            app: special-app

Bu örnekte, default-labels politikası alfabetik olarak önce işlenir ve app: default-app etiketini ekler. Ardından override-app-label politikası, type: special etiketine sahip Pod'lar için app etiketini special-app olarak günceller. Bu sıralama, beklenen sonucu verir. Ancak, eğer override-app-label daha genel olsaydı ve default-labels daha spesifik olsaydı, istenmeyen sonuçlar ortaya çıkabilirdi. Bu nedenle, genelden özele doğru bir sıralama veya daha spesifik politikaların daha sonra işlenmesini sağlayacak isim kuralları belirlemek faydalı olabilir.

Mutate Politikası En İyi Uygulamaları

Mutate politikaları tasarlarken determinizmi sağlamak için aşağıdaki noktalara dikkat etmek önemlidir:

• Idempotent Olun: Bir mutate politikası, aynı kaynak üzerinde birden fazla kez uygulandığında aynı sonucu vermelidir. Örneğin, bir alanın değerini belirli bir değere ayarlamak (set) idempotenttir, ancak bir listeye her zaman yeni bir öğe eklemek (append) değildir.
• Patch Stratejilerini Anlayın: Kyverno, patchStrategicMerge, jsonPatch ve overlay gibi farklı patch stratejileri sunar. patchStrategicMerge, Kubernetes'in kendi yama stratejisini kullanarak akıllı bir birleştirme yapar ve genellikle en güvenli seçenektir. jsonPatch daha güçlüdür ancak dikkatli kullanılmalıdır.
• Hedefi Netleştirin: Mutate politikaları, belirli bir amacı gerçekleştirmeli ve gereksiz değişikliklerden kaçınmalıdır. Örneğin, sadece belirli bir etiketin eksik olması durumunda ekleme yapın.

# Idempotent Mutate Örneği: Eğer yoksa etiket ekle
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-missing-owner-label
spec:
  rules:
  - name: add-owner-label
    match:
      any:
      - resources:
          kinds:
          - Deployment
    mutate:
      patchStrategicMerge:
        metadata:
          labels:
            # Eğer 'owner' etiketi yoksa ekle, varsa dokunma
            owner: "{{ coalesce(request.object.metadata.labels.owner, 'unknown') }}"

Validate Politikası En İyi Uygulamaları

Validate politikaları, kaynakların belirli kurallara uygunluğunu kontrol eder ve uyumsuz kaynakları reddeder. Determinizm açısından:

• Açık ve Kesin Kurallar: Validate kuralları, neye izin verildiğini veya neyin reddedildiğini açıkça belirtmelidir. Belirsiz kurallar, yanlış pozitiflere veya yanlış negatiflere yol açabilir.
• Mesajları Netleştirin: Politika başarısız olduğunda kullanıcıya gösterilen mesajlar, hatanın nedenini ve nasıl düzeltileceğini açıkça belirtmelidir.
• Deny Önceliği: Çatışma durumlarında, bir kaynağın reddedilmesi genellikle en güvenli varsayılandır. Eğer birden fazla validate politikası varsa ve biri reddederken diğeri izin veriyorsa, Kyverno kaynağı reddeder.

Generate Politikası En İyi Uygulamaları

Generate politikaları, bir kaynak oluşturulduğunda veya güncellendiğinde başka bir kaynak oluşturur. Çatışmasız ve deterministik generate politikaları için:

• Tekil Sorumluluk: Her generate politikası, belirli bir amaç için tek bir kaynak türünü veya belirli bir kaynak grubunu oluşturmaktan sorumlu olmalıdır.
• Hedef Kaynağı Belirleyin: Generate edilen kaynağın adını ve namespace'ini açıkça belirtin. Çakışan adlar, kaynak oluşturma hatalarına yol açar.
• Güncelleme Stratejisi: Generate edilen kaynakların nasıl güncelleneceğini (örneğin, synchronize: true ile) düşünün. Bu, orijinal kaynakta yapılan değişikliklerin generate edilen kaynağa yansıtılmasını sağlar.

Ortak Çatışma Senaryoları ve Çözümleri

Kyverno politikalarıyla çalışırken karşılaşılan bazı yaygın çatışma senaryoları ve bunların nasıl çözülebileceği aşağıda açıklanmıştır.

Çakışan Mutate Kuralları

İki mutate politikasının aynı alanı farklı değerlerle değiştirmeye çalışması en yaygın çatışmalardan biridir.

# Politika 1: default-env-label
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: default-env-label
spec:
  rules:
  - name: add-default-env
    match:
      any:
      - resources:
          kinds:
          - Deployment
    mutate:
      patchStrategicMerge:
        metadata:
          labels:
            env: dev

# Politika 2: prod-env-label
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: prod-env-label
spec:
  rules:
  - name: add-prod-env
    match:
      any:
      - resources:
          kinds:
          - Deployment
          selector:
            matchLabels:
              stage: production
    mutate:
      patchStrategicMerge:
        metadata:
          labels:
            env: prod

Eğer bir Deployment hem stage: production etiketine sahipse hem de genel bir Deployment ise, hangi env etiketinin uygulanacağı politika isimlerinin alfabetik sırasına göre belirlenir. Bu durumda, default-env-label önce çalışır, ardından prod-env-label onu geçersiz kılar.
Çözüm: Daha spesifik kuralların daha genel kuralları geçersiz kılması bekleniyorsa, isim sıralamasına güvenmek yerine exclude blokları veya daha karmaşık match koşulları kullanarak politikaların kapsamını net bir şekilde ayırmak daha güvenlidir. Örneğin, default-env-label politikasına exclude bloğu ekleyerek stage: production etiketine sahip Deployment'ları hariç tutabilirsiniz.

Deny ve Mutate Çatışmaları

Bir kaynak mutate edildikten sonra, validate politikaları tarafından reddedilebilir. Bu bir çatışma değildir, ancak istenmeyen bir sonuçtur.
Senaryo: Bir mutate politikası bir Pod'a belirli bir kaynak limiti eklerken, başka bir validate politikası bu limitlerin belirli bir eşiğin altında olmasını zorunlu kılar. Mutate politikası yanlışlıkla çok düşük bir limit eklerse, validate politikası Pod'u reddeder.
Çözüm: Mutate politikalarını tasarlarken, validate politikalarının beklentilerini göz önünde bulundurun. Mutate politikaları, validate politikalarının geçmesini sağlayacak şekilde kaynakları dönüştürmelidir. Politika raporları (Policy Reports) bu tür etkileşimleri anlamak için faydalıdır.

Çoklu Politika Uygulamaları

Bir Kubernetes kümesinde yüzlerce politika bulunabilir. Bunların yönetimi başlı başına bir zorluktur.
Çözüm:

• Politika Setleri: İlgili politikaları mantıksal gruplar halinde düzenleyin. Örneğin, "güvenlik politikaları", "uyumluluk politikaları", "uygulama özel politikaları".
• Adlandırma Kuralları: Politikalar için tutarlı adlandırma kuralları kullanın (örn: team-appname-rule-description). Bu, politikaların amacını ve kapsamını hızlıca anlamaya yardımcı olur.
• Versiyonlama: Politikaları Git gibi bir versiyon kontrol sisteminde yönetin ve CI/CD süreçleriyle otomatik olarak dağıtın.

Gelişmiş Stratejiler ve En İyi Uygulamalar

Çatışmasız Kyverno politikaları tasarlamak için bazı ileri düzey stratejiler ve genel en iyi uygulamalar şunlardır:

Politika Setleri ve Politika Raporları

Kyverno, politikaların uygulanma sonuçlarını görmek için PolicyReport ve ClusterPolicyReport kaynaklarını sağlar. Bu raporlar, hangi kaynakların hangi politikalar tarafından etkilendiğini, başarılı olup olmadığını veya reddedildiğini gösterir.

kubectl get policyreport -n my-app-namespace
kubectl get clusterpolicyreport

Bu raporları düzenli olarak incelemek, potansiyel çatışmaları veya istenmeyen politika etkileşimlerini erken aşamada tespit etmenizi sağlar.

Dry Run ve Test Süreçleri

Politikaları üretime almadan önce test etmek hayati önem taşır. Kyverno, dry run modunu destekler.

# Bir kaynağı dry run modunda oluşturarak politikaların nasıl etki edeceğini görün
kubectl apply -f my-resource.yaml --dry-run=server -o yaml

Ayrıca, Kyverno CLI aracı ile politikaları yerel olarak test edebilirsiniz.

# Politika ve kaynak dosyalarını kullanarak test etme
kyverno test policies/ my-resources/

Bu testler, bir politikanın beklenen davranışı sergileyip sergilemediğini ve diğer politikalarla çakışıp çakışmadığını doğrulamak için kritik öneme sahiptir.

Versiyonlama ve CI/CD Entegrasyonu

Politikaları kod olarak ele almak (Policy-as-Code), versiyon kontrol sistemlerinde yönetmek ve CI/CD pipeline'larına entegre etmek, çatışmasız bir ortam sürdürmek için en iyi yaklaşımdır.

• GitOps: Politikaları Git deposunda saklayın ve otomatik dağıtım için Argo CD veya Flux gibi araçlar kullanın.
• Otomatik Testler: CI/CD pipeline'larınızda Kyverno CLI testlerini çalıştırarak her politika değişikliğinin veya yeni politikanın mevcut kurallarla uyumlu olduğunu doğrulayın.
• Gözden Geçirme Süreçleri: Yeni veya değiştirilmiş politikaların başkaları tarafından gözden geçirilmesini sağlayarak potansiyel çatışmaları veya güvenlik açıklarını tespit edin.

Sonuç

Kyverno, Kubernetes ortamlarında politika yönetimini basitleştiren güçlü bir araçtır. Ancak, büyük ve karmaşık ortamlarda çatışmasız politikalar tasarlamak, dikkatli bir planlama ve en iyi uygulamaların benimsenmesini gerektirir. Mülkiyet, kapsam ve determinizm prensiplerine odaklanarak, politikalarınızı net bir şekilde tanımlayabilir, hedeflerini sınırlayabilir ve öngörülebilir sonuçlar elde edebilirsiniz. Kaynak seçicileri, etiketler, doğru admission kontrol aşaması kullanımı ve güçlü test süreçleri ile Kyverno politikalarınızın hem güvenli hem de operasyonel olarak verimli olmasını sağlayabilirsiniz. Bu desenleri uygulayarak, Kubernetes ortamınızda daha az hata, daha hızlı geliştirme döngüleri ve daha yüksek bir güvenlik duruşu elde edeceksiniz.

SSS (Sık Sorulan Sorular)

Kyverno politikaları neden çakışır?

Kyverno politikaları genellikle aynı kaynak üzerinde farklı değerler atamaya çalışan mutate kuralları veya bir kaynağa izin verirken diğerinin reddettiği validate kuralları nedeniyle çakışır. Bu durum, politikaların kapsamının ve hedeflerinin yeterince ayrıştırılmamasından kaynaklanır.

Çakışmaları önlemek için en iyi ilk adım nedir?

En iyi ilk adım, politikaların mülkiyetini ve kapsamını net bir şekilde tanımlamaktır. Hangi takımın veya bölümün hangi kaynaklar üzerinde hangi tür politikaları uygulayabileceğini belirlemek, gereksiz çakışmaları baştan engeller. Namespace bazlı veya etiket bazlı mülkiyet desenleri bu konuda çok yardımcı olur.

Mevcut çakışmaları nasıl tespit edebilirim?

Mevcut çakışmaları tespit etmek için Kyverno'nun PolicyReport ve ClusterPolicyReport kaynaklarını düzenli olarak incelemelisiniz. Ayrıca, yeni politikaları devreye almadan önce dry run modunu kullanmak ve Kyverno CLI ile yerel testler yapmak, potansiyel sorunları önceden görmenizi sağlar.

match ve exclude blokları nasıl kullanılır?

match blokları, politikanın uygulanacağı kaynakları belirlerken, exclude blokları bu kaynaklar arasından belirli istisnaları hariç tutar. Bu blokları kullanarak politikalarınızın kapsamını çok hassas bir şekilde tanımlayabilir, böylece sadece hedeflenen kaynaklar üzerinde işlem yapmalarını sağlayabilirsiniz.

Mutate ve Validate politikaları arasındaki fark nedir?

Mutate politikaları, bir kaynak Kubernetes API'ye gönderilmeden veya güncellenmeden önce onu değiştirir (örneğin, eksik etiketleri ekler). Validate politikaları ise kaynağın belirli kurallara uygun olup olmadığını kontrol eder ve uyumsuz kaynakları reddeder. Mutate politikaları önce çalışır, ardından validate politikaları mutate edilmiş kaynağı değerlendirir.