Configurando o acesso a registros privados para Dependabot

Você pode configurar o 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, fazer referência a eles no arquivo de configuração do Dependabot.

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 as dependências vulneráveis. Dependabot pode acessar registros públicos. Além disso, você pode conceder ao Dependabot acesso a registros de pacotes privados e repositórios privados do 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, eliminando as chamadas para registros públicos. Para saber mais, confira Removendo o acesso do Dependabot a registros públicos.

Configurando registros privados

Você pode configurar o acesso do Dependabot a registros privados no nível da organização. Para obter mais informações de como configurar isso, confira Como dar aos recursos de segurança acesso a registros privados.

Você também pode configurar o acesso do 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 conceder a Dependabot acesso aos registros privados compatíveis com GitHub, armazene o token de acesso ou o segredo do Registro no repositório de segredos para seu repositório ou organização.

Sobre os segredos criptografados do Dependabot

Os segredos de Dependabot são credenciais criptografadas que você cria no nível de organização ou no nível 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 as dependências localizadas nos registros dos pacotes privados. Quando você adiciona um segredo, ele é criptografado antes de alcançar GitHub e permanece criptografado até que seja usado por Dependabot para acessar um registro de pacote privado.

Os segredos do Dependabot também incluem segredos usados por fluxos de trabalho de GitHub Actions disparados por solicitações de pull do Dependabot. O próprio Dependabot pode não usar esses segredos, mas eles são exigidos pelos fluxos de trabalho. Para saber mais, confira Como solucionar problemas do Dependabot no GitHub Actions.

Depois de adicionar um segredo do Dependabot, referencie-o no arquivo de configuração dependabot.yml assim: ${{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 segredo de Dependabot:

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

Adicionar um repositório secreto para Dependabot

Declaração de permissões do repositório para segredos.

  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.

Adicionar um segredo de organização para 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.

  3. Na seção "Security" da barra lateral, selecione Secrets and variables e clique em Dependabot. Ignore a opção "Registros Privados", pois ela é usada apenas pela configuração padrão do code scanning.

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

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

  6. Insira o Valor do segredo.

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

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

  9. Clique em Adicionar segredo.

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

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, os trabalhos de atualização do Dependabot podem obter dinamicamente credenciais de curta duração do seu provedor de identidade na nuvem, assim como os fluxos de trabalho do GitHub Actions que usam a federação OIDC.

O Dependabot suporta autenticação OIDC para qualquer tipo de registro que utilize autenticação username e password, quando o registro estiver hospedado em um dos seguintes provedores de nuvem:

  • AWS CodeArtifact
  • Artefatos do 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 do Azure DevOps

O 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ê fornece acesso a Dependabot a um ou mais registros, a execução do código externo é desabilitada automaticamente a fim de proteger o código contra pacotes comprometidos. No entanto, algumas atualizações de versão podem falhar.

Se você precisar permitir que o Dependabot acesse um registro de pacote privado e habilite a execução limitada de código externo, você poderá definir insecure-external-code-execution como allow. Permitir que o Dependabot execute código externo no manifesto durante atualizações não é tão assustador quando 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 que Dependabot acessem o Registro de pacote privado ruby-github. 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 registros privados compatíveis com 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 qualquer registro de contêiner que implemente a especificação de registro de contêiner OCI. Para obter mais informações, consulte https://github.com/opencontainers/distribution-spec/blob/main/spec.md. Dependabot dá suporte à autenticação em registros privados por meio de um serviço de token central ou autenticação básica HTTP. Para obter mais detalhes, confira Especificação de autenticação de token na documentação do Docker e a Autenticação de acesso básica 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 campo `public-key-fingerprint` pode ser listado em texto não criptografado ou armazenado como um segredo de Dependabot.
YAML
registries:
   github-hex-repository:
     type: hex-repository
     repo: private-repo
     url: https://private-repo.example.com
     auth-key: ${{secrets.MY_AUTH_KEY}}
     public-key-fingerprint: ${{secrets.MY_PUBLIC_KEY_FINGERPRINT}}

maven-repository

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.

Quando um nome de usuário e uma senha são usados, o token de autenticação de .npmrcpode conter uma base64 codificada em _password. No entanto, a senha referenciada no arquivo de configuração do Dependabot precisará 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, o 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 no arquivo .yarnrc.yml, 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 o 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 de AZURE_TENANT_ID e de AZURE_CLIENT_ID podem ser obtidos na página de resumo 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 o 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}}