Separate argocd-secret into separate secrets

[paul-civitas]

Summary

Currently the secrets for oauth are mixed together with the server.secretkey

Motivation

This is painful because secrets for oauth you might be managing through terraform, helm some kinda configuration management or something.

However the sever.secretkey can not be touched. That need to be generated by argo upon server startup.

Proposal

Separate them out into separate secrets. One that is programmatically managed by argo that we don't touch, and one that we're free to touch to manage our oauth integration.

[crenshaw-dev]

I think this might be a duplicate of https://github.com/argoproj/argo-cd/issues/6642

[paul-civitas]

Don't really want to close as a duplicate considering I think #6642 is kinda erroneously tagged as answered.

Allowing the argocd secret to reference other secrets still doesn't change the fact that we're asking for part of the secret to be set by the user, and part of the secret to be set by the API server and to not be touched under any circumstances.

[paul-civitas]

I think the problem #6642 is trying to solve is some kind of compliance, requiring them to use sealedsecrets for sso keys.

The problem I'm trying to solve is helm wiping out my server.secretkey until I do a rollout restart

[jannfis]

I think there's a misunderstanding. You can refer to arbitrary secrets from e.g. argocd-cm. You don't have to touch argocd-secret at all.

Probably the Helm chart could be modified to not modify argocd-secret, and to create unique secrets for everything else. Then, referring to these secrets from their version of the argocd-cm.

[paul-civitas]

@jannfis you don't have to touch it after initial setup.

But you still need to touch it to configure it to refer to other secrets. So if you change your SSO provider then you need to change your argocd-secret config map and oops.

[yevhen-harmonizehr]

+1. My use case: i want to set admin password for argo from my terraform. I am using sealed secret which creates "argocd-secret" with admin.password in it. But after sealed-secrets controller pod restart, it will re-generate argocd-secret without server.secretKey and break argo-cd.
When i am trying to persist "server.secretKey" in my sealed-secret controller, argo-cd will ignore this value and generate new secretKey.

k get secret argocd-secret -o yaml
apiVersion: v1
data:
  admin.password:
  admin.passwordMtime:
  server.secretKey: <sealed-value>
  server.secretkey: <generated-value>

AFAIK i can not set admin password in argocd-cm, so i can not use refs from custom secrets. Auto-generated values should be isolated from configurable values.

[HariSekhon]

+1

I've been watching and waiting for this for a while.

This is really important to manage the secrets separately to minimize the risk when editing or using other tools to manage secrets.

Especially for example if you start managing things like Azure AD SSO client secret via External Secrets such as this, it's setting a sub-key of a secret:

https://github.com/HariSekhon/Kubernetes-configs/blob/master/argocd/base/argocd-azure-ad-external-secret.yaml