Network ACL Incus : segmenter comme des Security Groups

Dans un VPC OVN, les instances se parlent librement par défaut. Pour une application sérieuse, on veut l'inverse : que le web joigne l'app, que l'app joigne la base, et que le web ne touche jamais la base. Les network ACL d'Incus jouent exactement le rôle des Security Groups : des règles qui se référencent entre elles et s'appliquent par instance. Ce guide montre comment segmenter une 3-tiers, et surtout un piège d'enforcement à connaître, avec son contournement. Testé sur un cluster Incus OS. Pour qui durcit son cloud privé.

Ce que vous allez apprendre

Ce qu'est une network ACL Incus et son rapport aux Security Groups.
Écrire des règles qui référencent d'autres ACL (segmentation par rôle).
Appliquer une ACL à une instance.
Le piège du default-reject et son workaround.

Prérequis

Un réseau OVN fonctionnel : voir OVN dans Incus. Les ACL ne s'appliquent qu'aux réseaux OVN.
Des instances déjà lancées sur ce réseau (par exemple web1, api1, db1).

Une ACL Incus, c'est un Security Group

Une network ACL est un jeu de règles ingress (trafic entrant) et egress (trafic sortant), qu'on attache à une instance. Sa force : une règle peut désigner comme source ou destination le nom d'une autre ACL. Toutes les instances portant cette ACL forment alors un groupe logique, exactement comme un Security Group qui en référence un autre.

On crée un groupe par tier :

incus network acl create tier-web
incus network acl create tier-app
incus network acl create tier-db

Écrire les règles de segmentation

L'app n'accepte que le web, la base n'accepte que l'app. On exprime ça avec source pointant l'ACL du tier amont :

incus network acl rule add tier-app ingress action=allow protocol=tcp source=tier-web destination_port=8080
incus network acl rule add tier-db  ingress action=allow protocol=tcp source=tier-app destination_port=5432

La règle « autoriser le port 8080 depuis tier-web » signifie : toute instance portant l'ACL tier-app accepte le port 8080 uniquement des instances portant tier-web. C'est le mécanisme des Security Groups.

Appliquer les ACL aux instances

Une ACL n'a d'effet qu'attachée au NIC d'une instance. Comme le device eth0 existe déjà (créé par --network), on le modifie avec set (et non override) :

incus config device set web1 eth0 security.acls=tier-web \
  security.acls.default.ingress.action=drop \
  security.acls.default.egress.action=allow

On répète pour chaque instance : tier-web sur les web, tier-app sur les app, tier-db sur la base. La clé security.acls.default.ingress.action=drop pose une politique par défaut restrictive : tout ce qui n'est pas explicitement autorisé est bloqué.

Le piège du default-reject

En théorie, ce default.ingress.action=drop suffit à bloquer le web vers la base. En pratique, une limitation connue (lxc/incus#2851) fait que le reject par défaut n'est pas toujours appliqué au trafic est-ouest : le web parvient à joindre la base alors qu'il devrait être bloqué. Les ACL sont pourtant correctement programmées côté OVN, mais la règle de rejet implicite manque à l'appel.

Le workaround : interdire explicitement le web vers la base.

incus network acl rule add tier-db ingress action=drop source=tier-web

Vérifier la segmentation

On teste depuis chaque tier vers un port cible (avec un service qui écoute, ou /dev/tcp pour un simple test de connexion) :

# depuis web1 : web -> app doit passer, web -> db doit être bloqué
incus exec web1 -- bash -c 'echo > /dev/tcp/10.151.218.4/8080' && echo OPEN || echo BLOCKED
incus exec web1 -- bash -c 'echo > /dev/tcp/10.151.218.6/5432' && echo OPEN || echo BLOCKED
# depuis api1 : app -> db doit passer
incus exec api1 -- bash -c 'echo > /dev/tcp/10.151.218.6/5432' && echo OPEN || echo BLOCKED

web1 -> app:8080  OPEN
web1 -> db:5432   BLOCKED
api1 -> db:5432   OPEN

Le web atteint l'app, l'app atteint la base, mais le web ne touche jamais la base. La 3-tiers est segmentée, comme sur un cloud public.

À retenir

Les network ACL Incus sont les Security Groups du VPC OVN ; elles ne fonctionnent que sur OVN.
Une règle peut référencer une autre ACL comme source : c'est le groupe par rôle (web, app, db).
Une ACL s'applique en la posant sur le NIC (security.acls via config device set).
Ne vous fiez pas au reject par défaut (bug connu) : ajoutez des règles drop explicites.
Les règles s'appliquent immédiatement, sans redémarrer l'instance.

Prochaines étapes

OVN dans Incus : VPC et load balancers Le réseau virtuel sur lequel reposent les ACL.

Réseau Incus : bridge et NAT Les fondamentaux réseau avant OVN.

Cluster Incus La base multi-nœuds de votre cloud privé.

Incus OS sans interface Le socle immuable piloté par API.