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 fait le point sur le rejet par défaut, longtemps pris en défaut et corrigé depuis Incus 6.22. 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.
L'état réel du rejet par défaut selon votre version d'Incus.

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 default-reject : un bug corrigé, et ce qu'il faut en garder

Ce default.ingress.action=drop doit suffire à bloquer le web vers la base. Pendant un temps, il ne le faisait pas : sur les versions antérieures à Incus 6.22, le rejet implicite n'était pas appliqué au trafic est-ouest, et le web joignait la base alors qu'il aurait dû être bloqué. La cause n'était pas dans vos règles mais dans la programmation OVN du défaut : l'action egress par défaut était posée en allow, c'est-à-dire sans suivi de connexion, alors que toute règle personnalisée allow était, elle, traduite en allow-related.

Le défaut a été corrigé (lxc/incus#2851, PR #2985) en basculant l'egress par défaut sur allow-related. Le correctif est livré dans Incus 6.22.0 et rétroporté sur la branche 6.0, donc présent dans 6.0.6 LTS. Toute version supportée depuis mars 2026, la 7.0 LTS comprise, applique correctement le rejet par défaut.

Cela dit, la règle drop explicite garde une valeur qui ne dépend d'aucun bug. Elle écrit l'intention dans la configuration au lieu de la laisser dans un défaut implicite, elle survit à un changement de default.ingress.action, et elle se relit lors d'un audit. C'est la même logique qu'une règle deny explicite dans un Security Group.

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

Une règle explicite s'applique immédiatement, sans redémarrer l'instance.

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).
Le reject par défaut est corrigé depuis Incus 6.22 (rétroporté en 6.0.6 LTS) ; en deçà, posez des règles drop explicites, qui restent de toute façon plus lisibles.
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.