---
title: "Isolation réseau et sécurité"
description: "Comment le réseau est isolé entre clients sur Kontainers : qui peut joindre qui, le rôle du label exposition: public, et ce que cela implique pour vos environnements."
source_url:
  html: https://docs.blackswift.cloud/comprendre/isolation-reseau/
  md: https://docs.blackswift.cloud/comprendre/isolation-reseau.md
---

# Isolation réseau et sécurité

> Comment le réseau est isolé entre clients sur Kontainers : qui peut joindre qui, le rôle du label exposition: public, et ce que cela implique pour vos environnements.

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 :

```bash
kubectl get networkpolicies -n <votre-namespace>
```

```text
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 :

1. **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](https://docs.blackswift.cloud/deployer/exposer-en-https.md)).
2. **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) :

   ```yaml
   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](https://docs.blackswift.cloud/reference/mutations-et-politiques.md#politiques-de-rejet)) ;
- **TLS automatique** : certificats Let's Encrypt émis et renouvelés par la
  plateforme ([guide](https://docs.blackswift.cloud/deployer/exposer-en-https.md)) ;
- **Stockage chiffré et répliqué** ([détails](https://docs.blackswift.cloud/deployer/stockage-persistant.md)).

## En cas de problème réseau

Connexion refusée, service injoignable, certificat bloqué : suivez la
[checklist de diagnostic](https://docs.blackswift.cloud/depanner/checklist-de-diagnostic.md#connexion-refusée-vers-un-autre-service).