Remarque : La prise en charge d’OpenID Connect (OIDC) et de la stratégie d’accès conditionnel pour Enterprise Managed Users est disponible seulement pour Microsoft Entra ID (précédemment appelé Azure AD).
À propos de la prise en charge des stratégies d’accès conditionnel
Lorsque votre entreprise utilise le SSO OIDC, GitHub utilisera automatiquement les conditions IP de la politique d'accès conditionnel (CAP) de votre IdP pour valider les interactions avec GitHub lorsque les membres changent d'adresse IP, et pour chaque authentification avec une personal access token ou une clé SSH associée à un compte d'utilisateur.
GitHub Enterprise Cloud prend en charge la stratégie d’accès conditionnel pour toutes les entreprise avec utilisateurs managés où l’authentification unique OIDC est activée. GitHub Enterprise Cloud applique les conditions IP de votre fournisseur d’identité, mais ne peut pas appliquer les conditions de conformité de l’appareil. Les propriétaires d’entreprise peuvent choisir d’utiliser cette configuration de liste d’adresses IP autorisées au lieu de la liste d’adresses IP autorisées de GitHub Enterprise Cloud, et peuvent le faire une fois l’authentification unique OIDC configurée. Pour plus d’informations sur les listes d’adresses IP autorisées, consultez « Restriction du trafic réseau vers votre entreprise avec une liste d’adresses IP autorisées » et « Gestion des adresses IP autorisées pour votre organisation ».
Pour plus d’informations sur l’utilisation d’OIDC avec Enterprise Managed Users, consultez « Configuration d’OIDC pour les utilisateurs managés par l’entreprise » et « Migration de SAML vers OIDC ».
À propos de CAP et de clés de déploiements
Une clé de déploiement est une clé SSH qui accorde l’accès à un référentiel individuel. Étant donné que les clés de déploiement n’effectuent pas d’opérations pour le compte d’un utilisateur, les conditions IP CAP ne s’appliquent pas aux demandes authentifiées avec un clé de déploiement. Pour plus d’informations, consultez « Gestion des clés de déploiement ».
Considérations relatives aux intégrations et aux automatisations
GitHub envoie l’adresse IP d’origine à votre fournisseur d’identité pour validation par rapport à votre stratégie d’autorisation de connexion. Pour vous assurer que les actions et les applications ne sont pas bloquées par la stratégie d’autorisation de connexion de votre fournisseur d’identité, vous devrez apporter des modifications à votre configuration.
Avertissement : Si vous utilisez GitHub Enterprise Importer pour migrer une organisation depuis votre instance GitHub Enterprise Server, veillez à utiliser un compte de service exempté de la stratégie d’accès conditionnel d’Entra ID, sinon votre migration peut être bloquée.
GitHub Actions
Les actions qui utilisent un personal access token seront probablement bloquées par la stratégie d’accès conditionnel de votre fournisseur d’identité. Nous recommandons que les personal access token soient créés par un compte de service qui est ensuite exempté des contrôles d’IP dans la stratégie d’accès conditionnel de votre fournisseur d’identité.
Si vous ne pouvez pas utiliser un compte de service, une autre option pour débloquer les actions qui utilisent des personal access token consiste à autoriser les plages d’IP utilisées par GitHub Actions. Pour plus d’informations, consultez « À propos des adresses IP de GitHub ».
GitHub Codespaces
GitHub Codespaces peut ne pas être disponible si votre entreprise utilise l’authentification unique OIDC avec une stratégie d’accès conditionnel pour restreindre l’accès par adresses IP. En effet, les codespaces sont créés avec des adresses IP dynamiques qui seront probablement bloquées par la stratégie d’accès conditionnel de votre fournisseur d’identité. D’autres stratégies d’accès conditionnel peuvent également affecter la disponibilité de GitHub Codespaces, en fonction de la configuration spécifique de la stratégie.
L’éditeur github.dev
L'éditeur github.dev peut ne pas être disponible si votre entreprise utilise OIDC SSO avec CAP pour restreindre l'accès par adresses IP. En effet, github.dev s'appuie sur des adresses IP dynamiques que le CAP de votre IdP risque de bloquer. D'autres stratégies PAC peuvent également affecter la disponibilité de github.dev, en fonction de la configuration spécifique de la stratégie.
GitHub Apps et OAuth apps
Quand des GitHub Apps et des OAuth apps connectent un utilisateur et font des demandes au nom de cet utilisateur, GitHub envoie l’adresse IP du serveur de l’application à votre fournisseur d’identité pour validation. Si l’adresse IP du serveur de l’application n’est pas validée par la stratégie d’autorisation de connexion de votre fournisseur d’identité, la demande échouera.
Quand des GitHub Apps appellent des API GitHub faisant office d’application elle-même ou d’installation, ces appels ne sont pas effectués au nom d’un utilisateur. Étant donné que la stratégie d’autorisation de connexion de votre fournisseur d’identité exécute des stratégies et les applique à des comptes d’utilisateur, ces requêtes d’application ne peuvent pas être validées par rapport à la stratégie d’autorisation de connexion et elles sont toujours autorisées. Pour plus d’informations sur l’authentification des GitHub Apps en tant qu’elles-mêmes ou en tant qu’installations, consultez « À propos de l’authentification avec une application GitHub ».
Vous pouvez contacter les propriétaires des applications que vous souhaitez utiliser, demander leurs plages d’adresses IP et configurer la stratégie d’autorisation de connexion de votre fournisseur d’identité pour autoriser l’accès à partir de ces plages d’adresses IP. Si vous ne parvenez pas à contacter les propriétaires, vous pouvez consulter les journaux d’ouverture de session de votre fournisseur d’identité pour voir les adresses IP qui ont fait l’objet des demandes, puis les inscrire sur une liste d’autorisation.
Si vous ne souhaitez pas autoriser toutes les plages d’adresses IP pour toutes les applications de votre entreprise, vous pouvez également exempter les GitHub Apps installées et les OAuth apps autorisées de la liste d’autorisations du fournisseur d’identité. Si vous le faites, ces applications continueront de fonctionner quelle que soit l’adresse IP d’origine. Pour plus d’informations, consultez « Application de stratégies pour les paramètres de sécurité dans votre entreprise ».