-
Epic
-
Resolution: Done
-
Normal
-
1.19.0
-
Image Updater: Prevent users from referencing Applications in any namespace
-
False
-
-
False
-
In Progress
-
0% To Do, 0% In Progress, 100% Done
-
-
-
https://github.com/argoproj-labs/argocd-image-updater/issues/1381
We are running ArgoCD in a multi-tenant setup with the App-of-Apps pattern allowing users to create their own ArgoCD Application resources in their own namespaces so they can take full ownership. We limit users access by setting up ArgoCD AppProjects so they can only create Applications which deploy in the user's namespaces.
The problem with our setup and argocd-image-updater is that users can reference any application in any namespace via the .spec.namespace field as far as I am concerned. This means that a user could set up an ImageUpdater resource pointing to an Application which is not in their allowed namespaces and trigger an image update of one of the resources managed by said ArgoCD Application resource. Of course, this probably requires harmful intentions and a little bit of insider knowledge about the resources in other namespaces, but nevertheless this could be a risk.
Describe the solution you'd like
Enable admins to set a flag in the argocd-image-updater-controller to only allow ImageUpdate resources which point to Applications which live in the same namespace as the ImageUpdater resource itself.
If I am correct, this should be enough to close this issue.
I already tried to set up an Application in a user's namespace which is not allowed to reconcile based on the ArgoCD RBAC. When I set up an ImageUpdater resource in the same namespace then the Image Updater should not consider that application as it has no managed resources resulting in Image 'nginx/nginx-unprivileged' seems not to be live in this application, skipping. So this means to me that a simple check if .metadata.namespace and .spec.namespace are in sync should be sufficient.
Describe alternatives you've considered
- The platform team could manage the ImageUpdater resources. But we don't like that solution as we don't want to be the bottleneck for all the devs on our platform. This defeats the purpose of enabling users.
- Having a dedicated image-updater running in every users namespace with limited access (I did not test that). I would like to prevent that.
- Running a policy engine which only allows to reference Applications in the same namespace as the ImageUpdater resource (again, I did not test that). Introducing a policy engine for that use case seems to be a little far fetched.
Version
1.0.1
SDLC Questionnaire
| S.No | Questions | Yes/No | Sample JIRA Epic |
|---|---|---|---|
| 1 | Does this Epic address a change in way the product is being used? (eg: Adding support for OpenShift GitOps to be used in ROSA cluster with HCP) | No | GITOPS-5223 |
| 2 | Does this Epic require a change in the application's runtime - Upgrade of operator-sdk, OLM, client-go, go-toolset ? | No | GITOPS-8104 |
| 3 | Does this Epic primarily dealing with introducing a new security related feature (eg: Introduce SSO support) | No | GITOPS-437, GITOPS-547 |
| 4 | Does this Epic primarily dealing with the modification of an existing security feature ? (Eg: Supporting of External Authentication for SSO) | No | GITOPS-8017 |
| 5 | Does this Epic require changes to any cryptographic library ( Eg: FIPS support for OpenShift GitOps) | No | |
| 6 | Does this Epic require any new or change in the existing cryptographic algorithms used in the product (Eg: Using GPG verification for manifests, Upgrading from SHA256 to SHA512) | No | |
| 7 | Does this Epic require any change in existing authentication mechanisms (eg: Argo CD Auth integration with OpenShift, Kerberos to OAuth) | No | GITOPS-437 GITOPS-547 |
| 8 | Does this Epic require any change in authorisation mechanism (Eg: Using RBAC and service accounts impersonation for App Sync) | No | |
| 9 | Does this Epic require a change in the Communication protocol ( Eg: Using TLS to encrypt data traffic to/from Redis cache) | No | GITOPS-720 |
| 10 | Does this Epic require a change in how External Data is parsed and validated ? ( Eg: Change from JSON to Protobuf) | No | |
| 11 | Does this Epic require a change in core libraries or runtime (Eg: go compiler upgrade, Changing Operator SDK, controller-runtime, client-go versions) | No | |
| 12 | Does this Epic require exposing any internal service to internet (Eg: Allow exposing Argo CD Agent principal via Route, using ArgoCD CR) | No | |
| 13 | Does this Epic require a change in any existing gRPC service APIs | No | |
| 14 | Does this Epic require a change in any new external service (Eg: Support for OCI container registry for storing manifests) | No | |
| 15 | Does this Epic require a change in the tenancy model ? (Eg: Supporting Apps/Appsets in Any namespace, cluster and repo credentials in any namespace) | No | |
| 16 | Does this Epic require any addition/modification of RBAC resources (Service Account, Role, RoleBinding, ClusterRole, ClusterRoleBinding) ? | No | |
| 17 | Does this Epic require a feature that needs to be enabled only for cluster scoped Argo CD instances ? | No |
