Service mesh, servisler arası iletişimi uygulama koduna dokunmadan şifrelemek ve kimlik doğrulamak için sidecar veya node proxy katmanı ekler. TLS yönetimi uygulamadan altyapıya taşınır.
Mesh'in TLS modeli
Istio, Linkerd gibi çözümlerde her iş yüküne bir kimlik (çoğunlukla SPIFFE biçimi) ve kısa ömürlü bir sertifika verilir. Sertifikaları mesh'in kontrol düzlemi üretir, proxy'ler otomatik yeniler. Böylece servisler arası trafik varsayılan olarak karşılıklı TLS ile akar.
Istio örneği: STRICT mTLS
Ad alanı genelinde yalnızca mTLS trafiğini kabul etmek için:
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
name: default
namespace: uretim
spec:
mtls:
mode: STRICTGeçiş döneminde PERMISSIVE modu hem düz hem mTLS trafiğini kabul eder; tüm iş yükleri mesh'e alındıktan sonra STRICT'e geçilir. Hangi servisin kime erişebileceğini ise AuthorizationPolicy ile ayrıca kısıtlamanız gerekir; mTLS kimliği doğrular, yetkiyi vermez.
Uygulama adımları
- Mesh'e alınan ad alanlarını ve sidecar enjeksiyonunu belirleyin.
- PERMISSIVE modda bağlantıları izleyip mesh dışı istemcileri tespit edin.
- STRICT moda geçin ve kesinti olan servisleri kontrol edin.
- AuthorizationPolicy ile varsayılan reddet, gerekli çağrılara izin ver yaklaşımını uygulayın.
Dışa açık kapı için sertifika
Mesh içi sertifikalar dış dünya için geçerli değildir. Ingress gateway'in sunduğu sertifika tarayıcıların güvendiği bir CA'dan alınmalıdır; bir SSL sertifikası bu kapıya tanımlanır. Ara CA'yı kurum CA'nızdan vermek istiyorsanız kök anahtarın mesh dışında korunduğundan emin olun.
İpuçları
- Sertifika yenileme başarısızlıklarını proxy ve kontrol düzlemi metriklerinden izleyin.
- Saat senkronizasyonu (NTP) bozuksa sertifikalar geçersiz görünebilir.
- Mesh dışı veritabanı gibi uçlar için ayrıca TLS ayarı yapılması gerekebilir.
Özetle mesh, TLS operasyonunu otomatikleştirir; ancak STRICT mod, yetki politikaları ve dış sertifika yönetimi ayrı ayrı planlanmalıdır.