Sécuriser Incus : conteneurs non privilégiés, limites et projets restreints

Incus est sûr par défaut : ses conteneurs sont non privilégiés, c'est-à-dire que le root de l'instance n'est pas le root de l'hôte. Encore faut-il ne pas défaire cette protection et savoir cloisonner et limiter. Ce guide explique l'idmap qui isole les conteneurs, montre comment plafonner les ressources, et met en place un projet restreint qui interdit les conteneurs privilégiés. Testé sur Incus 7.0. Pour qui héberge des instances qui ne se font pas confiance.

Ce que vous allez apprendre

• Pourquoi un conteneur non privilégié est plus sûr (l'idmap).
• Limiter CPU et mémoire d'une instance.
• Cloisonner avec un projet restreint.
• Les flags security.privileged et security.nesting à manier avec prudence.

Prérequis

• Un serveur Incus fonctionnel : voir installer Incus.
• Les bases des profils et projets : voir Profils et projets Incus.

Le socle : les conteneurs non privilégiés

C'est la protection fondamentale d'Incus, active sans rien configurer. Un conteneur non privilégié décale les identifiants (idmap) : le root (UID 0) de l'instance correspond à un UID inoffensif et élevé sur l'hôte.

incus exec sec-lab -- cat /proc/self/uid_map

         0    1000000 1000000000

Cette ligne se lit : l'UID 0 dans le conteneur commence à 1000000 sur l'hôte, sur une plage d'un milliard d'UID. Concrètement, si un attaquant devient root dans le conteneur et s'échappe, il n'est qu'un utilisateur sans aucun privilège sur l'hôte. C'est toute la différence avec un conteneur Docker privilégié classique.

Limiter les ressources

Un conteneur sans limite peut épuiser le CPU ou la mémoire de l'hôte et affamer ses voisins (déni de service). On plafonne avec les clés limits.*.

incus config set sec-lab limits.cpu=1 limits.memory=512MiB
incus config show sec-lab | grep limits

  limits.cpu: "1"
  limits.memory: 512MiB

Ces limites sont appliquées à chaud et se déclinent (limits.cpu.allowance pour un quota temporel, limits.memory.swap, limits.processes). Sur un hôte partagé, plafonner est une mesure de sécurité, pas seulement de performance.

Cloisonner avec un projet restreint

Un projet isole un ensemble d'instances. En le passant en restricted=true, on interdit les fonctionnalités dangereuses à tout ce qui y est créé, quelle que soit la commande de l'utilisateur.

1. Créer le projet et le restreindre :

   incus project create confined
   incus project set confined restricted=true

2. Vérifier qu'un conteneur privilégié y est refusé :

   incus launch images:debian/13 badct --project confined -c security.privileged=true

   Error: ... Invalid value "true" for config "security.privileged" on
   container "badct" of project "confined": Privileged containers are forbidden

Le refus vient du projet, pas d'une convention : même un administrateur ne peut pas créer un conteneur privilégié dans un projet restreint. On affine ensuite avec les clés restricted.* (restricted.containers.nesting, restricted.devices.disk, restricted.networks.access) pour cadrer précisément ce que le projet autorise.

Un projet restreint démarre volontairement bridé

Un projet fraîchement restreint n'hérite pas des périphériques de l'hôte : son profil default peut manquer de disque racine ou de réseau, et un incus launch y échoue alors sur No root device could be found. C'est voulu : à vous d'ajouter explicitement, dans le profil du projet, le pool et le réseau autorisés. La restriction part du principe « rien n'est permis ».

Les flags à manier avec prudence

Deux paramètres défont l'isolation par défaut. Les activer doit être un choix conscient, jamais un réflexe pour « faire marcher » quelque chose.

• security.privileged=true : rend le conteneur privilégié (root du conteneur = root de l'hôte). Une évasion devient une compromission de l'hôte. À proscrire sauf besoin très spécifique et instance de confiance.
• security.nesting=true : autorise à faire tourner Incus ou Docker dans le conteneur. Pratique (c'est ce qui permet les labs imbriqués), mais élargit la surface d'attaque. À réserver aux cas qui l'exigent.

security.privileged annule la protection principale

Passer un conteneur en privilégié supprime l'idmap : le root interne redevient le root de l'hôte. Toute la sécurité décrite plus haut tombe. Si un conteneur a besoin d'une capacité précise, préférez l'ajouter finement (security.syscalls.intercept.*, un device dédié) plutôt que de tout ouvrir avec security.privileged.

Autres leviers

Au-delà de ces bases, Incus applique par défaut un profil AppArmor par instance et un filtrage seccomp des appels système. Pour l'accès distant à l'API, privilégiez l'authentification par certificat TLS ou OIDC plutôt qu'un accès large, et cloisonnez les droits par projet. Ces mécanismes se combinent : idmap, limites, projet restreint et AppArmor forment des couches indépendantes.

À retenir

• Les conteneurs Incus sont non privilégiés par défaut : l'idmap décale le root hors de l'hôte.
• Plafonner CPU et mémoire (limits.cpu, limits.memory) protège l'hôte partagé.
• Un projet restreint (restricted=true) interdit les conteneurs privilégiés, même à un admin.
• security.privileged=true annule l'idmap : à éviter ; security.nesting élargit la surface.
• Un projet restreint part de « rien n'est permis » : ajouter explicitement pool et réseau autorisés.

FAQ : questions fréquentes sur la sécurisation d'Incus

Un conteneur Incus est-il privilégié par défaut ?

Non. Les conteneurs Incus sont non privilégiés par défaut : un idmap décale les identifiants, si bien que le root du conteneur correspond à un UID élevé et sans privilège sur l'hôte. Une évasion ne donne donc aucun droit réel sur la machine.

Comment limiter le CPU et la mémoire d'une instance Incus ?

Avec les clés limits : incus config set instance limits.cpu=1 limits.memory=512MiB. Elles s'appliquent à chaud et se déclinent en limits.cpu.allowance, limits.memory.swap ou limits.processes. Sur un hôte partagé, c'est aussi une mesure de sécurité.

Comment empêcher la création de conteneurs privilégiés dans Incus ?

En passant le projet en restricted=true avec incus project set. Toute tentative de créer un conteneur avec security.privileged=true y est refusée, même par un administrateur, avec l'erreur Privileged containers are forbidden.

Faut-il activer security.privileged sur un conteneur Incus ?

À éviter. security.privileged=true supprime l'idmap et rend le root du conteneur égal au root de l'hôte : une évasion devient une compromission de l'hôte. On préfère ajouter finement une capacité ou un device dédié plutôt que tout ouvrir.

Prochaines étapes

Profils et projets Cloisonner et industrialiser.

GPU dans Incus Attacher une carte NVIDIA.

Accès distant et UI Administrer Incus à distance.

×

📖 Voir la documentation →