Gestion des accès
Contrôlez qui peut accéder à vos projets Skysize et les gérer grâce au contrôle d'accès basé sur les rôles.
Rôles d'accès
Chaque projet accorde l'accès avec l'un des quatre rôles : Admin (contrôle total), Mainteneur (voit tout, contrôle total du staging), Développeur (branches de développement uniquement) et Utilisateur (lecture seule). Le rôle d'une personne sur un projet peut être accordé directement (ajout au projet) ou via un groupe auquel elle appartient (voir Groupes ci-dessous).
Rôle Utilisateur
Les utilisateurs disposent d'un accès en lecture seule au projet.
Autorisations :
- Voir les détails du projet
- Voir le statut des déploiements et des builds
- Surveiller la santé, les métriques et les journaux de l'application
- Voir la configuration (mais pas la modifier)
Cas d'utilisation :
- Parties prenantes qui ont besoin de visibilité
- Clients qui souhaitent suivre l'avancement
- Membres de l'équipe qui n'ont pas besoin d'apporter des modifications
- Accès en lecture seule pour le reporting
Rôle Administrateur
Les admins disposent d'un contrôle total sur le projet.
Autorisations :
- Toutes les autorisations du rôle Utilisateur, plus :
- Créer, mettre à jour, reconstruire et supprimer des déploiements
- Modifier la configuration du projet et des branches
- Gérer les workers Odoo et les limites de temps
- Configurer les domaines personnalisés et le SSL
- Gérer l'accès au projet (inviter/supprimer des membres, changer les rôles)
- Créer, restaurer, télécharger et supprimer des sauvegardes
Cas d'utilisation :
- Chefs de projet
- Ingénieurs DevOps
- Développeurs principaux
- Administrateurs techniques
Rôle Mainteneur
Les mainteneurs voient tout et ont le contrôle total du staging, mais ne peuvent pas toucher à la production. Ce rôle est pensé pour les développeurs juniors, les consultants fonctionnels et les collaborateurs internes qui ont besoin d'une visibilité complète et d'un espace de test, par exemple pour une mise à niveau d'Odoo ou une ancienne sauvegarde, sans qu'on leur confie la production.
Permissions :
- Toutes les permissions du rôle Utilisateur, plus :
- Lire les logs Odoo, les requêtes lentes et le détail de santé de chaque branche, production comprise
- Se connecter en tant que n'importe quel utilisateur Odoo sur chaque branche (chaque connexion est enregistrée dans le journal d'audit)
- Consulter le journal d'audit, les membres et les invitations en attente
- Créer et télécharger des sauvegardes sur chaque branche
- Contrôle total des branches de staging : reconstruire, redémarrer, supprimer le déploiement, modifier les paramètres de la branche, restaurer ou importer une sauvegarde
- Passer une branche du staging au développement et inversement
- Contrôle total des branches de développement, comme le rôle Développeur
Ce qu'un mainteneur ne peut pas faire : modifier, reconstruire, redémarrer, supprimer ou restaurer quoi que ce soit en production, restaurer une sauvegarde dans une branche de développement, faire d'une branche la production, gérer les paramètres du projet, les membres, les domaines ou la facturation.
Reconstruire une branche de staging repart d'une copie fraîche de la production, et y restaurer une sauvegarde remplace sa base de données : les données saisies sur le staging entre-temps sont perdues.
Rôle Développeur
Les développeurs ont le contrôle total des branches de développement et de leurs données de démonstration, sans accès aux données de production ou de staging. Ce rôle est pensé pour les prestataires externes.
Les rôles en un coup d'œil
| Utilisateur | Développeur | Mainteneur | Admin | |
|---|---|---|---|---|
| Voir les déploiements, builds et métriques | ✅ | ✅ | ✅ | ✅ |
| Logs de production et de staging | ✅ | ❌ | ✅ | ✅ |
| Se connecter en tant qu'utilisateur Odoo | ❌ | développement uniquement | ✅ | ✅ |
| Créer et télécharger des sauvegardes | ❌ | ❌ | ✅ | ✅ |
| Reconstruire / redémarrer | ❌ | développement uniquement | staging et développement | ✅ |
| Supprimer des déploiements | ❌ | développement uniquement | staging et développement | ✅ |
| Restaurer ou importer des sauvegardes | ❌ | ❌ | staging uniquement | ✅ |
| Paramètres, membres, domaines | ❌ | ❌ | ❌ | ✅ |
Gestion des utilisateurs
Les admins de projet invitent des membres d'équipe par e-mail et leur attribuent un rôle :
- Accédez à la section Access Management du projet.
- Invitez un utilisateur par adresse e-mail et choisissez son rôle.
- La personne invitée reçoit un e-mail avec un lien pour accepter ou refuser l'invitation.
- Une fois acceptée, son accès prend effet immédiatement.
Détails de l'invitation :
- Les invitations expirent après 7 jours si elles ne sont pas acceptées.
- Une invitation ne peut être acceptée que par l'adresse e-mail à laquelle elle a été envoyée.
- Une invitation en attente peut être retirée par un admin avant d'être acceptée.
Vous pouvez accorder l'accès à des personnes par e-mail ou à un groupe entier en une seule fois. L'accès par groupe est pratique pour gérer des équipes stables sur plusieurs projets.
Opérations de déploiement
Les admins peuvent effectuer des opérations de déploiement critiques :
- Créer de nouveaux déploiements : lancer de nouveaux builds.
- Mettre à jour les déploiements : déployer les dernières modifications de code.
- Reconstruire les déploiements : recréer un déploiement avec une base de données fraîche (par exemple, un nouvel instantané de production pour le staging).
- Supprimer les déploiements : retirer les déploiements qui ne sont plus nécessaires.
Skysize n'expose pas d'action en un clic de type "revenir à une version précédente". À la place, les mises à jour sont sécurisées par rollback : si une mise à jour échoue à sa vérification de santé, la plateforme restaure automatiquement le déploiement à son état de fonctionnement précédent. Pour revenir délibérément à un état antérieur, restaurez une sauvegarde.
Bonnes pratiques
Principe du moindre privilège
Accordez aux utilisateurs le niveau d'accès minimum nécessaire à leur rôle :
- Donnez l'accès Utilisateur aux parties prenantes qui n'ont besoin que de visibilité
- Réservez l'accès Admin aux membres de l'équipe qui gèrent activement les déploiements
Examens d'accès réguliers
Examinez périodiquement qui a accès à vos projets :
- Supprimez les utilisateurs qui n'ont plus besoin d'accès
- Assurez-vous que les rôles sont toujours appropriés
- Auditez régulièrement les autorisations admin
Organisation de l'équipe
Structurez l'accès de votre équipe de manière logique :
- Admins : ingénieurs DevOps, développeurs principaux, chefs de projet
- Utilisateurs : parties prenantes, clients, développeurs juniors, équipe QA
Considérations de sécurité
- Limitez l'accès admin : tout le monde n'a pas besoin d'un contrôle total
- Utilisez une authentification forte : assurez-vous que tous les utilisateurs ont des mots de passe forts
- Supprimez les utilisateurs inactifs : nettoyez l'accès des utilisateurs qui quittent l'équipe
- Surveillez les modifications : gardez une trace de qui effectue les modifications de configuration
Gestion des accès
Ajout d'utilisateurs
- Accédez aux paramètres de votre projet
- Sélectionnez "Access Management"
- Cliquez sur "Add User"
- Saisissez l'adresse e-mail de l'utilisateur
- Sélectionnez son rôle
- Envoyez l'invitation
Modification des accès
- Accédez à la liste des utilisateurs dans les paramètres du projet
- Trouvez l'utilisateur que vous souhaitez modifier
- Changez son rôle ou supprimez son accès
- Les modifications prennent effet immédiatement
Suppression des accès
- Accédez à la gestion des accès du projet
- Trouvez l'utilisateur à supprimer
- Cliquez sur "Supprimer l'accès"
- Confirmez l'action
L'utilisateur perdra immédiatement l'accès au projet.
Un projet doit toujours conserver au moins un admin. Vous ne pouvez pas supprimer le dernier admin restant, et vous ne pouvez pas rétrograder le dernier admin en rôle Utilisateur. Ajoutez d'abord un autre admin si vous devez changer celui en place.
Groupes : accès par équipe
Au lieu d'inviter les personnes à chaque projet une par une, vous pouvez gérer l'accès à l'aide de groupes. Un groupe est un ensemble nommé d'utilisateurs ; accorder l'accès d'un groupe à un projet donne à chaque membre de ce groupe le rôle attribué sur ce projet.
Comment ça fonctionne :
- Un utilisateur peut être membre d'un ou plusieurs groupes.
- Un groupe se voit attribuer un rôle (Utilisateur ou Admin) sur un projet.
- Chaque membre du groupe hérite de ce rôle sur le projet.
- L'accès effectif d'un utilisateur est la combinaison de ses rôles directs sur le projet et de tout rôle obtenu via des groupes.
Pourquoi utiliser des groupes :
- Intégrez un nouveau membre d'équipe une seule fois (ajoutez-le au bon groupe) et il obtient l'accès à tous les projets couverts par ce groupe.
- Gérez l'accès d'équipes entières (par exemple, "QA" ou "Developers") en un seul endroit.
- Réduisez le risque d'autorisations obsolètes, projet par projet, lorsqu'une personne change d'équipe.
Dans la liste des membres du projet, l'accès accordé via un groupe est distingué de l'accès accordé directement, de sorte que vous pouvez toujours voir pourquoi une personne dispose d'un accès.