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
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.
É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"]
}
}
É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"]
}
}
É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
É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:*"]
}
]
}
É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.
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
autoApproverset invitations expirantes
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é.
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 *:* |