Argo-cd: jwtTokens are reset when applying AppProjects

Created on 14 Nov 2019  路  5Comments  路  Source: argoproj/argo-cd

Checklist:

  • [X] I've searched in the docs and FAQ for my answer: http://bit.ly/argocd-faq.
  • [X] I've included steps to reproduce the bug.
  • [X] I've pasted the output of argocd version.

Describe the bug

When kubectl apply-ing an AppProject, any jwtTokens created are cleared.

To Reproduce

  1. Create an AppProject with no tokens via kubectl apply
  2. Create a project token (via UI or CLI)
  3. kubectl apply the same AppProject
  4. Tokens are all revoked

Expected behavior

The tokens shouldn't be revoked. The use case for this is we have a mostly declarative setup, that we would like to just update the manifests and re-apply on updates.

Native kubernetes resources will normally only update what was changed since the last kubectl apply but this unfortunately seems to be not possible with CRDS. Maybe jwtTokens can be stored separately from the AppProject to work around it similar to how the admin password is in a secret?

A workaround is to update the AppProject with the new jwtTokens after creating them. This prevents them from being revoked on kubectl apply but is less than ideal for a declarative configuration as applying it in a different cluster doesn't actually make sense since we can't get the actual JWT token.

Version

argocd: v1.3.0+9f8608c
  BuildDate: 2019-11-13T01:49:01Z
  GitCommit: 9f8608c9fcb2a1d8dcc06eeadd57e5c0334c5800
  GitTreeState: clean
  GoVersion: go1.12.6
  Compiler: gc
  Platform: linux/amd64
argocd-server: v1.3.0+9f8608c
  BuildDate: 2019-11-13T01:51:00Z
  GitCommit: 9f8608c9fcb2a1d8dcc06eeadd57e5c0334c5800
  GitTreeState: clean
  GoVersion: go1.12.6
  Compiler: gc
  Platform: linux/amd64
  Ksonnet Version: v0.13.1
  Kustomize Version: Version: {Version:kustomize/v3.2.1 GitCommit:d89b448c745937f0cf1936162f26a5aac688f840 BuildDate:2019-09-27T00:10:52Z GoOs:linux GoArch:amd64}
  Helm Version: v2.15.2
  Kubectl Version: v1.14.0
bug multi-tenancy workaround

Most helpful comment

I think this is a CRD design bug. Currently tokens are stored in AppProject spec in roles list. Since AppProject is a CRD we cannot use strategic merge patch and kubectl apply just replaces roles list instead of merging changes.

We should deprecate spec.roles.jwtTokens field and move it to AppProject status.jwtTokens. The good news is that this can be done in a backward-compatible way.

All 5 comments

We are facing the same issue.

We are also facing this issue. We need the jwtToken for calling argocd sync and get the status via REST-API in our CI/CD-Pipeline like in https://argoproj.github.io/argo-cd/user-guide/ci_automation/#synchronize-the-app-optional.
So for me this is unfortunately currently a showstopper for integrating argocd in our CI-pipeline. Is there any other way doing this without jwtToken as a workaround?

I think this is a CRD design bug. Currently tokens are stored in AppProject spec in roles list. Since AppProject is a CRD we cannot use strategic merge patch and kubectl apply just replaces roles list instead of merging changes.

We should deprecate spec.roles.jwtTokens field and move it to AppProject status.jwtTokens. The good news is that this can be done in a backward-compatible way.

workaround (that we use):

  • create an jwtToken
  • add the id of the token to: spec.roles.jwtTokens
roles:
- name
   jwtTokens:
   - iat: ID

I think this might be fixable now based on a commit I saw in rollouts to add merge patch keys. My assumption here is that live to doesn鈥檛 know how to merge the array elements so it just replaces the whole thing. https://github.com/argoproj/argo-rollouts/pull/386

Looked into it more, and I don't necessarily see why rollout did that work but it would not solve this issue with overwrites during argo sync.

Was this page helpful?
0 / 5 - 0 ratings