Sécurité dans GitHub Codespaces

Vue d’ensemble de la sécurité des espaces de code

GitHub Codespaces est conçu avec une sécurité renforcée par défaut. Par conséquent, vous devez vous assurer que vos pratiques de développement de logiciels ne risquent pas de réduire la posture de sécurité de votre espace de code.

Ce guide décrit la façon dont GitHub Codespaces sécurise votre environnement de développement. Il fournit certaines des bonnes pratiques qui vous aideront à garantir la sécurité tout au long de votre travail. Comme avec tout outil de développement, n’oubliez pas que vous devez ouvrir et travailler uniquement dans des dépôts que vous connaissez et approuvez.

Isolation de l’environnement

GitHub Codespaces est conçu pour maintenir vos espaces de code séparés les uns des autres, chacun utilisant sa propre machine virtuelle et son propre réseau.

Machines virtuelles isolées

Chaque espace de code est hébergé sur sa propre machine virtuelle nouvellement créée. Deux espaces de code ne sont jamais colocalisés sur la même machine virtuelle.

Chaque fois que vous redémarrez un espace de code, il est déployé sur une nouvelle machine virtuelle avec les dernières mises à jour de sécurité disponibles.

Mise en réseau isolée

Chaque espace de code possède son propre réseau virtuel isolé. Nous utilisons des pare-feu pour bloquer les connexions entrantes à partir d’Internet et empêcher les espaces de code de communiquer entre eux sur des réseaux internes. Les espaces de code sont autorisés à établir des connexions sortantes vers Internet.

Authentification

Vous pouvez vous connecter à un espace de code à l’aide d’un navigateur web ou à partir de Visual Studio Code. Si vous vous connectez à partir de VS Code, vous êtes invité à vous authentifier auprès de GitHub.

Chaque fois qu’un espace de code est créé ou redémarré, il reçoit un nouveau jeton GitHub avec une période d’expiration automatique. Cette période vous permet de travailler dans l’espace de code sans avoir à vous réauthentifier au cours d’une journée de travail classique, mais elle réduit le risque de laisser une connexion ouverte quand vous cessez d’utiliser l’espace de code.

L’étendue du jeton varie en fonction de l’accès dont vous disposez au dépôt où l’espace de code a été créé :

• Si vous disposez d’un accès en écriture au dépôt : le jeton est limité pour l’accès en lecture/écriture au dépôt.
• Si vous disposez uniquement d’un accès en lecture au dépôt: le jeton autorise uniquement le clonage du code à partir du dépôt source. Si vous effectuez un commit dans le codespace, ou pousser une nouvelle branche, GitHub Codespaces crée automatiquement une duplication du dépôt ou lie le codespace à une duplication existante si vous en avez déjà une pour le dépôt en amont. Le jeton est mis à jour pour avoir un accès en lecture et en écriture à la duplication. Pour plus d’informations, consultez « Utilisation du contrôle de code source dans votre espace de code ».
• Si vous avez autorisé votre codespace à accéder à d’autres dépôts : l’étendue du jeton est délimitée pour disposer d’un accès en lecture ou en lecture/écriture au dépôt source ainsi qu’aux autres dépôts pour lesquels vous avez autorisé l’accès. Pour plus d’informations, consultez « Gestion de l’accès à d’autres dépôts dans votre codespace ».

Connexions aux espaces de code

Vous pouvez vous connecter à votre espace de code à l’aide du tunnel chiffré TLS fourni par le service GitHub Codespaces. Seul le créateur d’un espace de code peut se connecter à un espace de code. Les connexions sont authentifiées avec GitHub.

Si vous devez autoriser un accès externe aux services s’exécutant sur un espace de code, vous pouvez activer le réacheminement de port pour un accès privé ou public.

Réacheminement de port

Si vous devez vous connecter à un service (tel qu’un serveur web de développement) s’exécutant dans votre espace de code, vous pouvez configurer le réacheminement de port pour rendre le service disponible sur Internet.

Les propriétaires d’organisation peuvent restreindre la possibilité de rendre les ports de réacheminement disponibles publiquement ou au sein de l’organisation. Pour plus d’informations, consultez « Restriction de la visibilité des ports transférés ».

Ports transférés en privé : sont accessibles sur Internet, mais seul le créateur de l’espace de code peut y accéder, après s’être authentifié auprès de GitHub.

Ports transférés publiquement au sein de votre organisation : sont accessibles sur Internet, mais uniquement aux membres de la même organisation que l’espace de code, après authentification auprès de GitHub.

Ports transférés publiquement : sont accessibles sur Internet, et n’importe qui sur Internet peut y accéder. Aucune authentification n’est nécessaire pour accéder aux ports transférés publics.

Tous les ports transférés sont privés par défaut, ce qui signifie que vous devez vous authentifier avant de pouvoir y accéder. L’accès aux ports transférés privés d’un espace de code est contrôlé par les cookies d’authentification avec une période d’expiration de 3 heures. Quand le cookie expire, vous devez vous réauthentifier.

Un port transféré public redevient automatiquement privé quand vous supprimez et rajoutez le port, ou si vous redémarrez l’espace de code.

Vous pouvez utiliser le panneau « Ports » pour configurer un port pour un accès public ou privé, et vous pouvez arrêter le transfert de port lorsqu’il n’est plus nécessaire. Pour plus d’informations, consultez « Transfert de ports dans votre espace de code ».

Bonnes pratiques de sécurité pour vos espaces de code

Les espaces de code sont conçus de manière à ce que leur sécurité soit renforcée par défaut. Pour vous aider à maintenir cette posture, nous vous recommandons de suivre les bonnes pratiques de sécurité pendant vos procédures de développement :

• Comme avec tout outil de développement, n’oubliez pas que vous devez ouvrir et travailler uniquement dans des dépôts que vous connaissez et approuvez.
• Avant d’ajouter de nouvelles dépendances à l’espace de code, vérifiez si elles sont bien gérées et si elles publient des mises à jour pour corriger les vulnérabilités de sécurité trouvées dans leur code.

Utilisation de secrets d’environnement de développement pour accéder aux informations sensibles

Utilisez toujours des secrets d’environnement de développement quand vous souhaitez vous servir d’informations sensibles (telles que des jetons d’accès) dans un codespace. Vous pouvez accéder à vos secrets en tant que variables d’environnement dans l’espace de code, y compris à partir du terminal. Par exemple, vous pouvez lancer un terminal dans votre codespace et utiliser echo $SECRET_NAME pour afficher la valeur d’un secret d’environnement de développement.

Les valeurs secrètes sont copiées dans des variables d’environnement chaque fois que l’espace de code est repris ou créé, et sont également synchronisées lorsqu’elles sont modifiées.

Les secrets d’environnements de développement ne sont pas copiés dans l’environnement si vous n’avez pas accès en écriture au référentiel du codespace.

Pour plus d’informations sur les secrets, consultez :

• Gestion des secrets spécifiques à votre compte pour GitHub Codespaces
• Gestion des secrets d’environnement de développement pour votre référentiel ou votre organisation

Utilisation des contributions et dépôts d’autres personnes

Lorsque vous créez un espace de code à partir d’une branche de demande de tirage à partir d’une duplication, le jeton figurant dans l’espace de code varie selon que le dépôt est public ou privé :

• Pour un dépôt privé, l’espace de code se voit accorder un accès à la fois à la duplication et au parent.
• Pour un dépôt public, l’espace de code n’a accès qu’à la duplication et aux demandes de tirage d’ouverture sur le parent.

Nous vous protégeons également davantage dans ces scénarios en n’injectant aucun de vos secrets d’espace de code dans l’environnement. Pour plus d’informations, consultez « Gestion des secrets spécifiques à votre compte pour GitHub Codespaces ».

Bonnes pratiques supplémentaires

Il existe certaines bonnes pratiques et certains risques supplémentaires à connaître quand vous utilisez GitHub Codespaces.

Présentation du fichier devcontainer.json d’un dépôt

Quand vous créez un espace de code, si un fichier devcontainer.json est trouvé pour votre dépôt, il est analysé et utilisé pour configurer votre espace de code. Le fichier devcontainer.json peut contenir des fonctionnalités puissantes, telles que l’installation d’extensions tierces et l’exécution de code arbitraire fourni dans une postCreateCommand.

Pour plus d’informations, consultez « Présentation des conteneurs de développement ».

Octroi de l’accès via des fonctionnalités

Certaines fonctionnalités de développement peuvent potentiellement ajouter des risques à votre environnement. Par exemple, la signature de validation, les secrets injectés dans des variables d’environnement, l’accès au registre authentifié et l’accès aux packages peuvent tous présenter des problèmes de sécurité potentiels. Nous vous recommandons d’accorder uniquement l’accès à ceux qui en ont besoin et d’adopter une stratégie visant à être aussi restrictif que possible.

Utilisation d’extensions

Toute autre extension VS Code que vous avez installée peut éventuellement entraîner des risques supplémentaires. Pour atténuer ces risques, veillez à installer uniquement des extensions approuvées et à toujours les maintenir à jour.

Utilisation de la synchronisation des paramètres

La synchronisation des paramètres de VS Code peut permettre le transfert de contenu potentiellement malveillant entre les appareils. Par défaut, la synchronisation des paramètres est désactivée pour les espaces de code ouverts dans le navigateur. Si vous créez un codespace pour un dépôt dont le contenu ne vous inspire pas confiance, ouvrez ce codespace dans le navigateur et laissez la synchronisation des paramètres désactivée.

Si vous avez activé la synchronisation des paramètres dans vos préférences utilisateur et que vous souhaitez autoriser les modifications apportées à vos paramètres à se synchroniser de vos codespaces vers d’autres instances de VS Code, nous vous recommandons d’ajouter une liste sélectionnée de référentiels approuvés, plutôt que d’approuver tous les référentiels. Lorsque vous créez des codespaces à partir de référentiels approuvés, les modifications que vous apportez à vos paramètres dans les codespaces sont synchronisées avec vos paramètres mis en cache dans le cloud, à partir desquels ils peuvent être transférés vers vos appareils. Pour plus d’informations sur la gestion de la synchronisation des paramètres, consultez Personnalisation de GitHub Codespaces pour votre compte.