Jak ograniczyć interakcję między aplikacjami…

Polityki sieciowe: Określają, które zestawy podów są dozwolone do komunikacji ze sobą i z zewnętrznymi punktami końcowymi. Obowiązują na poziomie Namespace, Pod lub Egress.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace
  namespace: default # Namespace, do którego odnosi się polityka
spec:
  podSelector: {} # Dotyczy wszystkich Podów w Namespace 'default'
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector: {} # Zezwala na ruch przychodzący od Podów w tym samym Namespace
  // Brak sekcji egress, co domyślnie blokuje cały wychodzący ruch
  // Z wyjątkiem przypadków, które są wyraźnie dozwolone.

Service Meshes (np. Istio, Linkerd): Wprowadzają sidecar kontenery do Podów i zarządzają ruchem sieciowym na poziomie aplikacji. Pozwalają na wdrażanie polityk bezpieczeństwa, w tym ograniczeń w komunikacji między Namespace.
- Mutual TLS (mTLS): Szyfruje i uwierzytelnia cały ruch między usługami.
- Polityki autoryzacji: Określają, które usługi mogą się ze sobą komunikować na podstawie tożsamości.
Namespace-specific SecurityContextConstraints (SCC) w OpenShift: Ograniczają możliwości Podów w określonych Namespace, wpływając na możliwości sieciowe.
Oddzielny klaster dla różnych stref bezpieczeństwa: Najbardziej rygorystyczna metoda, ale też najdroższa. Całkowicie izoluje aplikacje działające w różnych klastrach.
Reguły zapory sieciowej: Konfiguracja reguł na poziomie infrastruktury sieciowej (np. AWS Security Groups, GCP Firewall Rules), które zezwalają lub blokują ruch między podsieciami, w których znajdują się węzły robocze różnych Namespace.
Segmentacja sieci na poziomie hypervisor: Używana w środowiskach maszyn wirtualnych, gdzie każdy Namespace lub grupa Namespace jest umieszczona w osobnej podsieci z odpowiednimi regułami routingu i zapory.

Jak ograniczyć interakcję między aplikacjami działającymi w różnych przestrzeniach nazw?