Add support for retrieving ClientId, ClientSecret, and SSO secret from env var as opposed to creating a kube Secret

[ebourgeois]

Summary

Problem statement

To use argo-workflow SSO, we are currently required to use Kubernetes Secrets; in some organizations, this kind is disallowed and must use external secret storage, e.g. HashiCorp Vault.

Enhancement

In the SSO auth code and config, to solve the above problem statement, we believe the following would be required:

• Allow setting clientId from environment variable
• Allow setting clientSecret from environment variable
• Allow setting of PKCS1 SSO secret from environment variable

Use Cases

This new enhancement would allow users to either:

1. Provide your own PKCS1 key, or
2. Your organization has regulatory requirements that prohibit the use of kind: Secret and require the use of external secret retrieval, e.g. HashiCorp Vault or Azure Key Vault.

---

Message from the maintainers:

Love this enhancement proposal? Give it a 👍. We prioritise the proposals with the most 👍.

[agilgur5]

Does your organization allow you to use External Secrets or Secrets Store CSI Driver? The Vault Secrets Operator works similarly, if you are using Vault specifically.

Most companies don't use Secrets directly, but through such an integration which creates and syncs Secrets from an external provider (as Secrets are still the only native k8s resource).

[ebourgeois]

Hi @agilgur5 ,

Thank you for your response, unfortunately, these are not an option, furthermore, these don't solve the fact that sso code creates kube secrets directly with kube API.

[eminty69]

Hi @agilgur5 ,

You've just put your finger on why we wanted to make this contribution! We assumed that there would be this integration but then realised that the sso code was hard coded to create and store the secrets.

[agilgur5]

these don't solve the fact that sso code creates kube secrets directly with kube API.

You mean the randomly generated PKCS1 Secret, correct? That secret isn't user-facing, so I'm surprised that matters.

I'm guessing you want to remove more Secrets RBAC? You'd still get for ServiceAccount's Secrets (e.g. for SSO RBAC)

We assumed that there would be this integration but then realised that the sso code was hard coded to create and store the secrets.

I'd be very surprised if an organization had a requirement that 3rd party apps couldn't use Secrets independently; they are the only way to store credentials natively in k8s. A 3rd party app generally wouldn't use Vault CRDs etc.

Dex supports passing client credentials as environment variables, so I think this is a valid request either way, but I'm a bit confused by the requirements

[ebourgeois]

Hi @agilgur5,

Yes, that is correct, my PR addresses the randomly generated PKCS1 Secret.

This is not really a matter of not using kube Secrets, it's regulatory need to have an approved secret store and kube Secrets is not. We need to manage the lifecycle of said secrets.

I hope this clears up our requirements.

[agilgur5]

This is not really a matter of not using kube Secrets, it's regulatory need to have an approved secret store and kube Secrets is not. We need to manage the lifecycle of said secrets.

As I mentioned above, this change will not suffice for all Secrets, such as those used by ServiceAccounts. They are the only native secret storage mechanism in k8s, so removing them entirely from every app would be challenging, to say the least.

Syncing your k8s Secrets with an actual secret store (like Vault et al) is how you can achieve that requirement. Removing k8s Secrets entirely is not necessary. Like I mentioned before, most companies don't use k8s Secrets directly. k8s Secrets are generally not the "source-of-truth" for a variety of reasons.