Introduce support for a new password parameter type with masking

[zensolution]

Summary

When submitting a workflow template with parameters, all parameter values are currently logged as plain text, which can pose a security issue, especially for sensitive information like passwords. To address this concern, it would be beneficial to introduce a new password parameter type. With this enhancement, when users enter passwords, they will be masked to ensure confidentiality, and the masked value will be logged as '***' in the logs or labels.

[terrytangyuan]

Seems like #5506 is a generalized version for this.

[zensolution]

Seems like #5506 is a generalized version for this.

Thank you for bringing this up. However, the current solution is not a perfect fit for our needs. As we use Argo Workflow as an internal control application, certain jobs requires users to input passwords through the Argo UI. Due to the plaintext nature of the passwords, we are exploring alternative methods to implement these jobs.

[boehb-efs]

We have the same(ish) problem: we execute a workflowtemplate via rest-api from an external service, that passes certain parameters, that should better be kept secret. Writing these parameters into a secret and referencing them from the workflow would not really fix the problem (culprit could write his own workflow and reference the same secret and read it).

[kangyanzhou]

We have a different use case: we would like to develop a workflow to allow users to input some password to create/update secrets stored in HCVault. This is not possible to accomplish via k8s secret.

[agilgur5]

We have a different use case: we would like to develop a workflow to allow users to input some password to create/update secrets stored in HCVault. This is not possible to accomplish via k8s secret.

I feel like there's a very narrow use-case where this makes sense, which is indeed creating/updating secrets or verifying passwords (e.g. check a password against a bcrypt hash).

The narrowest part is that you would usually update a tool's secrets via its own UI/CLI etc, but it can certainly make sense to have centralized WorkflowTemplates that do that for you.

For instance, in the above case, you could have a user create a k8s Secret that is then used to update Vault. But they have to create the initial Secret somehow.

But I'm not entirely convinced Argo should do that for you. For instance, secrets should be cryptographically randomly generated, which requires no secret input. And if you're using a secret store like Vault, it should probably be the main place where you modify secrets and nowhere else -- i.e. a single source-of-truth.

Seems like #5506 is a generalized version for this.

I actually think that if we ever implement #5506, it would use this exact type of parameter to ensure it's not logged anywhere etc. Similarly, I think #5506 may only make sense in very narrow use-cases.

In other words, many use-cases for both of these are not best practice, and the narrow ones may not be either.
Implementing it may also end up encouraging insecure practices. Certainly I think some folks are already using Secrets in an insecure way (e.g. #12796), but our best option may be user education and docs/tutorials on how to use them more securely.