Envoy ext_authz ile İç API Yetkilendirme Zinciri

İç API’lerde en sık görülen güvenlik hatası, kimlik doğrulama ile yetkilendirmeyi aynı uygulama koduna gömüp zamanla her serviste farklı davranış üretmektir. Bir servis JWT’yi sadece imzaya göre kabul eder, diğeri claim kontrolü yapar, bir başkası ise kullanıcı yerine servis kimliğini yorumlar. Envoy’un ext_authz filtresi burada pratik bir ara katman sunar: istek önce proxy’de karşılanır, karar ayrı bir yetkilendirme servisine sorulur, uygulama ise sadece iş mantığına odaklanır.

Hangi problem çözülüyor?

İç ağda çalışan servisler çoğu zaman “zaten güvenli bölgedeyiz” varsayımıyla büyür. Sonra entegrasyon sayısı arttığında şu sorunlar belirir:

• Aynı kimlik farklı servislerde farklı haklarla yorumlanır.
• Politika değişikliği için tüm servisleri ayrı ayrı yayınlamak gerekir.
• İstek reddedildiğinde kararın neden alındığı merkezi olarak görülemez.
• Operasyon ekibi 403 hatasının ağ mı, token mı, politika mı kaynaklı olduğunu ayırt edemez.

ext_authz modeli bu yüzden yalnızca güvenlik değil, operasyonel okunabilirlik de sağlar.

Hedef mimari

Temel akış şöyledir:

1. İstemci isteği Envoy’a gelir.
2. Envoy istek metadatasını ext_authz servisine yollar.
3. Yetkilendirme servisi kimliği ve politikayı değerlendirir.
4. Envoy isteği geçirir ya da reddeder.
5. Karar kaydı merkezi log veya metric hattına düşer.

Bu modelde uygulama servisi, isteğin yetki açısından önceden filtrelenmiş olduğunu varsayabilir.

Minimal Envoy yapılandırması

Aşağıdaki örnek, HTTP filtre zincirinde ext_authz kullanımını gösterir:

static_resources:
  listeners:
    - name: internal-api
      address:
        socket_address:
          address: 0.0.0.0
          port_value: 8443
      filter_chains:
        - filters:
            - name: envoy.filters.network.http_connection_manager
              typed_config:
                "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
                stat_prefix: internal_api
                route_config:
                  name: local_route
                  virtual_hosts:
                    - name: api
                      domains: ["*"]
                      routes:
                        - match: { prefix: "/" }
                          route: { cluster: app }
                http_filters:
                  - name: envoy.filters.http.ext_authz
                    typed_config:
                      "@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthz
                      transport_api_version: V3
                      failure_mode_allow: false
                      grpc_service:
                        envoy_grpc:
                          cluster_name: authz
                  - name: envoy.filters.http.router
  clusters:
    - name: authz
      connect_timeout: 1s
      type: STRICT_DNS
      load_assignment:
        cluster_name: authz
        endpoints:
          - lb_endpoints:
              - endpoint:
                  address:
                    socket_address:
                      address: authz.internal
                      port_value: 9000
    - name: app
      connect_timeout: 1s
      type: STRICT_DNS
      load_assignment:
        cluster_name: app
        endpoints:
          - lb_endpoints:
              - endpoint:
                  address:
                    socket_address:
                      address: app.internal
                      port_value: 8080

Buradaki kritik tercih failure_mode_allow: false ayarıdır. Yetkilendirme servisiniz cevap veremiyorsa isteği geçirmek değil, kontrollü biçimde reddetmek daha güvenlidir. Fakat bu kararın operasyon etkisini de baştan planlamak gerekir.

Yetkilendirme servisi neye bakmalı?

ext_authz servisini mümkün olduğunca küçük ama net sorumluluklu tasarlamak gerekir. Ben şu alanları temel kabul ediyorum:

• İstek yapanın servis ya da kullanıcı kimliği
• Hedef yol, metod ve tenant bağlamı
• Gerekli rol veya politika adı
• Kararın neden alındığını gösteren kısa neden kodu

Bu servisin doğrudan iş mantığına girmesi yanlış olur. Sipariş limiti, kampanya kuralı veya müşteri segmenti gibi alanlar uygulamanın sorumluluğunda kalmalı; ext_authz katmanı erişim kararıyla sınırlı olmalıdır.

Test akışı nasıl kurulmalı?

Bu hattı canlıya almadan önce üç senaryoyu otomatikleştirin:

• Geçerli kimlikle izin verilen istek
• Geçerli kimlikle reddedilmesi gereken istek
• Yetkilendirme servisi gecikmeli veya erişilemez durumdayken sistem davranışı

Özellikle üçüncü senaryo kritiktir. Çünkü birçok ekip normal trafik testini yapar ama yetkilendirme servisi yavaşladığında Envoy kuyruklarının ve istemci zaman aşımlarının nasıl davranacağını gözlemlemez.

Operasyonel gözlem katmanı

Kurulum tamamlandıktan sonra aşağıdaki sinyalleri izleyin:

• Toplam istek sayısı ve reddedilen oran
• Neden koduna göre ret dağılımı
• ext_authz yanıt süresi
• Proxy ile yetkilendirme servisi arasındaki hata oranı

Bu metrikler olmadan güvenlik katmanı görünürde merkezî, gerçekte opak kalır.

Sonuç

Envoy ext_authz ile iç API yetkilendirme zinciri kurmak, erişim kararını servis kodundan tamamen koparmak zorunda değildir; fakat bunu ortak, gözlemlenebilir ve yönetilebilir bir katmana taşır. Kimlik, politika ve karar kaydı ayrıldığında güvenlik ekibi daha tutarlı kontrol uygular, platform ekibi sorunları daha hızlı teşhis eder ve uygulama ekipleri iş mantığına odaklanabilir.