NGINX Ingress ile Karşılaşılan Zorluklar Nelerdir?

NGINX Ingress’ten Pomerium’a Geçiş: Gelişmiş Erişim Kontrolü ve Sıfır Güven Mimarisi

Modern bulut yerel uygulamalar ve mikroservis mimarileri, güvenlik ve erişim kontrolü konusunda geleneksel yaklaşımların ötesine geçen çözümler gerektirmektedir. Özellikle Kubernetes ortamlarında, NGINX Ingress Controller uzun yıllardır dış dünyaya açılan kapı olarak hizmet vermiştir. Ancak artan siber tehditler ve “Sıfır Güven” (Zero Trust) güvenlik prensiplerinin yükselişiyle birlikte, sadece trafik yönlendirmek ve SSL sonlandırmak yeterli olmamaktadır. Peki, NGINX Ingress’in sunduğu kolaylıkları korurken, uygulamalarınızın güvenliğini kimlik doğrulama ve yetkilendirme yetenekleriyle bir adım öteye taşıyabilir misiniz? Bu makalede, NGINX Ingress’ten Pomerium Ingress Controller’a geçişin nedenlerini, adımlarını ve ileri düzey kullanım senaryolarını detaylı bir şekilde inceleyeceğiz.

Kubernetes ekosisteminde Ingress, dış dünyadan gelen HTTP/S trafiğini küme içindeki servislere yönlendiren önemli bir bileşendir. NGINX Ingress Controller ise bu rolü üstlenen en popüler ve yaygın olarak kullanılan çözümlerden biridir. Esnek yapılandırma seçenekleri, performanslı çalışma ve geniş topluluk desteği sayesinde birçok organizasyon için vazgeçilmez bir araç haline gelmiştir. Ancak günümüzün karmaşık ve dinamik siber güvenlik ortamında, NGINX Ingress’in temel yetenekleri bazı önemli sınırlamaları beraberinde getirmektedir.

Öncelikle, NGINX Ingress Controller’ın ana odağı katman 7 (HTTP/S) trafiğini yönetmek, URL tabanlı yönlendirme yapmak ve SSL/TLS sonlandırmaktır. Temel kimlik doğrulama (basic auth) gibi sınırlı seçenekler sunsa da, modern kurumsal kimlik sağlayıcılarla (Identity Providers – IdP) derinlemesine entegrasyon veya bağlama duyarlı (context-aware) yetkilendirme politikaları uygulama yeteneği yoktur. Bu, genellikle başka araçlarla (örneğin, bir OAuth2 proxy veya API Gateway) ek güvenlik katmanları oluşturmayı gerektirir. Bu durum, mimariyi karmaşıklaştırabilir ve yönetim yükünü artırabilir.

Geleneksel çevre güvenliği (perimeter security) yaklaşımlarının, yani her şeyin güvenlik duvarının içinde güvenli olduğunu varsayan modelin yetersiz kalması, “Sıfır Güven” felsefesini ön plana çıkarmıştır. Sıfır Güven, ağın içinde veya dışında olmasından bağımsız olarak hiçbir kullanıcı veya cihazın varsayılan olarak güvenilmemesi gerektiğini savunur. Her erişim isteği, bağlamına göre (kullanıcı kimliği, cihaz durumu, ağ konumu vb.) doğrulanmalı ve yetkilendirilmelidir. NGINX Ingress, bu felsefeyi doğal olarak desteklememektedir. Uygulama katmanında detaylı yetkilendirme ve kimlik doğrulama işlemleri için ek bileşenlere ihtiyaç duyması, Sıfır Güven mimarisiyle tam uyumu zorlaştırmaktadır. Mikroservislerin ve dağıtık sistemlerin yaygınlaşmasıyla birlikte, her servis erişiminin ayrı ayrı güvenliğinin sağlanması kritik hale gelmiştir ve bu durum NGINX Ingress’in tek başına üstesinden gelebileceği bir görev değildir.

Bu eksiklikler, özellikle hassas verilerin işlendiği veya yüksek güvenlik gerektiren uygulamaların bulunduğu ortamlarda ciddi riskler oluşturabilir. Uygulamaların kimlik doğrulama mekanizmalarını kendi içlerinde yönetmesi veya her birinin farklı bir IdP ile entegre olması, tutarsız güvenlik politikalarına ve operasyonel karmaşıklığa yol açabilir. Bu noktada, Pomerium gibi Sıfır Güven odaklı bir erişim proxy’sine geçiş yapmak, hem güvenlik duruşunuzu güçlendirmenin hem de yönetim yükünü azaltmanın etkili bir yolunu sunar. Pomerium, kullanıcıların kimliklerini doğrulama, bağlama duyarlı politikalarla yetkilendirme ve tüm bu işlemleri merkezi bir noktadan yönetme yeteneği ile modern güvenlik ihtiyaçlarına kapsamlı bir yanıt verir.

Temel Kavramlar: Ingress NGINX ve Pomerium Ne Anlama Geliyor?

Her iki çözüm de Kubernetes kümesindeki servislere dışarıdan erişim sağlamak için kullanılsa da, temel yaklaşımları ve sundukları yetenekler açısından önemli farklılıklar barındırırlar. Bu bölümde, NGINX Ingress’in ne olduğunu ve nasıl çalıştığını hatırlayacak, ardından Pomerium’u detaylıca inceleyerek farklarını ortaya koyacağız.

Ingress NGINX Nedir ve Nasıl Çalışır?

Kubernetes’te Ingress, küme içindeki servislere dış dünyadan gelen HTTP ve HTTPS trafiğini yönetmek için kullanılan bir API nesnesidir. Bir Ingress Controller ise bu Ingress kurallarını uygulayan bir yazılımdır. NGINX Ingress Controller, Kubernetes Ingress nesnesini izleyerek gelen trafiği yapılandırılmış kurallara göre uygun servislere yönlendiren, popüler bir açık kaynaklı Ingress Controller’dır. Genellikle bir Kubernetes Service (LoadBalancer veya NodePort) arkasında çalışır ve şunları sağlar:

• URL Yönlendirme (Routing): Gelen istekleri URL yollarına veya ana bilgisayar adlarına göre farklı servislere yönlendirir. Örneğin, example.com/api adresini api-service‘e, example.com/app adresini app-service‘e yönlendirebilir.
• SSL/TLS Sonlandırma: Dışarıdan gelen şifreli (HTTPS) trafiği sonlandırır ve şifrelenmemiş (HTTP) trafiği küme içindeki servislere iletir. Bu, sertifika yönetimini merkezi bir noktadan yapmayı sağlar.
• Yük Dengeleme: Gelen trafiği birden fazla pod arasında dağıtarak servislerin yüksek erişilebilirliğini ve performansını artırır.
• Sanal Ana Bilgisayar (Virtual Host) Desteği: Aynı IP adresi üzerinden farklı alan adları için trafik yönetimi yapılmasına olanak tanır.

NGINX Ingress, esasen bir katman 7 (uygulama katmanı) ters proxy görevi görür. Güvenlik açısından ise, temel seviyede bazı özellikler sunar (örneğin, IP adresi kısıtlamaları veya basic auth), ancak modern kimlik doğrulama protokolleri (OAuth2, OIDC, SAML) ve bağlama duyarlı yetkilendirme için ek çözümlerle entegrasyon gerektirir. Bu durum, özellikle mikroservis tabanlı ve kullanıcı kimliği gerektiren uygulamalarda karmaşıklığa yol açabilir.

Pomerium Nedir ve Neden Farklıdır?

Pomerium, “Sıfır Güven” (Zero Trust) mimarisini temel alan, kimlik ve bağlama duyarlı bir erişim proxy’sidir. Geleneksel Ingress Controller’lardan farklı olarak, sadece trafiği yönlendirmekle kalmaz, aynı zamanda her erişim isteği için kapsamlı kimlik doğrulama (authentication) ve yetkilendirme (authorization) yapar. Pomerium, Kubernetes Ingress Controller’ı olarak da görev yapabilir, ancak esas gücü erişim yönetimindeki yeteneklerinde yatar. Temel bileşenleri şunlardır:

• Proxy: Gelen kullanıcı isteklerini alır, kimlik doğrulama ve yetkilendirme süreçlerinden geçirir ve onaylanan istekleri dahili servislere iletir.
• Authenticator: Kimlik sağlayıcınızla (Google Workspace, Azure AD, Okta, Auth0 vb.) etkileşime girerek kullanıcı kimliğini doğrular. OAuth2 ve OIDC gibi standart protokolleri destekler.
• Authorizer: Kullanıcının doğrulanan kimliğine, cihaz durumuna, ağ konumuna ve diğer bağlamsal faktörlere dayanarak erişim politikalarını değerlendirir ve erişime izin verilip verilmeyeceğine karar verir.
• Controller: Kubernetes içinde Pomerium Route ve Policy objelerini izler ve Pomerium’un diğer bileşenlerini dinamik olarak yapılandırır.

Pomerium, kimlik doğrulama ve yetkilendirmeyi ağın kenarına taşıyarak, uygulamaların kendi içlerinde bu yükü taşıma ihtiyacını ortadan kaldırır. Bu, geliştiricilerin güvenlik mekanizmaları yerine iş mantığına odaklanmasını sağlar. Ayrıca, her erişim isteğinin ayrı ayrı doğrulanması ve yetkilendirilmesi, içeriden gelebilecek tehditlere karşı da koruma sağlar. Pomerium’un esnek politika motoru sayesinde, karmaşık erişim kuralları tanımlanabilir; örneğin, sadece belirli bir IP aralığından, belirli bir güvenlik grubunun üyelerinin ve belirli bir coğrafi konumdan gelen kullanıcıların bir uygulamaya erişmesine izin verilebilir. Bu özellikleriyle Pomerium, sadece bir Ingress Controller olmanın ötesinde, modern uygulamalar için kapsamlı bir Sıfır Güven erişim yönetim platformu sunar.

Neden NGINX Ingress’ten Pomerium’a Geçiş Yapmalıyız?

NGINX Ingress, Kubernetes ortamlarında trafik yönlendirme ve SSL sonlandırma gibi temel Ingress ihtiyaçlarını başarıyla karşılasa da, modern güvenlik talepleri ve “Sıfır Güven” mimarisi yaklaşımları, daha gelişmiş çözümleri zorunlu kılmaktadır. Pomerium’a geçiş yapmak, organizasyonlara sadece güvenlik açısından değil, aynı zamanda operasyonel verimlilik ve yönetim kolaylığı açısından da önemli avantajlar sunar.

1. Sıfır Güven (Zero Trust) Mimarisine Uyum: Geleneksel güvenlik modelleri, ağ sınırları içindeki her şeyi varsayılan olarak güvenli kabul ederken, Sıfır Güven “asla güvenme, her zaman doğrula” prensibine dayanır. Pomerium, her erişim isteği için kullanıcı kimliğini, cihaz durumunu, ağ konumunu ve diğer bağlamsal faktörleri kullanarak sürekli doğrulama ve yetkilendirme yapar. Bu, içeriden veya dışarıdan gelebilecek tehditlere karşı çok daha güçlü bir savunma mekanizması sunar. NGINX Ingress tek başına bu seviyede bir Sıfır Güven uygulaması sağlayamazken, Pomerium bunu temel işlevselliği olarak sunar.

2. Merkezi Kimlik Doğrulama ve Yetkilendirme: Farklı uygulamaların kendi kimlik doğrulama mekanizmalarını veya farklı IdP’leri kullanması, hem geliştiriciler için ek yük oluşturur hem de güvenlik politikalarının tutarlılığını zorlaştırır. Pomerium, Google Workspace, Azure AD, Okta, Auth0 ve diğer OIDC/SAML uyumlu kimlik sağlayıcılarla tek bir noktadan entegrasyon sağlar. Bu sayede, tüm uygulamalarınız için merkezi bir kimlik doğrulama ve yetkilendirme katmanı oluşturabilir, kullanıcıların tek oturum açma (Single Sign-On – SSO) deneyimi yaşamasını sağlayabilirsiniz. Bu, yönetim karmaşıklığını önemli ölçüde azaltır ve güvenlik denetimini kolaylaştırır.

3. Gelişmiş Erişim Kontrol Politikaları (Context-Aware Access): Pomerium’un en güçlü yönlerinden biri, son derece esnek ve bağlama duyarlı erişim politikaları tanımlayabilmesidir. Yalnızca kullanıcı kimliğine değil, aynı zamanda aşağıdaki gibi faktörlere dayalı politikalar oluşturabilirsiniz:

• Grup Üyeliği: Yalnızca belirli bir LDAP veya IdP grubuna ait kullanıcıların erişimine izin verme.
• IP Adresi Kısıtlamaları: Yalnızca belirli bir IP aralığından gelen istekleri kabul etme.
• Cihaz Durumu: Kurumsal envanterdeki yönetilen cihazlardan veya belirli güvenlik gereksinimlerini karşılayan cihazlardan gelen erişime öncelik verme.
• Coğrafi Konum: Yalnızca belirli bir coğrafi bölgeden gelen erişime izin verme veya engelleme.
• Zaman Kısıtlamaları: Uygulamalara yalnızca belirli çalışma saatleri içinde erişilmesini sağlama.

Bu yetenekler, NGINX Ingress’in sunduğu temel yönlendirme ve TLS işlevselliğinin çok ötesindedir ve uygulamanızın hassasiyetine göre ince taneli erişim kontrolü sağlamanıza olanak tanır.

4. Mikroservis Güvenliği ve API Güvenliği: Mikroservis mimarilerinde her servis bağımsız bir şekilde dağıtılır ve genellikle diğer servislerle API’ler aracılığıyla iletişim kurar. Pomerium, bu dahili veya harici API çağrıları için de yetkilendirme katmanı sağlayabilir. Her API isteğinin kimlik doğrulamasını ve yetkilendirmesini yaparak, servisler arası iletişimin güvenliğini artırır. Bu, özellikle hassas verileri işleyen veya iş kritik operasyonları gerçekleştiren API’ler için hayati öneme sahiptir.

5. Operasyonel Basitleştirme ve Gelişmiş Güvenlik Duruşu: Pomerium’a geçiş, güvenlik politikalarını merkezi bir noktadan yöneterek operasyonel yükü azaltır. Geliştiricilerin her uygulamada kimlik doğrulama ve yetkilendirme kodu yazma ihtiyacını ortadan kaldırır. Bu sayede, güvenlik politikalarının tutarlılığı sağlanırken, yeni uygulamaların devreye alınması da hızlanır. Kurumsal bir şirket düşünün; farklı departmanların farklı uygulamaları var ve her birine dışarıdan güvenli erişim gerekiyor. NGINX Ingress ile her uygulama için ayrı bir kimlik doğrulama çözümü veya karmaşık ağ yapılandırmaları gerekebilir. Pomerium ile tüm bu uygulamalar tek bir merkezi erişim kontrol katmanının arkasına alınabilir, IdP entegrasyonu tek yerden yapılır ve her uygulama için özelleştirilmiş erişim politikaları kolayca tanımlanabilir. Bu, hem IT ekibinin yükünü azaltır hem de genel güvenlik duruşunu önemli ölçüde iyileştirir.

Özetle, NGINX Ingress hala birçok senaryo için uygun bir çözüm olsa da, özellikle modern bulut yerel ortamların ve Sıfır Güven prensiplerinin gerektirdiği gelişmiş kimlik doğrulama, yetkilendirme ve bağlama duyarlı erişim kontrolü yetenekleri için Pomerium çok daha kapsamlı ve güçlü bir alternatif sunar. Bu geçiş, uzun vadede daha güvenli, yönetilebilir ve esnek bir altyapı oluşturmanıza olanak tanır.

Pomerium Kurulumu ve Temel Konfigürasyon Adımları Nelerdir?

Pomerium’u Kubernetes kümenize kurmak ve temel bir kimlik sağlayıcı (IdP) ile entegre etmek, birkaç adımda gerçekleştirilebilir. Bu bölümde, Helm kullanarak Pomerium’un nasıl kurulacağını ve bir IdP ile nasıl yapılandırılacağını ele alacağız. Başlamadan önce, bazı önkoşulların yerine getirilmiş olması gerekmektedir:

• Çalışır durumda bir Kubernetes kümesi (versiyon 1.16 veya üzeri).
• Kümenize trafik yönlendirmek için bir DNS kaydı (örn: app.example.com ve auth.example.com).
• Pomerium’un kullanacağı bir TLS sertifikası (Let’s Encrypt ile otomatik veya mevcut bir sertifika).
• Seçtiğiniz bir Kimlik Sağlayıcı (Google Workspace, Azure AD, Okta vb.) ve bu IdP üzerinde Pomerium için bir OAuth2/OIDC uygulama kaydı oluşturulmuş olması. Bu kayıttan client_id ve client_secret bilgileri alınacaktır.

1. Helm ile Pomerium Repositories’i Ekleme

Pomerium, Helm grafikleri aracılığıyla kolayca dağıtılabilir. İlk olarak, Pomerium Helm deposunu yerel Helm kurulumunuza ekleyin:

helm repo add pomerium https://helm.pomerium.com
helm repo update

2. Kimlik Sağlayıcı (IdP) Yapılandırması

Kuruluma geçmeden önce, IdP'nizde Pomerium için bir uygulama (client) kaydı oluşturmanız gerekmektedir. Örnek olarak Google Workspace (Google Identity Platform) kullanalım:

1. Google Cloud Console'a gidin.
2. "APIs & Services" -> "Credentials" yolunu izleyin.
3. "Create Credentials" -> "OAuth client ID" seçeneğini tıklayın.
4. Uygulama türü olarak "Web application" seçin.
5. "Authorized redirect URIs" alanına Pomerium Authenticator'ınızın geri dönüş adresini ekleyin. Bu genellikle https://auth.example.com/oauth2/callback formatında olacaktır (buradaki auth.example.com kendi alan adınızla değiştirilmelidir).
6. Oluşturulan client'ın client ID ve client secret değerlerini kaydedin. Bunlar Pomerium yapılandırmasında kullanılacaktır.

3. Pomerium Temel Yapılandırma Dosyası Oluşturma (values.yaml)

Pomerium'u Helm ile kurarken, varsayılan yapılandırmaları değiştirmek için bir values.yaml dosyası oluşturmanız gerekecektir. Bu dosya, IdP bilgilerini, anahtar ve alan adlarını içerecektir. Aşağıdaki örnek, temel bir Google IdP entegrasyonu için values.yaml dosyasını göstermektedir. Kendi değerlerinizle güncellemeyi unutmayın.

# values.yaml
# Pomerium anahtar kelimesi için bir sır oluşturulacak. Güvenli bir anahtar kullanın.
# openssl rand -base64 32 komutu ile oluşturabilirsiniz.
sharedSecret: "buraya_güvenli_bir_paylaşılan_anahtar_ekle" 
# Pomerium Cookie şifreleme anahtarı. openssl rand -base64 32 komutu ile oluşturabilirsiniz.
cookieSecret: "buraya_güvenli_bir_çerez_şifreleme_anahtarı_ekle"

# Kubernetes Ingress yapılandırması
ingress:
  enabled: true
  annotations:
    kubernetes.io/ingress.class: "nginx" # Eğer NGINX Ingress kullanıyorsanız
  host: app.example.com # Uygulamalarınızın erişileceği ana alan adı

authenticate:
  url: https://auth.example.com # Authenticator servisinizin URL'i
  idp:
    provider: google
    clientID: "GOOGLE_CLIENT_ID_BURAYA" # IdP'den aldığınız Client ID
    clientSecret: "GOOGLE_CLIENT_SECRET_BURAYA" # IdP'den aldığınız Client Secret
    # Google'a özgü scopelar
    scopes:
      - "openid"
      - "profile"
      - "email"
      - "https://www.googleapis.com/auth/cloud-platform.read-only" # Örnek: GCP erişimi

# TLS sertifikası yönetimi (Cert-manager ile otomatik)
certmanager:
  enabled: true
  issuerName: "letsencrypt-prod" # Cert-manager ile kullandığınız Issuer adı
  issuerKind: "ClusterIssuer"

# Proxy ayarları
proxy:
  env:
    # Google IdP için ek ayar, eğer kullanılmıyorsa silinebilir
    GOOGLE_SERVICE_ACCOUNT: |
      {
        "type": "service_account",
        "project_id": "your-gcp-project-id",
        ...
        "private_key": "-----BEGIN PRIVATE KEY-----...-----END PRIVATE KEY-----\n"
      }

4. Pomerium'u Helm ile Kurma

values.yaml dosyanızı hazırladıktan sonra, Pomerium'u Kubernetes kümenize yükleyebilirsiniz:

helm upgrade --install pomerium pomerium/pomerium --namespace pomerium --create-namespace -f values.yaml

Bu komut, pomerium adında bir namespace oluşturacak ve tüm Pomerium bileşenlerini bu namespace içine dağıtacaktır. Kurulum tamamlandıktan sonra, kubectl get pods -n pomerium komutu ile pod'ların durumunu kontrol edebilirsiniz. Tüm pod'lar "Running" durumunda olmalıdır.

5. DNS ve TLS Ayarları

Pomerium'un doğru çalışabilmesi için DNS kayıtlarınızın Pomerium Proxy ve Authenticator servislerini işaret etmesi gerekmektedir. Eğer LoadBalancer tipinde bir servis kullanıyorsanız, LoadBalancer'ın dış IP adresini DNS A kaydınızda belirtmelisiniz:

• app.example.com -> LoadBalancer IP
• auth.example.com -> LoadBalancer IP

TLS sertifikası için Cert-manager kullanıyorsanız, yukarıdaki values.yaml dosyasında yapılandırdığınız certmanager ayarları sayesinde otomatik olarak sertifikalarınız oluşturulacak ve yönetilecektir. Eğer manuel sertifika kullanıyorsanız, bunları Kubernetes Secret olarak yükleyip Pomerium yapılandırmasında belirtmeniz gerekecektir.

Bu adımlarla, temel bir Pomerium kurulumunu tamamlamış olursunuz. Artık Pomerium'un arkasına uygulamalarınızı ekleyebilir ve gelişmiş erişim politikalarını uygulamaya başlayabilirsiniz. Bir sonraki bölümde, mevcut NGINX Ingress yapılandırmalarından Pomerium'a nasıl geçiş yapacağınızı inceleyeceğiz.

NGINX Ingress'ten Pomerium'a Uygulama Geçişi Nasıl Yapılır?

Mevcut uygulamalarınızı NGINX Ingress Controller'dan Pomerium'a taşımak, uygulamanızın dış dünyaya açılan erişim noktasını değiştirmek ve gelişmiş güvenlik politikaları eklemek anlamına gelir. Bu süreç, genellikle mevcut NGINX Ingress yapılandırmalarını analiz ederek başlar ve Pomerium'un özel kaynak tanımlamaları (Custom Resource Definitions - CRD) olan PomeriumRoute ve PomeriumPolicy nesnelerini kullanarak tamamlanır.

1. Mevcut NGINX Ingress Yapılandırmalarını İnceleme

Geçişe başlamadan önce, mevcut NGINX Ingress kaynaklarınızı anlamak kritik öneme sahiptir. Hangi alan adları kullanılıyor, hangi URL yolları hangi servislere yönlendiriliyor, TLS sertifikaları nasıl yönetiliyor ve varsa temel kimlik doğrulama ayarları nelerdir? Örnek bir NGINX Ingress kaynağı şu şekilde görünebilir:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/auth-url: "http://auth-service.default.svc.cluster.local/auth" # Varsayılan NGINX auth
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-service
            port:
              number: 80
  tls:
  - hosts:
    - myapp.example.com
    secretName: my-app-tls-secret

Bu örnekte, myapp.example.com adresine gelen tüm istekler my-app-service'e yönlendiriliyor ve my-app-tls-secret ile TLS sonlandırması yapılıyor. Ayrıca, harici bir auth-service ile kimlik doğrulama denemesi olduğu varsayılıyor. Pomerium'a geçerken, bu bilgileri eşleştirmemiz gerekecek.

2. Pomerium Rotası (Route) Tanımlama

Pomerium, dışarıdan gelen trafiği yönetmek için PomeriumRoute adlı özel bir kaynak kullanır. Bu rota tanımı, NGINX Ingress'in yaptığı gibi trafiği bir servise yönlendirmenin yanı sıra, erişim için hangi PomeriumPolicy'nin uygulanacağını da belirtir. Bir PomeriumRoute'u tanımlarken aşağıdaki temel alanlara dikkat etmeliyiz:

• from: Bu rotanın dinleyeceği dışarıdan gelen URL (alan adı).
• to: İsteğin yönlendirileceği dahili servis URL'i (genellikle http://[service-name].[namespace].svc.cluster.local formatında).
• policy: Bu rota için uygulanacak PomeriumPolicy'nin adları. Birden fazla politika da atanabilir.

Şimdi, yukarıdaki NGINX Ingress örneğimizdeki myapp.example.com uygulamasını Pomerium'a taşıyalım. Önce bir PomeriumPolicy oluşturalım. Bu politika, kullanıcıların kimlik sağlayıcınızda (IdP) geçerli bir oturum açmış olmasını ve belirli bir e-posta alan adına (örn: @example.com) sahip olmasını gerektirecektir:

apiVersion: getpomerium.com/v1
kind: PomeriumPolicy
metadata:
  name: my-app-access-policy
  namespace: pomerium
spec:
  # Kullanıcıların IdP'de kimlik doğrulaması yapması gerekiyor.
  authenticate: true
  # Sadece belirli bir e-posta alan adına sahip kullanıcılar erişebilir.
  allowedDomains:
    - example.com
  # Veya belirli bir e-posta adresine sahip kullanıcılar
  # allowedEmails:
  #   - user@example.com
  # Veya belirli bir IdP grubuna ait kullanıcılar
  # allowedGroups:
  #   - admins@example.com
  # Kaynağa doğrudan erişim sağlar (doğrulama sonrası).
  allowUnauthenticated: false

Ardından, bu politikayı kullanan bir PomeriumRoute tanımlayalım:

apiVersion: getpomerium.com/v1
kind: PomeriumRoute
metadata:
  name: my-app-route
  namespace: pomerium
spec:
  from: https://myapp.example.com # Dışarıdan erişim URL'i
  to: http://my-app-service.default.svc.cluster.local # Dahili servis URL'i
  policy: # Uygulanacak PomeriumPolicy'nin adı
    - my-app-access-policy
  # TLS sertifikası yönetimi (Cert-manager ile otomatik)
  tls:
    generate: true # Otomatik olarak sertifika oluştur
    issuer:
      name: letsencrypt-prod
      kind: ClusterIssuer
  # Eğer path tabanlı yönlendirme gerekiyorsa
  # pathPrefix: /
  # prefixRewrite: / # NGINX rewrite-target'a karşılık gelir

Bu PomeriumRoute ve PomeriumPolicy kaynaklarını Kubernetes kümenize uygulayın:

kubectl apply -f my-app-policy.yaml
kubectl apply -f my-app-route.yaml

Pomerium Controller, bu kaynakları algılayacak ve Pomerium Proxy'sini buna göre yapılandıracaktır. Artık myapp.example.com adresine yapılan istekler önce Pomerium tarafından yakalanacak, kullanıcı kimliği doğrulanacak, my-app-access-policy politikası uygulanacak ve erişime izin verilirse my-app-service'e yönlendirilecektir. TLS sonlandırması da generate: true sayesinde otomatik olarak Pomerium tarafından yönetilecektir.

3. Test ve Doğrulama Adımları

Geçiş yaptıktan sonra uygulamanın doğru çalıştığından emin olmak için kapsamlı testler yapmanız önemlidir:

1. DNS Doğrulaması: myapp.example.com adresinin Pomerium'un LoadBalancer IP adresine işaret ettiğinden emin olun.
2. Tarayıcı Erişimi: Bir tarayıcıdan https://myapp.example.com adresine gidin. Pomerium sizi otomatik olarak IdP'nize yönlendirmeli ve kimlik doğrulama ekranını göstermelidir.
3. Kimlik Doğrulama: IdP'niz ile oturum açın. Başarılı bir oturum açmanın ardından, uygulamanıza erişebilmeniz gerekir.
4. Yetkilendirme Testi: Tanımladığınız politikalara (örn: allowedDomains) uymayan bir kullanıcıyla oturum açmayı deneyin. Erişimin reddedilmesi ve Pomerium'un hata sayfasını göstermesi beklenir.
5. Log Kontrolü: Pomerium pod'larının loglarını kontrol ederek (kubectl logs -f -n pomerium pomerium-proxy-xxx ve pomerium-authenticate-xxx) erişim isteklerinin nasıl işlendiğini ve herhangi bir hata olup olmadığını gözlemleyin.

Bu adımları takip ederek, NGINX Ingress üzerindeki uygulamalarınızı Pomerium'a başarıyla taşıyabilir ve Sıfır Güven prensiplerine uygun gelişmiş erişim kontrolü sağlayabilirsiniz. Tüm uygulamalarınızı tek seferde taşımak yerine, küçük bir pilot uygulama ile başlayarak süreci anlamak ve olası sorunları çözmek iyi bir stratejidir.

İleri Düzey Kullanım Senaryoları ve En İyi Uygulamalar Nelerdir?

Pomerium, temel kimlik doğrulama ve yetkilendirme özelliklerinin ötesinde, modern ve karmaşık bulut yerel ortamlar için tasarlanmış bir dizi ileri düzey yetenek sunar. Bu bölümde, Pomerium'un potansiyelini tam olarak kullanmanızı sağlayacak bazı senaryoları ve en iyi uygulamaları ele alacağız.

1. Birden Fazla Kimlik Sağlayıcı (IdP) ile Entegrasyon

Büyük kuruluşlar veya birleşme-satın alma sonrası durumlar gibi senaryolarda, birden fazla kimlik sağlayıcıya sahip olmak yaygın bir durumdur. Pomerium, tek bir Pomerium dağıtımı altında birden fazla IdP ile entegre olabilir. Bu, farklı kullanıcı gruplarının (örneğin, çalışanlar Google Workspace kullanırken, dış ortaklar Azure AD kullanıyor olabilir) kendi tercih ettikleri IdP aracılığıyla uygulamalara erişmesini sağlar. Pomerium yapılandırmasında, birden fazla authenticate.idp bloğu tanımlayarak bu entegrasyonu gerçekleştirebilirsiniz. Kullanıcılar, erişmek istediklerinde hangi IdP ile oturum açacaklarını seçebilirler.

authenticate:
  url: https://auth.example.com
  idp:
    - provider: google
      id: google-idp
      clientID: "GOOGLE_CLIENT_ID"
      clientSecret: "GOOGLE_CLIENT_SECRET"
      scopes: ["openid", "profile", "email"]
    - provider: azure
      id: azure-idp
      clientID: "AZURE_CLIENT_ID"
      clientSecret: "AZURE_CLIENT_SECRET"
      tenantID: "AZURE_TENANT_ID"
      scopes: ["openid", "profile", "email"]

2. Gelişmiş Erişim Politikaları (Context-Aware Access)

Pomerium'un gücü, basit grup üyeliği veya e-posta alanı kontrollerinin ötesine geçen bağlama duyarlı politikalar tanımlama yeteneğidir. Aşağıdaki gibi daha karmaşık senaryoları destekleyebilirsiniz:

• IP Bazlı Kısıtlamalar: Yalnızca belirli bir IP adresinden veya CIDR bloğundan gelen isteklere izin verme. Bu, özellikle iç ağdan erişilmesi gereken uygulamalar için kullanışlıdır.
• Cihaz Durumu Doğrulaması: Pomerium, entegre edildiği mobil cihaz yönetimi (MDM) çözümleri veya cihaz sertifikaları aracılığıyla cihazın güvenli olup olmadığını kontrol edebilir. Örneğin, yalnızca MDM tarafından yönetilen, şifrelenmiş diske sahip cihazların belirli bir uygulamaya erişmesine izin verilebilir.
• Zaman Bazlı Erişim: Bir uygulamanın yalnızca belirli mesai saatleri içinde erişilebilir olmasını sağlayabilirsiniz.
• Birden Fazla Politika Zincirleme: Bir PomeriumRoute'a birden fazla PomeriumPolicy atayarak, "VE" (AND) veya "VEYA" (OR) mantığıyla daha karmaşık kurallar oluşturabilirsiniz. Örneğin, "admin grubunda OLAN VE şirket VPN'inden gelen" kullanıcıların erişimine izin verme.

apiVersion: getpomerium.com/v1
kind: PomeriumPolicy
metadata:
  name: critical-app-policy
  namespace: pomerium
spec:
  authenticate: true
  allowedGroups: # Sadece admin grubundakiler
    - "admin-group@example.com"
  allowedIpRanges: # Sadece şirket VPN IP'lerinden
    - "192.168.1.0/24"
  # allowedDeviceContext:
  #   - "managed-device-id" # Cihaz yönetimi entegrasyonu ile

3. API Ağ Geçidi (API Gateway) Entegrasyonu

Pomerium, bir API Gateway'in önüne yerleştirilerek veya API Gateway ile birlikte kullanılarak API'leriniz için ek bir güvenlik katmanı sağlayabilir. Pomerium, kullanıcı ve servis kimlik doğrulaması yaparken, API Gateway ise trafik yönetimini, istek/yanıt manipülasyonunu ve rate limiting gibi API özelindeki işlevleri yerine getirebilir. Bu kombinasyon, API'lerinize hem güçlü bir Sıfır Güven erişim kontrolü hem de gelişmiş trafik yönetimi sağlar.

4. Pomerium CLI ve Hata Ayıklama

Pomerium CLI, yapılandırma dosyalarını doğrulamak, erişim politikalarını test etmek ve genel Pomerium dağıtımınızla etkileşim kurmak için güçlü bir araçtır. Özellikle politika değerlendirmelerini yerel olarak test etmek, hataları erken aşamada yakalamanıza yardımcı olur. Pomerium logları (proxy ve authenticate pod'larından), erişim reddi nedenlerini veya kimlik doğrulama akışındaki sorunları anlamak için hayati öneme sahiptir.

# Pomerium CLI ile bir politikayı test etme (örnek)
pomeriumctl policy test --email user@example.com --ip 192.168.1.10 critical-app-policy.yaml

Vaka Analizi: Büyük Bir E-ticaret Platformunun İç API'lerini Güvenli Hale Getirmesi

Büyük bir e-ticaret platformu, yüzlerce mikroservis ve onlarca dahili API kullanmaktadır. Bu API'lerin bir kısmı hassas müşteri verilerine erişirken, diğerleri envanter yönetimi veya sipariş işleme gibi kritik işlevleri yerine getirmektedir. Geleneksel olarak, bu API'lere erişim VPN veya IP beyaz listeleri aracılığıyla sağlanmaktaydı. Ancak bu yöntemler, uzaktan çalışan sayısının artmasıyla yönetim zorlukları yaratmış ve Sıfır Güven prensiplerine uymamıştır.

Platform, Pomerium'u iç API'lerinin önüne bir erişim proxy'si olarak dağıtmıştır. Her API için ayrı bir PomeriumRoute tanımlanmış ve kullanıcı rollerine, departmanlarına ve hatta API'nin hassasiyetine göre özelleştirilmiş PomeriumPolicy'ler oluşturulmuştur. Örneğin:

• Müşteri Destek API'leri: Yalnızca "Müşteri Destek" IdP grubunun üyelerinin erişimine açık ve sadece şirket ağından veya onaylı cihazlardan.
• Finansal Raporlama API'leri: Yalnızca "Finans" IdP grubunun üyelerinin erişimine açık, çok faktörlü kimlik doğrulama gerektiren ve hafta içi 09:00-17:00 saatleri arasında erişilebilen.
• Envanter Güncelleme API'leri: Hem bir kullanıcının kimliğini doğrulayan hem de bir servis hesabının API anahtarıyla yetkilendirilmesini gerektiren hibrit politikalar.

Bu geçiş sayesinde, e-ticaret platformu VPN bağımlılığını azaltmış, API'lerin güvenlik duruşunu önemli ölçüde güçlendirmiş ve merkezi bir erişim yönetim paneli aracılığıyla politikalarını kolayca yönetebilir hale gelmiştir. Geliştiriciler, her API için kimlik doğrulama ve yetkilendirme kodu yazma yükünden kurtularak iş mantığına odaklanabilmişlerdir. Bu vaka analizi, Pomerium'un sadece basit bir Ingress Controller değil, aynı zamanda kapsamlı bir Sıfır Güven erişim yönetim platformu olarak nasıl konumlandırılabileceğini açıkça göstermektedir.

Pomerium ile Güvenli Geleceğe Adım Atın: Sonuç ve Sıkça Sorulan Sorular

Bu makalede, Kubernetes ortamlarında NGINX Ingress Controller'dan Pomerium'a geçişin nedenlerini, kurulum adımlarını ve ileri düzey kullanım senaryolarını detaylıca ele aldık. Gördüğümüz gibi, NGINX Ingress temel trafik yönlendirme ve SSL sonlandırma görevleri için hala güçlü bir araç olsa da, modern güvenlik tehditleri ve Sıfır Güven mimarisi prensipleri, Pomerium gibi gelişmiş bir erişim kontrol çözümünü zorunlu kılmaktadır.

Pomerium'a geçiş yaparak, uygulamalarınız için merkezi bir kimlik doğrulama ve bağlama duyarlı yetkilendirme katmanı oluşturursunuz. Bu sayede, geliştiricilerin güvenlik mekanizmalarını kendi içlerinde yönetme yükünü hafifletir, tutarlı güvenlik politikaları uygulayabilir ve hassas uygulamalarınızın ve API'lerinizin güvenliğini önemli ölçüde artırırsınız. Birden fazla IdP entegrasyonu, ince taneli erişim politikaları ve operasyonel basitleştirme gibi yetenekleriyle Pomerium, şirketlerin bulut yerel ortamlarında daha sağlam ve yönetilebilir bir güvenlik duruşu sergilemelerine olanak tanır.

Sıfır Güvenin "asla güvenme, her zaman doğrula" felsefesi, günümüzün dağıtık ve dinamik altyapıları için vazgeçilmezdir. Pomerium, bu felsefeyi Kubernetes ortamınıza taşıyarak, sadece dış tehditlere karşı değil, aynı zamanda içeriden gelebilecek risklere karşı da kapsamlı bir koruma sağlar. NGINX Ingress'ten Pomerium'a geçiş, sadece bir teknoloji değişimi değil, aynı zamanda güvenlik mimarinizi geleceğe hazırlayan stratejik bir adımdır.

Sıkça Sorulan Sorular (SSS)

1. Pomerium ücretli mi?

Pomerium, Apache 2.0 lisansı altında açık kaynaklı bir yazılımdır ve temel işlevselliği ücretsiz olarak kullanılabilir. Ayrıca, kurumsal düzeyde destek ve ek özellikler sunan ücretli versiyonları da mevcuttur.

2. Pomerium mevcut NGINX Ingress ile birlikte çalışabilir mi?

Evet, Pomerium ve NGINX Ingress Controller aynı Kubernetes kümesinde birlikte çalışabilirler. Farklı Ingress Class'ları kullanarak hangi Ingress Controller'ın hangi Ingress veya PomeriumRoute nesnesini yönettiğini belirtebilirsiniz. Bu, aşamalı bir geçiş yapmanıza veya bazı uygulamalar için NGINX'i, diğerleri için Pomerium'u kullanmanıza olanak tanır.

3. Pomerium performans overhead'ine neden olur mu?

Pomerium, her istek için kimlik doğrulama ve yetkilendirme yaptığı için doğal olarak NGINX Ingress'e göre biraz daha fazla işlem yükü getirebilir. Ancak Pomerium yüksek performanslı bir Go uygulamasıdır ve iyi optimize edilmiştir. Performans, kullanılan IdP'nin yanıt süresine, politika karmaşıklığına ve ağ gecikmesine bağlı olacaktır. Çoğu senaryoda, güvenlik ve yönetim avantajları bu hafif performans düşüşünden daha ağır basar.

4. Hangi Kimlik Sağlayıcıları (IdP) destekler?

Pomerium, OAuth2 ve OIDC (OpenID Connect) standartlarını destekleyen çoğu IdP ile entegre olabilir. Başlıca desteklenen IdP'ler arasında Google Workspace (Google Identity Platform), Azure Active Directory, Okta, Auth0, OneLogin ve GitHub gibi popüler çözümler bulunmaktadır.

5. Pomerium küçük projeler veya geliştirme ortamları için uygun mu?

Kesinlikle. Pomerium'un açık kaynaklı doğası ve Helm ile kolay kurulumu, onu küçük projeler ve geliştirme ortamları için de uygun bir seçenek haline getirir. Geliştirme aşamasında bile uygulamalarınıza Sıfır Güven prensiplerini entegre etmek, güvenlik kültürünüzü erken aşamada oluşturmanıza yardımcı olur. Karmaşık politikalar yerine basit e-posta alan adı kısıtlamalarıyla başlayabilir ve ihtiyacınıza göre genişletebilirsiniz.