Kubernetes’e birden fazla kiracı güvenli bir şekilde dağıtma ve çalıştırma


Siber güvenlik platformu

Kubernetes, modern bulut yerel uygulamalarının belkemiği haline geldi ve evlat edinme büyüdükçe, kuruluşlar aynı Kubernetes altyapısında birden fazla kiracı çalıştırarak iş yüklerini ve kaynakları birleştirmeye çalışıyor. Bu kiracılar, geliştirme ve üretim için Kubernetes kümesini paylaşan bir şirket içindeki iç ekipler veya departmanlar olabilir. Alternatif olarak, paylaşılan altyapı üzerinde müşteri iş yüklerini barındıran SaaS sağlayıcıları olan harici istemciler olabilirler.

Multennancy maliyet verimliliği ve merkezi yönetim sunarken, güvenlik ve operasyonel zorluklar da sunar. Kullanıcıların dikkate alınması gereken üç husus şunları içerir:

  • Kiracılar arasında güçlü bir tecrit sağlıyorsunuz?
  • Kaynakları nasıl yönetiyorsunuz ve bir kiracının diğerini etkilemesini nasıl önlüyorsunuz?
  • Düzenleyici ve uyumluluk gereksinimlerini nasıl karşılıyorsunuz?

Bu endişeleri gidermek için, uygulayıcıların birden fazla kiracıyı Kubernetes’e güvenli bir şekilde dağıtmak için üç birincil seçeneği vardır. Burada, üç seçeneğe dalacağız ve her biri için ana hususları özetleyeceğiz.

Kubernetes’e birden çok kiracı nasıl dağıtılır

Ağ politikaları, RBAC ve Güvenlik Kontrolleri ile Ad Alanı Tabanlı Yalıtım

Ad alanları, mantıksal izolasyon için Kubernetes’in yerleşik mekanizmasıdır. Bu yaklaşım:

  • Ad alanları: Kiracı iş yüklerini ayırmak için mantıksal sınırlar.
  • RBAC (rol tabanlı erişim kontrolü): Kiracının ad alanlarına ve kaynaklarına erişimini kısıtlar.
  • Ağ Politikaları: Pods ve ad alanları arasındaki giriş ve çıkış trafiğini kontrol eder.
  • Kaynak Kotaları: Gürültülü komşuları önlemek için CPU, bellek ve diğer kaynakları sınırlar.

Avantajlar, kiracılar küme altyapısını paylaştıkça maliyet etkinliğini içerir. Dahası, bu yaklaşımı tek bir kümedeki merkezi işlemlerle yönetmek kolaydır. Sınırlamalar, RBAC veya ağ politikalarında yanlış yapılandırmalar meydana gelirse güvenlik risklerini içerir.

Aşağıda, ad alanı tabanlı izolasyon yaklaşımı söz konusu olduğunda ek hususlarla daha derin bir dalış bulunmaktadır.

  • İzolasyon Seviyesi: Ad alanları, RBAC ve ağ politikaları kullanılarak mantıksal izolasyon. Uygun yapılandırmaya dayanır.
  • Güvenlik: Paylaşılan bileşenlerdeki (API sunucusu gibi) veya yanlış yapılandırılmış politikalardaki güvenlik açıkları ihlallere yol açabilir.
  • Kaynak çekişmesi: Tüm kiracılar, düğümler ve kontrol uçakları gibi küme kaynaklarını paylaşarak potansiyel kaynak tartışmasına yol açar.
  • Ölçeklenebilirlik: Yeni kiracıların eklenmesi, yeni bir ad alanı oluşturulmasını ve mevcut küme içinde politikalar uygulanmasını gerektirir.
  • Maliyet: Paylaşılan küme kaynakları altyapı ve operasyonel maliyetleri azaltır.
  • Operasyonel karmaşıklık: Yönetmek için tek küme, ancak ad alanlarının, RBAC ve ağ politikalarının dikkatli bir şekilde yapılandırılmasını gerektirir.
  • Performans Yalıtım: Kiracılar, kaynak artışları sırasında performansı potansiyel olarak etkileyen kontrol düzlemini ve düğüm kaynaklarını paylaşırlar.
  • Yönetim Tepesi: Bir kümede kiracılar üzerinde merkezi kontrol.

Küme seviyesi izolasyonu

Küme düzeyinde izolasyon yaklaşımı, her kiracıya, tamamen fiziksel veya sanal izolasyon sağlayarak özel bir Kubernetes kümesini atar. Rancher, Google Anthos ve AWS EKS gibi araçlar birden fazla kümeyi yönetmeyi basitleştirir.

Bu yaklaşımın avantajları, kiracılar herhangi bir küme bileşenini paylaşmadığından güçlü izolasyon içerir. Güvenlik seviyeleri de yüksektir, kiracılar arası veri sızıntısı veya kaynak tartışması riski yoktur.

Bununla birlikte, yüksek maliyet gibi sınırlamalar mevcuttur: her küme kontrol düzlemine ve düğüm maliyetlerine neden olur. Ek sınırlamalar operasyonel karmaşıklık ve ölçeklenebilirlik zorlukları içerir. Birden fazla kümeyi yönetmek, yükseltmek ve izlemek kaynak yoğundur ve yeni kümelerin sağlanması kiracıyı işe almayı geciktirebilir.

İşte küme düzeyinde izolasyon yaklaşımı ile ilgili daha fazla ayrıntı ve husus.

  • İzolasyon Seviyesi: Fiziksel veya sanal izolasyon; Paylaşılan küme bileşeni yok.
  • Güvenlik: Yüksek güvenlik, bir kiracının güvenlik açıkları başkalarını etkilemez.
  • Kaynak çekişmesi: Her kiracı için özel kaynaklar kaynak müdahalesi veya çekişme sağlamaz.
  • Ölçeklenebilirlik: Yeni kiracıların eklenmesi, ölçeklenebilirliği sınırlandırarak yeni kümelerin sağlanmasını ve yönetilmesini gerektirir.
  • Maliyet: Ayrı kümeler altyapı, operasyonel ve izleme maliyetlerini arttırır.
  • Operasyonel karmaşıklık: Birden çok kümeyi yönetme, önemli operasyonel ek yük ekler ve özel araçlar gerektirir.
  • Performans Yalıtım: Özel kümeler nedeniyle performans izole edilir.
  • Yönetim Tepesi: Ayrı kontrol düzlemleri ve kümeler yönetim yükünü arttırır.

Sanal kümeler

Sanal kümeler, paylaşılan bir fiziksel küme içinde kiracıya özgü kontrol uçakları sağlar. Her kiracı, işçi düğümlerini ve fiziksel altyapıyı paylaşırken sanal Kubernetes ortamını alır.

Avantajlar, güçlü mantıksal izolasyonu içerir, yani kiracı iş yüklerinin bağımsız olarak çalıştığı anlamına gelir. Paylaşılan işçi düğümleri altyapı maliyetlerini azalttığı için bu yaklaşım da maliyet verimlidir. Başka bir avantaj, sanal kümeler hızlı bir şekilde sağlanabilir – çünkü saniyeler içinde.

Sınırlamalar, ad alan tabanlı izolasyona kıyasla altyapı düzeyinde izolasyondan kaynaklanan daha yüksek karmaşıklık ve işçi düğümleri aşırı işlenirse performans etkisi içerir.

Aşağıdaki liste, sanal kümeler yaklaşımıyla ilgili ek hususlar içermektedir.

Sanal kümeler

  • İzolasyon Seviyesi: Her kiracı, paylaşılan bir fiziksel kümenin içinde çalışan bir sanal Kubernetes kümesi alır.
  • Güvenlik: Sanal kümeler kiracıya özgü kontrol uçakları sağlar ve kiracılar arası sorun riskini azaltır.
  • Kaynak çekişmesi: Paylaşılan işçi düğümleri, ancak izole kontrol uçakları kontrol düzlemiyle ilgili işlemler için çekişmeyi azaltır.
  • Ölçeklenebilirlik: Mevcut fiziksel küme içinde yeni sanal kümeler hızlı bir şekilde sağlanabilir.
  • Maliyet: Paylaşılan altyapı, fiziksel kümelere kıyasla maliyetleri azaltır, ancak ad alanı izolasyonundan daha yüksektir.
  • Operasyonel karmaşıklık: Merkezi yönetim operasyonları fiziksel kümelere kıyasla basitleştirir, ancak yine de sanal kümelerin yönetilmesini içerir.
  • Performans Yalıtım: Kontrol düzlemleri izole edilir; Ancak, paylaşılan işçi düğümleri performansı etkiler.
  • Yönetim Tepesi: Fiziksel kümelere kıyasla basitleştirilmiş yönetim, ancak ad alanlarından daha ek yük.

Multi -Mitenancy’yi kabul etmeden bırakmanın etkileri nelerdir?

Sağlam bir çoklu deneme stratejisinin uygulanması kritiktir. Bunu yapmamak, güvenlik, uyum ve operasyonel verimsizlikler açısından yıkıcı sonuçlara yol açabilir. Belirli sorunlar şunları içerir:

  • Güvenlik İhlalleri: Paylaşılan kümelerdeki yanlış yapılandırmalar, bir kiracının başkasının iş yüklerine veya verilerine erişmesine izin verebilir.
  • Kaynak çekişmesi: Tek bir kiracı, paylaşılan kaynakları tekelleştirebilir ve başkaları için performansı düşürebilir.
  • Uyumsuzluk: Yetersiz izolasyon, HIPAA veya PCI-DSS gibi düzenleyici gereksinimleri karşılamamaya neden olabilir.
  • Operasyonel Verimsizlik: Kötü tasarlanmış multekenite, yönetim yükünü arttırır ve küme kesinti riski taşır.

Kubernetes’teki güvenli multitenancy, Kubernetes kümelerinin güvenlik ve güvenlik gereksinimleri için güvenlik duruşunu korumak için gereklidir. Multi-Meotancy, iş yüklerini ve kaynaklarını verimli bir şekilde birleştirir ve merkezi yönetim ile para tasarrufu sağlar, ancak ad alanı tabanlı izolasyon veya sanal kümelerin güvenli bir şekilde konuşlandırılması gibi en iyi uygulamalarla ele alınması gereken önemli güvenlik ve operasyonel zorluklar getirir.

Multiciterance’ın düzgün bir şekilde güvence altına alınamaması, uyum ihlallerine ve güvenlik boşluklarına yol açabilir, bu da Kubernetes’te güvenli ve verimli çok etli bir ortamın korunması için sağlam güvenlik önlemlerinin ve izolasyon tekniklerinin uygulanmasını sağlayabilir.

# # #

Yazar Biyografisi

Ratan Tipirneni, strateji tanımlamaktan, önde gelen infazdan ve ölçeklendirmekten sorumlu olduğu Tigera’da Başkan ve CEO’dur. Ratan, yazılım işletmelerini erken aşamadan yüz milyonlarca dolar gelire kadar inkübe etme, inşa etme ve ölçeklendirme deneyimi olan bir girişimci yöneticisidir. Birinci sınıf takımlar inşa etmenin bir sicili olan kanıtlanmış bir liderdir.

Reklam

LinkedIn Group Bilgi Güvenlik Topluluğumuza katılın!



Source link