declarative setup and jwt tokens retrieval

[iburrows]

Hi, I would like to use a jwt token for a role. My question is with a declarative setup where argocd is deploying argocd how do I retrieve the jwt token? I have created the following manifest

  - name: role
    description: Role used for role access
    policies:
    - p, proj:nonprod:role, applications, sync, nonprod/*, allow
    - p, proj:nonprod:role, applications, get, nonprod/*, allow
    - p, proj:nonprod:role, applications, update, nonprod/*, allow
    jwtTokens:
    - iat: 1676531730
      exp: 0
      id: 1234

In the ui or cli I could create one as well but how do I retrieve it by creating it in this way?
I have looked here: https://argo-cd.readthedocs.io/en/release-2.1/operator-manual/declarative-setup/#projects
Many thanks for the help.

[jannfis]

The token itself is not stored anywhere, but instead will be printed out to you when you create the token.

[sass1997]

I saw diffrent setups of argocd but all had one thing in common. All Human Users incl. Admins had to Login via the SSO and the only reason for a usertoken is to enable CD Pipelines or data-loader pods which had to access to capabilities of creating and deleting applications. And for this users you are mostly creating a token without an expiry date, which isn't the best but this would be another reaso that argocd handles then also the lifecycle of the secret and will be renewed as soon as it has expired.

Other Option which would be I think fast is to allow users without the login capabilties to generate a JWT Token for themselves. Authentication on this endpoint would then be basic auth

[jannfis]

I agree, that a declarative way to request tokens to be consumed by another entity would be great to have. However, I don't see that fit in any of the Argo CD components. Maybe this could evolve as a third-party controller.

Authentication on this endpoint would then be basic auth

I think it would be a bad idea to do that, for various security relevant reasons.

[bakayolo]

https://argo-cd.readthedocs.io/en/stable/user-guide/projects/

Since the JWT tokens aren't stored in Argo CD, they can only be retrieved when they are created.

What's the point of having this if we can't retrieve or provide the jwt token declaratively?

[jannfis]

What's the point of having this if we can't retrieve or provide the jwt token declaratively?

This is used similarly as in projects, for token authorization. Probably it doesn't need to be stored in the secret at all, because it's not really confidential data. When Argo CD issues a token, the token's ID as well as the time of issue and expiry are stored. When a client sends a token to Argo CD, the respective properties will be compared against this list. This way, tokens can easily be revoked by just removing the reference from the argocd-secret.

[bakayolo]

ack ok. Hopefully, we will get a way to provide jwt tokens in a declarative way in the future.
I have 15 argocd instance, I don't want to have to create tokens manually, and I have to keep the admin user just for that :)

[ebuildy]

The JWT token is generated at https://github.com/argoproj/argo-cd/blob/master/util/session/sessionmanager.go#L158

We should be able via argocd-cli to generate such JWT token for existing account token !

But as a workaround, use any tool such as https://jwt.io/ to generate a token , btw "iat" is required but not validated by argocd.

[ChichiCaleb]

This PR feat: Support service account token for argocd server authentication might solve this issue .
Though best suited for incluster token generation