Replies: 60 comments 12 replies
-
|
Considering how organization level secrets are indirectly available to all users with |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Просто зараз час такий людям віриш шо некинуть а потім думаєш чого не прийняв всі міри безпеки)Щоб інші теж могли заробляти |
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.
-
|
Totally agree, managing environment configurations on each individual repo is painful |
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.
-
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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
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.
-
|
+1 it would really simplify lots of things |
Beta Was this translation helpful? Give feedback.
-
|
+1. I was surprised that this functionality didn't exist when I went looking for it. Gitlab already has this I believe. |
Beta Was this translation helpful? Give feedback.
-
|
+1 How can this not be organization-wide? |
Beta Was this translation helpful? Give feedback.
-
|
me too +1 |
Beta Was this translation helpful? Give feedback.
-
|
We have considered not using Environments at all because they are not org-wide. It ends up being too much manual work updating them across repositories. Our alternative solution has looked to using Org-wide secrets purely, but that means we are eschewing some of the great Environment protection tools at play. Please get this sorted out sooner than later. |
Beta Was this translation helpful? Give feedback.
-
|
Since I first started watching this topic, I've had second thoughts. What we are asking for might be an anti-pattern. Multiple services (each with its own repository) should not share deployment service principals. ServiceA should deploy to ResourceGroupA (using Azure-speak here) using a service principal that can only access ResourceGroupA. Some secrets for external services should be shared. E.g. when using an external tool that scans your code for vulnerabilities. But in that case there are no separate environments to worry about. Secret rotation is something I won't need. Using OIDC and federated credentials with azure/login solves that. If you have a dozen (or a hundred) services being deployed into separate environments: You're worried about letting the same principal deploy to the prod environment as the test environment, but you are not so cocnerned about serviceA being able to play around with resources that serviceB set up for itself? That sounds a little bit odd. |
Beta Was this translation helpful? Give feedback.
-
|
What if you deploy multiple services in the same subscription/resource group hence using the same configuration, wouldn't be nice to be configure this at the organization level and be done with it?
Different business have different requirements, I don't see anything wrong with it If that's an accepted risk by the business. Point is that it would be nice to have the luxury of choosing which approach best fits your need. |
Beta Was this translation helpful? Give feedback.
-
|
You do not HAVE to conflate those things. The described anti-pattern can be implemented at this exact moment with Organization Secrets. We shouldn't not get nice things because you could implement something poorly. I think the uses-cases far outweigh a potential of abuse. GitHub already supports organization-wide configuration (secrets, runners, etc.) and this plays well with those. |
Beta Was this translation helpful? Give feedback.
-
|
me too +1. This is becoming an issue for our org as we manage many code repositories. |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
+1 this is a huge miss from GitHub in support of larger customers |
Beta Was this translation helpful? Give feedback.
-
|
Organizational Environments could be configured via RuleSets and greatly simply GH org wide admin by centralizing which environments apply to which repos (i.e. using repo properties) |
Beta Was this translation helpful? Give feedback.
-
|
This is good idea to make those org wide. But imho they should first decouple environments from deployments so each job running with |
Beta Was this translation helpful? Give feedback.
-
|
One simple way of implementing this feature would be to allow members to mark an organization secret as "private", and then manually select it for use in environments at the repository level (for each repository that needs it). It's the principle of reusability. P.S.: I know that there is already a "Repository access" option, but what I'm asking is the ability to restrict access to environments within the repository. |
Beta Was this translation helpful? Give feedback.
-
|
It seems so intuitive that this would exist that I keep forgetting it doesn't. |
Beta Was this translation helpful? Give feedback.
-
|
Org environments would be an amazing gift right now... |
Beta Was this translation helpful? Give feedback.
-
|
this would be a blessing |
Beta Was this translation helpful? Give feedback.
-
|
We need this. |
Beta Was this translation helpful? Give feedback.
-
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