-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
Restrict the default
project
#11058
Comments
Maybe it need add the possibility to modify default project for example by Helm values? and set something like this:
|
@galibozek is that something that should be done on the argo-helm repo? |
@crenshaw-dev probably yes, but I don't see adding a default project there, and helm doesn't want to modify resources other than my own |
Hi @galibozek did you happen to find a way to handle this other than (maybe) modifying the project resource post install? |
I was surprised to discover this is the out-of-the-box configuration when reading through the Argo CD End User Threat Model document. It would be useful to get this secured by default (pardon the pun) when Argo CD is installed rather than being a security hole that needs to be manually fixed post installation. |
I'm really happy that people read the threat model. 😄 Yeah, we gotta do something about this. It's tough, because if we lock down the default project in the upstream manifests, we'll break a lot of existing setups where people used the default project for everything. If we delete the default project, it'll get pruned and potentially also break things. I've kinda been waiting for 3.0, since no solution seems clean/easy. But maybe I'm missing a better option. |
Nonexpert here, random thought. Would it be possible to add a cmdline arg to the argocd binary that says This keeps a simple default behavior, but lets everyone customize it without manual intervention after, which is the issue I'm facing when creating a good amount of clusters. If this is done then it could all be tiedl together from the helm side, as the argocd-helm could add a default project block in the argocd helm values like the one one can find in the argocd-apps helm values (see below). ### argocd-helm values.yaml
# ...
defautProject:
# enabled: true # false
# namespace: argocd
# additionalLabels: {}
# additionalAnnotations: {}
# finalizers:
# - resources-finalizer.argocd.argoproj.io
# description: Example Project
# sourceRepos:
# - '*'
# destinations:
# - namespace: guestbook
# server: https://kubernetes.default.svc
# clusterResourceWhitelist: []
# clusterResourceBlacklist: []
# namespaceResourceBlacklist:
# - group: ''
# kind: ResourceQuota
# - group: ''
# kind: LimitRange
# - group: ''
# kind: NetworkPolicy
# orphanedResources: {}
# roles: []
# namespaceResourceWhitelist:
# - group: 'apps'
# kind: Deployment
# - group: 'apps'
# kind: StatefulSet
# orphanedResources: {}
# roles: []
# syncWindows:
# - kind: allow
# schedule: '10 1 * * *'
# duration: 1h
# applications:
# - '*-prod'
# manualSync: true
# signatureKeys:
# - keyID: ABCDEF1234567890
# sourceNamespaces:
# - argocd |
How about this being controlled by a feature flag? Current situation is that the security policy requires custom workarounds to achieve this, which leads to very hackish solutions. |
Thanks @12345ieee for the insightful comment! Your suggestion inspired a workaround that addresses the core issue without waiting for the v3.0 release. |
Hm. I think it would not so much be a breaking change if we just have the default project created with locked down permissions. It won't affect existing installations, because the default project is not touched by Argo CD when it already exists. Having the default project locked down would neither impact upgrade nor downgrade paths. The only situation where the behavior would change is, if someone deletes the default project and it gets recreated by Argo CD. But this is an edge case imho. Users can already modify the default project to be locked down by themselves, and when they (accidentally or deliberately) delete the default project it will be recreated with even wider permissions than they configured the project to have. I'm all for locking down the default project, and imho, we can do it before a v3.0 would allow breaking changes. I don't think it's a breaking change. |
Oh sure, I thought the project was created via manifests, but I guess it's created programmatically. I agree, let's lock it down before 3.0. |
@jannfis @crenshaw-dev does this mean there is agreement to simply modify the Lines 238 to 257 in fd3462e
|
Just chiming in to say that I absolutely love the cmdline arg of |
I have a dumb question: What's the currently recommended workaround? Is it set the values to |
use-as-default-project would work. |
Summary
For convenience, the
default
AppProject which ships with Argo CD is completely unrestricted.Motivation
It's a bit of a foot-gun.
Proposal
We should add some restrictions (for example, only allowing deploying
Deployment
andService
resources). This would allow, for example, theguestbook
example to run. But it would prevent folks from unwisely leaving the project completely unrestricted.The text was updated successfully, but these errors were encountered: