Gestion des clés de déploiement

Vous pouvez gérer des clés SSH sur vos serveurs pendant l’automatisation des scripts de déploiement en utilisant le transfert d’agent SSH, HTTPS avec des jetons OAuth, des clés de déploiement ou des utilisateurs de machine.

Transfert d’agent SSH

Dans de nombreux cas, en particulier au début d’un projet, le transfert d’agent SSH est la méthode la plus rapide et la plus simple. Le transfert d’agent utilise les mêmes clés SSH que votre ordinateur de développement local.

Avantages du transfert d’agent SSH

Vous n’avez pas besoin de générer ni de suivre de nouvelles clés.
Il n’y a pas de gestion des clés, les utilisateurs ont les mêmes autorisations sur le serveur que celles qu’ils ont localement.
Comme aucune clé n’est stockée sur le serveur, si le serveur est compromis, vous n’avez pas besoin de chasser ni de supprimer les clés compromises.

Inconvénients du transfert d’agent SSH

Les utilisateurs doivent ouvrir une connexion SSH pour le déploiement, les processus de déploiement automatiques ne peuvent pas être utilisés.
Le transfert d’agent SSH peut être difficile à exécuter pour les utilisateurs Windows.

Configurer le transfert d’agent SSH

Activez le transfert d’agent localement. Pour plus d’informations, consultez notre guide sur le transfert d’agent SSH.
Définissez vos scripts de déploiement pour utiliser le transfert d’agent. Par exemple, sur un script bash, l’activation du transfert d’agent ressemble à ceci : ssh -A serverA 'bash -s' < deploy.sh

Clonage HTTPS avec des jetons OAuth

Si vous ne voulez pas utiliser de clés SSH, vous pouvez utiliser HTTPS avec des jetons OAuth.

Avantages du clonage HTTPS avec des jetons OAuth

Toute personne ayant accès au serveur peut déployer le dépôt.
Les utilisateurs n’ont pas besoin de changer leurs paramètres SSH locaux.
Vous n’avez pas besoin d’avoir plusieurs jetons (un pour chaque utilisateur), un jeton par serveur suffit.
Un jeton peut être révoqué à tout moment, ce qui le convertit essentiellement en mot de passe à usage unique.
La génération de nouveaux jetons peut être facilement scriptée avec l’API OAuth.

Inconvénients du clonage HTTPS avec des jetons OAuth

Vous devez veiller à configurer votre jeton avec les étendues d’accès appropriées.
Les jetons sont essentiellement des mots de passe et doivent être protégés de la même façon.

Configurer le clonage HTTPS avec des jetons OAuth

Consultez notre guide sur la création d’un personal access token.

Clés de déploiement

Vous pouvez lancer des projets à partir d’un référentiel sur votre instance GitHub Enterprise Server sur votre serveur à l’aide d’une clé de déploiement, qui est une clé SSH accordant l’accès à un seul référentiel. GitHub Enterprise Server attache la partie publique de la clé directement à votre dépôt, au lieu d’un compte personnel, tandis que la partie privée de la clé reste sur votre serveur. Pour plus d’informations, consultez « Livraison de déploiements ».

Les clés de déploiement avec accès en écriture peuvent effectuer les mêmes actions qu’un membre d’organisation avec un accès administrateur ou qu’un collaborateur sur un dépôt personnel. Pour plus d’informations, consultez « Rôles de dépôt pour une organisation » et « Niveaux d’autorisation pour un référentiel de compte personnel ».

Pour une sécurité renforcée et un contrôle précis sur l’accès au référentiel et les autorisations, nous vous recommandons d’utiliser une application GitHub à la place. Consultez « Décider quand créer une application GitHub ».

Avantages des clés de déploiement

Toute personne ayant accès au dépôt et au serveur a la possibilité de déployer le projet.
Les utilisateurs n’ont pas besoin de changer leurs paramètres SSH locaux.
Les clés de déploiement sont en lecture seule par défaut, mais vous pouvez leur accorder un accès en écriture quand vous les ajoutez à un dépôt.

Inconvénients des clés de déploiement

Déployer des clés accorde uniquement l’accès à un seul dépôt. Les projets plus complexes peuvent avoir de nombreux dépôts à tirer sur le même serveur.
Les clés de déploiement ne sont généralement pas protégées par une phrase secrète, ce qui rend la clé facilement accessible si le serveur est compromis.
Les clés de déploiement sont des informations d’identification qui n’ont pas de date d’expiration.
Les clés de déploiement ne sont pas directement liées à l’appartenance à l’organisation. Si l’utilisateur qui a créé le clé de déploiement est supprimé du référentiel, la clé de déploiement sera toujours active, car il n’est pas lié à l’utilisateur spécifique, mais plutôt au référentiel.

Configurer des clés de déploiement

Exécutez la procédure ssh-keygen sur votre serveur et notez l’endroit où vous enregistrez la paire de clés RSA publique et privée générée.
Sur GitHub, accédez à la page principale du référentiel.
Sous le nom de votre dépôt, cliquez sur Paramètres. Si vous ne voyez pas l’onglet « Paramètres », sélectionnez le menu déroulant , puis cliquez sur Paramètres.
Dans la barre latérale, cliquez sur Clés de déploiement.
Cliquez sur Add deploy key (Ajouter une clé de déploiement).
Dans le champ « Titre », indiquez un titre.
Dans le champ « Clé », collez votre clé publique.
Sélectionnez Autoriser l’accès en écriture pour que cette clé ait un accès en écriture sur le dépôt. Une clé de déploiement avec un accès en écriture permet à un déploiement de pousser vers le dépôt.
Cliquez sur Ajouter une clé.

Vous pouvez également utiliser l’API REST pour créer des clés de déploiement. Pour plus d’informations, consultez « Points de terminaison d’API REST pour les clés de déploiement ».

Utilisation de plusieurs dépôts sur un seul serveur

Si vous utilisez plusieurs dépôts sur un serveur, vous devez générer une paire de clés dédiée pour chacun. Vous ne pouvez pas réutiliser une clé de déploiement pour plusieurs dépôts.

Dans le fichier de configuration SSH du serveur (généralement ~/.ssh/config), ajoutez une entrée d’alias pour chaque dépôt. Par exemple :

Host my-GHE-hostname.com-repo-0
        Hostname my-GHE-hostname.com
        IdentityFile=/home/user/.ssh/repo-0_deploy_key

Host my-GHE-hostname.com-repo-1
        Hostname my-GHE-hostname.com
        IdentityFile=/home/user/.ssh/repo-1_deploy_key

Host my-GHE-hostname.com-repo-0 : alias du dépôt.
Hostname my-GHE-hostname.com : configure le nom d’hôte à utiliser avec l’alias.
IdentityFile=/home/user/.ssh/repo-0_deploy_key : attribue une clé privée à l’alias.

Vous pouvez ensuite utiliser l’alias du nom d’hôte pour interagir avec le dépôt en utilisant SSH, qui utilise la clé de déploiement unique attribuée à cet alias. Par exemple :

git clone git@my-GHE-hostname.com-repo-1:OWNER/repo-1.git

Jetons d’accès d’installation pour une GitHub App

Si votre serveur doit accéder à des référentiels dans une ou plusieurs organisations, vous pouvez utiliser une GitHub App pour définir l’accès dont vous avez besoin, puis générer des jetons d’accès d’installation étroitement définis à partir de cette GitHub App. Les jetons d’accès d’installation peuvent être délimités à un ou plusieurs référentiels, et peuvent avoir des permissions affinées. Par exemple, vous pouvez générer un jeton avec un accès en lecture seule sur le contenu d’un dépôt.

Étant donné que GitHub Apps constitue un acteur de première classe sur GitHub Enterprise Server, les jetons d’accès à l’installation sont découplés à partir de n’importe quel utilisateur GitHub, ce qui les rend comparables à des « jetons de service ». Par ailleurs, les jetons d’accès d’installation ont des limites de débit dédiées qui s’adaptent en fonction de la taille des organisations sur lesquelles ils agissent. Pour plus d’informations, consultez Limites de débit des GitHub Apps.

Avantages des jetons d’accès d’installation

Jetons avec une étendue limitée, et avec des jeux d’autorisation et des délais d’expiration bien définis (1 heure ou moins s’ils sont révoqués manuellement avec l’API)
Limites de débit dédiées qui augmentent avec votre organisation
Découplées à partir des identités des utilisateurs GitHub, de sorte qu’ils ne consomment pas de sièges sous licence
Ne reçoit jamais de mot de passe, ne peut donc pas recevoir de connexion directe

Inconvénients des jetons d’accès d’installation

Une configuration supplémentaire est nécessaire pour créer la GitHub App.
Les jetons d’accès d’installation expirent au bout d’une heure, c’est pourquoi ils doivent être regénérés, en général à la demande dans le code.

Configurer des jetons d’accès d’installation

Déterminez si votre GitHub App doit être publique ou privée|masquée. Si votre GitHub App agit uniquement sur les dépôts au sein de votre organisation, elle peut être privée.
Déterminez les autorisations dont a besoin votre GitHub App, par exemple, un accès en lecture seule au contenu du référentiel.
Créez votre GitHub App via la page des paramètres de votre organisation. Pour plus d’informations, consultez « Création d’une GitHub App ».
Notez votre GitHub App id.
Générez et téléchargez la clé privée de votre GitHub App, et conservez-la en toute sécurité. Pour plus d’informations, consultez Génération d’une clé privée.
Installez votre GitHub App sur les référentiels sur lesquels elle doit agir, vous pouvez également installer la GitHub App sur tous les référentiels de votre organisation.
Identifiez le installation_id qui représente la connexion entre votre GitHub App et les référentiels de l’organisation auxquels elle peut accéder. Chaque paire de GitHub App et d’organisations a au plus un seul installation_id. Vous pouvez identifier cet installation_id avec Obtenir une installation d’organisation pour l’application authentifiée. Cela requiert une authentification en tant que GitHub App à l’aide d’un JWT. Pour plus d’informations, consultez la section Authentification en tant que GitHub App.
Générez un jeton d’accès d’installation en utilisant le point de terminaison d’API REST correspondant, Créer un jeton d’accès d’installation pour une application. Cela requiert une authentification en tant que GitHub App à l’aide d’un JWT. Pour plus d’informations, consultez les sections Authentification en tant que GitHub App et Authentification en tant qu’installation.
Utilisez ce jeton d’accès d’installation pour interagir avec vos dépôts, via l’API REST ou l’API GraphQL, ou via un client Git.

Pour plus d’informations, consultez « Génération d’un jeton d’accès d’installation pour une application GitHub ».

Utilisateurs machines

Si votre serveur doit avoir accès à plusieurs référentiels, vous pouvez créer un compte sur votre instance GitHub Enterprise Server et attacher une clé SSH, utilisée exclusivement pour l’automatisation. Étant donné que ce compte sur votre instance GitHub Enterprise Server ne sera pas utilisé par un humain, il s’agit d’un utilisateur d’ordinateur. Vous pouvez ajouter l’utilisateur machine comme collaborateur sur un dépôt personnel (en lui accordant un accès en lecture et en écriture), comme collaborateur externe sur un dépôt d’organisation (en lui accordant un accès en lecture, en écriture ou d’administrateur) ou l’ajouter à une équipe avec un accès aux dépôts dont il a besoin pour l’automatisation (en lui accordant les autorisations de l’équipe).

Avantages des utilisateurs machine

Toute personne ayant accès au dépôt et au serveur a la possibilité de déployer le projet.
Aucun utilisateur (humain) n’a besoin de changer ses paramètres SSH locaux.
Vous n’avez pas besoin de plusieurs clés, une par serveur suffit.

Inconvénients des utilisateurs machine

Seules les organisations peuvent limiter les utilisateurs machines à l’accès en lecture seule. Les dépôts personnels accordent toujours aux collaborateurs un accès en lecture/écriture.
Les clés d’utilisateur machine, comme les clés de déploiement, ne sont généralement pas protégées par une phrase secrète.

Configurer des utilisateurs machine

Exécutez la procédure ssh-keygen sur votre serveur et attachez la clé publique au compte de l’utilisateur machine.
Donnez au compte de l’utilisateur machine un accès aux dépôts que vous voulez automatiser. Pour ce faire, vous pouvez ajouter le compte comme collaborateur, comme collaborateur externe ou l’ajouter à une équipe d’organisation.

Pour aller plus loin

Configuration des notifications

Dans cet article