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

À 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 Configuration de Dependabot sur des exécuteurs auto-hébergés.

Configuration des registres privés GitHub-hébergés

Pour les packages stockés dans GitHub Packages ou Container registry, Dependabot peuvent s’authentifier automatiquement à l’aide de son GITHUB_TOKEN. Cela utilise les mêmes autorisations « Gérer l’accès aux actions » que celles utilisées par les flux de travail GitHub Actions. Aucune entrée de registre personal access tokens ou dependabot.yml n’est requise.

La configuration du registre dependabot.yml utilisant des entrées de registre basées sur Personal Access Token et décrite dans Configuration des registres tiers privés reste nécessaire pour les registres tiers privés (tels qu’Artifactory, Azure Artifacts ou Nexus).

Pour accorder Dependabot l’accès à un package privé :

Sur GitHub, accédez à la page principale de votre organisation.
Sous le nom de votre organisation, cliquez sur l’onglet Paquets.
Recherchez le nom du package que vous souhaitez gérer et cliquez dessus.
Dans la page d’accueil de votre package, sur le côté droit, cliquez sur Paramètres du package.
Sous « Gérer l’accès à Actions », cliquez sur Ajouter un dépôt et recherchez le dépôt que vous souhaitez ajouter. Recherchez le référentiel dans lequel Dependabot s’exécute, puis sélectionnez-le.
Utiliser le menu déroulant Rôle pour sélectionner le niveau d’accès par défaut dont vous aimeriez que votre dépôt dispose sur votre package. Sélectionnez Lire comme niveau d’accès. Dependabot a seulement besoin d’un accès en lecture pour récupérer des packages.

Vous devez répéter ces étapes pour chaque package privé auquel vous souhaitez Dependabot accéder.

Une fois l’accès accordé, Dependabot peut extraire automatiquement ces packages. Vous pouvez supprimer toutes les entrées de registre basées sur personal access token dans dependabot.yml que vous avez précédemment configurées pour ces packages.

Remarque

Cette méthode fonctionne pour tous les écosystèmes GitHub Packages pris en charge par Dependabot, y compris les images de conteneur dans Container registry.

Pour plus d’informations sur le fonctionnement de l’accès automatique, consultez Accès automatique de Dependabot aux registres hébergés sur GitHub. Pour plus d’informations sur les paramètres d’accès aux packages, consultez Configuration du contrôle d’accès et de la visibilité d’un package.

Configuration des registres tiers 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ètres	Objectif
`REGISTRY_NAME`
Obligatoire : définit un identificateur pour le Registre.
`type`
Obligatoire : identifie le type de registre.
Informations sur l’authentification
Obligatoire : les paramètres pris en charge pour fournir les détails de l’authentification varient selon les registres de différents types.
`url`
Obligatoire : 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 finales si nécessaire.
`replaces-base`	Si la valeur booléenne est `true`, Dependabot résout les dépendances à l’aide de l’URL de base spécifiée `url` plutôt que l’URL de base de cet écosystème.
`scope`	Pour le type `npm-registry` uniquement. Étendue npm à associer à ce registre, par exemple `@my-company`. Lorsque `scope` est fourni, Dependabot génère la configuration `.npmrc` à partir des identifiants du registre, en remplaçant tout fichier `.npmrc` versionné ou toute déduction à partir du fichier de verrouillage.

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 ceux utilisés par GitHub Actions les flux de travail déclenchés par Dependabot les pull requests. Dependabot elle-même ne peut pas utiliser ces secrets, mais les flux de travail les nécessitent. Pour plus d’informations, consultez « Résolution des problèmes de Dependabot sur GitHub Actions ».

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}}

password: ${{secrets.MY_ARTIFACTORY_PASSWORD}}

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

Sur GitHub, accédez à la page principale du référentiel.
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.
Dans la section « Sécurité » de la barre latérale, sélectionnez Secrets et variables, puis cliquez sur Dependabot.
Cliquez sur Nouveau secret de dépôt.
Tapez un nom pour votre secret dans la zone d’entrée Nom.
Entrez la valeur de votre secret.
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.

Sur GitHub, accédez à la page principale de l’organisation.
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.
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 » ; celle-ci est utilisée uniquement par la configuration code scanning par défaut.
Cliquez sur Nouveau secret d’organisation.
Tapez un nom pour votre secret dans la zone d’entrée Nom.
Entrez la valeur de votre secret.
Dans la liste déroulante Accès au dépôt, choisissez une stratégie d’accès.
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.
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 liées à la liste de permis IP de votre registre.

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 « Dependabot sur des 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 suivants :

AWS CodeArtifact
Artefacts Azure DevOps
Cloudsmith
Google Cloud Artifact Registry
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 }}

Cloudsmith

Cloudsmith requiert les valeurs namespace, service-sluget audience. Le api-host champ est facultatif et est défini par défaut sur api.cloudsmith.io:

registries:
  my-cloudsmith-feed:
    type: npm-registry
    url: https://dl.cloudsmith.io/MY-NAMESPACE/MY-REPOSITORY/npm/
    namespace: MY-NAMESPACE
    service-slug: MY-SERVICE-SLUG
    audience: https://github.com/GITHUB-ORG
    api-host: api.cloudsmith.io  # if required by your feed

Google Cloud Artifact Registry

Google Cloud Artifact Registry nécessite les valeurs url et workload-identity-provider. Les valeurs service-account et audience sont facultatives :

registries:
  my-gcp-artifact-registry:
    type: docker-registry
    url: https://REGION-docker.pkg.dev
    workload-identity-provider: projects/PROJECT-NUMBER/locations/global/workloadIdentityPools/POOL/providers/PROVIDER
    service-account: SA-NAME@PROJECT-ID.iam.gserviceaccount.com  # if required by your provider
    audience: MY-AUDIENCE  # if required by your provider

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"

# 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
composer-repository
docker-registry
git
goproxy-server
hex-organization
hex-repository
maven-repository
npm-registry
nuget-feed
pub-repository
python-index
rubygems-server
terraform-registry

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

YAML

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

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. 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 dans la documentation Docker et l’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.

YAML

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

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

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}}

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.

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}}

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.

YAML

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

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

YAML

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

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}}

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.

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

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

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

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

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.

Utilisation `scope` pour mapper des étendues npm aux registres

Vous pouvez utiliser le scope paramètre pour associer une étendue npm à un registre privé. Lorsque scope est configuré, Dependabot génère le .npmrc à partir de vos identifiants de registre, qui prévaut sur tout fichier .npmrc validé ou sur l’inférence basée sur le fichier de verrouillage. La valeur d’étendue doit commencer par @, par exemple @my-company. Pour associer plusieurs étendues au même registre, créez une entrée de Registre distincte pour chaque étendue.

Dans l’exemple suivant, les packages sous @my-company et @my-other-org sont tous les deux routés vers le registre npm privé GitHub , chacun avec sa propre entrée de Registre.

YAML

registries:
  npm-github-company:
    type: npm-registry
    url: https://npm.pkg.github.com
    scope: "@my-company"
    token: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}
  npm-github-other-org:
    type: npm-registry
    url: https://npm.pkg.github.com
    scope: "@my-other-org"
    token: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}

registries:
  npm-github-company:
    type: npm-registry
    url: https://npm.pkg.github.com
    scope: "@my-company"
    token: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}
  npm-github-other-org:
    type: npm-registry
    url: https://npm.pkg.github.com
    scope: "@my-other-org"
    token: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}

`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}}

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}}

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}}

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

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.

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

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

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

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

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.

YAML

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

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

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}}

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

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

Qui peut utiliser cette fonctionnalité ?

Dans cet article

À propos des registres privés

Configuration des registres privés GitHub-hébergés

Configuration des registres tiers privés

Stockage des informations d’identification pour Dependabot

À propos des secrets chiffrés pour Dependabot

Nommer vos secrets

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

Ajout d’un secret d’organisation pour Dependabot

Configuration des règles IP du pare-feu

Utilisation de OIDC pour l’authentification

AWS CodeArtifact

Artefacts Azure DevOps

Cloudsmith

Google Cloud Artifact Registry

JFrog Artifactory

Autoriser l’exécution de code externe

Registres privés pris en charge

`cargo-registry`

`composer-repository`

`docker-registry`

`git`

`goproxy-server`

`helm-registry`

`hex-organization`

`hex-repository`

`maven-repository`

`npm-registry`

Utilisation `scope` pour mapper des étendues npm aux registres

`nuget-feed`

`pub-repository`

`python-index`

`rubygems-server`

`terraform-registry`

Ce document a-t-il été utile ?

Encore besoin d’aide ?