-
Notifications
You must be signed in to change notification settings - Fork 5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Declarative Secrets with Apps in Any Namespace #11874
Comments
This is not a bug. However, I think it is a valid enhancement request, but we must be careful. It's a big change, with possible side-effects that we need to evaluate. I would suggest this to be designed & agreed on with a formal enhancement proposal. |
My apologies, I assumed this was expected behaviour, but I was incorrect. Rewriting the first comment to the format of an enhancement proposal :) Let me know if theres any more detail you think should be added to the proposal. |
@patrickbardo Thank you for adapting the issue's description! We discussed this topic in today's contributors meeting, and we think it is something to take forward. There are currently a few serious caveats and implications which we need to find solutions for. We do have a formal proposal process for these kind of architectural changes. When you take a look at the template, and other existing architectural proposals, you can get a glimpse of what level of detail we are looking for. I'd be willing to work together with you to come up with a proposal, I can't make any promises about my availability currently as there are some higher priority items on my plate right now. But I'm interested in bringing this feature to live, since it's a logical extension of the app-in-any-namespace feature :) |
@jannfis Sounds great! I will start the formal proposal, and link it here once I have a first draft written :) |
@jannfis I have started a proposal PR. Still a work in progress, but it can be found here. I also hope you don't mind I have piggy backed a lot from your previous proposal :D |
@patrickbardo Awesome! I took a quick glance and it looks good, I will take a closer look during the week when I have some spare time. I don't know what you mean by "piggy backing" - It's the beauty of Open Source that we all can get inspired to build new & better things upon work that exists somewhere, isn't it? :) |
Sorry for the late update; I still couldn't manage to come around for a proper review of your draft. I have the review on my task list for this week, though. |
No rush, I haven't had a good chunk of time to sit and finish the other half. I will hopefully find some time in the coming weeks :) |
Summary
Apps in any namespace was a wonderful change for ArgoCD that allows ArgoCD tenants manage their own resources, and following those changes, I believe that applying a
x-in-any-namespace
pattern for declarative repository connections would be a helpful enhancement.Motivation
Instead of an Admin team having to manage repository connection secrets in the ArgoCD namespace, this would be used to allow teams to store repository connections as secrets in their own namespaces.
Proposal
How do you think this should be implemented?
All secrets in
--application-namespaces
with labelargocd.argoproj.io/secret-type: repository
should be included in a get repositories. The schema of a repository needs to include an AppProject it belongs to so that the proper RBAC can be applied to restrict access, while defaulting to default AppProject to maintain backwards compatibility.The text was updated successfully, but these errors were encountered: