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 fichier de configuration Dependabot.

Qui peut utiliser cette fonctionnalité ?

Utilisateurs avec accès en écriture

Dans cet article

À propos des registres privés

Dependabot version updates maintient vos dépendances à jour 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 packages privés et aux référentiels GitHub privés afin que vous puissiez maintenir vos dépendances privées et internes à jour en tant que 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 ».

Configuration de registres privés

Vous pouvez configurer l'accès de Dependabot aux registres privés au niveau de l'organisation. Pour plus d’informations sur la configuration, consultez Accès des fonctionnalités de sécurité aux registres privés.

Vous pouvez également configurer l’accès de Dependabot aux registres privés dans le fichier dependabot.yml. 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, stockez le jeton d’accès ou le secret du registre dans le magasin de secrets de votre dépôt ou organisation.

À propos des secrets chiffrés pour Dependabot

Les secrets Dependabot sont des informations d’identification chiffrées que vous créez au niveau de l’organisation ou du dépôt. 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 autoriser Dependabot à mettre à jour les dépendances situées dans les registres de packages privés. Quand vous ajoutez un secret, il est chiffré avant d’atteindre GitHub et reste chiffré jusqu’à ce que Dependabot l’utilise pour accéder à un registre de packages privé.

Les secrets Dependabot incluent également les secrets utilisés par les workflows GitHub Actions déclenchés par les demandes de tirage Dependabot. Dependabot peut ne pas utiliser ces secrets, mais les workflows en ont besoin. Pour plus d’informations, consultez « Résolution des problèmes de Dependabot sur GitHub Actions ».

Après avoir ajouté un secret Dependabot, vous pouvez le référencer dans le fichier de configuration dependabot.yml 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

Le nom d’un secret Dependabot :

  • 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 dépôt pour Dependabot

  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.

éléments réutilisables.organizations.secrets-permissions-statement %}

  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é.

  3. Dans la section « Sécurité » de la barre latérale, sélectionnez Secrets et variables, puis cliquez sur Dependabot. Ignorez l’option « Registres privés », cette option est réservée à code scanning dans la configuration par défaut.

  4. Cliquez sur Nouveau secret d’organisation.

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

  6. Entrez la valeur de votre secret.

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

  8. 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.

  9. 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 ou sa stratégie d’accès. Vous pouvez cliquer sur Supprimer pour supprimer le secret.

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 référentiel.

Avec l’authentification basée sur OIDC, les tâches de mise à jour de Dependabot peuvent obtenir dynamiquement des identifiants de courte durée auprès de votre fournisseur d’identité cloud, tout comme les workflows de GitHub Actions utilisant la fédération OIDC.

Dependabot supporte l’authentification OIDC pour tout type de registre qui utilisent l'authentification username et password, 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 afin de protéger votre code contre les packages compromis. Toutefois, certaines mises à jour de version peuvent échouer.

Si vous devez accorder à Dependabot l’accès à un registre de packages privés et permettre l’exécution limitée de code externe, vous pouvez définir insecure-external-code-execution sur allow. Autoriser Dependabot à exécuter du code externe dans le manifeste lors des mises à jour n’est pas aussi effrayant que cela en a l’air :

  • 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 registre de packages privé ruby-github. 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 les spécifications du registre de conteneurs OCI. Pour plus d’informations, consultez https://github.com/opencontainers/distribution-spec/blob/main/spec.md. Dependabot prend en charge l’authentification auprès des registres privés via un service de jeton central ou l’authentification de base HTTP. Pour plus d’informations, consultez Spécification de l’authentification par jeton dans la documentation Docker et Authentification d’accès de base 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 champ `public-key-fingerprint` peut être listé en texte clair ou stocké en tant que secret Dependabot.
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.

Quand vous utilisez le nom d’utilisateur et le mot de passe, votre jeton d’authentification de .npmrc peut contenir un base64 codé _password ; toutefois, le mot de passe référencé dans votre fichier config Dependabot 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 fichier .yarnrc.yml, 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 Artifacts. 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 de présentation de l'enregistrement de votre 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 Artifacts. 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}}