#3769 [Core feature] Configuration containing secrets should use Opaque Secrets over ConfigMaps Issue created by EternalDeiwos Motivation: Why do you think this is important? The way secrets are handled in deployment cause several headaches: 1. Secrets are supplied in plain text in Helm configuration; this is a problem when deployments and Helm

values.yaml

contents are stored in a git repository and deployed using an external tool. 2. There are no existing configuration to pull configuration and/or secrets from existing configmaps or secrets; this makes it difficult inject secrets and configuration from a central vault (e.g. Hashicorp Vault). 3. Potentially long-lived secrets are being kept in ConfigMaps instead of Opaque Secrets; this is generally not idiomatic even if the security of the two option were roughly equivalent. This is creating a significant barrier to me deploying a test instance in our environment (bare metal K8s). Goal: What should the final outcome look like, ideally? I would like to supply names of existing secrets to the Helm chart and/or Kustomization without directly exposing secrets in configuration files or Helm values. This will allow incremental improvement of my deployment configuration without needing to expose secrets directly as part of the deployment. Describe alternatives you've considered I've been working on a Kustomization with significant patching to move existing configmaps into secrets... however I am considering a completely parallel deployment because writing the patches takes more time than editing the original files. Propose: Link/Inline OR Additional context No response Are you sure this issue hasn't been raised already? ☑︎ Yes Have you read the Code of Conduct? ☑︎ Yes flyteorg/flyte