Cloud privé multi-tenant avec Incus : projects, quotas et peering

Un cluster Incus ne sert pas qu'une équipe : il peut héberger plusieurs tenants isolés, chacun avec ses instances, son VPC, ses quotas et ses accès. Le tout repose sur les projects, l'équivalent des comptes d'un cloud. Ce guide montre comment créer un tenant, lui poser des quotas réellement appliqués, lui émettre un credential confiné à son périmètre, et peerer deux VPC OVN entre tenants. Avec, à la fin, une mise au point honnête sur ce qui n'est pas encore là. Public avancé, orienté cloud privé.

Ce que vous allez apprendre

Utiliser un project comme tenant isolé.
Poser des quotas et vérifier qu'ils bloquent vraiment.
Émettre un credential scopé (l'équivalent d'une clé d'accès) et le révoquer.
Peerer deux VPC de tenants différents.

Prérequis

Un réseau OVN opérationnel : voir OVN dans Incus.
Un uplink existant (ici nommé UPLINK).

Le project, c'est le tenant

Un project isole ses instances, réseaux, profils et volumes. On active features.networks pour qu'il porte son propre VPC :

incus project create tenant-b -c features.networks=true

Chaque tenant crée ensuite son réseau OVN, ses instances, ses ACL, sans voir ceux des autres.

Poser des quotas, et vérifier qu'ils tiennent

Les quotas cadrent la consommation d'un tenant. On les pose sur le project :

incus project set tenant-b \
  limits.cpu=4 limits.memory=8GiB limits.instances=5 \
  restricted=true restricted.networks.uplinks=UPLINK

Un quota ne vaut que s'il est appliqué. On le vérifie en le dépassant volontairement. Avec limits.instances=2, la troisième instance est refusée :

incus launch images:debian/13 c3 --network vpc-b --storage ceph-rbd --project tenant-b

Error: Failed instance creation: Reached maximum number of instances in project "tenant-b"

Le message est sans ambiguïté : les quotas Incus bloquent réellement.

Émettre un credential scopé

Chaque utilisateur reçoit son certificat, restreint à son project. L'opérateur émet un token (l'équivalent d'une clé d'accès) :

incus config trust add alice --projects tenant-b --restricted

Client alice certificate add token:
eyJjbGllbnRfbmFtZSI6ImFsaWNlIi...

L'utilisateur ajoute ce token dans sa propre configuration, ce qui génère son certificat, automatiquement confiné :

incus remote add moncloud eyJjbGll...   # dans la config de l'utilisateur
incus project list moncloud:            # il ne voit QUE tenant-b

Il ne voit rien des autres tenants, et un listing du project default revient vide. Pour couper l'accès, on révoque le certificat comme on désactiverait une clé :

incus config trust remove <fingerprint>

Peerer deux VPC de tenants différents

Par défaut, deux VPC OVN de tenants différents sont isolés : ils ne se voient pas. Pour les relier, on crée un peering, à établir des deux côtés (relation mutuelle) :

incus network peer create vpc0  to-tenantb tenant-b/vpc-b --project default
incus network peer create vpc-b to-default default/vpc0   --project tenant-b

Une fois les deux moitiés en place, l'état passe à CREATED et le trafic route directement entre les deux VPC, sans repasser par l'uplink. Point remarquable : les ACL restent appliquées à travers le peering. Un tenant peut atteindre le web d'un autre (si autorisé), mais pas sa base de données si une ACL le bloque. C'est le comportement d'un VPC Peering couplé à des Security Groups.

Ce qui n'est pas encore là (soyons honnêtes)

Ce modèle couvre l'essentiel d'un cloud privé géré par l'équipe infra. Deux limites à connaître :

Pas de RBAC fin par ressource en standard : les certificats de confiance donnent un accès au niveau project, pas « lecture seule sur ce réseau ». La granularité fine passe par OpenFGA (backend d'autorisation), qui n'est pas encore exposé par toutes les versions.
Pas de portail self-service : l'utilisateur ne gère pas ses ressources depuis une console à son nom comme sur un cloud public. Tout se pilote en CLI/API (souvent via Terraform). Le portail multi-tenant reste une couche à construire au-dessus.

Pour un cloud privé d'entreprise piloté par IaC, c'est suffisant. Pour un cloud public self-service, il manque cette couche.

À retenir

Un project = un tenant isolé ; features.networks lui donne son propre VPC.
Les quotas (limits.*) sont appliqués : le dépassement est refusé.
Un credential scopé (config trust add --projects --restricted) confine l'utilisateur à son project ; la révocation coupe l'accès.
Le peering relie deux VPC (mutuel), et les ACL restent enforced à travers.
Manquent encore le RBAC fin (OpenFGA) et le portail self-service.

Prochaines étapes

OVN dans Incus : VPC et load balancers Le réseau virtuel de chaque tenant.

Network ACL (Security Groups) Segmenter le trafic, y compris à travers le peering.

Operations Center Piloter la flotte de clusters au-dessus des tenants.

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