Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

mTLS

Bir önceki konularda cluster'ımızın ana kapısını (Ingress) güvenceye aldık ve Network Policies kimin kiminle konuşabileceğini sınırladık. Ancak hala cevaplanması gereken kritik bir soru var: "Konuşmasına izin verdiğimiz bu iki pod arasındaki veri akışı gerçekten güvenli mi, yoksa araya biri girip bu trafiği dinleyebilir mi?"

Tıpkı dış dünyadaki trafiği Cloudflare veya HAProxy gibi araçlarla şifrelediğimiz gibi, cluster içindeki backend servislerinin de birbirleriyle şifreli ve kimlik doğrulamalı konuşması gerekir. İşte mTLS (Mutual TLS) tam olarak bu noktada devreye girer.

1. Standart TLS vs. Mutual TLS (mTLS) Arasındaki Fark

Konuyu en iyi anlamanın yolu, standart internet trafiğiyle kıyaslamaktır.

  • Standart TLS (Tek Yönlü Güven): Bir e-ticaret sitesine girdiğinizde tarayıcınız sunucunun sertifikasını kontrol eder ("Bu site gerçekten o site mi?"). Ancak sunucu sizin kim olduğunuzu sormaz. Sadece sunucu kimliğini kanıtlar.

  • mTLS (İki Yönlü Güven): İletişime geçen hem istemci (client) hem de sunucu (server) birbirlerine dijital sertifikalarını gösterir. "Sen kimsin?" ve "Peki sen kimsin?" diyaloğu yaşanır. Her iki taraf da birbirini doğrulamadan (Zero-Trust mantığı) tek bir bayt bile veri transfer edilmez.

🗺️ Zihinde Canlandırma: El Sıkışma (Handshake) Topolojisi

Diyelim ki Bolatoğlu Yapı'nın arka planda çalışan iç sistemlerinde, Siparis (Order) servisi Fatura (Billing) servisiyle konuşmak istiyor.

  [ Sipariş Pod'u (Client) ]                                [ Fatura Pod'u (Server) ]

  1. "Merhaba, ben seninle konuşmak istiyorum" ──────────▶
                                                            2. "Merhaba, al bu benim sertifikam."
                                              ◀──────────
  3. (Sertifikayı doğrular, onaylar)
  4. "Tamam inandım, al bu da BENİM sertifikam" ─────────▶
                                                            5. (Sertifikayı doğrular, onaylar)
                                              ◀──────────
               (✅ İKİ YÖNLÜ ŞİFRELEME VE GÜVENLİ KANAL OLUŞTURULDU)

Bu iki yönlü doğrulama sayesinde, eğer bir saldırgan Sipariş pod'unu taklit etmeye çalışırsa (Man-in-the-Middle - Ortadaki Adam saldırısı), elinde geçerli bir istemci sertifikası olmadığı için Fatura servisi bağlantıyı anında reddeder.

2. Kubernetes'te mTLS Nasıl Uygulanır? (Service Mesh)

Teoride harika, peki pratikte bunu nasıl yapacağız? Uygulamalarımızın (örneğin yazdığınız bir Node.js veya Python kodunun) içine girip sertifika doğrulama kodları mı yazacağız? Kesinlikle hayır.

Modern Kubernetes mimarilerinde mTLS, uygulamadan tamamen bağımsız bir şekilde Service Mesh araçlarıyla çözülür. En popüler olanları Istio ve Linkerd'dir. (Cilium'un da mTLS desteği vardır ancak şu an beta aşamasındadır).

Sidecar Proxy Mantığı

Service Mesh araçları, pod'unuzun içine uygulamanızın hemen yanına (sidecar) görünmez bir Proxy (genellikle Envoy proxy) yerleştirir. Uygulamanız sadece dışarıya düz (şifresiz) HTTP isteği attığını sanır. Ancak o istek pod'dan çıkmadan önce bu Proxy tarafından yakalanır, mTLS ile şifrelenir, karşı tarafın sertifikası sorulur ve karşı pod'daki Proxy'ye teslim edilir.

Bu mimarinin en büyük avantajı; sertifikaların oluşturulması, süresi dolduğunda yenilenmesi (rotation) ve iptal edilmesi işlemlerinin tamamının Service Mesh kontrolcüsü tarafından otomatik yapılmasıdır. Yazılımcının ruhu bile duymaz.

3. Pratik Senaryo: Istio ile mTLS'i Zorunlu Kılmak

Eğer sisteminizde Istio Service Mesh kuruluysa, mTLS'i belirli bir namespace genelinde zorunlu kılmak inanılmaz derecede basittir. Kubernetes'e standart bir YAML göndererek tüm trafiği anında zırhlayabilirsiniz.

Aşağıdaki YAML (PeerAuthentication objesi), belirtilen namespace içindeki tüm pod'lar arası iletişimin kesinlikle (STRICT) mTLS ile yapılmasını emreder. Düz HTTP ile gelen tüm iç istekler anında reddedilir.

Bu kodu apply ettiğiniz saniyeden itibaren, o namespace içindeki tüm mikroservisler sadece sertifika gösteren diğer servislerle konuşabilir.

4. Avantajlar ve Bedeller (Trade-offs)

Mühendislikte her güzel şeyin bir bedeli vardır. mTLS'i sisteminize entegre etmeden önce artılarını ve eksilerini tartmak gerekir:

Avantajları (Neden Kullanmalıyız?):

  • Ağınıza sızan bir hacker, pod'lar arasındaki trafiği dinlese bile sadece şifrelenmiş anlamsız karakterler görür.

  • KVKK, GDPR, PCI-DSS (Kredi kartı güvenliği) gibi standartlar genellikle servisler arası trafiğin şifrelenmesini şart koşar.

  • Service Mesh sayesinde uygulamaların kaynak koduna dokunmadan tüm sistemi şifreleyebilirsiniz.

Zorlukları (Maliyetleri Nelerdir?):

  • Şifreleme ve şifre çözme işlemleri CPU ve RAM tüketir. Ağ trafiğinde (latency) milisaniyelik gecikmeler yaratabilir. Yoğun trafikli cluster'larda altyapı (kaynak) planlamasını buna göre yapmak gerekir.

  • Sorun anında şifrelenmiş trafiği debug etmek (örneğin tcpdump veya wireshark ile okumak) çok daha zordur.

  • cluster dışındaki legacy sistemler bu sertifika yapısını desteklemiyorsa, entegrasyon zorlaşır.

PreviousDemoNextCilium Hubble

Last updated