Skip to content
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

Missing rights on ApplicationSet resource for application controller service account #2974

Open
OpenGuidou opened this issue Oct 11, 2024 · 5 comments · May be fixed by #2975
Open

Missing rights on ApplicationSet resource for application controller service account #2974

OpenGuidou opened this issue Oct 11, 2024 · 5 comments · May be fixed by #2975
Labels
argo-cd bug Something isn't working

Comments

@OpenGuidou
Copy link

Describe the bug

Hello,

When performing an argocd installation using the chart, namespace-scoped (createClusterRoles: false), we can't sync ApplicationSet in the cluster as the role defined for the application controller is missing this resource.
An error is displayed as the application controller can't create applicationsets

Related helm chart

argo-cd

Helm chart version

7.6.8

To Reproduce

  1. Install the chart argo-cd with value createClusterRoles: false
  2. Create an app referencing a repo containing an applicationset
  3. See the error as in the screenshot below

Expected behavior

The applicationset should be correctly created.

Screenshots

image

Additional context

No response

@crenshaw-dev
Copy link
Member

I'm not sure that this is actually unexpected behavior. My understanding of namespaced mode is that Argo CD comes with roles for each component to manage their own resources and do nothing else. There's no GitOps management out of the box. After installing the namespaced-mode Argo CD, you're expected to add cluster configurations for anywhere you want to deploy to.

I'm inferring all this from looking at the manifests, I could be missing something.

@OpenGuidou
Copy link
Author

One of the usual use cases it to have ArgoCD deployed on a control plane cluster, managing applicative remote clusters.
In my case, we have several namespaced instances, each managing their set of clusters.

In such case, we expect to deploy in-cluster only Applications and ApplicationSets. Other ressources are deployed on the target remote clusters.
I would find it difficult to explain that we can use applications and not applicationsets.

I think this use case is common enough to not force all users to redefine their roles on top to allow it.

@crenshaw-dev
Copy link
Member

Fair point, especially when it's possible to create (certain) AppSets via the API.

If the goal is to allow people to fully manage Argo CD's own config out of the box, we'd want to add write access for these as well:

grep -E "^kind: " manifests/namespace-install.yaml | uniq | sort | awk '{print $2}'
ConfigMap
Deployment
NetworkPolicy
Role
RoleBinding
Secret
Service
ServiceAccount
StatefulSet

If the goal is feature parity between API-managed resources and GitOps managed resources, I think the list is this:

Applications
ApplicationSets
AppProjects
Secrets

I've added a topic to the next contributors meeting. We'll pick a strategy and then make the changes. Probably need some docs around this.

@OpenGuidou
Copy link
Author

Should we list secrets in the gitops option ?
Are there still people pushing secrets in git ? 😁
Could we advise ExternalSecret or no secrets at all if we go for a solution without external dependency?

@crenshaw-dev
Copy link
Member

Agreed on Secrets.

Contributors call says lets add Applications access.

We probably need some upstream docs on the intent of namespaced mode. i.e. you can GitOps-managed Argo CRDs in the argocd namespace out of the box, but for anything else you're going to have to configure your own access.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
argo-cd bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants