DEV Community: Yunus Emre Dere

NeuVector - Rke2: Kubernetes İçin Derinlemesine Güvenlik

Yunus Emre Dere — Thu, 04 Dec 2025 11:25:13 +0000

Standart Kubernetes ağ politikaları (Network Policies) ve klasik güvenlik duvarları, podlar arasındaki trafiği (East-West) analiz etmede yetersiz kalır. Bu araçlar genellikle IP ve Port seviyesinde (Layer 3/4) çalışır, ancak uygulama katmanındaki (Layer 7) tehditleri göremezler.

Bu yazıda, RKE2 üzerinde koşan iş yüklerimizi korumak için neden NeuVector tercih ettiğimizi, teknik mimarisini ve diğer çözümlerden farkını inceleyeceğiz.

NeuVector, patentli Derin Paket İnceleme (DPI) teknolojisi ile konteyner trafiğini gerçek zamanlı analiz eder ve Zero-Trust prensibini cluster içine kadar indirger.

Detaylar ve Temel Özellikler

1. Canlı Ağ Güvenliği (Runtime Security)

Genellikle güvenlik araçları imajlardaki açıkları tarar. NeuVector ise çalışma zamanında podlar arası trafiği izler.

Deep Packet Inspection (DPI): Pod'lar birbirleriyle konuşurken paketlerin içine bakar. Bir SQL Injection veya şüpheli bir DNS sorgusu görürse, ağ seviyesinde bunu engelleyebilir.
East-West Trafiği: Klasik firewall'lar sadece dışarıdan gelen (North-South) trafiği görür. NeuVector ise cluster içindeki (East-West) trafiği görür ve yönetir.

2. Zero-Trust ve Davranışsal Öğrenme

NeuVector kurulduğu andan itibaren hemen trafiği izlemeye başlar ve normal davranışları öğrenir.

Discover: Uygulamanın kimle konuştuğunu öğrenir ve otomatik kurallar oluşturur.
Monitor: Normalin dışına çıkıldığında, yani bir pod normalde hiç iletişime geçmediği bir podla iletişime geçerse sadece alarm verir.
Protect: Normal dışı her türlü hareketi bloklar. Yani saldırgan içeri girse bile ağda hareket edemez.

3. Zafiyet ve Uyumluluk Taraması

Konteynır imajlarını hem registry'de hem de çalışırken tarar.
CIS Benchmark (Kubernetes güvenlik standartları) testlerini otomatik yapar ve raporlar.

Olumsuz Yanları

Yüksek Kaynak Tüketimi

Ağ trafiğini analiz etmek için her Kubernetes Node'una bir "Enforcer" podu kurar.

Sorun: Bu Enforcer'lar, geçen her veri paketini açıp (Layer 7 inceleme) içine baktığı için ciddi miktarda CPU ve Bellek tüketebilir.

Ağ Gecikmesi (Latency)

Sorun: Aşırı düşük gecikme gerektiren gerçek zamanlı uygulamalarda performans olumsuz etkilenebilir.

`Protect` Moduna Geçiş Riski

NeuVector'un en güçlü yanı en riskli yanı olabilir.

Sorun: Sistem öğrenme modundayken görmediği nadir bir trafiği, koruma moduna geçtiğinde tehdit sanıp engelleyebilir. Bu yüzden Protect modunda kullanmaktansa Alarm modunda kullanmak daha tercih edilebilir bir seçimdir.

Karmaşık Yönetim ve Öğrenme Eğrisi

Basit bir antivirus gibi "kur ve unut" türü bir yazılım değildir.
Detayları ve kuralları anlamlandırmak zor olabilir.

İlk Kurulumda Kargaşa

Sorun: Kubernetes ortamları çok gürültülüdür (Health checkler, DNS sorguları, metrik toplayıcılar vb.). Bu sebeple çok fazla sayıda anlamsız kural oluşabilir ve bunları temizlemek zaman alabilir.

Ne Zaman Kullanılmalı?

Eğer blog sitesi gibi basit bir sistem ise kaynakları boşa harcamak olur. Ama finans, bankacılık veya hassas verilerin olduğu, "Zero Trust" bir mimaride NeuVector vazgeçilmezdir.

Mimari ve Kavramlar

5 temel kavramı vardır.

1. Üç Temel Bileşen

NeuVector kurulduğunda Cluster içinde birkaç farklı pod görülür:

Controller (Beyin): Kuralları yönetir, kararları verir. Genelde 3 kopya çalışır.
Manager (Yüz): Web Arayüzünü (UI) sağlayan servistir.
Enforcer (Kas): En kritiği budur. Her bir node üzerinde bir ajan gibi (DaemonSet olarak) çalışır. Trafiği kesen veya izin veren, paketin içine bakan parça budur.
Scanner (Göz): İmajları tarayıp güvenlik açığı (CVE) bulan parçadır.

2. Altın Kural: "Önce Öğren, Sonra Koru"

Doğru akış şu şekildedir:

Discover: Sistemi en az 1-2 hafta bu modda bırakmak gerekir. NeuVector normal trafiğin ne olduğunu, hangi servisin kiminle konuştuğunu öğrensin.
Monitor: Kurallar oturduktan sonra bu moda geçilmelidir. Artık yeni veya bilinmeyen bir trafik gelirse engellemez ama Alarm verir.
Protect: Sadece %100 emin olunan servislerde bu moda geçilmelidir.

3. SUSE ve Açık Kaynak Durumu

SUSE firmasının ürünü satın alması ile tamamen açık kaynak oldu. Eski enterprise özelliklerinin çoğu artık bedava. DockerHub veya GitHub üzerinden imajlar ücretsiz olarak çekilebilir.

4. Kurallar Kod Olarak Dışarı Alınabilir (Security As Code)

Mesela NeuVector Development ortamında trafiği öğrendi. Bu kuralları YAML dosyası olarak Export edebilirsiniz. Daha sonrasında Production ortamında uygulayarak öğrenme süresi kısılabilir. Bu, DevOps süreçleri için harika bir özelliktir.

5. Helm İle Kurulum

Resmi Helm Chartı vardır ve kurulumu standarttır.

Diğer Firewall'lar ile Karşılaştırma

Özellik	NeuVector	Cilium (Hubble)	Calico	Istio (Service Mesh)
Temel Teknoloji	Özel DPI Motoru	eBPF (Linux Kernel)	Iptables / eBPF	Envoy Proxy (Sidecar)
En Güçlü Yanı	DPI (Derin Paket İnceleme)	Yüksek Performans & Ölçek	Standart ve Kararlı	Trafik Yönetimi & mTLS
OSI Katmanı	Katman 7 (Uygulama)	Katman 3-4 (ve kısmen 7)	Katman 3-4 (IP/Port)	Katman 7 (Uygulama)
Paket İçeriği	✅ Okur (SQLi vb. görür)	❌ Genelde okumaz	❌ Okumaz	✅ Okur (Yönlendirme için)
Görünürlük (UI)	✅ Çok detaylı Ağ Haritası	✅ Hubble UI	⚠️ Temel	✅ Kiali vb. ile harita var
WAF Özelliği	✅ Var (Basit WAF)	❌ Yok	❌ Yok	❌ Yok (Eklenti gerekir)
Öğrenme Modu	✅ Otomatik kural yazar	❌ Manuel	❌ Manuel	❌ Manuel
Kaynak Tüketimi	Orta/Yüksek	Düşük	Düşük	Yüksek
Kullanım Amacı	Tam Güvenlik / Saldırı Engelleme	Ağ Bağlantısı & Gözlem	Standart Ağ Politikaları	Servisler Arası Şifreleme

Ek Bilgi: WAF Nedir?

WAF (Web Application Firewall): İnternetten gelebilecek saldırılara karşı koruyan özel bir güvenlik kalkanıdır. Basitçe, klasik güvenlik duvarı "ağ trafiğine" bakarken, WAF "uygulamanın diline" (HTTP/HTTPS) bakar.

WAF Neleri Engeller? (OWASP Top 10)

Genelde Layer 7 (Uygulama Katmanı) seviyesinde çalışır ve şunları yakalar:

SQL Injection (SQLi): Saldırganın web sitesindeki formları kullanarak veritabanını çalmaya çalışması.
Cross-Site Scripting (XSS): Web sayfasına zararlı JavaScript kodları gömerek kullanıcıların bilgilerini çalma girişimi.
Cookie Poisoning: Kullanıcı oturumlarını ele geçirme çabaları.
L7 DDoS Saldırıları: Siteyi çökertmek için yapılan sahte ve yoğun istekler.

Kubernetes Gateway API Rehberi: Ingress NGINX'ten Göç ve Zabbix Örneği

Yunus Emre Dere — Fri, 28 Nov 2025 05:57:09 +0000

NGINX Ingress'e Ne Oldu?

2026 yılında Kubernetes dünyasında önemli bir değişiklik yaşanacak: NGINX Ingress Controller artık yeni özellik güncellemeleri almayacak. Panik yapmaya gerek yok - mevcut kurulumlarınız çalışmaya devam edecek. Ancak yeni özellikler için artık başka bir çözüme bakmamız gerekiyor.

İşte burada Kubernetes Gateway API devreye giriyor.

Gateway API Nedir ve Neden Önemli?

Gateway API, Kubernetes'in resmi olarak desteklediği yeni nesil routing çözümü. Ingress'ten temel farkı şu: modüler yapısı.

Ingress'te her şey tek bir YAML dosyasında toplanıyordu. Gateway API ise işleri üç parçaya ayırıyor:

1. GatewayClass

Cluster genelinde hangi gateway controller'ın kullanılacağını belirler. Bunu bir kere tanımlıyorsunuz ve tüm cluster için geçerli oluyor.

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: cluster-gateway-class
spec:
  controllerName: gateway.nginx.org/nginx-gateway-controller

GatewayClass seçenekleri:

NGINX Gateway Fabric (NGINX Inc.)
Istio Gateway (Google/IBM)
Cilium Gateway (eBPF tabanlı)
Kong Gateway (Enterprise)
Envoy Gateway (CNCF)

Her birinin kendine göre avantajları var. NGINX Gateway Fabric hafif ve basit, Istio daha gelişmiş service mesh özellikleri sunuyor, Cilium performans odaklı.

2. Gateway

Asıl trafiği dinleyen ve yönlendiren bileşen. HTTP, HTTPS, TCP gibi farklı protokolleri destekliyor.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: cluster-gateway
  namespace: nginx-gateway
spec:
  gatewayClassName: cluster-gateway-class
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      allowedRoutes:
        namespaces:
          from: All  # TÜM namespace'lerden route kabul et

3. HTTPRoute

Her servis için ayrı tanımlanıyor. Hangi hostname'den gelen trafiğin hangi servise gideceğini belirliyor.

Gateway API'nin Sağladığı Kolaylıklar

1. Rol Ayrımı:

Cluster admin: GatewayClass ve Gateway'i yönetir
Geliştirici: Sadece kendi HTTPRoute'unu yönetir

2. Namespace İzolasyonu:
Gateway başka namespace'de olsa bile HTTPRoute kendi namespace'inden bağlanabiliyor.

3. Daha Detaylı Routing:

Header-based routing
Query parameter routing
Method-based routing (GET, POST, etc.)
Weight-based traffic splitting

4. Backend Seçenekleri:
Ingress'te sadece Service'e yönlendirme vardı. Gateway API ile:

Multiple backends
Traffic weighting (A/B testing)
Request/response header değiştirme

Gerçek Dünya Örneği: Zabbix Deployment

Şimdi pratiğe geçelim. Zabbix monitoring sistemini Gateway API ile nasıl expose ediyoruz?

Adım 1: GatewayClass Oluşturma

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: cluster-gateway-class
  annotations:
    description: "Cluster-wide gateway class for all services"
spec:
  controllerName: gateway.nginx.org/nginx-gateway-controller
  description: "NGINX Gateway Fabric for cluster infrastructure"

Bu dosyayı cluster'da bir kere deploy ediyoruz. Tüm servisler bunu kullanacak.

Adım 2: Gateway Oluşturma

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: cluster-gateway
  namespace: nginx-gateway
  annotations:
    description: "Cluster-wide gateway for all services"
spec:
  gatewayClassName: cluster-gateway-class
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      allowedRoutes:
        namespaces:
          from: All
    - name: https
      protocol: HTTPS
      port: 443
      allowedRoutes:
        namespaces:
          from: All
      tls:
        mode: Terminate
        certificateRefs:
          - kind: Secret
            name: cluster-tls-secret

Önemli detay: allowedRoutes.namespaces.from: All

Bu satır olmadan Gateway sadece kendi namespace'indeki route'ları kabul eder. All yaparak tüm namespace'lerdeki servislerin bu gateway'i kullanmasına izin veriyoruz.

Adım 3: Zabbix için HTTPRoute

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: zabbix-route
  namespace: zabbix
spec:
  parentRefs:
    - name: cluster-gateway
      namespace: nginx-gateway
      sectionName: http
    - name: cluster-gateway
      namespace: nginx-gateway
      sectionName: https
  hostnames:
    - "zabbix"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: zabbix-zabbix-web
          port: 80

Dikkat edilmesi gerekenler:

Cross-namespace referans: HTTPRoute zabbix namespace'inde ama nginx-gateway namespace'indeki gateway'e bağlanıyor.
parentRefs: Hem HTTP hem HTTPS listener'a bağlandık. Böylece her iki protokol de çalışıyor.
sectionName: Gateway'deki hangi listener'a bağlanacağımızı belirtiyoruz.
hostnames: Browser'da http://zabbix yazınca bu route devreye girecek.

Deployment

# 1. NGINX Gateway Fabric kur
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.1.0/standard-install.yaml
kubectl apply -f https://raw.githubusercontent.com/nginxinc/nginx-gateway-fabric/v1.5.0/deploy/default/deploy.yaml

# 2. Gateway controller'ı yapılandır
kubectl patch deployment nginx-gateway -n nginx-gateway --type='json' \
  -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/args/2", "value": "--gatewayclass=cluster-gateway-class"}]'

# 3. Gateway infrastructure'ı deploy et
kubectl apply -f gatewayclass.yaml
kubectl apply -f gateway.yaml

# 4. Zabbix HTTPRoute'u deploy et
kubectl apply -f zabbix-httproute.yaml

# 5. Kontrol et
kubectl get gateway -A
kubectl get httproute -A

Sık Karşılaşılan Sorunlar ve Çözümleri

Problem 1: HTTPRoute "Not Allowed by Listeners" hatası

Çözüm: Gateway'de allowedRoutes.namespaces.from: All ekleyin.

Problem 2: Gateway EXTERNAL-IP pending kalıyor

Çözüm: On-premise kurulumda MetalLB kullanın veya manuel IP atayın: (Bu komut, MetalLB gibi bir LoadBalancer servisi olmayan Lab/Test ortamlarında manuel IP atamak içindir. Production ortamında Cloud Provider veya MetalLB bu IP'yi otomatik verir.)

kubectl patch svc nginx-gateway -n nginx-gateway \
  -p '{"spec":{"externalIPs":["10.67.67.217"]}}'

Problem 3: Backend HTTPS çalışmıyor

Çözüm: NGINX Gateway Fabric, backend TLS konusunda çok katı standartlara sahip. Self-signed sertifikalarla uğraşmak yerine, SSL Offloading (Termination) yapıp arkada HTTP kullanmak şu an için en stabil ve hızlı yöntem.

Önemli Trickler ve Best Practices

1. Gateway Namespace Seçimi

Gateway'i infrastructure namespace'ine (nginx-gateway) koyun, uygulama namespace'ine değil. Böylece:

Merkezi yönetim sağlanır
Uygulama namespace'leri silinse bile gateway ayakta kalır
Rol ayrımı net olur

2. Gateway İsimlendirme

zabbix-gateway gibi servise özel isim yerine cluster-gateway gibi neutral isim kullanın. Gateway tüm cluster'a hizmet ediyor.

3. LoadBalancer External IP

Cloud sağlayıcı kullanmıyorsanız:

kubectl patch svc nginx-gateway -n nginx-gateway \
  -p '{"spec":{"externalIPs":["YOUR_IP"]}}'

4. Multiple Listeners

Hem HTTP hem HTTPS için ayrı listener tanımlayın:

listeners:
  - name: http
    port: 80
  - name: https
    port: 443

HTTPRoute her ikisine de bağlanabilir:

parentRefs:
  - name: cluster-gateway
    sectionName: http
  - name: cluster-gateway
    sectionName: https

5. Debugging

Gateway durumunu kontrol etmek için:

# Gateway programmed mı?
kubectl get gateway -n nginx-gateway

# Route accepted mı?
kubectl describe httproute zabbix-route -n zabbix

# NGINX Gateway Fabric logları
kubectl logs -n nginx-gateway deployment/nginx-gateway -f

Gateway API vs Ingress: Özet Karşılaştırma

Özellik	Ingress	Gateway API
Modüler yapı	❌	✅
Rol ayrımı	❌	✅
Advanced routing	Sınırlı	✅
Multiple protocols	❌	✅
Vendor-neutral	Kısmen	✅
Production-ready	✅	✅ (v1.0+)

Kubectl Alias'ları (Bonus)

Gateway API ile çalışırken işinizi kolaylaştıracak alias'lar:

# ~/.bash_aliases dosyasına ekleyin
alias kgg='kubectl get gateway'
alias kgh='kubectl get httproute'
alias kgc='kubectl get gatewayclass'
alias kdg='kubectl describe gateway'
alias kdh='kubectl describe httproute'
alias kdc='kubectl describe gatewayclass'

# Hepsini görmek için
alias kgg-all='kubectl get gateway -A'
alias kgh-all='kubectl get httproute -A'

Kullanım:

kgg -n nginx-gateway        # Gateway'leri listele
kgh-all                     # Tüm HTTPRoute'ları göster
kdh zabbix-route -n zabbix  # Route detaylarını göster

Sonuç

Gateway API, Kubernetes routing'in geleceği. 2026'da NGINX Ingress'in güncelleme almaması ile birlikte Gateway API'ye geçiş kaçınılmaz hale geliyor.

Modüler yapısı sayesinde:

Cluster admin'ler altyapıyı yönetiyor
Geliştiriciler sadece kendi route'larını düşünüyor
Farklı namespace'ler izole çalışıyor
Controller değiştirmek kolay

Eğer yeni bir proje başlıyorsanız veya mevcut Ingress yapınızı modernize etmek istiyorsanız, Gateway API doğru seçim.

Önemli Not: Bu yazıda kullanılan yapı production-ready. Ancak backend HTTPS gibi bazı özellikler NGINX Gateway Fabric v1.5.0'da henüz tam desteklenmiyor. Bu özellikler 2025 Q3-Q4'te gelecek güncellemelerle eklenecek.

Kaynaklar

Bu makale, gerçek bir production deployment deneyimine dayanarak yazılmıştır. Zabbix monitoring sistemi üzerinde test edilmiş ve çalışır durumda olan yapılandırmalar kullanılmıştır.

RKE2'de Liman MYS & Keycloak Kurulumu: Longhorn ve Docker Hub Hata Çözümleri Dahil Tam Rehber

Yunus Emre Dere — Fri, 24 Oct 2025 10:37:05 +0000

Kubernetes (K8s) dünyasında, Liman MYS gibi, envanter yönetiminden servis takibine kadar pek çok işlevi eklentilerle yürüten platformlar kullanırız. Bu farklı bileşenler ve yetkiler için merkezi bir kimlik doğrulama (Authentication) yönetimi hızla karmaşıklaşabilir. İşte bu noktada Keycloak devreye giriyor.

Bu rehberde, RKE2 (hafifletilmiş bir K8s dağıtımı) üzerinde Liman MYS ve Keycloak'u sıfırdan kuracak, bu iki güçlü sistemi birbirine bağlayacak (SSO) ve bu süreçte kesinlikle karşılaşacağınız en yaygın iki hatayı (Longhorn Pending ve Docker Hub TooManyRequests) adım adım çözeceğiz.

Faz 1: Gerekli Altyapı (Bizim "Sandbox" Ortamımız)

Başlamadan önce, RKE2 sunucumuzun uygulamaları barındırmaya hazır olması gerekir.

RKE2: Zaten kurulu olduğunu varsayıyoruz.
Helm: Kubernetes için bir paket yöneticisidir.
```
sudo snap install helm --classic
```
StorageClass (Longhorn): Liman ve Keycloak'un veritabanları gibi 'stateful' (durum bilgisi tutan) uygulamaları, verilerini kalıcı olarak saklamak zorundadır. Bunun için bir StorageClass (Depolama Sınıfı) sağlayıcısına ihtiyacımız var. Biz burada popüler ve RKE2 ile uyumlu olan Longhorn'u kullanacağız.

Aşağıdaki kod Longhorn'u ve onun 'longhorn' adlı StorageClass'ını kurar

kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.9.0/deploy/longhorn.yaml

Longhorn'un longhorn-system namespace'inde kurulup pod'larının Running duruma gelmesini bekleyin.

Faz 2: Keycloak Kurulumu ve Erişimi

Artık altyapımız hazır olduğuna göre, kimlik sunucumuz olan Keycloak'u kuralım.

Adım 1: Keycloak'u Kurma

Topluluk tarafından sağlanan resmi YAML dosyası, hem Keycloak'u (bir StatefulSet olarak) hem de veritabanı için bir PostgreSQL'i (bir Deployment olarak) kurar.

kubectl apply -f https://raw.githubusercontent.com/keycloak/keycloak-quickstarts/refs/heads/main/kubernetes/keycloak.yaml

Adım 2: Pod Kontrolü

Kurulumun tamamlandığını görmek için pod'ları kontrol edin.

kubectl get pods

NAME                       READY   STATUS    RESTARTS   AGE
keycloak-0                 1/1     Running   0          39h
keycloak-1                 1/1     Running   0          39h
postgres-65cf55dbf-nv5kx   1/1     Running   0          40h
redis-58f44d957b-6gzmw     1/1     Running   0          24h

Pod'ların Running durumuna geçmesi, Docker Hub limitlerine takılmazsanız birkaç dakika sürebilir. (Eğer ErrImagePull hatası alırsanız, Faz 4'teki çözüme atlayın).

Adım 3: Keycloak Ingress Yapılandırması

Keycloak'a tarayıcıdan temiz bir adresle (keycloak.test.local gibi) erişmek için bir Ingress oluşturacağız.

Önce, Keycloak servisinin hangi portu kullandığını öğrenelim:

kubectl get svc

NAME                 TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
keycloak             ClusterIP   10.43.158.36   <none>        8080/TCP   40h
keycloak-discovery   ClusterIP   None           <none>        <none>     40h
kubernetes           ClusterIP   10.43.0.1      <none>        443/TCP    42h
postgres             ClusterIP   10.43.32.41    <none>        5432/TCP   40h

Gördüğümüz gibi, keycloak servisi 8080 portunu kullanıyor. Şimdi keycloak-ingress.yaml dosyamızı oluşturalım:

nano keycloak-ingress.yaml

Dosyanın içeriği:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: keycloak-ingress
spec:
  # RKE2'nin varsayılan nginx controller'ını kullan
  ingressClassName: nginx  
  rules:
  - host: "keycloak.test.local" # Keycloak'a bu adresle erişeceğiz
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: keycloak   # Yukarıda öğrendiğimiz servis adı
            port:
              number: 8080 # Yukarıda öğrendiğimiz port

Ingress kuralını uygulayalım:

kubectl apply -f keycloak-ingress.yaml

Adım 4: Hosts Dosyası

keycloak.test.local adresinin RKE2 sunucumuzun IP'sine yönlenmesi için, tarayıcıyı kullandığımız kendi bilgisayarımızda (sunucuda değil!) /etc/hosts dosyasını düzenlememiz gerekiyor.

sudo nano /etc/hosts

Dosyanın en altına RKE2 sunucunuzun IP'sini ve host adını ekleyin:

<kubernetes-kurulu-server-ip-adresi>   keycloak.test.local

Artık tarayıcıdan http://keycloak.test.local adresine giderek Keycloak arayüzüne erişebilirsiniz.

Varsayılan hızlı başlangıç bilgileri:

Kullanıcı Adı: admin
Şifre: admin

Faz 3: Keycloak'u Liman için Yapılandırma

Liman'a "Bana güvenebilirsin" demek için Keycloak'ta bir "Client" (istemci) ve "Realm" (Bölge) oluşturmalıyız.

Realm Oluşturun: admin olarak giriş yaptıktan sonra, sol üstteki "master" yazan yerden "Manage realms" > "Create Realm" deyin. Realm adınızı Liman-Realm gibi bir şey yapın ve "Create"e tıklayın.
Client Oluşturun: Sol üstten Liman-Realm'i seçtiğinizden emin olun. Sol menüden "Clients" sekmesine ve ardından "Create Client"a tıklayın. "Client ID" kısmına liman-client gibi hatırlayacağınız bir isim verin. Gelen ekranda "Client authentication" ve "Authorization" seçeneklerini ON (Açık) konuma getirin. Aşağıdaki "Valid redirect URIs" alanına, Liman arayüzünde bizden istenen adresi girmeliyiz. Bu, Liman'ın Ingress host adına bağlı olacaktır. Şimdilik https://liman.test.local/keycloak/callback yazabilirsiniz. (Liman Ingress'ini oluştururken liman.test.local kullanacağız). Web origins kısmına da https://liman.test.local yazın ve kaydedin.
Client Secret'ı Alın: Kaydettikten sonra açılan "Credentials" sekmesine tıklayın ve "Client Secret" değerini kopyalayın. Bu, Liman'daki forma yapıştıracağımız "şifre" olacak.
Rolleri Token'a Ekleyin (Çok Önemli Adım!): Liman'ın, giriş yapan kullanıcının yetkilerini anlaması için bu rollerin Keycloak tarafından oluşturulan token'a eklenmesi gerekir.
- Sol menüden "Client Scopes"a tıklayın.
- roles adlı scope'u seçin.
- Açılan ekranda "Mappers" (Eşleyiciler) sekmesine tıklayın.
- realm-roles'e girin, "Add to access token" seçeneğini aktifleştirip kaydedin.
- Aynı işlemi client-roles için de yapın.
Test Kullanıcısı Oluşturun:
- Sol menüden "Users"a gidin ve "Add User" deyin.
- Kullanıcı bilgilerinizi girin, "Email verified" seçeneğini açın ve Create'e tıklayın.
- Kullanıcıyı oluşturduktan sonra, "Credentials" sekmesine giderek ona kalıcı bir şifre belirleyin (Temporary'i kapatarak).

Keycloak tarafı artık Liman'ı kabul etmeye hazır.

Faz 4: Liman MYS Kurulumu ve Hata Ayıklama

Şimdi Liman MYS'yi kuralım ve bu süreçte karşılaşacağımız iki yaygın hatayı çözelim.

git clone https://github.com/limanmys/core.git
cd core/k8s/helm
kubectl create namespace liman
helm install limancore . --namespace liman

kubectl get pods -n liman komutunu çalıştırdığınızda, pod'ların Pending (Beklemede) veya ErrImagePull durumunda takıldığını göreceksiniz. Panik yapmayın, bu normal.

HATA 1 ÇÖZÜMÜ: Pending (Beklemede) Pod'lar

db- ve limancore- pod'larının Pending kalmasının nedeni, Longhorn'un varsayılan olarak 3 replica (kopya) disk oluşturmaya çalışmasıdır. Bizim RKE2 kurulumumuz tek bir sunucudan (Node) oluştuğu için Longhorn "Verinin 3 kopyasını oluşturamam" diyerek diski (Volume) oluşturmayı reddeder.

Bunu düzeltmek için Longhorn arayüzüne erişip replica sayısını 1'e düşüreceğiz:

Longhorn Arayüzünü Erişime Açın:
```
kubectl edit svc longhorn-frontend -n longhorn-system
```
Açılan vi editöründe, spec: altındaki type: ClusterIP satırını type: NodePort olarak değiştirin ve kaydedip çıkın (Esc > :wq > Enter).

Portu Öğrenin:

kubectl get svc -n longhorn-system
NAME                          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
longhorn-admission-webhook    ClusterIP   10.43.130.170   <none>        9502/TCP       23h
longhorn-backend              ClusterIP   10.43.171.127   <none>        9500/TCP       23h
longhorn-conversion-webhook   ClusterIP   10.43.234.16    <none>        9501/TCP       23h
longhorn-frontend             NodePort    10.43.84.222    <none>        80:31248/TCP   23h
longhorn-recovery-backend     ClusterIP   10.43.60.100    <none>        9503/TCP       23h

longhorn-frontend servisinin NodePort değerini (örn: 80:31248/TCP) göreceksiniz. Bize 31248 portu lazım.

Replica Sayısını Düşürün: Tarayıcınızdan http://<sunucu-ip-adresi>:<port-sayısı> (örn: http://xx.xx.xx.xx:31248) adresine gidin. "Volume" sekmesine gidin. Faulted (Hatalı) durumda olan volüm'leri (liman db ve core için) göreceksiniz. Sağ taraftaki üç noktaya tıklayın ve "Update Replicas" (Replica'ları Güncelle) deyin. Değeri 3'ten 1'e düşürün ve OK'e basın.

Bunu hatalı olan tüm Liman volüm'leri için yaptığınızda, durumları "Healthy" (Sağlıklı) olacaktır ve pod'lar Pending durumundan çıkacaktır.

HATA 2 ÇÖZÜMÜ: ErrImagePull / TooManyRequests

Pending sorununu çözseniz bile, pod'ların bu kez ErrImagePull veya ImagePullBackOff hatası verdiğini göreceksiniz. Bunun nedeni, Docker Hub'ın anonim (giriş yapmamış) kullanıcılara çok düşük bir imaj indirme limiti koymasıdır.

Çözüm, RKE2 sunucumuza Docker Hub'a nasıl giriş yapacağını öğretmektir.

Docker Hub Access Token Oluşturun:
- Docker Hub'a giriş yapın.
- Ayarlar > Security > Personal Access Tokens sayfasına gidin.
- "Generate New Token" diyerek bir token oluşturun ve bu token'ı güvenli bir yere kopyalayın.

Kubernetes Secret Oluşturun: Terminalde, kopyaladığınız o token'ı kullanarak bir Kubernetes "giriş kartı" (secret) oluşturun:

kubectl create secret docker-registry dockerhub-auth \
  --docker-username="SizinDockerHubKullanıcıAdınız" \
  --docker-password="YENİ_OLUŞTURDUĞUNUZ_TOKEN" \
  --docker-email="SizinEmailAdresiniz" \
  -n liman

Secret'ı Pod'lara Tanıtın: liman namespace'indeki default (varsayılan) hizmet hesabını (Service Account) yamalayarak, bu namespace'de oluşturulan her pod'un imaj çekerken bu "giriş kartını" kullanmasını sağlayacağız:
```
kubectl patch serviceaccount default -n liman -p '{"imagePullSecrets": [{"name": "dockerhub-auth"}]}'
```
Pod'ları Yeniden Başlatın: Hatalı pod'ları silerek Kubernetes'in onları yeni ayarla (giriş yapmış olarak) yeniden başlatmasını sağlayın:
```
kubectl delete pods --all -n liman
```
Tekrar kubectl get pods -n liman -w komutuyla izlediğinizde, bu kez tüm pod'ların imajları başarıyla çektiğini ve Running durumuna geçtiğini göreceksiniz.

Faz 5: Liman Ingress ve Son Ayarlar

Artık çalışan bir Liman'ımız var. Ona da Keycloak gibi temiz bir adresle erişelim.

Liman Ingress Dosyası:

sudo nano liman-ingress.yaml

Dosyanın içeriği:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: liman
  namespace: liman
  annotations:
    # Arka uç (Liman) HTTPS (443) kullandığı için Nginx'e HTTPS konuşmasını söylüyoruz
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
    # Liman'ın kendi imzaladığı sertifikayı Nginx'in dert etmemesini söylüyoruz
    nginx.ingress.kubernetes.io/proxy-ssl-verify: "off"
spec:
  ingressClassName: nginx
  rules:
  - host: "liman.test.local" # Liman'a bu adresle erişeceğiz
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: limancore # Liman'ın ana servis adı
            port:
              number: 443    # Liman'ın servis portu

Dosyayı kaydedin ve uygulayın:

kubectl apply -f liman-ingress.yaml -n liman

Hosts Dosyasını Güncelleyin: Tekrar kendi bilgisayarınızda sudo nano /etc/hosts dosyasını açın ve liman.test.local adresini de ekleyin:
```
<kubernetes-kurulu-server-ip-adresi>   keycloak.test.local
<kubernetes-kurulu-server-ip-adresi>   liman.test.local
```

Liman Admin Şifresini Alın: Liman'a ilk giriş için tek kullanımlık bir şifre almamız gerekiyor:

# Önce limancore pod'unun tam adını bulalım:
LIMAN_POD_NAME=$(kubectl get pods -n liman -l service=limancore -o jsonpath='{.items[0].metadata.name}')
echo "Liman Pod Adı: $LIMAN_POD_NAME"

# Şimdi o pod'dan şifreyi isteyelim:
kubectl exec -it $LIMAN_POD_NAME -n liman -- limanctl administrator

Size administrator kullanıcısı için bir şifre verecektir.

Liman'ı Keycloak'a Bağlayın:
- Tarayıcınızdan http://liman.test.local adresine gidin. (Ingress, isteğinizi otomatik olarak HTTPS'e yönlendirecektir).
- Aldığınız administrator şifresiyle giriş yapın.
- Ayarlar > Erişim > Keycloak sekmesine gidin.
- Buradaki alanları, Faz 3'te Keycloak'ta oluşturduğunuz bilgilerle doldurun:
  - Client ID: liman-client (veya ne isim verdiyseniz)
  - Client Secret: Keycloak'tan kopyaladığınız gizli şifre.
  - Redirect URL: https://liman.test.local/keycloak/callback (Keycloak'a girdiğiniz adresin aynısı)
  - Base URL: http://keycloak.default.svc.cluster.local:8080 (Keycloak adresiniz)
  - Realm: Liman-Realm (veya ne isim verdiyseniz)
- "Entegrasyonu aktifleştir" butonunu AÇIK hale getirin ve kaydedin.

Son Adım: Liman'ı Yeniden Başlatın

Liman'ın bu yeni ayarları çekmesi için limancore pod'unu yeniden başlatmamız gerekiyor:

# Pod'un tam adını tekrar bulup silin
kubectl delete pod $LIMAN_POD_NAME -n liman

Pod yeniden başladığında, Liman giriş ekranına geri dönün.

Artık "Giriş Yöntemi" olarak Keycloak'u seçebilir, Faz 3'te oluşturduğunuz test kullanıcısıyla giriş yapabilir ve Keycloak üzerinden Liman'a başarıyla bağlandığınızı görebilirsiniz.

Tebrikler! Artık RKE2 üzerinde çalışan, Longhorn ile kalıcı depolamaya sahip ve Keycloak ile SSO entegrasyonu tamamlanmış bir Liman MYS kurulumunuz var.

DEV Community: Yunus Emre Dere

NeuVector - Rke2: Kubernetes İçin Derinlemesine Güvenlik

Detaylar ve Temel Özellikler

1. Canlı Ağ Güvenliği (Runtime Security)

2. Zero-Trust ve Davranışsal Öğrenme

3. Zafiyet ve Uyumluluk Taraması

Olumsuz Yanları

Yüksek Kaynak Tüketimi

Ağ Gecikmesi (Latency)

Protect Moduna Geçiş Riski

Karmaşık Yönetim ve Öğrenme Eğrisi

İlk Kurulumda Kargaşa

Ne Zaman Kullanılmalı?

Mimari ve Kavramlar

1. Üç Temel Bileşen

2. Altın Kural: "Önce Öğren, Sonra Koru"

3. SUSE ve Açık Kaynak Durumu

4. Kurallar Kod Olarak Dışarı Alınabilir (Security As Code)

5. Helm İle Kurulum

Diğer Firewall'lar ile Karşılaştırma

Ek Bilgi: WAF Nedir?

WAF Neleri Engeller? (OWASP Top 10)

Kubernetes Gateway API Rehberi: Ingress NGINX'ten Göç ve Zabbix Örneği

NGINX Ingress'e Ne Oldu?

Gateway API Nedir ve Neden Önemli?

1. GatewayClass

2. Gateway

3. HTTPRoute

Gateway API'nin Sağladığı Kolaylıklar

Gerçek Dünya Örneği: Zabbix Deployment

Adım 1: GatewayClass Oluşturma

Adım 2: Gateway Oluşturma

Adım 3: Zabbix için HTTPRoute

Deployment

Sık Karşılaşılan Sorunlar ve Çözümleri

Önemli Trickler ve Best Practices

1. Gateway Namespace Seçimi

2. Gateway İsimlendirme

3. LoadBalancer External IP

4. Multiple Listeners

5. Debugging

Gateway API vs Ingress: Özet Karşılaştırma

Kubectl Alias'ları (Bonus)

Sonuç

Kaynaklar

RKE2'de Liman MYS & Keycloak Kurulumu: Longhorn ve Docker Hub Hata Çözümleri Dahil Tam Rehber

Faz 1: Gerekli Altyapı (Bizim "Sandbox" Ortamımız)

Faz 2: Keycloak Kurulumu ve Erişimi

Adım 1: Keycloak'u Kurma

Adım 2: Pod Kontrolü

Adım 3: Keycloak Ingress Yapılandırması

Adım 4: Hosts Dosyası

Faz 3: Keycloak'u Liman için Yapılandırma

Faz 4: Liman MYS Kurulumu ve Hata Ayıklama

HATA 1 ÇÖZÜMÜ: Pending (Beklemede) Pod'lar

HATA 2 ÇÖZÜMÜ: ErrImagePull / TooManyRequests

Faz 5: Liman Ingress ve Son Ayarlar

Son Adım: Liman'ı Yeniden Başlatın

`Protect` Moduna Geçiş Riski