Organization-wide Environments and Environment Secrets

[philomory]

If you have a lot of repositories with microservices deploying to the same environments (e.g. the same Kubernetes clusters, say), it can be useful to have a set of secrets available to all repositories in an organization. Of course, we already have this with Organization Secrets. However, this breaks down when some of those secrets - still common to many repositories within the organization - need to be distinct for different environments.

Environments and Environment Secrets are a great feature. Organization Secrets are a great feature. But, there's friction because you can't really use them together. We need Organization Environments and Organization Environment Secrets.

NOTE: If you want to show your support for this feature request, please upvote it using the upvote button

rather than replying with a "+1". Replies like that just result in sending spam to everyone else interested in the issue, and importantly, don't even "count" when it comes to how much GitHub will prioritize the issue. They're just spam, they're not spam that also counts as a vote in any way.

[djfinnoy]

Considering how organization level secrets are indirectly available to all users with write access, environments are the only way to protect sensitive secrets from attacks originating inside the organization (eg. stolen credentials). Without organization-wide environments, protecting sensitive secrets across multiple repositories is a huge pain.

[Vana12330]

• [ ]

[Vana12330]

Просто зараз час такий людям віриш шо некинуть а потім думаєш чого не прийняв всі міри безпеки)Щоб інші теж могли заробляти

[RakeshAMD]

This feature will really reduce our work a lot. Please try to implement this.

[tomer-ds]

Potentially the biggest improvement to GitHub in 2023 will be this (if it happens).
It is an absolute pain attempting to generate and manage environments in each individual repository.
This feature is sorely lacking and a definite blocker to adoption on our part!!!

[SteveGachanja]

Totally agree, managing environment configurations on each individual repo is painful

[anthonyh-quilt]

if the repo's environment configurations were providing repo-specific overrides of org-wide environments

[guilhermeoki]

This feature will help us a lot! Due to this limitation, we've had to use organizational secrets per environment like K8S_SECRET_DEV and K8S_SECRET_PROD, and have replicated our workflows.

[ilmax]

This feature would help us to avoid a lot of duplication. I would also add that in our case we need the approval to be defined on these environments as well.

[andyjballgit]

+1 from me here - my use case is an Organisation that has multiple repos that host Terrafrom for Azure deployments - using github Environments / secrets for Service Principals / subscription ids etc. We have to duplicate secrets across the repos / environments . Just spent about an hour troubleshooting a missing one - so thats how i ended up here :-)

[marchenko1985]

Here is one more concern: Imagine we have "development", "staging" and "production" environments

How can we be sure that each and every repository will have them, e.g. I, as engineer, by mistake, created "testing" environment instead of "staging"

At moment it seems that only possible way to manage this is to make environments via API only and by schedule check/fix drift in every repository

[ilmax]

How can we be sure that each and every repository will have them, e.g. I, as engineer, by mistake, created "testing" environment instead of "staging"

One way to achieve it is to use terraform to setup the repository/environments/secrets structure, but with a lot of repositories and a lot of environments you need to figure out a way to partition the work because it takes a very loooooong time to apply

[akrymets]

We shouldn't worry about it. If some particular repository doesn't have a particular environment then it simply will not inherit this parameter from the organizational level.
It's not a technical issue - it's a question to your organization

[yukccy]

Is there any official plan on implementing organization level environment?

[cpvlordelo]

+1 on this. It would be really neat to be able to have org-level env secrets. It would reduce a lot of copypasta one has to do across org repos to create same environment settings. Any plans on making this available at all?

[wrzolekLukasz]

+1 on this. Do we have any updates if its even considered on a roadmap?

[hoherman]

this++

We are looking at switching to another manager because without this it becomes very unwieldy

[vmuthusamy-nlg]

+1

Definitely this will reduce lot of duplication.

[SOSkr]

+1

I am migrating to Actions, and I thought this functionality existed.
It was a disappointment to realize that it does not exist. :(

[trapeznikov]

+1

It's hard to understand why this feature hasn't been implemented yet, environment setup and secret rotation is a nightmare without it.

[kanocarra]

+1

We are microservices with ~80 repositories that all need to go to dev/staging/prod with terraform. I really don't fancy setting up environments with the exact same info for each repository 🙏🏻

[rickardp]

Another use case for this that I don't think was mentioned in this thread is for use with federated credentials. Currently for example Azure only supports per-repo or per-repo-per-environment

https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation-create-trust?pivots=identity-wif-apps-methods-azp#github-actions

This makes federated credentials virtually unusable unless you have a monorepo-type set up as every repository would mean having to add one environment and then updating the managed identity. The support for defining environments on a organization level and then associating these with federated credentials is currently preventing us from moving away from manually rotated client secrets. Azure DevOps does this (IMHO) correctly with the service connections and project-level environments. A manual approval with elevated permissions would be needed to prevent "rogue" repositories from hijacking credentials (also, look at AzDO)

[glucaci]

+1

[felipementel]

We've been looking forward to this feature for years. We need to have a single point of control for variables and secrets at the organization level to improve security and avoid replicating information, which is always a major point of failure when we need to update it.

[brnpimentel]

+1

[ernstk]

Something else to keep in mind for when this feature gets done (if ever) is that, a "staging" environment should never have access to secrets in the "production" environment.
An example could be an auth token that allows deployment to production GKE - when a staging-environment deployment task executes, it is essential that it only has access to the secrets for the chosen environment.

Duplicating secrets and recreating copies of environments for each repo is, as others have mentioned, horrible to do as well as maintain.

[alexandzors]

Duplicating secrets and recreating copies of environments for each repo is, as others have mentioned, horrible to do as well as maintain. @ernstk

This is a major pain point for us as well. It's extremely tedious to maintain copies of an environment on EVERY repository. Having org level environments would be very helpful. Most of our environments are the same so having them centrally located would be great.

[anthonyh-quilt]

Duplicating secrets and recreating copies of environments for each repo is, as others have mentioned, horrible to do as well as maintain. @ernstk

This is a major pain point for us as well. It's extremely tedious to maintain copies of an environment on EVERY repository. Having org level environments would be very helpful. Most of our environments are the same so having them centrally located would be great.

I was able to mitigate this attrition with a .bat script that would read values from a .env file and use the github cli to automate the step of updating the secrets in GitHub.

set GH_TOKEN=<TOKEN>
gh secret set -f .env

• This approach worked well for me but was difficult to support multiple devs needing to fan out to different service implementations (blocked until someone with a valid .env can "provision" the repo for the dev 🥴)
• Setting up a Team and unlocking Org Secrets for Private Repos was a huge win for unblocking the intended gitops flow... But now the same issue is preventing us from automating dev/staging/prod environment support (which is becoming critical as we approach app release 😅)

I've been keeping an eye on this issue since it was created but wanted to provide my 2 cents since it's still an issue... Unless there's an overall approach that would negate needing to store env-specific secrets in GitHub?

[alexandzors]

Appreciate the response! I'm not worried about the secrets since most of our actions read from org secrets anyway. Its mainly setting up the actual environments (prod, pre-prod, etc.). Having to manually create the envs on each repo that needs them is tedious to do and manage. They all have the same branch/tag rules and reviewer groups.

[ernstk]

So the exact same approach that has been taken per repo: a named environment with vars and secrets, should be done at an organizational level, and access can then be given to these organization-level environments (not vars) to selected- or all repositories.

…

-Ernst

On Sun, 26 Jan 2025 at 12:31, Erik Osinski ***@***.***> wrote: How do you think GitHub improving the management of environment configurations for individual repositories could facilitate broader adoption? — Reply to this email directly, view it on GitHub <#15379 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEGXP65M6QBCG5T6LT6WBD2MS2Q3AVCNFSM5UA7BK4KU5DIOJSWCZC7NNSXTOSENFZWG5LTONUW63SDN5WW2ZLOOQ5TCMJZGU3TAOBQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[exalted]

FWIW, here's the workaround I've been using in my workflows that reads from organization secrets:

Suppose you have two secrets in your organization, one for env1 and one for env2:

SECRET_ENV1=***
SECRET_ENV2=***

When configuring environments in a given repo, I set a single variable called SECRET_KEY.

So, for the first environment, the value of SECRET_KEY would be SECRET_ENV1 and SECRET_ENV2 for the second environment.

The secret remains in the organization, and the repository [environments] contain a reference to the secret's name of the organization.

Now, all that remains is a way to read the org secret, given the secret's name. Here's what you do in your workflow file:

env:
  SECRET: ${{ secrets[vars.SECRET_KEY] }}

Note: secrets[vars.SECRET_KEY] refers to org secret (or, technically, repo secret, if it was overridden —but the whole point of this exercise is that you don't need to!)

[bencat-sixense]

Thanks a lot for this trick, it's perfect !!!

[jfrank-nih]

This is a clever trick, and you don't even need to use your repo environments if you don't want to. You can calculate the secret name to use in a previous job and use the needs context to get to it: ${{ secrets[needs.my-job.outputs.secret-name] }}.

That said, if you use CodeQL scanning for GitHub actions it will give you a medium level issue for doing this:

When the workflow runner cannot determine what secrets are needed to run the workflow, it will pass all the available secrets to the runner including organization and repository secrets. This violates the least privileged principle and increases the impact of a potential vulnerability affecting the workflow.

Only pass those secrets that are needed by the workflow. Avoid using expressions such as toJSON(secrets) or dynamically accessed secrets such as secrets[format('GH_PAT_%s', matrix.env)] since the workflow will need to receive all secrets to decide at runtime which one needs to be used.

So if you're in an enterprise where such things are monitored/enforced this won't work for you.

[rondefreitas]

Looks like this item still isn't on the roadmap :(

[sebastianfeduniak]

+1

[saargon]

Hey GitHub, hear our cheer,
We've been waiting many years.
Roadmap on, then roadmap gone,
Why’s this taking quite so long?

Secrets here and envs are near,
But the feature’s not yet here.
Competitors, they have it too,
We just want the same from you!

Think of UX, smooth and sweet,
Make our workflows feel complete.
Hey GitHub, we hope you’ll see,
How much this would mean to we. ❤️

[xaviergmail]

We have been using org-level secrets with prefixes ({STAGE}_SECRET_KEY) since 2021. We have hit the 100 org secrets limit ages ago. This solution is desperately needed.

We don't want to have to rely on an external service to fetch secrets during CI, as that introduces another potential failure point.

Please don't make me have to use terraform to populate environment secrets and variables for each repo.

[TechIsCool]

With the recent change in copilot permissions that limits its access from ORG Secrets this has become a problem for our organization. We have a few read-only tokens that enable thinks like package repositories and we no longer have any simple solution to enable this.
https://github.com/orgs/community/discussions/177690

It would be nice to hear a response from GitHub as they are making the shared responsibility for secrets painful at best.

[gggoce]

+1

[alexandzors]

Can we finally get an update on this GitHub? Its now 2026 and we still do not have any information if this will ever be a feature for Orgs/Enterprise. The original request was posted in 2022... A simple 'yes its in the works' or 'no not happening' would be extremely appreciated.

We use workflow reviews for release gates which means we need to maintain copies of environments per repository rather then at the Org level. Not having this feature is making it harder on us to manage them when changes are needed. Especially across 100+ repositories. This would also help us lock down our secrets to specific deployment environments so not everyone in the org can easily access credentials for some of them.

At this rate we are looking at moving off GitHub for CI/CD specifically because of this one feature.