Using organization secrets in reusable workflows

I imagine a fairly common use case is that organizations have a number of repositories with similar build and test processes. As such, reusable workflow are awesome. Within that, organization has Secrets which get used within said workflows.

Right now, secrets can be explicitly passed to reusable workflows, but that’s the only way to access them. So if we have 20 repositories using the same workflow, and that workflow accesses 7 secrets, then that’s 140 lines that are unnecessary if both repositories are in the same organization.

Am I missing something? Is there a way to do this now? Otherwise, this would be an amazing feature.


Hi - I’m the product manager for reusable workflows.

You’re right; the only way to access organization secrets is explicitly pass them. We designed it this way in order to support the principal of least privilege.

If the secrets you are creating are primarily for cloud credentials, than you find the upcoming feature Secure Cloud Deployments with OpenID Connect to be interesting. This feature will enable you to create a secret in AWS, Azure, GCP, HashiCorp, or other cloud services and then make that secret available to the reusable workflow, regardless of where its called from.

Hi @jenschelkopf!

Thank you for the insight. While that is useful, it doesn’t help with our specific situation. The workflow I’m using right now, for example, has the following secrets:

  • Path on remote server
  • Cloudflare zone
  • Remote server host
  • Remote server user
  • Private SSH key
  • Internal product ID
  • Slack webhook URL

None of these would be able to be exchanged with an OpenID. This workflow is used in ~20 repositories, and all but one secret is an organization secret. That means we have ~120 lines of redundant code, and changing the organization secret name has to be applied in every repo.

One option here would be the ability to allow organization secrets to be accessible to the repository which contains the reusable workflow. Secrets could even be manually selected or full access. This would tackle the issue for us and I suspect many others.


Same issue here. It would be nice to access the org secrets without passing them into every workflow.

Reusable workflows is a nice feature, but sadly, it lacks some handy features.

The reason “principal of least privilege” is perfect for theory and manager books but should not be used in practice. I have a huge amount of repositories which need to call a reusable workflow. The reusable workflow has its own repository with central secrets. All caller only need to call the reusable workflow. The reusable workflow takes care about the secrets. With this implementation i need to define the secrets for the whole organization and i need to pass them redundant from each caller. This is a very bad approach.

1 Like

We also have this issue. Secrets should not have to be manually passed down if the reusable workflow has access to the org secrets. There is so much duplicate code required, it’s going to be so difficult to convince my devops team that this is a better solution than our current jenkins/powershell where there is none of this extra overhead.