Isolation réseau et sécurité

Vos namespaces vivent dans un cluster mutualisé : l’isolation réseau entre clients est assurée par la plateforme, via des NetworkPolicies que vous pouvez consulter mais pas modifier :

kubectl get networkpolicies -n <votre-namespace>

NAME                  POD-SELECTOR        AGE
blackswift-public     exposition=public   ...
blackswift-standard   <none>              ...

Qui peut joindre qui ?

Source du trafic	Vers vos pods	Autorisé ?
Un pod du même namespace		✅
Un pod d’un autre namespace de votre organisation		✅
Les services de la plateforme (ingress, monitoring…)		✅
Un pod d’une autre organisation		❌ bloqué by design
Internet, via l’Ingress HTTP(S)		✅ (transite par le reverse-proxy plateforme)
Internet, en direct (NodePort, LoadBalancer)		❌ sauf label `exposition: public` sur les pods

En sortie (egress), vos pods sont libres : Internet et les services de votre organisation sont joignables sans configuration.

Le label `exposition: public`

La politique blackswift-standard protège vos pods de tout trafic entrant extérieur à votre organisation. Deux chemins pour recevoir du trafic public :

L’Ingress HTTP(S) — aucun label requis : le trafic entre par le reverse-proxy de la plateforme, qui est autorisé à joindre vos pods. C’est le chemin recommandé pour tout ce qui est web (guide).
L’exposition directe (Service NodePort ou LoadBalancer) — le trafic arrive directement sur vos pods : vous devez déclarer explicitement cette intention en posant le label exposition: public sur les pods (pas sur le Service) :
```
template:
  metadata:
    labels:
      app: mon-app
      exposition: public
```

Le piège à connaître : dev peut joindre prod

L’ouverture intra-organisation vaut pour tous vos namespaces : un pod de c-acme-rtximz-dev peut joindre la base de données de c-acme-rtximz-prod, et vous ne pouvez pas poser de NetworkPolicy pour l’empêcher.

Ce comportement est utile (un namespace tooling peut superviser dev et prod), mais impose de la rigueur : des secrets distincts par environnement, et jamais d’URL de prod dans une configuration de dev.

Le reste de la sécurité

Pod Security Standard baseline : pods privilégiés, hostPath, hostNetwork… rejetés à la création (détails) ;
TLS automatique : certificats Let’s Encrypt émis et renouvelés par la plateforme (guide) ;
Stockage chiffré et répliqué (détails).

En cas de problème réseau

Connexion refusée, service injoignable, certificat bloqué : suivez la checklist de diagnostic.