argo-cd
argo-cd copied to clipboard
argoproj
Restrict the `default` project
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 and Service resources). This would allow, for example, the guestbook example to run. But it would prevent folks from unwisely leaving the project completely unrestricted.
Maybe it need add the possibility to modify default project for example by Helm values? and set something like this:
spec:
clusterResourceWhitelist: []
destinations: []
sourceRepos: []
@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 --dont-create-a-default-project-but-instead-use-this-project-resource-thats-already-deployed-as-default=<NAMESPACE>/<MY-NICE-PROJECT-CALLED-DEFEAULT>?
Or an envvar, same thing.
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). If that block is enabled, helm deploys the default project the way the user asks and adds the above arg to the argocd server Pod.
### 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.
https://github.com/argoproj/argo-cd/issues/15518
I've kinda been waiting for 3.0, since no solution seems clean/easy. But maybe I'm missing a better option.
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.
the default project is not touched by Argo CD when it already exists
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 AppProjectSpec below to lock down the default project? It seems like if it was that easy it'd already be done, but I'm happy to submit a pull if that is the case.
https://github.com/argoproj/argo-cd/blob/fd3462e9c0eeb6e6c577a7775e93fc449bb4546a/server/server.go#L238-L257
Would it be possible to add a cmdline arg to the argocd binary that says
--dont-create-a-default-project-but-instead-use-this-project-resource-thats-already-deployed-as-default=<NAMESPACE>/<MY-NICE-PROJECT-CALLED-DEFEAULT>? Or an envvar, same thing.
Just chiming in to say that I absolutely love the cmdline arg of --dont-create-a-default-project-but-instead-use-this-project-resource-thats-already-deployed-as-default. It might be a little wordy, but there's no question that it's very communicative!
I have a dumb question: What's the currently recommended workaround? Is it set the values to [] like in this comment https://github.com/argoproj/argo-cd/issues/11058#issuecomment-1301118045 ?
