CI/CD Süreçlerinde Istio ve Calico Politikalarını GitOps ile Yönetmek

GitOps Yaklaşımıyla Güvenli Mikroservis Yönetimi

image from GoOps

Bir önceki yazımda, OpenShift ortamında Istio Service Mesh ve Calico’yu entegre ederek hem ağ hem de servis seviyesinde güvenliği nasıl sağladığımızı paylaşmıştım.

Bu yazıda artık bu yapının bir adım ötesine geçiyoruz. Konumuz: güvenlik politikalarının CI/CD süreçlerine entegre edilmesi. Yani sadece uygulamaları değil, ağ ve servis erişim politikalarını da kod gibi yönetmek.

Modern Kubernetes altyapılarında multi-tenant yapıların yaygınlaşması, ağ güvenliği ve erişim kontrolü konularını daha karmaşık hale getirmiştir. Bu karmaşıklığın en belirgin olduğu alanlardan biri de CI/CD süreçlerinde ağ politikalarının ve güvenlik kurallarının otomatik ve kontrollü bir şekilde yönetilmesidir. Günümüzde firmalar, service mesh (Istio) ve network policy (Calico) çözümlerini kullanarak mikroservisler arasında detaylı trafik kontrolü sağlamakta; ancak bu politikaların yönetimi çoğu zaman manuel, riskli ve sürdürülemez bir hale gelmektedir.

Bu noktada devreye GitOps yaklaşımı giriyor. GitOps, uygulama ve altyapı konfigürasyonlarının kod olarak tanımlanmasını ve bu konfigürasyonların Git üzerinden yönetilmesini sağlayarak, hem görünürlük hem de denetlenebilirlik sağlar. Fakat uygulamada sadece konfigürasyonların Git’e alınması yeterli değildir; bu politikaların farklı tenant yapıları için test edilebilir, onay mekanizmalarına tabi ve otomatik uygulanabilir olması gerekir.

Uygulama kodlarını nasıl CI/CD ile yönetiyorsak, artık ağ ve erişim politikalarını da kod gibi versiyonlamamız, test etmemiz ve otomatik deploy etmemiz gerekiyor. Bu sadece bir verimlilik konusu değil; güvenlik, regülasyon uyumu ve sistem kararlılığı için kritik. Bu yaklaşım neden gerekli, hangi sorunlara çözüm oluyor, birlikte inceleyelim.

Bu yazıda, sahada karşılaştığımız gerçek problemler üzerinden hareketle;

• Istio ve Calico politikalarının GitOps ile nasıl yönetileceğini,
• Ortak bir policy deployment yapısının nasıl kurulacağını,
• Tenant bazlı politika izolasyonunun nasıl sağlanacağını,
• Ve son olarak, OPA Gatekeeper ile policy test, validasyon ve uyumluluk süreçlerinin nasıl otomatize edileceğini detaylı şekilde ele alacağız.

Neden Böyle Bir Yaklaşıma İhtiyaç Duyduk?

Mikroservis mimarileri işimizi hızlandırdı, evet. Ama beraberinde yönetilmesi ve güvenliği zorlaşan bir ortam da getirdi.

Sahada karşılaşılan güvenlik sorunları, çoğu zaman sistemsel zafiyetlerden değil, süreç eksikliklerinden kaynaklanıyor. Örneğin, “Policy Hell” olarak adlandırabileceğimiz bir senaryoda, test ortamında geçici olarak dış trafiğe açılan bir servis, farkında olunmadan production ortamına da aynı şekilde kopyalanabiliyor. Güvenlik tarayıcıları bu açığı tespit ettiğinde ise genellikle iş işten geçmiş oluyor. Bu tür durumların temel nedeni, politikaların versiyonlanmaması ve ortama özel ayrıştırılmamasıdır. Benzer şekilde, “Gölge Erişim” durumunda erişimle ilgili bir sorun yaşandığında, sistemde kimin, ne zaman, hangi politikayı değiştirdiği bilinmeyebiliyor. Audit log’ların yetersiz olması, Git geçmişinin tutulmaması ve açıklayıcı bir dokümantasyonun eksikliği, süreci tamamen kaotik bir hale getirebiliyor. Bu durum, KVKK, ISO 27001 gibi regülasyonlar karşısında ciddi riskler doğuruyor. Bir diğer problem ise “Çakışan Politikalar” vakasında karşımıza çıkıyor. Aynı namespace üzerinde çalışan farklı geliştiriciler, birbirinden habersiz şekilde çelişen politikalar tanımladığında — örneğin biri servisi erişime kapatırken, diğeri açmaya çalıştığında — sistemde çatışmalar meydana geliyor ve sonuç olarak hiçbir şey düzgün çalışmıyor. Bu tür karmaşalar, merkezi ve senkronize bir policy yönetiminin ne kadar kritik olduğunu ortaya koyuyor. Son olarak, “Sürümsüz Güvenlik” vakasında, yapılan bir politika değişikliği sistemi bozduğunda, eski haline dönmek mümkün olmayabiliyor. Çünkü önceki policy’nin yedeği tutulmamışsa, neyin nerede olduğu bilinmiyorsa ve geçmiş versiyonlara erişilemiyorsa, sistemin eski haline getirilmesi imkansız hale geliyor. Kod gibi versiyonlanmayan her şey gibi, güvenlik politikaları da bu durumda sürdürülebilirliğini kaybediyor. Tüm bu örnekler, güvenliğin yalnızca teknik değil, aynı zamanda operasyonel bir disiplin olduğunu da açıkça gösteriyor.

Gelin, birkaç gerçek örnekle bu ihtiyacı daha somut hale getirelim:

• Bir geliştirici, test ortamında geçici olarak bir servisi tüm trafiğe açtı. Sonra aynı policy, farkında olmadan production’a taşındı.
• Yeni bir mikroservis deploy edildi, ancak servis erişim politikaları manuel yazıldığı için, sadece gece saatlerinde fark edilen bir servis kesintisi yaşandı.
• Güvenlik ekibi, production ortamında hangi politikaların ne zaman değiştiğini denetleyemediği için regülasyon denetiminde zorlandı.
• İki farklı geliştiricinin aynı namespace’e yaptığı ayrı policy değişiklikleri birbirini ezdi ve servisler birbirine erişemez hale geldi.

Bu örnekler, size de tanıdık geliyor olabilir. Özellikle yüksek regülasyon ve çok ekipli organizasyonlar için bu tarz problemler sadece teknik değil, operasyonel ve yönetimsel riskler de taşıyor.

İşte bu yüzden bu sorulara kalıcı bir yanıt aradık:

• Politikaları sürümleyip, test edip, güvenle deploy edemez miyiz?
• CI/CD süreçlerine dahil ederek, her adımı şeffaf ve izlenebilir hale getiremez miyiz?
• Ortama özel, versiyonlanabilir güvenlik kontrolleriyle hataları en aza indirmek mümkün değil mi?

Cevabımız: Elbette mümkün. Üstelik bu artık bir lüks değil, modern mikroservis mimarisinde bir gereklilik.

Bu yazıda, bu ihtiyaca nasıl bir çözüm getirdiğimizi adım adım paylaşıyorum. Kullanacağımız teknolojiler arasında GitOps (ArgoCD), Conftest, OPA Rego, Tekton veya GitHub Actions ve yapılandırma yönetiminde Helm/Kustomize yer alıyor.

Amacımız:

· Politika değişikliklerini tıpkı kod gibi versiyonlamak

· Her değişikliği test ederek hataları önceden yakalamak

· Güvenli, kontrollü ve otomatize bir dağıtım süreci kurmak

Hadi şimdi bu yapının teknik bileşenlerine ve süreçlerine birlikte bakalım.

Adım Adım Süreç: Politika Otomasyonu Nasıl Kurulur?

1. Politikaları Git ile Yönet

GitOps ile Çözüm: Tek Kaynak, Çok Tenant

Bu problemi çözmek için GitOps yaklaşımıyla merkezi bir policy yönetim modeli uygulanabilir:

1.1 Policy Şablonlarının Kodu

Ortak kurallar, base klasörü altında şablon (template) olarak tanımlanır. Bu şablonlar kustomize veya helm gibi araçlarla parametrik hale getirilir:

# base/network-policy.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: {{ .Values.namespace }}
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

1.2. Tenant’a Özel Overlays

Her tenant için ayrı bir klasör (overlays/tenant-a, overlays/tenant-b) oluşturulur ve namespace gibi özel parametreler burada belirtilir.

1.3. ArgoCD veya Flux ile Dağıtım

Bu Git reposu ArgoCD gibi bir GitOps aracı ile izlenir. Her tenant’ın overlay klasörü ayrı bir ArgoCD uygulaması olarak tanımlanır. Böylece her tenant’a aynı kural şablonları, farklı namespace’lere otomatik ve tutarlı şekilde uygulanır.

1.4. Versiyon Kontrolü ve Geri Alım

Her değişiklik Git üzerinden takip edilir. Gerekirse geçmişe dönülebilir, hangi tenant’ta hangi policy’lerin geçerli olduğu izlenebilir.

Bu çözüm sayesinde:

• Ortak kurallar merkezi ve tekrar kullanılabilir hale gelir,
• Hatalı konfigürasyon riski azalır,
• Değişiklikler otomatik yayılır ve denetlenebilir olur.

Tüm politikalarımız artık Git’te.

repo-root/
├── policies/
│   ├── istio/
│   │   └── authz-orders.yaml
│   └── calico/
│       └── netpol-orders.yaml

Bu yapı sayesinde kim, ne zaman, hangi policy’yi değiştirmiş görebiliyor, hatta onay mekanizmaları kurabiliyoruz.

2. CI Aşamasında Politika Doğrulama

Kod yazarken test yapıyoruz, değil mi? Aynı şeyi güvenlik politikaları için de yapmalıyız.

conftest ve OPA Rego ile yazdığımız basit kurallar sayesinde hatalı policy’lerin cluster’a ulaşmasını engelleyebiliriz.

Kurumsal Kubernetes ortamlarında güvenlik politikalarının (örneğin NetworkPolicy, AuthorizationPolicy, PeerAuthentication) doğrudan prod ortamlara uygulanması birçok riski beraberinde getirir. En sık karşılaşılan problemler:

• Yanlış yazılmış bir NetworkPolicy tüm trafiği engeller, uygulamalar erişilemez hale gelir.
• Istio AuthorizationPolicy ile uygulamaya dışarıdan erişim tamamen kesilir.
• Geri dönüş için manuel müdahale gerekir ve bu da zaman kaybı ve kesinti anlamına gelir.

Bu problemler, politikaların önce test edilmeden prod ortamına alınmasından kaynaklanır. Özellikle çok sayıda tenant’ın bulunduğu ortamlarda bir hatalı policy tüm müşterileri etkileyebilir.

Örnek Vaka:

Bir müşterinin namespace’ine aşağıdaki AuthorizationPolicy tanımı uygulanıyor:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: tenant-x
spec:
  {}

Bu policy hiçbir kaynak tanımı içermediği için Istio default olarak tüm trafiği engeller. Hedeflenen erişim kısıtlaması yerine tüm servisler dış erişime kapanır. Eğer bu tanım doğrudan prod ortamına uygulanırsa, müşteri sistemleri erişilemez hale gelir.

Bunun yerine AuthorizationPolicy nesnesinde güvenlik açığına yol açabilecek bir yapı olup olmadığını kontrol eden bir policy validation (doğrulama) kuralı uygulayabiliriz.

rego

deny[msg] {
  input.kind == "AuthorizationPolicy"
  input.spec.action == "ALLOW"
  not input.spec.rules[_].from
  msg := "AuthorizationPolicy tanımında kaynak belirtilmemiş"
}

Özellikle Kubernetes ortamlarında, OPA Gatekeeper veya Conftest gibi araçlarla policy kontrolleri yapılırken, bu kod yapısı, yanlış yapılandırılmış ve herkese açık hale gelebilecek AuthorizationPolicy nesnelerinin küme içine alınmasını önler.

Not: Bu Rego kuralı, ALLOW tipindeki AuthorizationPolicy nesnelerinde from belirtilmemişse reddedilmesini ister. Çünkü bu durum, herhangi bir kaynak (source) kısıtlaması olmadan erişim izni verilmesi anlamına gelir.

Bu test, pipeline’ın bir aşamasında otomatik olarak çalıştırılır ve başarısızsa deployment durdurulur.

3. ArgoCD ile Otomatik Uygulama

CI aşamasını geçen her değişiklik, Git’e commitlendiğinde ArgoCD bunu otomatik olarak algılar ve cluster’a uygular.

syncPolicy:
  automated:
    prune: true
    selfHeal: true

Bu sayede operasyon ekibi elle müdahale etmeden tüm güvenlik politikaları doğru namespace’e uygulanmış olur.

4. Ortama Özel Şablonlama

Geliştirme, test ve prod ortamları arasında farklılıklar olabilir. Örneğin sadece prod ortamında bazı servislerin dış dünyaya açılması gerekebilir.

Bunu çözmek için Helm veya Kustomize gibi araçlarla şablonlama yapıyoruz.

yaml

# values.yaml
namespace: prod
app: orders

# templates/authz.yaml
spec:
  rules:
    - from:
        - source:
            namespaces: ["{{ .Values.namespace }}"]

Artık tek bir tanım ile tüm ortamlarda aynı yapıyı sürdürebilir hale geldik.

Gerçek Hayattan Bir Senaryo

Haydi bu yapıyı bir örnekle somutlaştıralım.

orders-service adlı bir mikroservisimiz var. Bu servise sadece frontend namespace’indeki diğer servislerin erişmesini istiyoruz. Ve trafiğin mTLS ile şifrelenmesini şart koşuyoruz.

Bu durumda:

• Geliştirici, policy dosyasını oluşturup Git’e push eder.
• CI pipeline dosyayı test eder, onay verirse
• ArgoCD otomatik olarak bu policy’yi cluster’a uygular.
• Calico sadece frontend’den gelen trafiğe izin verir.
• Istio ise servis içi trafiği mTLS ile şifreler ve kimlik doğrulaması yapar.

Kodu yazan ekip, ağ güvenliğini de sürüm kontrolüne dahil etmiş olur. Her şey belgelenmiş, otomatize edilmiş ve geri alınabilir.

Güvenlik Katmanlarını Artırmak İçin Neler Yapabiliriz?

• CODEOWNERS dosyası ile sadece belirli kişilerin belirli dosyaları değiştirmesine izin verebiliriz.
• Pull request’ler için Conftest testlerinin geçmesi zorunlu hale getirilebilir.
• ArgoCD, yapılan tüm değişikliklerin geçmişini tuttuğu için geri dönüş mümkündür.
• Bildirim mekanizmaları ile (örneğin Slack entegrasyonu) yapılan değişiklikler ekiplerle paylaşılabilir.

Buradan Sonra Ne Olmalı?

Bu yapıyı kurduktan sonra fark edileceği üzere, her namespace’e özel policy yönetmek bile yeterli değil. Çünkü artık aynı cluster üzerinde farklı tenant’lara (müşteri, ekip, uygulama grubu) hizmet veren yapılarda, daha katmanlı bir kontrol modeline ihtiyaç var.

Tenant Bazlı Policy Yönetimine Geçiş

Tenant’lar arasında hem ağ hem servis seviyesinde izolasyon kritik hale geliyor. Bu durumda:

• Her tenant’ın kendi policy setine,
• Bu policy’lerin yukarıdan aşağıya kontrol edilmesine (OPA Gatekeeper gibi),
• Ve tanımlanan kuralların sadece deploy öncesi değil, çalışma zamanında da denetlenmesine ihtiyaç var.

Bu noktada devreye OPA Gatekeeper giriyor.

OPA Gatekeeper ile Kuralları Enforcement Etmek

Gatekeeper, Kubernetes’e entegre çalışan bir politika enforcement mekanizması. Bu yapı sayesinde:

· Tenant’lar sadece belirlenen label ve namespace altında kaynak tanımlayabilir

· Belirli policy’ler dışında hiçbir erişim şekli kabul edilmez

· Yeni policy eklemek bile, Gatekeeper kurallarına uymak zorundadır

· Politikalar YAML değil, kurallarla yönetildiğinden sürprizlerle karşılaşılmaz

Örnek bir Gatekeeper constraint’i şöyle görünür:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: tenant-namespace-labels
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Namespace"]
  parameters:
    labels: ["tenant", "environment"]

Bu örnekte her namespace tanımı, tenant ve environment label’larını taşımak zorundadır. Aksi halde Kubernetes objesi reddedilir.

Buraya Kadar Güzel: Peki ya Multi-Tenant Ortamlar?

Şimdi geldik bir diğer kritik noktaya: Sistemde farklı ekiplerin, farklı müşterilerin, yani farklı tenant’ların olduğunu düşünün.

Her birinin:

• Kendi namespace’i var,
• Farklı servis erişim ihtiyaçları var,
• Güvenlik seviyeleri farklı.

Bu ortamda genel geçer bir policy tanımı artık yeterli değil. Daha gelişmiş, tenant bazlı bir kontrol yapısına ihtiyacımız var.

Tenant Bazlı Politika Yönetimi ve OPA Gatekeeper

Burada devreye OPA Gatekeeper giriyor. Gatekeeper sayesinde:

• Her tenant için ayrı constraint set’leri oluşturabiliyoruz.
• Örneğin, “finans tenant’ı sadece internal network ile konuşabilir” gibi kurallar tanımlayabiliyoruz.
• Bir geliştirici bu kurala aykırı bir şey deploy etmek isterse, admission controller bunu engelliyor.

Örnek Constraint (Gatekeeper için):

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: tenant-namespace-labels
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Namespace"]
  parameters:
    labels: ["tenant", "environment"]

Bu örnekle, her namespace’in tenant ve environment etiketi taşımasını zorunlu hale getiriyoruz.

Policy Rehberi Olarak Repo Kullanımı

GitOps ile bu constraint’ler ve policy dosyaları versiyon kontrolü altında tutulur. Her tenant için özel dizin yapıları oluşturularak politika yönetimi sadeleştirilir:

policies/
  tenant-x/
    istio/
    calico/
    gatekeeper/
  tenant-y/
    ...

CI/CD ile Otomatik Validasyon

Her pull request şu aşamalardan geçer:

• OPA test runner ile Rego kuralları test edilir.
• kubectl gatekeeper validate ile policy’lerin uygunluğu sınanır.
• kustomize build ile tüm yapı doğrulanır.
• Uygunsa otomatik olarak tenant ortamına deploy edilir.

Sonuç: Güvenlik, Otomasyon ve Denetlenebilirlik Aynı Anda Mümkün

Bu yapının sonunda geldiğimiz noktada şunu net şekilde gördük:

• Güvenlik politikaları yalnızca bir güvenlik ekip işi değil ve kod gibi yönetilebilir hale geldi
• Değişiklikler daha şeffaf, izlenebilir ve denetlenebilir oldu
• Farklı ortamlarda tutarlı politikalar sağlandı
• Hatalı policy’ler CI seviyesinde yakalanabilir hale geldi
• Tenant bazlı özel güvenlik kuralları tanımlanabildi
• Mikroservis geliştiren her ekibin doğrudan sorumluluğunda olan,
• Süreçlere entegre bir parça haline gelmeli.

Hem hataları önceden yakalayabildik, hem ortamlar arasında tutarlılık sağladık, hem de denetlenebilirliği üst seviyeye taşıdık.

Eğer bu yazı sizin için faydalı olduysa, takipte kalın. Yorumlarınızı, sorularınızı veya yaşadığınız benzer problemleri benimle paylaşmanız beni çok mutlu eder!