Les ACLs Tailscale (Access Control Lists) sont l’outil qui transforme un VPN basique en infrastructure sécurisée granulairement contrôlée. Avec quelques lignes de JSON, vous définissez qui peut accéder à quoi : devs vers staging, admins vers production, monitoring vers tous, jamais l’inverse. Couplé aux tags, vous obtenez un système RBAC simple et puissant. Voici le tutoriel pratique 2026.

Voir notre guide Tailscale.

Concepts clefs

Users : les comptes humains de votre tailnet (depuis Google/GitHub/SSO)
Groups : ensembles de users (devs, admins, ops)
Tags : labels appliqués à des machines (tag:prod, tag:staging, tag:db)
Hosts : alias d’IP/CIDR pour références plus lisibles
ACL rules : règles src → dst qui autorisent (ou refusent) le trafic

Tailscale ACLs reposent sur trois concepts. Les Tags identifient les machines (tag:web, tag:db, tag:dev). Les Groups identifient les humains (group:admins, group:developers). Les ACL Rules autorisent ou refusent les flux entre tags et groups. Cette abstraction par étiquettes (au lieu d’IPs) reste valide même si vos serveurs changent d’IP, ce qui rend la sécurité maintenable sur plusieurs années sans révision permanente.

ACLs par défaut

Par défaut, Tailscale autorise tout vers tout dans le tailnet. C’est pratique pour démarrer, dangereux en équipe sérieuse. Première chose à faire en passant à plusieurs personnes : restreindre.

Par défaut, Tailscale autorise tout le monde à voir tout le monde. Cette ouverture est dangereuse en production. La première action est de remplacer la rule par défaut par {"Action": "accept", "Src": ["autogroup:admin"], "Dst": ["*:*"]} qui n’autorise que les admins à voir tous les nodes. Puis ajoutez des règles spécifiques pour les autres groupes (developers peuvent ssh vers tag:dev mais pas vers tag:prod, par exemple).

Étape 1 — Définir tags et tagOwners

Les tags doivent avoir un « owner » — l’utilisateur autorisé à appliquer ce tag à une machine :

{
  "tagOwners": {
    "tag:prod":    ["admin@exemple.sn"],
    "tag:staging": ["admin@exemple.sn", "dev1@exemple.sn"],
    "tag:db":      ["admin@exemple.sn"],
    "tag:bastion": ["admin@exemple.sn"]
  }
}

Dans le fichier ACL JSON de Tailscale Admin Console, ajoutez la section tagOwners qui définit qui peut assigner quel tag. Exemple : "tag:web": ["group:admins"], "tag:db": ["group:admins"]. Sans tagOwner, n’importe quel utilisateur peut s’attribuer un tag élevé et bypass les règles. Cette discipline isole les rôles : un développeur ne peut pas se déclarer prod-server pour accéder à la DB.

Étape 2 — Définir les groupes

{
  "groups": {
    "group:admins":  ["admin@exemple.sn"],
    "group:devs":    ["dev1@exemple.sn", "dev2@exemple.sn"],
    "group:monitor": ["monitor@exemple.sn"]
  }
}

Section groups du JSON ACL : "group:admins": ["alice@example.sn", "bob@example.sn"]. Listez chaque utilisateur par email Tailscale (correspondant au compte Google ou OIDC utilisé pour s’authentifier). Pour une équipe à Plateau de 15 personnes, prévoyez 3-5 groups (admins, developers, support, external-consultants). Cette structure simple couvre 95 % des besoins de granularité d’accès.

Étape 3 — Définir les ACLs

{
  "acls": [
    // Admins : accès total
    {
      "action": "accept",
      "src":    ["group:admins"],
      "dst":    ["*:*"]
    },
    // Devs : accès staging seulement, ports 22, 80, 443, 5432
    {
      "action": "accept",
      "src":    ["group:devs"],
      "dst":    ["tag:staging:22,80,443,5432"]
    },
    // Monitoring : ping et HTTP partout
    {
      "action": "accept",
      "src":    ["group:monitor"],
      "dst":    ["*:80,443,9100"]
    },
    // Bastion peut SSH vers prod
    {
      "action": "accept",
      "src":    ["tag:bastion"],
      "dst":    ["tag:prod:22"]
    }
  ]
}

Étape 4 — SSH ACL séparé

Tailscale SSH a sa propre policy distincte des ACLs réseau :

{
  "ssh": [
    // Admins peuvent SSH en root sur prod
    {
      "action": "accept",
      "src":    ["group:admins"],
      "dst":    ["tag:prod"],
      "users":  ["root", "deploy"]
    },
    // Devs peuvent SSH en deploy sur staging
    {
      "action": "accept",
      "src":    ["group:devs"],
      "dst":    ["tag:staging"],
      "users":  ["deploy"]
    }
  ]
}

Étape 5 — Appliquer les tags aux VPS

# Sur le VPS de production
sudo tailscale up --advertise-tags=tag:prod --ssh

# Sur le VPS de staging
sudo tailscale up --advertise-tags=tag:staging --ssh

# Sur la base
sudo tailscale up --advertise-tags=tag:db,tag:prod

Sur chaque VPS, lancez tailscale up avec le flag –advertise-tags : tailscale up --advertise-tags=tag:web,tag:prod. Le node demande validation à un membre du groupe défini comme tagOwner avant que les tags soient effectivement appliqués. Vérifiez dans l’Admin Console que les tags apparaissent bien sur la machine. Cette validation à deux niveaux empêche un opérateur compromis de bypasser les règles via re-tagging arbitraire.

Étape 6 — Hosts (alias d’IP/CIDR)

{
  "hosts": {
    "office-network": "10.0.0.0/24",
    "client-vpn":     "192.168.50.0/24"
  },
  "acls": [
    {
      "action": "accept",
      "src":    ["group:admins"],
      "dst":    ["office-network:*"]
    }
  ]
}

La section hosts permet de nommer des IP ou CIDR pour rendre les ACLs lisibles. Exemple : "office": "100.64.0.0/24", "vpn-gateway": "100.100.100.1". Référencez ensuite dans les rules : {"Src": ["office"], "Dst": ["tag:web:80,443"]}. Pour une entreprise multi-sites (siège Dakar, agence Abidjan, télétravail), chaque site reçoit son CIDR Tailscale et les règles deviennent géo-conscientes.

Étape 7 — Tester avec le validator

Avant de pousser les ACLs, le dashboard Tailscale a un validator qui simule « user X peut-il accéder à dst Y sur port Z ? ». Utilisez-le systématiquement.

Avant d’appliquer, l’Admin Console Tailscale propose un Validator qui simule les flux ACL. Saisissez source (utilisateur ou tag) et destination (tag:host:port). Le résultat indique allow ou deny avec la rule qui matche. Cette pré-validation évite les downtime imprévus quand une rule mal écrite bloque tout. Pour un changement majeur d’ACL en production, le test du validator est non-négociable avant le commit.

Patterns courants

Lecture seule monitoring : groupe monitor → tag:* sur ports d’API metrics uniquement
Bastion only : devs ne peuvent SSH qu’au bastion, bastion peut SSH partout
Read-only DB : groupe analytics → tag:db:5432 mais pas de SSH
Time-bound access : ACL avec autoApprovers et invitations expirantes

Quatre patterns récurrents en entreprise. Premier : segmentation prod/staging/dev (les développeurs voient dev, les opérateurs voient staging et prod, les admins voient tout). Deuxième : least-privilege (chaque service voit uniquement ses dépendances directes, pas tout le réseau). Troisième : break-glass (un groupe break-glass:emergency activable manuellement pour les incidents critiques). Quatrième : auditeurs externes (groupe auditors:Q2-2026 avec accès lecture seule limité dans le temps).

Adaptation Afrique de l’Ouest

Pour une équipe ouest-africaine de 3-10 développeurs, les ACLs Tailscale offrent du RBAC professionnel sans déployer Active Directory ou autre LDAP. Configuration en JSON commit dans Git, peer review possible, audit clair. Idéal pour une PME tech qui veut grandir sans complexifier la sécurité.

Pour une PME basée à Cocody ou Sicap Liberté qui héberge ses serveurs sur Hetzner Falkenstein, Tailscale élimine la complexité du VPN OpenVPN ou WireGuard manuel. Les développeurs en télétravail à Bamako se connectent en 1 clic au réseau d’entreprise via leur app Tailscale (gratuite jusqu’à 100 nodes). La latence ouest-Falkenstein reste 60-90 ms, suffisamment rapide pour le SSH et la maintenance distante. Pour les besoins très haute performance, Tailscale Subnet Router permet d’exposer un sous-réseau local via un node bridge.

Erreurs fréquentes

Erreur	Cause	Solution
« tag is not declared »	tagOwners manquant	Ajouter tagOwners avant ACL rules
Tag refusé sur tailscale up	User pas dans tagOwners	Ajouter l’email comme owner du tag
SSH refuse même avec accept	Bloc ssh: pas configuré	Ajouter section ssh: distincte
Lockout après push ACL	Trop restrictif	Garder toujours admin avec accès :

Pourquoi modeliser les permissions par tags plutot que par utilisateur

Dans un tailnet jeune, on autorise volontiers chaque membre individuellement : marie peut acceder a la base, abdou au serveur de build, fatou aux deux. Au-dela de cinq personnes, ce modele devient ingerable. Tailscale propose une approche par tags : on tague les machines (tag:db, tag:build, tag:prod) et les utilisateurs (autogroup:admin, group:devs) puis on ecrit des regles entre groupes. Quand un nouveau developpeur arrive a Dakar ou Cotonou, il suffit de l’ajouter au groupe devs : ses droits decoulent automatiquement.

Pour une PME tech qui paie son tailnet sur le plan Premium a 6 USD par utilisateur et par mois (environ 3940 FCFA), cette gouvernance reduit aussi les couts caches : moins d’erreurs humaines, moins d’audits manuels, moins d’incidents lies a un acces oublie apres le depart d’un prestataire.

Etape 1 : Recenser les machines et les profils

Avant d’ecrire la moindre ACL, faites l’inventaire. Sur une feuille de calcul, listez chaque machine du tailnet avec sa fonction (base de donnees, serveur web, CI runner, poste developpeur). En face, listez les profils humains : admin systeme, developpeur backend, developpeur frontend, prestataire externe, support client.

L’objectif est de regrouper : si trois bases de donnees ont les memes regles d’acces, elles partagent un seul tag. Si quatre developpeurs ont les memes droits, ils partagent un seul groupe. Cette etape papier prend une heure et evite des semaines de retouches plus tard.

Etape 2 : Declarer les groupes d’utilisateurs

Connectez-vous sur login.tailscale.com, onglet Access Controls. Le fichier policy est en HuJSON (JSON avec commentaires). Commencez par definir les groupes humains.

{
  "groups": {
    "group:admins":   ["alice@itskillscenter.io", "bob@itskillscenter.io"],
    "group:devs":     ["marie@itskillscenter.io", "abdou@itskillscenter.io"],
    "group:support":  ["fatou@itskillscenter.io"]
  }
}

Sauvegardez. Tailscale valide la syntaxe : si un email n’est pas membre du tailnet, vous voyez un avertissement (pas un blocage). C’est utile pour preparer l’arrivee d’une recrue avant qu’elle ait son compte.

Etape 3 : Declarer les tags machines

Dans le meme fichier, ajoutez la section tagOwners. Chaque tag indique qui peut creer une machine portant ce tag (autorite de delegation, pas autorite d’acces).

"tagOwners": {
  "tag:prod-db":    ["group:admins"],
  "tag:prod-web":   ["group:admins"],
  "tag:dev-build":  ["group:admins", "group:devs"],
  "tag:laptop":     ["autogroup:member"]
}

Le tag laptop est ouvert a tout membre car chacun gere son propre poste. Les tags prod sont reserves aux admins : un developpeur ne peut pas creer une machine prod-db par erreur.

Etape 4 : Appliquer un tag a une machine existante

Sur la machine en question, relancez tailscale up avec l’option avancee. Si la machine appartient deja au tailnet, on doit reauthentifier.

sudo tailscale up --advertise-tags=tag:prod-db --reset

Ensuite, dans la console Tailscale, l’admin doit approuver le tag (sauf s’il l’a applique lui-meme). Apres approbation, la machine perd son association a l’utilisateur qui l’a installee : c’est devenu une machine de service, qui ne peut etre ni revoquee par changement de mot de passe ni rotee par changement d’identite.

Etape 5 : Ecrire les regles ACL entre groupes et tags

Maintenant on connecte. La section acls liste les autorisations explicites : tout ce qui n’est pas autorise est refuse par defaut.

"acls": [
  {
    "action": "accept",
    "src":    ["group:admins"],
    "dst":    ["*:*"]
  },
  {
    "action": "accept",
    "src":    ["group:devs"],
    "dst":    ["tag:dev-build:22,3000-3010"]
  },
  {
    "action": "accept",
    "src":    ["group:support"],
    "dst":    ["tag:prod-web:443"]
  }
]

Les admins ont tous les droits sur toutes les machines et tous les ports. Les devs accedent au build server en SSH (22) et aux ports applicatifs (3000-3010). Le support accede uniquement au port 443 du serveur web prod, pas en SSH.

Etape 6 : Tester sans risque avec ssh check

Avant de sauvegarder une regle critique, Tailscale propose une simulation. Dans la console, en bas de l’editeur ACL, le bouton Preview permet de tester une connexion theorique : source = abdou@itskillscenter.io, destination = tag:prod-db, port = 5432. Le simulateur repond accept ou drop avec la regle qui s’applique.

En CLI, depuis votre poste : tailscale ping prod-db-1. Si le ping repond, la regle vous laisse passer. Si vous voyez « no acceptable rule », la regle vous bloque, comme attendu pour un developpeur.

Etape 7 : Mode auto-approve pour les routes subnet

Si une machine taguee tag:prod-router expose un sous-reseau (par exemple 10.0.0.0/24 du datacenter), l’admin doit normalement valider chaque route. Pour automatiser, utilisez autoApprovers.

"autoApprovers": {
  "routes": {
    "10.0.0.0/24": ["tag:prod-router"]
  },
  "exitNode": ["tag:exit-node"]
}

Toute machine portant le tag prod-router peut annoncer la route 10.0.0.0/24 sans validation manuelle. Pratique pour redeployer un routeur apres incident sans intervention humaine.

Etape 8 : Audit mensuel des permissions effectives

Tailscale fournit un endpoint API qui retourne, pour chaque utilisateur, la liste des destinations atteignables. C’est la verite terrain de votre politique.

curl -u "tskey-api-xxx:"   "https://api.tailscale.com/api/v2/tailnet/itskillscenter.io/acl/validate"   -H "Content-Type: application/json"   --data '{"src":"abdou@itskillscenter.io","dst":"tag:prod-db","proto":"tcp","port":5432}'

La reponse vaut accept ou drop. Croisez avec votre tableau RH : tout developpeur qui peut joindre prod-db sans raison metier est un signal d’alarme. Faites cet exercice tous les debuts de mois, version moins de 30 minutes pour une equipe de 10 personnes.

Etape 9 : Plan de rollback rapide

Une mauvaise ACL peut couper la prod en 10 secondes. Tailscale conserve l’historique des versions de policy : onglet Access Controls, sous-onglet Logs. Chaque sauvegarde est datee et signee par l’auteur. Le bouton Revert restaure une version anterieure en un clic.

Bonne pratique : avant chaque modification importante, copiez le JSON courant dans un commit git d’un repo prive. Vous gardez la traçabilite hors plateforme et pouvez restaurer meme si Tailscale connait une panne du control plane.

Voir aussi notre tutoriel Tailscale SSH bastion et notre guide Supabase Storage upload.

Tailscale ACLs et tags : tutoriel permissions 2026