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

À 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 ».

Pour autoriser l’accès de Dependabot aux registres hébergés en privé ou limités aux réseaux internes, configurez Dependabot pour qu’il s’exécute sur les exécuteurs GitHub Actions auto-hébergés. Pour plus d’informations, consultez Configuration de Dependabot sur des exécuteurs auto-hébergés.

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è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 de fin selon les besoins.
`replaces-base`	Si 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}}

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

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.

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

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 », cette option est réservée à code scanning dans la configuration 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 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"

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

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

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.

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

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

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 de registres privés

Stockage des informations d’identification pour Dependabot

À propos des secrets chiffrés pour Dependabot

Nommage de vos secrets

Ajout d’un secret de dépôt pour Dependabot

Ajout d’un secret d’organisation pour Dependabot

Utilisation de OIDC pour l’authentification

AWS CodeArtifact

Artefacts Azure DevOps

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`

`nuget-feed`

`pub-repository`

`python-index`

`rubygems-server`

`terraform-registry`