1

I am building a GitHub reusable workflow to act as a CI/CD pipeline for other repositories to use in our GitHub organization. Right now, the callee repository would need to pass in service principal credentials that the reusable workflow would use to login to azure, retrieve other secrets, etc. I was wondering if there was any possible way that the secrets that belong to the repository where the reusable workflow lives (say repo A) would be accessible when another workflow (say repo B) calls the reusable workflow, so that they do not need to pass in service principal creds or use the Azure/login action prior to calling the workflow. This would make it much easier so teams wouldn't be required to create a new service principal and configure permissions to our key vault in order to use the reusable workflow. Instead, only the one service principal (with creds stored as a secret in repo A) would be used.

I know this is possible with organization secrets, but we would want to ensure that that org secret would only be used in the context of the reusable workflow, and not capable of being used by other workflows. Basically, we need a way to have service principal creds consumable by every repository in our GitHub organization that wants to use the reusable workflow, but only in the context of the reusable workflow. I have been looking into using OIDC w/ Azure login, but since that is scoped to only specific repositories, didn't think it would work if we scoped it to repository A when the workflow is technically being ran in repository B.

Erik Umhoefer
  • 11
  • 2
  • There is currently no native solution to your problem. Or you'll need to inform org secrets (or repo secrets) through the workflow calling the reusable workflow, or you'll need a service to get those credentials from elsewhere, and then set them as env variable before using them. Another solution could be to use two repository dispatch events (a ping pong between 2 repos) to perform an operation on a specific repo (without using reusable workflow) and calling back the previous one afterwards... I don't know if your context would allow this behavior. – GuiFalourd Jul 19 '22 at 16:58
  • That's what I figured, I was mostly checking there wasn't an easier way that I hadn't discovered yet. I was thinking of possibly setting up some automation to create a new OIDC cred for a repository using our workflow (we have existing automation that runs as part of a GH workflow when teams make new repos for our service). Could you possibly explain a bit more about what you mean 'inform org secrets'? – Erik Umhoefer Jul 19 '22 at 17:06
  • It's just that there are 2 levels of secrets. Repository secrets, and organization secrets. I was just saying you can use one or the other from the workflow calling the reusable one. – GuiFalourd Jul 19 '22 at 17:56

1 Answers1

0

I found a solution to this issue using OpenID Connect with the Azure/login action.

Erik Umhoefer
  • 11
  • 2
  • As it’s currently written, your answer is unclear. Please [edit] to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Jul 22 '22 at 00:31