GitHub Actions secrets improvements for Reusable workflows

[github-product-roadmap]

Summary

Today, a reusable workflow can only refer to the secrets from the repository where it is called (the caller repository), rather than the one in which it lives (the called repository). However, giving access to the secrets to the entire repository means anyone in the repository can use the secret.

With this current improvement, teams managing reusable workflows can refer to the secrets from the called (source) repos. These secrets are available only in the reusable workflow run context within in the caller (target) repos.

Intended Outcome

• Customers frequently have DevOps/platform teams that set policy centrally for tasks such as production deployments, while they have developer teams that own their own code and invoke the central policies.
• The platform team can create a reusable workflow (e.g., deploy.yml) in a repository managed by them and also define secrets referred to in the workflow.
• When a developer team uses the reusable workflow, they don't have to worry about the secrets used in the reusable workflow. Those secrets will not be accessible outside the context of the reusable workflow run.

How will it work?

• When a reusable workflow author wants to enforce the use of a secret from the called (source) repository, he or she will refer to that secret with a special syntax such as secret.source.NAME (syntax is not finalized yet)
• When that reusable workflow is run in the caller (target) repo, the secrets referred with the special syntax will be passed from the called (source) repo.
• Those secrets cannot be accessed outside the reusable workflow run context, preventing the developer team from viewing or exfiltrating them.

[ankneis]

This issue is being closed as outdated. For more information, please check out this Discussion post. Stay tuned for new additions to our refreshed public roadmap!