Missing Resources on App installation with Helm

[thomas-2020]

Hello team,
I want to install (e.g.) ECK-Operator with ArgoCD and the Helm Chart. After ArgoCD has the application synchronized, the app is in green state. But I miss a lot of K8S resources (ServiceAccount, StatefuleSet, ...). ArgoCD doesn't display the missing resources. I find only warings in "Application conditions" ...

ExcludedResourceWarning Resource /ServiceAccount elastic-operator is excluded in the settings

I never configure ArgoCD to exclude these resources. I think it is a policy, role or permission issue.

Have you any idea how to drill down into the root cause?

[christianalberto]

Hi @thomas-2020, glad to meet you.

That ExcludedResourceWarning means ArgoCD is intentionally skipping those resources (ServiceAccount, StatefulSet, etc.) because of an exclusion rule defined higher up in your setup. Even if you didn't configure any exclusions inside your Application manifest, ArgoCD inherits these restrictions from global or project-level settings.

In my experience with ArgoCD, this almost always boils down to one of three places. Here is how I'd drill down into it step-by-step:

1. Global ConfigMap (argocd-cm)
   ArgoCD allows global resource exclusions that apply across the entire cluster. Some pre-packaged distributions or managed GitOps platforms enable these by default to reduce controller memory consumption or restrict sensitive system resources.

Check your global ConfigMap:

kubectl get cm argocd-cm -n argocd -o yaml | grep -A 15 "resource.exclusions"

If ServiceAccount or StatefulSet show up under the excluded kinds, that's your root cause.

2. AppProject restrictions
   Every application belongs to an AppProject (which defaults to default if not specified). Projects enforce granular RBAC and resource filtering through whitelists and blacklists at both cluster and namespace scopes.

Inspect the project attached to your app:

kubectl get appproject <project-name> -n argocd -o yaml | grep -iE 'blacklist|whitelist' -A 10

Look for entries under clusterResourceBlacklist, namespaceResourceBlacklist, or overly restrictive clusterResourceWhitelist rules blocking these resource types.

3. Operator reconciliation (ArgoCD CR)
   If ArgoCD was installed via the ArgoCD Operator or OpenShift GitOps, editing argocd-cm directly won't work—the operator's reconciliation loop will constantly overwrite your edits and reinstate the default exclusions.

Check the operator's Custom Resource:

kubectl get argocd -n argocd -o yaml | grep -i -A 10 "resourceExclusions"

If exclusions are defined here, you'll need to patch the ArgoCD Custom Resource itself rather than modifying the ConfigMap.

Once you run those commands, you should be able to pinpoint exactly which layer is filtering them out.

Let me know if this helps resolve the issue! If not, feel free to share any other errors, log outputs, or details you encounter so we can dig deeper and get it sorted out.

[thomas-2020]

Hello @christianalberto ,
option 1 and 2 can we exclude because we use one Appproject to deploy from a centralized ArgoCD all application in remote K8S or OpenShift clusters. The deployment to K8S is working for all resources.
The command in option 3 is not working. Also, I didn't follow option 3 because we try to work without operator.

Regarding OpenShift, we create a ServiceAccount and we configure a Cluster in ArgoCD for using this service account to deploy remotely. Can we debug (or log) how ArgoCD is working with the remote cluster connection and which resources are generated from the Helm Chart?

[christianalberto]

Hi @thomas-2020,

Since options 1 and 2 are ruled out and this involves a remote OpenShift cluster, the issue is almost certainly caused by API Discovery/RBAC limitations on the remote ServiceAccount or Helm values.yaml conditional rendering.

Here is how to isolate and fix it step-by-step:

1. Check generated Helm manifests
Verify if Helm is actually rendering those missing resources before ArgoCD attempts to deploy them:

argocd app manifests <application-name>

If missing from the output: The issue lies within your Helm values.yaml (e.g., flags like createServiceAccount: false or disabled sub-components).

If present in the output: The issue is strictly related to remote cluster API permissions (step 2).

2. Verify Remote OpenShift ServiceAccount RBAC

OpenShift enforces strict default security constraints and RBAC. If the remote ServiceAccount lacks permissions to discover or list those specific API groups (e.g., apps/v1 for StatefulSet or core ServiceAccount), ArgoCD's application-controller cannot track their state and flags them with ExcludedResourceWarning.

Test the permissions directly against the remote OpenShift cluster:

kubectl auth can-i create serviceaccounts -n <target-namespace> --as=system:serviceaccount:<remote-namespace>:<remote-sa-name>
kubectl auth can-i create statefulsets -n <target-namespace> --as=system:serviceaccount:<remote-namespace>:<remote-sa-name>

If any command returns no, you need to grant the remote ServiceAccount an appropriate ClusterRoleBinding (or cluster-admin for full remote management).

3. Enable Controller Debug Logs
To trace how ArgoCD communicates with the remote OpenShift API server and handles API discovery, check the application-controller logs:

Bash
kubectl logs -n argocd -l app.kubernetes.io/name=argocd-application-controller -f | grep -iE "eck|elastic|excluded"

Let me know what argocd app manifests outputs!

[thomas-2020]

Hi @christianalberto ,
I want to give a short update. All kubectl auth can-i create ... commands are returned yes. The permissions of SA seams to be OK. I hope that I can get information for point 1. and 3. next week.
Many thanks meanwhile for your support
Thomas

[Icaro0310]

That warning means Argo CD's resource filters dropped those objects — it discovered them, but isn't allowed to manage them, so they aren't shown. Two places to check:

1. AppProject whitelist/blacklist. If the app isn't in the default project, your project must permit the resources:

spec:
  namespaceResourceWhitelist:
    - group: '*'
      kind: '*'
  clusterResourceWhitelist:
    - group: '*'
      kind: '*'
  destinations:
    - namespace: 'elastic-system'
      server: https://kubernetes.default.svc

2. Global exclusions in argocd-cm:

kubectl get cm argocd-cm -n argocd -o jsonpath='{.data.resource\.exclusions}'
kubectl get cm argocd-cm -n argocd -o jsonpath='{.data.resource\.inclusions}'

If anything there matches ServiceAccounts/StatefulSets in elastic-system, narrow or remove the exclusion. Once the filters permit the resources, a hard refresh (argocd app get <app> --hard-refresh) will make them appear.

—
Check out my Repositories: github.com/Icaro0310 · Website: icaro0310.github.io

[keemgdeok]

That exact message points back to Argo CD's resource filter: the controller code drops a rendered target object when IsExcludedResource returns true. For the ServiceAccount named in the warning, Helm has already rendered it; create=yes doesn't explain why the filter rejects it.

Using the same AppProject doesn't rule out global filters, because inclusion/exclusion rules can match cluster URLs. Check resource.inclusions and resource.exclusions in the central Argo CD's argocd-cm against the OpenShift cluster's registered server URL. Check inclusions too: a kind can be excluded without an exclusion rule explicitly naming it. The API group is "" for ServiceAccount and apps for StatefulSet. Could you share those two filter entries and your Argo CD version?

[michaelkoettenstorfer]

We solved it with this patch in our ArgoCD kustomization.yaml

      kind: ConfigMap
      name: argocd-cm
    patch: |-
      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: argocd-cm
      data:
        url: https://example.com
        oidc.tls.insecure.skip.verify: "true"
        oidc.config: |
          name: Keycloak
          issuer: https://example.com/auth/realms/ExampleRealm
          clientID: client-argocd
          clientSecret: $oidc.keycloak.clientSecret
          refreshTokenThreshold: 2m
          requestedScopes: ["openid", "profile", "email", "groups-simple"]
        resource.inclusions: |
          - apiGroups:
              - apps
            kinds:
              - StatefulSet
            clusters:
              - https://cluster:6443
          - apiGroups:
              - ""
            kinds:
              - Secret
              - ConfigMap
              - ServiceAccount
            clusters:
              - https://cluster:6443

[thomas-2020]

How Michael mentioned we solved the issue with an explicit definition of resource types in the inclusions. Thank you very much for your inputs.