Configurando o acesso a registros privados para Dependabot

Você pode configurar Dependabot para acessar dependências armazenadas em registros privados. Você pode armazenar informações de autenticação, como senhas e tokens de acesso, como segredos criptografados e, em seguida, referenciá-las no Dependabot arquivo de configuração. Se você tiver registros em redes privadas, também poderá configurar o acesso de Dependabot ao executar Dependabot em executores auto-hospedados.

Quem pode usar esse recurso?

Usuários com com acesso para gravação

Neste artigo

Sobre registros privados

          Dependabot version updates mantém suas dependências atualizadas e Dependabot security updates atualiza dependências vulneráveis. 
          Dependabot pode acessar registros públicos. Além disso, você pode dar Dependabot acesso a registros de pacotes privados e repositórios privados GitHub para que você possa manter suas dependências privadas e internas tão atualizadas e seguras quanto suas dependências públicas.

Na maioria dos ecossistemas, as dependências privadas geralmente são publicadas em registros de pacotes privados. Esses registros privados são semelhantes aos equivalentes públicos, mas exigem autenticação.

Para ecossistemas específicos, você pode configurar Dependabot para acessar apenas registros privados removendo chamadas para registros públicos. Para saber mais, confira Removendo o acesso do Dependabot a registros públicos.

          Para permitir o Dependabot acesso a registros hospedados de forma privada ou restrita a redes internas, configure Dependabot para ser executado em GitHub Actions executores auto-hospedados. Para obter mais informações, consulte [AUTOTITLE](/code-security/dependabot/maintain-dependencies/managing-dependabot-on-self-hosted-runners).

Configurando registros privados

Você pode configurar o acesso de Dependabot a registros privados no nível da organização.

Os registros no nível da organização dão suporte à autenticação token, nome de usuário e senha e OIDC .

Para obter mais informações sobre a configuração, consulte Como dar aos recursos de segurança acesso a registros privados.

Você também pode configurar o acesso de Dependabot a registros privados no arquivo dependabot.yml. A chave de nível superior registries é opcional e especifica detalhes de autenticação.

Há 2 locais no arquivo dependabot.yml em que você pode usar a chave registries:

  • No nível superior, onde você define os registros e suas informações de acesso, se necessário.
  • Dentro dos blocos updates, onde você pode usar registries: "*" para dizer ao Dependabot para usar qualquer um ou todos os registros que você definiu no nível superior.
# 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"

Você utiliza as seguintes opções para especificar as configurações de acesso. As configurações do registro precisam conter um type e uma url e, normalmente, uma combinação de username e password ou um token.

ParâmetrosFinalidade
REGISTRY_NAMEObrigatório: define um identificador para o registro.
typeObrigatório: identifica o tipo de registro.
Detalhes de autenticaçãoObrigatório: os parâmetros com suporte para fornecer detalhes de autenticação variam para registros de diferentes tipos.
urlObrigatório: a URL a ser usada para acessar as dependências deste registro. O protocolo é opcional. Se não for especificado, https:// é assumido. Dependabot adiciona ou ignora barras à direita, conforme necessário.
replaces-baseSe o valor booliano for true, Dependabot resolverá as dependências usando a URL base especificada url e não a URL base desse ecossistema.

Para obter mais informações sobre as opções de configuração disponíveis, como usá-las e sobre os tipos compatíveis, consulte Referência de opções do Dependabot.

Armazenando credenciais para o Dependabot usar

Para dar Dependabot acesso aos registros privados com suporte GitHub, armazene o token de acesso ou o segredo do registro no repositório de segredos para seu repositório ou organização.

Sobre segredos criptografados para Dependabot

          Dependabot os segredos são credenciais criptografadas que você cria no nível da organização ou do repositório.

Ao adicionar um segredo no nível da organização, é possível especificar quais repositórios podem acessar o segredo. Você pode usar segredos para permitir que Dependabot atualize dependências localizadas em registros de pacotes privados. Quando você adiciona um segredo, ele é criptografado antes de chegar a GitHub e permanece criptografado até ser usado por Dependabot para acessar um registro de pacote privado.

          Dependabot os segredos também englobam aqueles usados por GitHub Actions fluxos de trabalho iniciados por Dependabot pull requests. 
          Dependabot em si pode não usar esses segredos, mas os fluxos de trabalho exigem eles. Para saber mais, confira [AUTOTITLE](/code-security/dependabot/troubleshooting-dependabot/troubleshooting-dependabot-on-github-actions#accessing-secrets).

Depois de adicionar um Dependabot segredo, você pode referenciá-lo no dependabot.yml arquivo de configuração como este: ${{secrets.NAME}}, em que "NAME" é o nome escolhido para o segredo. Por exemplo:

YAML
password: ${{secrets.MY_ARTIFACTORY_PASSWORD}}

Nomear os seus segredos

O nome de um Dependabot segredo:

  • Só pode conter caracteres alfanuméricos ([A-Z], [0-9]) ou sublinhados (_). Não são permitidos espaços. Se você inserir letras minúsculas, elas serão alteradas para maiúsculas.
  • Não precisa começar com o prefixo GITHUB_.
  • Não precisa começar com um número.

Adicionando um segredo de repositório para Dependabot

Para criar segredos para um repositório de conta pessoal, você deve ser o proprietário do repositório. Para criar segredos para um repositório da organização, você precisa ter acesso de admin.

  1. Em GitHub, acesse a página principal do repositório.

  2. No nome do repositório, clique em Settings. Caso não consiga ver a guia "Configurações", selecione o menu suspenso , clique em Configurações.

    Captura de tela de um cabeçalho de repositório que mostra as guias. A guia "Configurações" é realçada por um contorno laranja-escuro.

  3. Na seção "Security" da barra lateral, selecione Secrets and variables e clique em Dependabot.

  4. Clique em Novo segredo de repositório.

  5. Digite um nome para o segredo na caixa de entrada Nome.

  6. Insira o valor para o seu segredo.

  7. Clique em Adicionar segredo.

    O nome do segredo está listado na página de segredos do Dependabot. Clique em Atualizar para alterar o valor secreto. Clique em Remover para excluir o segredo.

Adicionando um segredo da organização a Dependabot

Ao criar um segredo em uma organização, você pode usar uma política para limitar quais repositórios podem acessar esse segredo. Por exemplo, você pode conceder acesso a todos os repositórios ou limitar o acesso a apenas repositórios privados ou a uma lista específica de repositórios.

Para criar segredos no nível da organização, você precisa ter acesso de admin.

  1. Em GitHub, acesse a página principal da organização.

  2. No nome da organização, clique em Settings. Caso não consiga ver a guia "Configurações", selecione o menu suspenso , clique em Configurações.

    Captura de tela das guias no perfil de uma organização. A guia "Configurações" está contornada em laranja escuro.

           1. Na seção "Security" da barra lateral, selecione **<svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-key-asterisk" aria-label="key-asterisk" role="img"><path d="M0 2.75A2.75 2.75 0 0 1 2.75 0h10.5A2.75 2.75 0 0 1 16 2.75v10.5A2.75 2.75 0 0 1 13.25 16H2.75A2.75 2.75 0 0 1 0 13.25ZM2.75 1.5c-.69 0-1.25.56-1.25 1.25v10.5c0 .69.56 1.25 1.25 1.25h10.5c.69 0 1.25-.56 1.25-1.25V2.75c0-.69-.56-1.25-1.25-1.25Z"></path><path d="M8 4a.75.75 0 0 1 .75.75V6.7l1.69-.975a.75.75 0 0 1 .75 1.3L9.5 8l1.69.976a.75.75 0 0 1-.75 1.298L8.75 9.3v1.951a.75.75 0 0 1-1.5 0V9.299l-1.69.976a.75.75 0 0 1-.75-1.3L6.5 8l-1.69-.975a.75.75 0 0 1 .75-1.3l1.69.976V4.75A.75.75 0 0 1 8 4Z"></path></svg> Secrets and variables** e clique em **Dependabot**.
       Ignore a opção "Registros Privados", que é usada apenas pela code scanning configuração padrão.

  3. Clique em Novo segredo da organização.

  4. Digite um nome para o segredo na caixa de entrada Nome.

  5. Insira o Valor do segredo.

  6. Na lista suspensa Acesso do repositório, escolha uma política de acesso.

  7. Se você escolheu Repositórios selecionados:

    • Clique em .
    • Na caixa de diálogo, selecione os repositórios que podem acessar esse segredo.
    • Clique em Atualizar seleção.

  8. Clique em Adicionar segredo.

    O nome do segredo está listado na Dependabot página de segredos. Clique em Atualizar para alterar o valor do segredo ou a respectiva política de acesso. Clique em Remover para excluir o segredo.

Como configurar regras de IP do firewall

Você pode adicionar Dependabot endereços IP relacionados à lista de IPs permitidos de seus registros.

Se o registro privado estiver configurado com uma lista de permissões de IP, você poderá encontrar os endereços Dependabot IP usados para acessar o registro no ponto de extremidade da meta API, sob a chave actions. Para saber mais, confira Pontos de extremidade da API REST para metadados e Sobre o Dependabot em executores do GitHub Actions.

Usando o OIDC para autenticação

          Dependabot pode usar o OpenID Connect (OIDC) para autenticar com registros privados, eliminando a necessidade de armazenar credenciais de longa duração como segredos do repositório.

Com a autenticação baseada em OIDC, Dependabot as tarefas de atualização podem obter dinamicamente credenciais de curta duração do seu provedor de identidade na nuvem, assim como GitHub Actions fluxos de trabalho usando a federação OIDC.

Dica

A autenticação OIDC também está disponível para registros privados no nível da organização , que você pode definir por meio da interface do usuário das configurações da organização ou da API REST. Para saber mais, confira Como dar aos recursos de segurança acesso a registros privados.

          Dependabot dá suporte à autenticação OIDC para qualquer tipo de registro que usa `username` e `password` autenticação, quando o registro é hospedado em um dos seguintes provedores de nuvem:
  • AWS CodeArtifact
  • Artefatos de Azure DevOps
  • Artefato JFrog

Para configurar a autenticação OIDC, você precisa especificar valores diferentes em vez de username e password na configuração do seu registro.

AWS CodeArtifact

O CodeArtifact do AWS requer os valoresaws-region, account-id, role-namee domain``domain-owner. O campo audience é opcional.

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

Artefatos de Azure DevOps

Azure DevOps Artifacts requer os valores tenant-id e 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 }}

Artefato JFrog

JFrog Artifactory requer os valores url e jfrog-oidc-provider-name. Os valores audience e identity-mapping-name são opcionais:

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

Para obter mais informações sobre como o OIDC funciona, consulte OpenID Connect.

Permitir a execução de código externo

Quando você dá Dependabot acesso a um ou mais registros, a execução de código externo é desabilitada automaticamente para proteger seu código contra pacotes comprometidos. No entanto, algumas atualizações de versão podem falhar.

Se você precisar permitir o Dependabot acesso a um registro de pacote privado e habilitar a execução limitada de código externo, poderá definir insecure-external-code-execution como allow. Permitir a execução Dependabot de código externo no manifesto durante as atualizações não é tão assustador quanto parece:

  • Qualquer execução de código externo só terá acesso aos gerenciadores de pacotes nos registros associados à configuração delimitadora updates.
  • Não há permissão para acesso a nenhum dos registros definidos na configuração registries de nível superior.

É comum que ferramentas, como bundler, mix, pip e swift, permitam a execução de código externo por padrão.

Neste exemplo, o arquivo de configuração permite Dependabot acessar o registro de ruby-github pacote privado. Na mesma configuração updates, insecure-external-code-executioné definido como allow, o que significa que o código executado por dependências acessará apenas o Registro ruby-github e não o Registro 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"

Registros privados com suporte

Exemplos de como configurar o acesso aos repositórios privados com suporte de Dependabot.

cargo-registry

O tipo cargo-registry dá suporte a um token.

Esse tipo de registro corresponderá ao prefixo do caminho fornecido na opção url. Isso significa que você pode fornecer várias credenciais para o mesmo host, que podem ser usadas para acessar caminhos distintos. No entanto, se você não tiver vários registros no mesmo host, recomendamos que omita o caminho no url, para que todos os caminhos para o registro recebam credenciais.

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

Testamos essa configuração em relação ao registro privado https://cargo.cloudsmith.io.

composer-repository

O tipo composer-repository dá suporte a nome de usuário e senha. Se a conta for uma conta GitHub, você poderá usar um GitHub personal access token no lugar da senha.

Esse tipo de registro corresponderá ao prefixo do caminho fornecido na opção url. Isso significa que você pode fornecer várias credenciais para o mesmo host, que podem ser usadas para acessar caminhos distintos. No entanto, se você não tiver vários registros no mesmo host, recomendamos que omita o caminho no url, para que todos os caminhos para o registro recebam credenciais.

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

docker-registry

          Dependabot funciona com todos os registros de contêiner que implementam a especificação do registro de contêiner OCI. Para obter mais informações, consulte [https://github.com/opencontainers/distribution-spec/blob/main/spec.md](https://github.com/opencontainers/distribution-spec/blob/main/spec.md). 
          Dependabot dá suporte à autenticação para registros privados por meio de um serviço de token central ou autenticação HTTP Basic. Para obter mais detalhes, consulte [Especificação de Autenticação de Token](https://docs.docker.com/registry/spec/auth/token/) na documentação do Docker e [autenticação de acesso básico](https://en.wikipedia.org/wiki/Basic_access_authentication) na Wikipédia.

O tipo docker-registry dá suporte a nome de usuário e senha. Se a conta for uma conta GitHub, você poderá usar um GitHub personal access token no lugar da senha.

Esse tipo de registro corresponderá ao prefixo do caminho fornecido na opção url. Isso significa que você pode fornecer várias credenciais para o mesmo host, que podem ser usadas para acessar caminhos distintos. No entanto, se você não tiver vários registros no mesmo host, recomendamos que omita o caminho no url, para que todos os caminhos para o registro recebam credenciais.

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

O tipo docker-registry também pode ser usado para pull do Amazon ECR particular usando as credenciais estáticas da AWS.

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

O tipo git dá suporte a nome de usuário e senha. Se a conta for uma conta GitHub, você poderá usar um GitHub personal access token no lugar da senha.

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

goproxy-server

O tipo goproxy-server dá suporte a nome de usuário e senha. Se a conta for uma conta GitHub, você poderá usar um GitHub personal access token no lugar da senha.

Esse tipo de registro corresponderá ao prefixo do caminho fornecido na opção url. Isso significa que você pode fornecer várias credenciais para o mesmo host, que podem ser usadas para acessar caminhos distintos. No entanto, se você não tiver vários registros no mesmo host, recomendamos que omita o caminho no url, para que todos os caminhos para o registro recebam credenciais.

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

O helm-registry tipo dá suporte apenas à Autenticação Básica HTTP e não dá suporte a registros compatíveis com OCI. Se você precisar acessar um registro compatível com OCI para gráficos do Helm, configure um docker-registry em vez disso.

O tipo helm-registry dá suporte a nome de usuário e senha. Se a conta for uma conta GitHub, você poderá usar um GitHub personal access token no lugar da senha.

Esse tipo de registro corresponderá ao prefixo do caminho fornecido na opção url. Isso significa que você pode fornecer várias credenciais para o mesmo host, que podem ser usadas para acessar caminhos distintos. No entanto, se você não tiver vários registros no mesmo host, recomendamos que omita o caminho no url, para que todos os caminhos para o registro recebam credenciais.

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

hex-organization

O tipo hex-organization dá suporte a organização e chave.

Esse tipo de registro corresponderá ao prefixo do caminho fornecido na opção url. Isso significa que você pode fornecer várias credenciais para o mesmo host, que podem ser usadas para acessar caminhos distintos. No entanto, se você não tiver vários registros no mesmo host, recomendamos que omita o caminho no url, para que todos os caminhos para o registro recebam credenciais.

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

hex-repository

O tipo hex-repository dá suporte a uma chave de autenticação.

          `repo` é um campo obrigatório, que precisa corresponder ao nome do repositório usado na sua declaração de dependência.

          `public-key-fingerprint` é um campo de configuração opcional, que representa a impressão digital da chave pública para o repositório Hex. 
          `public-key-fingerprint` é usado pelo Hex para estabelecer confiança com o repositório privado. O `public-key-fingerprint` campo pode ser listado em texto sem formatação ou armazenado como um Dependabot segredo.
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

O maven-repository tipo dá suporte a nome de usuário, senha e substitui-base. Se a conta for uma conta GitHub, você poderá usar um GitHub personal access token no lugar da senha.

Esse tipo de registro corresponderá ao prefixo do caminho fornecido na opção url. Isso significa que você pode fornecer várias credenciais para o mesmo host, que podem ser usadas para acessar caminhos distintos. No entanto, se você não tiver vários registros no mesmo host, recomendamos que omita o caminho no url, para que todos os caminhos para o registro recebam credenciais.

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

Você também pode usar a autenticação OIDC para acessar o JFrog Artifactory. Com o OIDC, Dependabot obtém dinamicamente credenciais de curta duração em vez de usar credenciais estáticas.

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

O tipo npm-registry dá suporte a nome de usuário e senha ou a um token. Se a conta for uma conta GitHub, você poderá usar um GitHub personal access token no lugar da senha.

Ao utilizar nome de usuário e senha, o token de autenticação do .npmrc pode conter um base64 codificado _password; entretanto, a senha referenciada no arquivo de configuração do Dependabot deve ser a senha original (não codificada).

Observação

Ao utilizar npm.pkg.github.com, não inclua um caminho. Em vez disso, use a URL https://npm.pkg.github.com sem um caminho.

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

Por motivos de segurança, Dependabot não define variáveis de ambiente. O Yarn (v2 e posterior) requer que todas as variáveis de ambiente acessadas sejam definidas. Ao acessar variáveis de ambiente em seu .yarnrc.yml arquivo, você deve fornecer um valor de fallback, como${ENV_VAR-fallback} ou .${ENV_VAR:-fallback} Para obter mais informações, confira os arquivos Yarnrc na documentação do Yarn.

nuget-feed

O tipo nuget-feed dá suporte a nome de usuário e senha ou a um token. Se a conta for uma conta GitHub, você poderá usar um GitHub personal access token no lugar da senha.

          `nuget-feed` não oferece suporte ao parâmetro `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}}

Você também pode usar a autenticação OIDC para acessar Azure DevOps Artifacts. Com o OIDC, Dependabot obtém dinamicamente credenciais de curta duração em vez de usar credenciais estáticas.

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

Os valores AZURE_TENANT_ID e AZURE_CLIENT_ID podem ser obtidos na página de visão geral do registro do aplicativo Entra ID.

pub-repository

O tipo pub-repository dá suporte a uma URL e um token.

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

O tipo python-index dá suporte a nome de usuário e senha ou a um token. Se a conta for uma conta GitHub, você poderá usar um GitHub personal access token no lugar da senha.

Esse tipo de registro corresponderá ao prefixo do caminho fornecido na opção url. Isso significa que você pode fornecer várias credenciais para o mesmo host, que podem ser usadas para acessar caminhos distintos. No entanto, se você não tiver vários registros no mesmo host, recomendamos que omita o caminho no url, para que todos os caminhos para o registro recebam credenciais.

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

Você também pode usar a autenticação OIDC para acessar Azure DevOps Artifacts. Com o OIDC, Dependabot obtém dinamicamente credenciais de curta duração em vez de usar credenciais estáticas.

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

O tipo rubygems-server dá suporte a nome de usuário e senha ou a um token. Se a conta for uma conta GitHub, você poderá usar um GitHub personal access token no lugar da senha.

Esse tipo de registro corresponderá ao prefixo do caminho fornecido na opção url. Isso significa que você pode fornecer várias credenciais para o mesmo host, que podem ser usadas para acessar caminhos distintos. No entanto, se você não tiver vários registros no mesmo host, recomendamos que omita o caminho no url, para que todos os caminhos para o registro recebam credenciais.

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

O tipo terraform-registry dá suporte a um token.

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