Utiliser la même clé de déploiement pour plusieurs projets Github
Github ne permet pas d'utiliser la même clé de déploiement ssh pour plus d'un projet, ce qui serait très utile dans certains cas (par exemple, serveur CI traitant un projet avec des sous-modules privés). J'ai vu divers fils de discussion qui semblent dire que cette limitation est là pour des `` raisons de sécurité '', mais je n'ai pas encore vu d'explication convaincante sur exactement quel risque cela augmenterait.
Notez que le fait que Github n'autorise pas la réutilisation des clés au niveau du compte est logique (deux utilisateurs ne devraient pas partager de clés). Ce n'est que la restriction sur Déployer les clés que je remets en question.
Et pour être clair, je ne cherche pas des solutions de contournement (créez un utilisateur fictif, utilisez plusieurs clés, ...), mais uniquement pour un explication de cette limitation sur les clés de déploiement.
Sujets associés:
- Un montrant un solution de contournement
- Un discuter du problème mais ne va vraiment nulle part
La seule raison, illustrée par la solution de contournement à laquelle vous faites référence (créer un seul utilisateur "build" ou partager le même id_rsa.REPONAME.pub par repo) est:
évitez de partager la clé publique/privée pour différents utilisateurs
Même si ce ne serait pas le cas dans votre situation (construire plusieurs projets), autoriser à réutiliser la même clé ssh ouvrirait la possibilité à deux différents utilisateurs de partager la même clé ssh, ce qui annulerait l'objectif d'authentification .
L'authentification signifie:
"l'utilisation d'une certaine clé ssh devrait impliquer que vous êtes censé savoir qui l'utilise".
La page GitHub "Gestion des clés de déploiement" détaille les différents comptes utilisant ssh:
Transfert d'agent SSH : Le transfert d'agent utilise les clés SSH déjà configurées sur votre machine de développement locale lorsque vous vous connectez SSH à votre serveur et exécutez les commandes git.
Vous pouvez laisser sélectivement les serveurs distants accéder à votre agent ssh local comme s'il s'exécutait sur le serveur.
Il n'est donc pas nécessaire de répliquer votre clé privée sur le serveur.Utilisateurs de machine : (c'est la stratégie "compte factice") Attachez la clé à un compte utilisateur. Étant donné que ce compte ne sera pas utilisé par un humain, il s'appelle un utilisateur de machine.
Vous traitez cet utilisateur de la même manière que vous le feriez avec un humain, attachez la clé au compte d'utilisateur de la machine comme s'il s'agissait d'un compte normal.
Accordez au collaborateur de compte ou à l'équipe l'accès aux référentiels auxquels il doit accéder.
Donc une clé privée associée à un "utilisateur de machine", une par serveur.Clé de déploiement (une par dépôt GitHub) Clé SSH qui est stockée sur le serveur et accorde l'accès à un seul dépôt sur GitHub.
Cette clé est attachée directement au référentiel au lieu d'un compte utilisateur .
Au lieu d'accéder aux paramètres de votre compte, accédez à la page d'administration du référentiel cible.
Aller à "Deploy Keys"et cliquez sur"Add deploy key". Collez la clé publique et soumettez-la.
Cette fois, la clé ssh n'est pas attachée à un utilisateur (pour lequel vous pouvez accorder l'accès à plusieurs repo), mais à un seul repo.
Accorder l'accès ssh pour plusieurs repo serait l'équivalent d'un "utilisateur de machine".
En termes d'authentification :
- l'utilisation de la même clé pour plusieurs dépôts est acceptable lorsqu'elle est effectuée par un utilisateur (qui a ladite clé associée à son compte)
- utiliser la même clé pour plusieurs repo n'est PAS correct lorsque la clé est attachée par un repo, car vous ne savez pas du tout qui accédé à quoi.
Cela diffère de l '"utilisateur de la machine" où un "utilisateur" est déclaré comme collaborateur pour de nombreux repo.
Ici (clé de déploiement), il n'y a pas de "collaborateur" , juste un accès ssh direct accordé au dépôt.
Malheureusement, c'est un scénario où github interprète mal la distinction entre une paire de clés et un compte ou un projet.
Puisqu'une paire de clés est utilisée pour l'authentification et l'autorisation, il s'agit effectivement d'une identité. Les comptes Github sont une autre identité. La connexion de comptes github à des paires de clés établit effectivement un mappage 1: N entre les identités basées sur les comptes github et les identités de paires de clés.
À l'inverse, github applique un mappage 1: N des projets aux identités basées sur les paires de clés. L'analogue du monde réel est qu'il existe une porte donnant accès au projet qui peut être déverrouillée par de nombreuses personnes différentes. Mais une fois que l'un d'eux a obtenu une clé de la porte, il ne peut plus obtenir d'autres clés pour d'autres portes.
Il est logique de ne pas réutiliser les clés souvent dans la perspective de contenir les violations si une clé est compromise. Mais c'est juste une bonne administration politique. Cela n'a pas beaucoup de sens d'empêcher une clé d'être utilisée plus d'une fois en principe. Qu'il y a des clés pour certaines portes qui ne sont jamais réutilisées, eh bien, encore une fois, cela dépend de politique.
Une vue légèrement plus complexe consiste à illustrer les paires de clés sous la forme rôles. Vous pouvez posséder plusieurs paires de clés et donc occuper de nombreux rôles. La clé privée vous authentifie pour le rôle.
Le mappage de clé de déploiement de Github sur les projets indique qu'un rôle ne peut jamais englober plus d'une tâche. C'est rarement réaliste.
Rien de tout cela ne change ce que github permet, bien sûr.
Il m'a fallu beaucoup de réflexion pour rationaliser les implications et est venu avec ce scénario.
Imaginez que vous créez une seule clé de déploiement pour un utilisateur que vous avez affecté à plusieurs référentiels. Vous voulez maintenant révoquer cette clé, mais elle est utilisée à plusieurs endroits. Ainsi, au lieu de pouvoir révoquer tous les accès, vous pouvez par inadvertance révoquer uniquement les accès partiels.
Cela peut sembler un avantage, mais cette relation à plusieurs est en fait intrinsèquement précaire une fois que vous prenez en compte le facteur humain. En effet, vous ne pouvez pas savoir avec certitude si vous avez vraiment révoqué tous les accès sans inspecter chaque référentiel et comparer chaque clé publique individuellement dans le cas où vous avez oublié où vous l'avez réellement attribué.
Il est certainement frustrant d'affecter et de gérer autant de clés uniques, mais les implications en matière de sécurité sont claires avec la façon dont GitHub a institué sa politique: lorsque vous révoquez une clé, vous êtes assuré de révoquer tous les accès accordés par cette clé, car c'est uniquement utilisé en un seul endroit.