Replies: 93 comments 24 replies
-
|
Considering how organization level secrets are indirectly available to all users with |
Beta Was this translation helpful? Give feedback.
-
|
This feature will really reduce our work a lot. Please try to implement this. |
Beta Was this translation helpful? Give feedback.
-
|
Potentially the biggest improvement to GitHub in 2023 will be this (if it happens). |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
+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 :-) |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
Is there any official plan on implementing organization level environment? |
Beta Was this translation helpful? Give feedback.
-
|
+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? |
Beta Was this translation helpful? Give feedback.
-
|
+1 on this. Do we have any updates if its even considered on a roadmap? |
Beta Was this translation helpful? Give feedback.
-
|
this++ We are looking at switching to another manager because without this it becomes very unwieldy |
Beta Was this translation helpful? Give feedback.
-
|
+1 Definitely this will reduce lot of duplication. |
Beta Was this translation helpful? Give feedback.
-
|
+1 I am migrating to Actions, and I thought this functionality existed. |
Beta Was this translation helpful? Give feedback.
-
|
+1 It's hard to understand why this feature hasn't been implemented yet, environment setup and secret rotation is a nightmare without it. |
Beta Was this translation helpful? Give feedback.
-
|
+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 🙏🏻 |
Beta Was this translation helpful? Give feedback.
-
|
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 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) |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
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. Duplicating secrets and recreating copies of environments for each repo is, as others have mentioned, horrible to do as well as maintain. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
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 When configuring environments in a given repo, I set a single variable called So, for the first environment, the value of 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: |
Beta Was this translation helpful? Give feedback.
-
|
Looks like this item still isn't on the roadmap :( |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
Hey GitHub, hear our cheer, Secrets here and envs are near, Think of UX, smooth and sweet, |
Beta Was this translation helpful? Give feedback.
-
|
We have been using org-level secrets with prefixes ( 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. |
Beta Was this translation helpful? Give feedback.
-
|
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. It would be nice to hear a response from GitHub as they are making the shared responsibility for secrets painful at best. |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions