OIDC config should reference dedicated secret instead of key in argocd-secret

[stewartshea]

Summary

The current oidc client secret allows you to reference a key inside of argocd-secret for this key, but this needs to be added after the argocd instance is created (for instance, with the operator). When modifying the instance, the manual step needs to be performed again, which isn't scalable for bootstrapping clusters.

The suggestion here is simply to reference a dedicated secret that contains this key, which could be prepopulated (or pulled in from an external source).

Motivation

When bootstrapping multiple clusters into ArgoCD to manage their configuration, this step adds manual overhead and the risk of human error. It would be better if humans didn't need to manually insert a key that was base64 encoded from a local terminal.

• argocd instance

  oidcConfig: |
    name: SSO
    clientID: argocd
    clientSecret: $oidc.sso.clientSecret

• argocd-secret

data:
  admin.password: [redacted]
  admin.passwordMtime:  [redacted]
  oidc.sso.clientSecret: [manually added]

Proposal

Instead of the argocd-cm (or operator spec) referencing a key in the dedicated argocd-secret (which gets manipulated by the operator), allow it to reference a separate secret:

• argocd instance

  oidcConfig: |
    name: SSO
    clientID: argocd
    clientSecretRef: oidc-secret

• oidc-secret

data:
  clientSecret: [someValue]

[mcwienczek]

I would add that the same applies to TLS secret. It should be in a separate secret as the argocd-secret is of type Opaque. Plus when using let's encrypt it relies on the fact that cert-manager will happily add the certificate to existing secret instead of overriding the value.

[stewartshea]

Totally agreed!

…

On Fri, Aug 28, 2020, 10:25 AM Michal Cwienczek ***@***.***> wrote: I would add that the same applies to TLS secret. It should be in a separate secret as the argocd-secret is of type Opaque. Plus when using let's encrypt it relies on the fact that cert-manager will happily add the certificate to existing secret instead of overriding the value. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4188 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AELXHODHTGA7EUSE3WZWAXDSC645DANCNFSM4QNNULJQ> .

[HumairAK]

It would be also nice if we could specify the name of the key in the secret so it's not required to be named clientSecret, this would also solve #4052 and not require hardcoding of the serviceaccount token

[alexmt]

I believe this is implemented by #4342 . Now secret value can be referenced from any secret labeled with app.kubernetes.io/part-of: argocd label.

Let me know if I'm missing something please

[lknite]

This still work for you guys? I'm trying this and it doesn't appear to be finding the secret:

$ cat base/templates/argocd-oidc-secret.yaml 
apiVersion: v1
kind: Secret
metadata:
  name: argocd-oidc-secret
  labels:
    app.kubernetes.io/part-of: argocd
type: Opaque
data:
  oidc.azure.clientSecret: base64encodesecretgoeshere

I can put the same base64encoded value in argocd-secret and the value is found.

[lknite]

Answering my own question, yes it works. Thought it would search any secret but what this does it allows you "reference" another secret. I used the method from #4342 mentioned above. Here's an example for someone who sees this later, this is a configuration using the argocd helm chart:

    config:
      url: https://argocd.prod.k.home.net
      oidc.config: |
        name: AzureAD
        issuer: https://login.microsoftonline.com/1e888cbd-d0a7-4ee5-94d0-f6e973140727/v2.0
        clientID: 7a907dbd-41a0-4a40-b2d1-597f1e925bfd
        clientSecret: $argocd-oidc:oidc.azuread.clientSecret
        requestedIDTokenClaims:
          groups:
            essential: true
        requestedScopes:
        - openid
        - profile
        - email
        - offline_access

Above I'm using a secret 'argocd-oidc' which contains the data 'oidc.azuread.clientSecret' which is the client secret.

[presidenten]

@lknite You the mvp man. Thanks for sharing!

Edit: Btw .. sorry for commenting on long closed issue. Happy feelings got the better of me...

[crenshaw-dev]

Issues are never closed to happiness. :-)

[vini-gorillas]

I m unable to use this still, i do have the label added and the secret is still not found. is there something else that i m missing while referncig the secret?

[davidmontoyago]

hi @vini-gorillas, we were able to reference any property from any k8s Secret after upgrading to 2.8.0. specifically, after getting fix #13475. our config looks as follows:

1. k8s Secret has label app.kubernetes.io/part-of: argocd
2. OIDC config looks as follows:

---
apiVersion: v1
data:
  oidc.config: |
    issuer: $my-k8s-secret-with-oidc-config:my_issuer
    clientSecret: $my-k8s-secret-with-oidc-config:my_client_secret
    allowedAudiences:
      - my-audience.example.org
  url: https://myargocd.example.org
  users.anonymous.enabled: "false"
kind: ConfigMap
metadata:
  labels:
    app.kubernetes.io/name: argocd-cm
    app.kubernetes.io/part-of: argocd
    name: argocd-cm
  name: argocd-cm
  namespace: argocd

Additionally, make sure your ArgoCD server has enough RBAC permissions to get/watch Secrets, if not already.

[Shreyas2792]

@davidmontoyago Do you know if we can refer to secret in the allowedAudiences field?

This is my use case:

I need to add clientID in the list explicitly as I have added another aud as well. Do let me know if you have any thoughts.


apiVersion: v1
data:
oidc.config: |
name: Azure
issuer: https://login.microsoftonline.com/$(TENANT_ID)/v2.0
clientID: $app-registration-secret:password
clientSecret: $app-registration-secret:password
allowedAudiences:
- $app-registration-secret:password
- avsbsdndmdmdllll