Hoe beperk je de interactie tussen applicaties die in verschillende namespaces werken?

Netwerkbeleid: Bepalen welke sets van pods zijn toegestaan om met elkaar en met externe eindpunten te communiceren. Wordt toegepast op Namespace-, Pod- of Egress-niveau.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace
  namespace: default # Namespace waarop het beleid van toepassing is
spec:
  podSelector: {} # Van toepassing op alle pods in de Namespace 'default'
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector: {} # Staat inkomend verkeer toe van pods in dezelfde Namespace
  // Geen egress-sectie, wat standaard al het uitgaande verkeer blokkeert
  // Behalve in gevallen die expliciet zijn toegestaan.

Service Meshes (bijvoorbeeld, Istio, Linkerd): Introduceren sidecar-containers in pods en beheren het netwerkverkeer op applicatieniveau. Stellen het implementeren van beveiligingsbeleid mogelijk, inclusief beperkingen op de interactie tussen Namespaces.

• Mutual TLS (mTLS): Versleutelt en verifieert al het verkeer tussen services.
• Autorisatiebeleid: Bepaalt welke services met elkaar kunnen communiceren op basis van identiteit.

Namespace-specifieke SecurityContextConstraints (SCC) in OpenShift: Beperken de mogelijkheden van pods in specifieke Namespaces, wat invloed heeft op netwerkmogelijkheden.

Aparte Cluster voor Verschillende Beveiligingszones: De strengste methode, maar ook de duurste. Isoleert volledig de applicaties die in verschillende clusters draaien.

Firewallregels: Configuratie van regels op netwerk-infrastructuurniveau (bijvoorbeeld, AWS Security Groups, GCP Firewall Rules), die verkeer tussen subnetten toestaan of blokkeren waar de Worker Nodes van verschillende Namespaces zich bevinden.

Netwerksegmentatie op Hypervisor-niveau: Gebruikt in virtuele machine-omgevingen, waarbij elke Namespace of Namespace-groep in een apart subnet wordt geplaatst met bijbehorende routing- en firewallregels.