Configuration de l’accès aux registres privés pour Dependabot

Vous pouvez configurer Dependabot pour accéder aux dépendances stockées dans des registres privés. Vous pouvez stocker des informations d’authentification, telles que des mots de passe et des jetons d’accès, en tant que secrets chiffrés, puis les référencer dans le Dependabot fichier de configuration. Si vous avez des registres sur des réseaux privés, vous pouvez également configurer Dependabot l’accès lors de l’exécution Dependabot sur des exécuteurs auto-hébergés.

Qui peut utiliser cette fonctionnalité ?

Utilisateurs avec accès en écriture

Dans cet article

À propos des registres privés

          Dependabot version updates conserve vos dépendances up-to-date et Dependabot security updates met à jour les dépendances vulnérables. 
          Dependabot peut accéder aux registres publics. En outre, vous pouvez accorder Dependabot l’accès aux registres de paquets privés et aux dépôts privés GitHub afin que vous puissiez conserver vos dépendances privées et internes aussi à jour et sécurisées que vos dépendances publiques.

Dans la plupart des écosystèmes, les dépendances privées sont généralement publiées dans des registres de packages privés. Ces registres privés sont similaires à leurs équivalents publics, mais ils nécessitent une authentification.

Pour des écosystèmes spécifiques, vous pouvez configurer Dependabot pour accéder uniquement aux registres privés en supprimant les appels aux registres publics. Pour plus d’informations, consultez « Suppression de l’accès Dependabot aux registres publics ».

          Pour autoriser Dependabot l’accès aux registres hébergés en privé ou limités aux réseaux internes, configurez-le Dependabot pour s’exécuter sur GitHub Actions des exécuteurs auto-hébergés. Pour plus d’informations, consultez [AUTOTITLE](/code-security/dependabot/maintain-dependencies/managing-dependabot-on-self-hosted-runners).

Configuration de registres privés

Vous pouvez configurer Dependabotl’accès aux registres privés au niveau de l’organisation.

Les registres au niveau de l’organisation prennent en charge l’authentification jeton, nom d’utilisateur et mot de passe et OIDC .

Pour plus d’informations sur la configuration, consultez Accès des fonctionnalités de sécurité aux registres privés.

Vous pouvez également configurer Dependabotl’accès aux registres privés dans le dependabot.yml fichier. La clé registries de niveau supérieur est facultative et spécifie les détails d’authentification.

Il y a deux endroits dans le fichier dependabot.yml où vous pouvez utiliser la clé registries:

  • Au niveau supérieur, où vous définissez les registres et leurs informations d'accès, si nécessaire.
  • Dans les blocs updates, vous pouvez utiliser registries: "*" pour indiquer à Dependabot d'utiliser un ou tous les registres que vous avez définis au niveau supérieur.
# registries: gradle-artifactory - provides access details for the gradle-artifactory registry
# registries: "*" - allows Dependabot to use all the defined registries specified at the top level

version: 2
registries:
  gradle-artifactory:
    type: maven-repository
    url: https://acme.jfrog.io/artifactory/my-gradle-registry
    username: octocat
    password: ${{secrets.MY_ARTIFACTORY_PASSWORD}}
updates:
  - package-ecosystem: "gradle"
    directory: "/"
    registries: "*"
    schedule:
      interval: "monthly"

Vous utilisez les options suivantes pour spécifier les paramètres d’accès. Les paramètres de registre doivent contenir un type et une url et généralement soit une combinaison d’un username et d’un password, soit un token.

ParamètresObjectif
REGISTRY_NAMEObligatoire : définit un identificateur pour le Registre.
typeObligatoire : identifie le type de registre.
Informations sur l’authentificationObligatoire : les paramètres pris en charge pour fournir les détails de l’authentification varient selon les registres de différents types.
urlObligatoire : l’URL à utiliser pour accéder aux dépendances dans ce registre. Le protocole est facultatif. S’il n’est pas renseigné, la valeur https:// est supposée. Dependabot ajoute ou ignore les barres obliques de fin selon les besoins.
replaces-baseSi la valeur booléenne est true, Dependabot résout les dépendances en utilisant le url spécifié plutôt que l’URL de base de cet écosystème spécifique.

Pour plus d’informations sur les options de configuration disponibles et les types pris en charge, consultez Référence des options Dependabot.

Stockage des informations d’identification pour Dependabot

Pour accorder Dependabot l’accès aux registres privés pris en charge par GitHub, vous stockez le jeton d’accès ou le secret du registre dans le magasin de secrets de votre référentiel ou organisation.

À propos des secrets chiffrés pour Dependabot

          Dependabot les secrets sont des informations d’identification chiffrées que vous créez au niveau de l’organisation ou du référentiel.

Quand vous ajoutez un secret au niveau de l’organisation, vous pouvez spécifier les dépôts qui peuvent accéder à ce secret. Vous pouvez utiliser des secrets pour permettre Dependabot de mettre à jour les dépendances situées dans les registres de packages privés. Lorsque vous ajoutez un secret, il est chiffré avant d'atteindre GitHub et reste chiffré jusqu'à ce qu'il soit utilisé par Dependabot pour accéder à un registre privé de paquets.

          Dependabot les secrets incluent également les secrets utilisés par les flux de travail déclenchés par GitHub Actions les demandes de Dependabot tirage. 
          Dependabot elle-même ne peut pas utiliser ces secrets, mais les flux de travail les nécessitent. Pour plus d’informations, consultez « [AUTOTITLE](/code-security/dependabot/troubleshooting-dependabot/troubleshooting-dependabot-on-github-actions#accessing-secrets) ».

Après avoir ajouté un Dependabot secret, vous pouvez le référencer dans le dependabot.yml fichier de configuration comme suit : ${{secrets.NAME}}, où « NAME » est le nom que vous avez choisi pour le secret. Par exemple:

YAML
password: ${{secrets.MY_ARTIFACTORY_PASSWORD}}

Nommage de vos secrets

Nom d’un Dependabot secret :

  • Peut contenir uniquement des caractères alphanumériques ([A-Z], [0-9]) ou des traits de soulignement (_). Les espaces ne sont pas autorisés. Si vous entrez des lettres minuscules, celles-ci sont converties en lettres majuscules.
  • Ne doit pas commencer par le préfixe GITHUB_.
  • Ne doit pas commencer par un chiffre.

Ajout d’un secret de référentiel pour Dependabot

Pour créer des secrets pour un dépôt de compte personnel, vous devez être le propriétaire du dépôt. Pour créer des secrets pour un dépôt d’organisation, vous devez disposer d’un accès admin.

  1. Sur GitHub, accédez à la page principale du référentiel.

  2. Sous le nom de votre référentiel, cliquez sur Paramètres. Si vous ne voyez pas l’onglet « Paramètres », sélectionnez le menu déroulant , puis cliquez sur Paramètres.

    Capture d’écran d’un en-tête de dépôt montrant les onglets. L’onglet « Paramètres » est mis en évidence avec un encadré orange foncé.

  3. Dans la section « Sécurité » de la barre latérale, sélectionnez Secrets et variables, puis cliquez sur Dependabot.

  4. Cliquez sur Nouveau secret de dépôt.

  5. Tapez un nom pour votre secret dans la zone d’entrée Nom.

  6. Entrez la valeur de votre secret.

  7. Cliquez sur Ajouter un secret.

    Le nom du secret est listé dans la page des secrets Dependabot. Vous pouvez cliquer sur Mettre à jour pour changer la valeur du secret. Vous pouvez cliquer sur Supprimer pour supprimer le secret.

Ajout d’un secret d’organisation pour Dependabot

Lors de la création d’un secret dans une organisation, vous pouvez utiliser une stratégie pour limiter les dépôts qui peuvent accéder à ce secret. Par exemple, vous pouvez accorder l’accès à tous les dépôts, ou limiter l’accès aux seuls dépôts privés ou à une liste spécifiée de dépôts.

Pour créer des secrets au niveau de l’organisation, vous devez disposer d’un accès admin.

  1. Sur GitHub, accédez à la page principale de l’organisation.

  2. Sous le nom de votre organisation, cliquez sur Settings. Si vous ne voyez pas l’onglet « Paramètres », sélectionnez le menu déroulant , puis cliquez sur Paramètres.

    Capture d’écran des onglets dans le profil d’une organisation. L’onglet « Paramètres » est présenté en orange foncé.

           1. Dans la section « Sécurité » de la barre latérale, sélectionnez **<svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-key-asterisk" aria-label="key-asterisk" role="img"><path d="M0 2.75A2.75 2.75 0 0 1 2.75 0h10.5A2.75 2.75 0 0 1 16 2.75v10.5A2.75 2.75 0 0 1 13.25 16H2.75A2.75 2.75 0 0 1 0 13.25ZM2.75 1.5c-.69 0-1.25.56-1.25 1.25v10.5c0 .69.56 1.25 1.25 1.25h10.5c.69 0 1.25-.56 1.25-1.25V2.75c0-.69-.56-1.25-1.25-1.25Z"></path><path d="M8 4a.75.75 0 0 1 .75.75V6.7l1.69-.975a.75.75 0 0 1 .75 1.3L9.5 8l1.69.976a.75.75 0 0 1-.75 1.298L8.75 9.3v1.951a.75.75 0 0 1-1.5 0V9.299l-1.69.976a.75.75 0 0 1-.75-1.3L6.5 8l-1.69-.975a.75.75 0 0 1 .75-1.3l1.69.976V4.75A.75.75 0 0 1 8 4Z"></path></svg> Secrets et variables**, puis cliquez sur **Dependabot**.
       Ignorez l’option « Registres privés », qui est utilisée uniquement par la configuration par défaut.

  3. Cliquez sur Nouveau secret d’organisation.

  4. Tapez un nom pour votre secret dans la zone d’entrée Nom.

  5. Entrez la valeur de votre secret.

  6. Dans la liste déroulante Accès au dépôt, choisissez une stratégie d’accès.

  7. Si vous avez choisi Dépôts sélectionnés :

    • Cliquez sur .
    • Dans la boîte de dialogue, sélectionnez les dépôts qui peuvent accéder à ce secret.
    • Cliquez sur Mettre à jour la sélection.

  8. Cliquez sur Ajouter un secret.

    Le nom du secret est répertorié sur la Dependabot page des secrets. Vous pouvez cliquer sur Mettre à jour pour changer la valeur du secret ou sa stratégie d’accès. Vous pouvez cliquer sur Supprimer pour supprimer le secret.

Configuration des règles IP du pare-feu

Vous pouvez ajouter Dependabotdes adresses IP associées à votre liste d’adresses IP des registres.

Si votre registre privé est configuré avec une liste d'autorisation IP, vous pouvez trouver les adresses IP utilisées par Dependabot pour accéder au registre dans le point de terminaison de l'API meta, sous la clé actions. Pour plus d’informations, consultez « Points de terminaison d’API REST pour les métadonnées » et « À propos de Dependabot sur les exécuteurs GitHub Actions ».

Utilisation de OIDC pour l’authentification

          Dependabot peut utiliser OpenID Connect (OIDC) pour s’authentifier auprès des registres privés, ce qui élimine la nécessité de stocker des informations d’identification de longue durée en tant que secrets de dépôt.

Avec l’authentification basée sur OIDC, Dependabot les travaux de mise à jour peuvent obtenir dynamiquement des informations d’identification de courte durée auprès de votre fournisseur d’identité cloud, tout comme GitHub Actions les flux de travail utilisant la fédération OIDC.

Conseil

L’authentification OIDC est également disponible pour les registres privés au niveau de l’organisation , que vous pouvez configurer via l’interface utilisateur des paramètres de l’organisation ou l’API REST. Pour plus d’informations, consultez « Accès des fonctionnalités de sécurité aux registres privés ».

          Dependabot prend en charge l’authentification OIDC pour tout type de Registre qui utilise `username` et `password` authentification, lorsque le Registre est hébergé sur l’un des fournisseurs de cloud suivants :
  • AWS CodeArtifact
  • Artefacts Azure DevOps
  • JFrog Artifactory

Pour configurer l'authentification OIDC, vous devez spécifier différentes valeurs au lieu de username et password dans votre configuration de registre.

AWS CodeArtifact

AWS CodeArtifact nécessite les valeurs aws-region, , account-id``role-name, domainet domain-owner. Le champ audience est facultatif.

registries:
  my-aws-codeartifact-feed:
    type: npm-registry
    url: https://MY_DOMAIN-MY-ACCOUNT_ID.d.codeartifact.REGION.amazonaws.com/npm/MY_REPOSITORY/
    aws-region: REGION
    account-id: '123456789012'
    role-name: MY_ROLE_NAME
    domain: MY_DOMAIN
    domain-owner: '987654321098'
    audience: MY_AUDIENCE  # if required by your feed

Artefacts Azure DevOps

Azure DevOps Artifacts nécessite les valeurs tenant-id et client-id :

registries:
  my-azure-devops-artifacts-feed:
    type: npm-registry
    url: https://pkgs.dev.azure.com/MY-ORGANIZATION/MY-PROJECT/_packaging/MY-FEED/npm/registry/
    tenant-id: ${{ secrets.AZURE_TENANT_ID }}
    client-id: ${{ secrets.AZURE_CLIENT_ID }}

JFrog Artifactory

JFrog Artifactory requiert les valeurs url et jfrog-oidc-provider-name. Les valeurs audience et identity-mapping-name sont facultatives :

registries:
  my-jfrog-artifactory-feed:
    type: npm-registry
    url: https://JFROG-PLATFORM-URL/artifactory/api/npm/MY-REPOSITORY
    jfrog-oidc-provider-name: MY-PROVIDER
    audience: MY-AUDIENCE  # if required by your feed
    identity-mapping-name: MY-IDENTITY-MAPPING  # if required by your feed

Pour plus d’informations sur le fonctionnement d’OIDC, consultez OpenID Connect.

Autoriser l’exécution de code externe

Lorsque vous accordez Dependabot l’accès à un ou plusieurs registres, l’exécution de code externe est automatiquement désactivée pour protéger votre code contre les packages compromis. Toutefois, certaines mises à jour de version peuvent échouer.

Si vous devez autoriser Dependabot l’accès à un registre de packages privés et activer l’exécution limitée du code externe, vous pouvez définir insecure-external-code-execution sur allow. Autoriser Dependabot à exécuter du code externe dans le manifeste pendant les mises à jour n’est pas aussi effrayant qu'il n'y paraît.

  • Toute exécution de code externe n’aura accès qu’aux gestionnaires de packages dans les registres associés au paramètre contenant updates.
  • Aucun accès aux registres définis dans la configuration registries de niveau supérieur n’est autorisé.

Il est courant que les outils tels que bundler, mix, pip et swift autorisent par défaut l’exécution de code externe.

Dans cet exemple, le fichier de configuration permet Dependabot d’accéder au ruby-github registre de packages privés. Dans le même paramètre updates, insecure-external-code-execution est défini avec la valeur allow, ce qui signifie que le code exécuté par les dépendances accède uniquement au registre ruby-github, et non au registre dockerhub.

YAML
# Allow external code execution when updating dependencies from private registries

version: 2
registries:
  ruby-github:
    type: rubygems-server
    url: https://rubygems.pkg.github.com/octocat/github_api
    token: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}
updates:
  - package-ecosystem: "bundler"
    directory: "/rubygems-server"
    insecure-external-code-execution: allow
    registries: "*"
    schedule:
      interval: "monthly"

Registres privés pris en charge

Exemples de configuration de l’accès aux registres privés pris en charge par Dependabot.

cargo-registry

Le type cargo-registry prend en charge un jeton.

Ce type de registre correspond au préfixe du chemin d’accès fourni dans l’option url. Cela signifie que vous pouvez fournir plusieurs informations d’identification au même hôte, qui peuvent être utilisées pour accéder à des chemins d’accès distincts. Toutefois, si vous ne possédez pas plusieurs registres sur le même hôte, nous vous recommandons d’omettre le chemin d’accès du url, afin que tous les chemins d’accès au registre reçoivent des informations d’identification.

registries:
  cargo-example:
    type: cargo-registry
    registry: "name-of-your-registry"
    url: https://cargo.cloudsmith.io/foobaruser/test/
    token: "Token ${{secrets.CARGO_TOKEN}}"

Nous avons testé cette configuration sur le registre privé https://cargo.cloudsmith.io.

composer-repository

Le type composer-repository prend en charge le nom d’utilisateur et le mot de passe. Si le compte est celui GitHub, vous pouvez utiliser un GitHub personal access token à la place du mot de passe.

Ce type de registre correspond au préfixe du chemin d’accès fourni dans l’option url. Cela signifie que vous pouvez fournir plusieurs informations d’identification au même hôte, qui peuvent être utilisées pour accéder à des chemins d’accès distincts. Toutefois, si vous ne possédez pas plusieurs registres sur le même hôte, nous vous recommandons d’omettre le chemin d’accès du url, afin que tous les chemins d’accès au registre reçoivent des informations d’identification.

YAML
registries:
  composer:
    type: composer-repository
    url: https://repo.packagist.com/example-company/
    username: octocat
    password: ${{secrets.MY_PACKAGIST_PASSWORD}}

docker-registry

          Dependabot fonctionne avec tous les registres de conteneurs qui implémentent la spécification du registre de conteneurs OCI. Pour plus d’informations, consultez [https://github.com/opencontainers/distribution-spec/blob/main/spec.md](https://github.com/opencontainers/distribution-spec/blob/main/spec.md). 
          Dependabot prend en charge l’authentification auprès de registres privés par le biais d’un service de jeton central ou d’authentification HTTP Basic. Pour plus d’informations, consultez [la spécification de l’authentification par jeton](https://docs.docker.com/registry/spec/auth/token/) dans la documentation Docker et l’authentification [d’accès de base](https://en.wikipedia.org/wiki/Basic_access_authentication) sur Wikipédia.

Le type docker-registry prend en charge le nom d’utilisateur et le mot de passe. Si le compte est celui GitHub, vous pouvez utiliser un GitHub personal access token à la place du mot de passe.

Ce type de registre correspond au préfixe du chemin d’accès fourni dans l’option url. Cela signifie que vous pouvez fournir plusieurs informations d’identification au même hôte, qui peuvent être utilisées pour accéder à des chemins d’accès distincts. Toutefois, si vous ne possédez pas plusieurs registres sur le même hôte, nous vous recommandons d’omettre le chemin d’accès du url, afin que tous les chemins d’accès au registre reçoivent des informations d’identification.

YAML
registries:
  dockerhub:
    type: docker-registry
    url: https://registry.hub.docker.com
    username: octocat
    password: ${{secrets.MY_DOCKERHUB_PASSWORD}}
    replaces-base: true

Le type docker-registry peut également être utilisé pour effectuer un tirage à partir d’un registre ECR Amazon privé en utilisant des informations d’identification AWS statiques.

YAML
registries:
  ecr-docker:
    type: docker-registry
    url: https://1234567890.dkr.ecr.us-east-1.amazonaws.com
    username: ${{secrets.ECR_AWS_ACCESS_KEY_ID}}
    password: ${{secrets.ECR_AWS_SECRET_ACCESS_KEY}}
    replaces-base: true

git

Le type git prend en charge le nom d’utilisateur et le mot de passe. Si le compte est celui GitHub, vous pouvez utiliser un GitHub personal access token à la place du mot de passe.

YAML
registries:
  github-octocat:
    type: git
    url: https://github.com
    username: x-access-token
    password: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}

goproxy-server

Le type goproxy-server prend en charge le nom d’utilisateur et le mot de passe. Si le compte est celui GitHub, vous pouvez utiliser un GitHub personal access token à la place du mot de passe.

Ce type de registre correspond au préfixe du chemin d’accès fourni dans l’option url. Cela signifie que vous pouvez fournir plusieurs informations d’identification au même hôte, qui peuvent être utilisées pour accéder à des chemins d’accès distincts. Toutefois, si vous ne possédez pas plusieurs registres sur le même hôte, nous vous recommandons d’omettre le chemin d’accès du url, afin que tous les chemins d’accès au registre reçoivent des informations d’identification.

YAML
registries:
  my-private-registry:
    type: goproxy-server
    url: https://acme.jfrog.io/artifactory/api/go/my-repo
    username: octocat
    password: ${{secrets.MY_GO_REGISTRY_TOKEN}}

helm-registry

Le helm-registry type prend uniquement en charge l’authentification HTTP De base et ne prend pas en charge les registres conformes à OCI. Si vous avez besoin d’accéder à un registre conforme à OCI pour les charts Helm, configurez plutôt un docker-registry.

Le type helm-registry prend en charge le nom d’utilisateur et le mot de passe. Si le compte est celui GitHub, vous pouvez utiliser un GitHub personal access token à la place du mot de passe.

Ce type de registre correspond au préfixe du chemin d’accès fourni dans l’option url. Cela signifie que vous pouvez fournir plusieurs informations d’identification au même hôte, qui peuvent être utilisées pour accéder à des chemins d’accès distincts. Toutefois, si vous ne possédez pas plusieurs registres sur le même hôte, nous vous recommandons d’omettre le chemin d’accès du url, afin que tous les chemins d’accès au registre reçoivent des informations d’identification.

YAML
registries:
  helm_registry:
    type: helm-registry
    url: https://registry.example.com
    username: octocat
    password: ${{secrets.MY_REGISTRY_PASSWORD}}

hex-organization

Le type hex-organization prend en charge l’organisation et la clé.

Ce type de registre correspond au préfixe du chemin d’accès fourni dans l’option url. Cela signifie que vous pouvez fournir plusieurs informations d’identification au même hôte, qui peuvent être utilisées pour accéder à des chemins d’accès distincts. Toutefois, si vous ne possédez pas plusieurs registres sur le même hôte, nous vous recommandons d’omettre le chemin d’accès du url, afin que tous les chemins d’accès au registre reçoivent des informations d’identification.

YAML
registries:
  github-hex-org:
    type: hex-organization
    organization: github
    key: ${{secrets.MY_HEX_ORGANIZATION_KEY}}

hex-repository

Le type hex-repository prend en charge une clé d’authentification.

          `repo` est un champ obligatoire, qui doit correspondre au nom du dépôt utilisé dans votre déclaration de dépendance.

          `public-key-fingerprint` est un champ de configuration facultatif, qui représente l’empreinte digitale de la clé publique pour le dépôt Hex. 
          `public-key-fingerprint` est utilisé par Hex pour établir une confiance avec le dépôt privé. Le `public-key-fingerprint` champ peut être répertorié en texte clair ou stocké en tant que Dependabot secret.
YAML
registries:
   github-hex-repository:
     type: hex-repository
     repo: private-repo
     url: https://private-repo.example.com
     auth-key: ${{secrets.MY_AUTH_KEY}}
     public-key-fingerprint: ${{secrets.MY_PUBLIC_KEY_FINGERPRINT}}

maven-repository

Le type maven-repository prend en charge le nom d'utilisateur, le mot de passe et replaces-base. Si le compte est celui GitHub, vous pouvez utiliser un GitHub personal access token à la place du mot de passe.

Ce type de registre correspond au préfixe du chemin d’accès fourni dans l’option url. Cela signifie que vous pouvez fournir plusieurs informations d’identification au même hôte, qui peuvent être utilisées pour accéder à des chemins d’accès distincts. Toutefois, si vous ne possédez pas plusieurs registres sur le même hôte, nous vous recommandons d’omettre le chemin d’accès du url, afin que tous les chemins d’accès au registre reçoivent des informations d’identification.

YAML
registries:
  maven-artifactory:
    type: maven-repository
    url: https://acme.jfrog.io/artifactory/my-maven-registry
    username: octocat
    password: ${{secrets.MY_ARTIFACTORY_PASSWORD}}
    replaces-base: true

Vous pouvez également utiliser l’authentification OIDC pour accéder à JFrog Artifactory. Avec OIDC, Dependabot obtient dynamiquement des informations d’identification de courte durée au lieu d’utiliser des informations d’identification statiques.

YAML
registries:
  maven-artifactory-oidc:
    type: maven-repository
    url: https://acme.jfrog.io/artifactory/my-maven-registry
    tenant-id: ${{secrets.ARTIFACTORY_TENANT_ID}}
    client-id: ${{secrets.ARTIFACTORY_CLIENT_ID}}
    replaces-base: true

npm-registry

Le type npm-registry prend en charge le nom d’utilisateur et le mot de passe ou le jeton. Si le compte est celui GitHub, vous pouvez utiliser un GitHub personal access token à la place du mot de passe.

Lorsque vous utilisez un nom d’utilisateur et un mot de passe, votre .npmrcjeton d’authentification peut contenir un base64 mot de passe codé _password; toutefois, le mot de passe référencé dans votre Dependabot fichier de configuration doit être le mot de passe d’origine (non codé).

Remarque

Lorsque vous utilisez npm.pkg.github.com, n'incluez pas de chemin d'accès. Utilisez plutôt l’URL https://npm.pkg.github.com sans chemin.

YAML
registries:
  npm-npmjs:
    type: npm-registry
    url: https://registry.npmjs.org
    username: octocat
    password: ${{secrets.MY_NPM_PASSWORD}}  # Must be an unencoded password
    replaces-base: true
YAML
registries:
  npm-github:
    type: npm-registry
    url: https://npm.pkg.github.com
    token: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}
    replaces-base: true

Pour des raisons de sécurité, Dependabot ne définit pas les variables d’environnement. Yarn (v2 et ultérieur) nécessite que toutes les variables d’environnement accessibles soient définies. Lorsque vous accédez à des variables d’environnement dans votre .yarnrc.yml fichier, vous devez fournir une valeur de secours telle que${ENV_VAR-fallback} ou .${ENV_VAR:-fallback} Pour plus d’informations, consultez Fichiers Yarnrc dans la documentation de Yarn.

nuget-feed

Le type nuget-feed prend en charge le nom d’utilisateur et le mot de passe ou le jeton. Si le compte est celui GitHub, vous pouvez utiliser un GitHub personal access token à la place du mot de passe.

          `nuget-feed` ne prend pas en charge le paramètre `replaces-base`.
YAML
registries:
  nuget-example:
    type: nuget-feed
    url: https://nuget.example.com/v3/index.json
    username: octocat@example.com
    password: ${{secrets.MY_NUGET_PASSWORD}}
YAML
registries:
  nuget-azure-devops:
    type: nuget-feed
    url: https://pkgs.dev.azure.com/.../_packaging/My_Feed/nuget/v3/index.json
    username: octocat@example.com
    password: ${{secrets.MY_AZURE_DEVOPS_TOKEN}}

Vous pouvez également utiliser l’authentification OIDC pour accéder à Azure DevOps Artefacts. Avec OIDC, Dependabot obtient dynamiquement des informations d’identification de courte durée au lieu d’utiliser des informations d’identification statiques.

YAML
registries:
  nuget-azure-devops-oidc:
    type: nuget-feed
    url: https://pkgs.dev.azure.com/MyOrganization/MyProject/_packaging/MyArtifactFeedName/nuget/v3/index.json
    tenant-id: ${{secrets.AZURE_TENANT_ID}}
    client-id: ${{secrets.AZURE_CLIENT_ID}}

Les valeurs AZURE_TENANT_ID et AZURE_CLIENT_ID peuvent être obtenues à partir de la page vue d’ensemble de votre inscription d’application Entra ID.

pub-repository

Le type pub-repository prend en charge une URL et un jeton.

YAML
registries:
  my-pub-registry:
    type: pub-repository
    url: https://example-private-pub-repo.dev/optional-path
    token: ${{secrets.MY_PUB_TOKEN}}
updates:
  - package-ecosystem: "pub"
    directory: "/"
    schedule:
      interval: "weekly"
    registries:
      - my-pub-registry

python-index

Le type python-index prend en charge le nom d’utilisateur et le mot de passe ou le jeton. Si le compte est celui GitHub, vous pouvez utiliser un GitHub personal access token à la place du mot de passe.

Ce type de registre correspond au préfixe du chemin d’accès fourni dans l’option url. Cela signifie que vous pouvez fournir plusieurs informations d’identification au même hôte, qui peuvent être utilisées pour accéder à des chemins d’accès distincts. Toutefois, si vous ne possédez pas plusieurs registres sur le même hôte, nous vous recommandons d’omettre le chemin d’accès du url, afin que tous les chemins d’accès au registre reçoivent des informations d’identification.

YAML
registries:
  python-example:
    type: python-index
    url: https://example.com/_packaging/my-feed/pypi/example
    username: octocat
    password: ${{secrets.MY_BASIC_AUTH_PASSWORD}}
    replaces-base: true
YAML
registries:
  python-azure:
    type: python-index
    url: https://pkgs.dev.azure.com/octocat/_packaging/my-feed/pypi/example
    username: octocat@example.com
    password: ${{secrets.MY_AZURE_DEVOPS_TOKEN}}
    replaces-base: true

Vous pouvez également utiliser l’authentification OIDC pour accéder à Azure DevOps Artefacts. Avec OIDC, Dependabot obtient dynamiquement des informations d’identification de courte durée au lieu d’utiliser des informations d’identification statiques.

YAML
registries:
  python-azure-oidc:
    type: python-index
    url: https://pkgs.dev.azure.com/octocat/_packaging/my-feed/pypi/example
    tenant-id: ${{secrets.AZURE_TENANT_ID}}
    client-id: ${{secrets.AZURE_CLIENT_ID}}
    replaces-base: true

rubygems-server

Le type rubygems-server prend en charge le nom d’utilisateur et le mot de passe ou le jeton. Si le compte est celui GitHub, vous pouvez utiliser un GitHub personal access token à la place du mot de passe.

Ce type de registre correspond au préfixe du chemin d’accès fourni dans l’option url. Cela signifie que vous pouvez fournir plusieurs informations d’identification au même hôte, qui peuvent être utilisées pour accéder à des chemins d’accès distincts. Toutefois, si vous ne possédez pas plusieurs registres sur le même hôte, nous vous recommandons d’omettre le chemin d’accès du url, afin que tous les chemins d’accès au registre reçoivent des informations d’identification.

YAML
registries:
  ruby-example:
    type: rubygems-server
    url: https://rubygems.example.com
    username: octocat@example.com
    password: ${{secrets.MY_RUBYGEMS_PASSWORD}}
    replaces-base: true
YAML
registries:
  ruby-github:
    type: rubygems-server
    url: https://rubygems.pkg.github.com/octocat/github_api
    token: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}
    replaces-base: true

terraform-registry

Le type terraform-registry prend en charge un jeton.

YAML
registries:
  terraform-example:
    type: terraform-registry
    url: https://terraform.example.com
    token: ${{secrets.MY_TERRAFORM_API_TOKEN}}