Sprig support in templates

[n9]

Which component:
Controller.

Is your feature request related to a problem? Please describe.
Derive password hash (bcrypt) from password (e.g. for htpasswd).

Describe the solution you'd like
Add sprig functions to templates.

Describe alternatives you've considered
I do not know any alternatives in sealed-secrets. An alternative could be to use external-secrets (https://github.com/external-secrets/external-secrets/blob/d605a5b450abb8072090ef115396f8b618aec2ec/pkg/template/v2/template.go#L138).

Additional context
No.

[josvazg]

Hi @n9!
Thanks a lot for your issue. We would like to understand better what use cases this sprig support will cover.

Sealed Secrets was initially conceived to safely store passwords or keys as part of your regular gitops flow.

The repo for a project setup or its deployment setup refers to the secrets to be used to get access to some resource, in a way that such secret is only legible by the intended Kubernetes cluster to enjoy access to the resource the secret protects.

Key derivation and hashing functions are usually intended on the other side of the access equation: Verification.

You store a derivation of the actual secret that the user or agent must posses to get access. That way, if your authentication database is leaked, the actual secrets are not leaked with it. Attackers will still need to brute force the derivation algorithm to get possible password candidates that produce the derivation result hash.

So again. Given that Sealed Secrets is designed to store and distribute keys to get access rather than verify access.

What would be the use cases of key derivation on this context?

[n9]

@josvazg For instance, harbor is composed from multiple components. The UC is following:

• core component needs a user name and password for a registry (another component)
• registry needs to the same in the htpasswd format (the user name + hash of the password)

You may want to have one place where the password is stored and just derive the htpasswd from it. And not to have two places where the password (e.g. in SS) and the hash of the same password (e.g. in CM) is stored.

Disclaimer: I have switched to the external secrets for this case, I do not need this feature.