You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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!
We wanted to provide more details on why this issue was removed from the public roadmap. We continue to recognize that these features are important and they're under consideration. We're removing it from this roadmap for now until we have more certainty on our timeline.
While we don’t have a timeline just yet, we’d love to hear your thoughts on what you’d like to see - feel free to upvote and share your feedback in this dedicated thread.
If this thread doesn’t quite cover what you had in mind, feel free to start a new discussion!
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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
deploy.yml
) in a repository managed by them and also define secrets referred to in the workflow.How will it work?
secret.source.NAME
(syntax is not finalized yet)The text was updated successfully, but these errors were encountered: