Как да ограничим взаимодействието между приложения…

Мрежови политики: Определят кои набори от подове са разрешени да взаимодействат помежду си и с външни крайни точки. Прилагат се на ниво Namespace, Pod или Egress.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace
  namespace: default # Namespace, към който се прилага политиката
spec:
  podSelector: {} # Прилага се към всички подове в Namespace 'default'
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector: {} # Позволява входящ трафик от подове в същия Namespace
  // Няма секция egress, което по подразбиране блокира целия изходящ трафик
  // Освен в случаите, които са явно разрешени.

Service Meshes (например, Istio, Linkerd): Въвеждат страйдкар контейнери в подовете и управляват мрежовия трафик на ниво приложения. Позволяват реализирането на политики за сигурност, включително ограничаване на взаимодействието между Namespace.
- Mutual TLS (mTLS): Криптира и удостоверява целия трафик между услугите.
- Политики за авторизация: Определят кои услуги могат да взаимодействат помежду си въз основа на идентичността.
SecurityContextConstraints (SCC) специфични за Namespace в OpenShift: Ограничават възможностите на подовете в конкретни Namespace, влияят върху мрежовите възможности.
Отделен клъстер за различни зони за сигурност: Най-строгият метод, но и най-скъпият. Пълна изолация на приложенията, работещи в различни клъстери.
Firewall правила: Конфигурация на правила на ниво мрежова инфраструктура (например, AWS Security Groups, GCP Firewall Rules), които разрешават или забраняват трафик между подсетите, където се намират работните възли на различни Namespace.
Мрежова сегментация на ниво хипервизор: Използва се при работа с виртуални машини, където всеки Namespace или група Namespace се поставя в отделна подсетка с подходящи правила за маршрутизиране и защитна стена.

Как да ограничим взаимодействието между приложения, работещи в различни namespace-ове?