Hogyan korlátozható az alkalmazások közötti interakció, amelyek külön namespace-ekben működnek?

Hálózati Szabályzatok: Meghatározzák, hogy mely pod-készletek engedélyezettek egymással és külső végpontokkal való kommunikációra. Alkalmazhatók Namespace, Pod vagy Egress szinten.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace
  namespace: default # A politikát alkalmazó Namespace
spec:
  podSelector: {} # Minden podra vonatkozik a 'default' Namespace-ben
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector: {} # Bejövő forgalom engedélyezése ugyanabból a Namespace-ből
  // Nincs egress szekció, ami alapértelmezés szerint blokkolja az összes kimenő forgalmat
  // Kivéve azokat az eseteket, amelyek kifejezetten engedélyezettek.

Service Meshek (pl. Istio, Linkerd): Sidecar konténereket vezetnek be a podokba, és kezelik a hálózati forgalmat alkalmazás szinten. Lehetővé teszik biztonsági politikák végrehajtását, beleértve a Namespace közötti kommunikáció korlátozását.

• Mutual TLS (mTLS): Titkosítja és hitelesíti a teljes forgalmat a szolgáltatások között.
• Engedélyezési politikák: Meghatározzák, hogy mely szolgáltatások kommunikálhatnak egymással azonosítás alapján.

OpenShift-ben Namespace-specifikus SecurityContextConstraints (SCC): Korlátozzák a podok lehetőségeit adott Namespace-ekben, befolyásolva a hálózati lehetőségeket.

Külön cluster különböző biztonsági zónákhoz: A legszigorúbb módszer, de a legköltségesebb is. Teljesen izolálja a különböző cluster-eken futó alkalmazásokat.

Tűzfal szabályok: Hálózati infrastruktúra szintjén konfigurált szabályok (pl. AWS Security Groups, GCP Firewall Rules), amelyek engedélyezik vagy blokkolják a forgalmat a különböző Namespace-ekben lévő Worker Nodes között.

Hálózati szegmentáció hypervisor szinten: Virtuális gépek esetében alkalmazott, ahol minden Namespace vagy Namespace csoport külön alhálózatban helyezkedik el, megfelelő útválasztási és tűzfal szabályokkal.