Modern bulut-native uygulamalar ortamında güvenlik sınırları değişti. Güvenlik duvarının içindeki her şeye güvenmeye dayanan geleneksel ağ güvenlik modelleri artık uygulanabilir değildir. Mikro servislerin ve konteynerleşmiş yüklerin yaygınlaşmasıyla birlikte "sıfır-güvenlik" mimarisi altın standart haline gelmiştir. Bu yaklaşım, "asla güvenme, her zaman doğrula" ilkesi üzerine çalışır. Kubernetes ortamları için Istio servis mesh'i, bu sıfır-güvenlik ilkelerini altyapı düzeyinde uygulamak için güçlü bir araç olarak öne çıkar.
Kubernetes'te Sıfır-Güvenliğe Geçiş
Sıfır-güvenlik güvenliği, kökeni ne olursa olsun her isteğin erişim sağlanmadan önce kimlik doğrulamasından ve yetkilendirmeden geçmesini gerektirir. Standart bir Kubernetes kümesinde NetworkPolicies, trafiği IP adreslerine ve bağlantı noktalarına dayalı olarak kısıtlayabilir, ancak servisler arasındaki ince taneli erişim kontrolü için gereken ayrıntılı kontrolü genellikle sağlamaz. Örneğin, A Servisi'nin yalnızca iş saatleri boyunca B Servisi'ndeki belirli bir uç noktaya çağrı yapmasını sağlamak, basit paket filtrelemesinin ötesinde mantık gerektirir.
Istio, trafik akışını yöneten ve tüm servisler üzerinde ilkeleri uygulayan birleşik bir kontrol düzlemi sağlayarak bu boşluğu doldurur. Istio'nun Yetkilendirme İlkelerinden yararlanarak geliştiriciler ve operatörler, rol tabanlı erişim kontrolü (RBAC) kurallarını doğrudan mesh içinde tanımlayabilir ve yalnızca yetkili kimliklerin iletişim kurmasını sağlayabilir.
Istio Yetkilendirme İlkelerini Anlamak
Istio, yetkilendirme için Kubernetes Özel Kaynak Tanımı (CRD)'sini kullanır; bu da erişilebilecek kaynakları belirleyen kurallar tanımlamanıza olanak tanır. Bu ilkeler, trafiğin uygulama kodunuza ulaşmadan önce bile uygulanmasını sağlamak üzere Envoy proxy sidecar'ında değerlendirilir.
Bir Istio yetkilendirme ilkesinin temel bileşenleri şunları içerir:
- Kurallar: Erişimin izin verildiği veya reddedildiği koşulları tanımlar.
- Eylemler: Eylemin ALLOW (İzin Ver) veya DENY (Reddet) olduğunu belirtir.
- Konular (Subjects): İsteği yapan birimi (kaynağı) tanımlar; genellikle karşılıklı TLS (mTLS) sertifikalarından türetilir.
Pratik Örnek: Erişimi Kısıtlama
Her halka açık bir ön uç servisi (frontend-v1) ve hassas bir arka uç API'si (backend-v1) olduğunu varsayalım. Yalnızca ön uçtan gelen isteklerin arka uca ulaşmasına izin verildiğinden ve hatta o zaman bile yalnızca belirli HTTP yöntemlerinin izin verildiğinden emin olmak istiyorsunuz.
Öncelikle, ad alanınızda mTLS'nin etkinleştirildiğinden emin olun. mTLS olmadan Istio, kaynak servisi güvenilir bir şekilde tanımlayamaz ve bu da yetkilendirme ilkelerinin etkisiz hale gelmesine neden olur.
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: prod-ns
spec:
mtls:
mode: STRICT
Ardından, arka uç servisi için Yetkilendirme İlkesini uygulayın. Bu ilke, belirli kurullarla eşleşmedikçe varsayılan olarak tüm istekleri reddeder. Bu durumda, yalnızca ön uç servisi tarafından gönderilen POST isteklerine izin veriyoruz.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: backend-policy
namespace: prod-ns
spec:
selector:
matchLabels:
app: backend-v1
rules:
- from:
- source:
principals: ["cluster.local/ns/prod-ns/sa/frontend-v1"]
to:
- operation:
methods: ["POST"]
paths: ["/api/v1/data"]
Değerlendirme sırasını anlamak çok önemlidir. Birden fazla ilkeniz varsa, Istio bunları belirli bir sırayla işler. Bir DENY (Reddet) ilkesi, ALLOW (İzin Ver) ilkesi olsa bile trafiği hemen engelleyecektir. Tersine, eşleşen hiçbir DENY ilkesi yoksa, isteğin devam etmesi için bir ALLOW ilkesinin eşleşmesi gerekir.
Uygulama İçin En İyi Uygulamalar
Istio ile sıfır-güvenlik güvenliğini uygularken, servisler arası iletişiminizi denetleyerek başlayın. Hangi servislerin birbirleriyle konuştuğunu anlamak ve yetkisiz veya şüpheli trafik desenlerini belirlemek için Istio'nun telemetri araçlarını kullanın. Görünürlüğe sahip olduktan sonra, yalnızca meşru trafiğe izin veren izin listesi ilkeleri oluşturabilirsiniz.
Ayrıca, aşırı geniş yetkilendirme ilkeleri yerleştirmekten kaçının. Trafik için bir ad alanından izin vermek yerine, bireysel servis hesaplarını belirtin. Bu, bir servis ele geçirildiğinde hasarın yayılmasını minimize eder. Uygulama mimariniz geliştiğinde ilkelerinizi düzenli olarak gözden geçirin ve güncelleyin.
Sonuç
Istio Yetkilendirme İlkelerinin uygulanması, Kubernetes ortamlarında sağlam bir sıfır-güvenlik güvenlik pozisyonu elde etmek için kritik bir adımdır. Güvenlik kararlarını ağ katmanından servis mesh'ine kaydırarak, servisler arası iletişim üzerinde ince taneli kontrol elde edersiniz. İlk yapılandırma dikkatli planlama ve uygulamanızın trafik akışlarına derin bir anlayış gerektirse de, artan güvenlik, uyumluluk ve operasyonel görünürlük uzun vadeli faydaları, bunu herhangi bir DevOps ekibi için paha biçilmez bir yatırım haline getirir. Bulut-native teknolojileri benimsemeye devam ettikçe, güvenliğin tek seferlik bir yapılandırma değil, doğrulama ve iyileştirme sürekliliği olan bir süreç olduğunu unutmayın.