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]

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

[cipacera]

What challenges have you faced in managing sensitive secrets across multiple repositories in your organization?

[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

[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 :-)

[mac2000]

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 🙏🏻

[javy99]

GitHub needs Organization Environment Secrets to address the gap between Organization Secrets and Environment Secrets. This feature would allow environment-specific secrets to be shared across multiple repositories in an organization, simplifying management and improving consistency for deploying to different environments (like Kubernetes clusters).

Note: If you support this request, please upvote instead of replying with "+1" to avoid unnecessary notifications.

[WZaradzki]

+1

[armand-sauzay]

+1

[subarudad]

+1

[bryanmundieGroups360]

+1

[mohamedelhabib]

+1

[ro8SebMi]

+1

[saargon]

Please add this.

[Grgroupbangalore]

Use tools like GitHub Actions or Azure Pipelines, which offer secure storage and management of environment variables and secrets, to efficiently manage organizations and confidential data. By centralizing these, you can simplify updates when credentials or configurations change between environments, increase security by restricting access, and guarantee consistency across projects.

[nebuk89]

Hey! Sorry product has been quiet on this one :) I am trying to catch up going through all the items in discussions that have high engagement but we have quite a few 😱

We do have this scoped, but no timelines right now. Realistically this means we know we are not doing something this big within the next 6 months or so 😞 The roadmap is the place to look to see where we are investing, so please keep an eye there.
And thank you all for engaging and for so long without product coming back -> we are here to listen so please keep sharing with us <3

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[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.