[Core feature] authType=accesskey has no means to provide the secret securely

[dwo]

Motivation: Why do you think this is important?

flyte-core: If you need to use authType=accesskey for storage, the only option is to pass the secret part of the access key in your Helm values (storage.s3.secretKey) and to have it inlined into various ConfigMaps.

This stands in contrast to how the database password is handled with common.databaseSecret where you can have your password mounted from the specified secret to /etc/db/pass.txt or similar.

Goal: What should the final outcome look like, ideally?

Ideally the secret part of storage access keys should not be passed through Helm values or appear in a ConfigMap, it should be configurable via a Secret.

Describe alternatives you've considered

I tried to check if it is possible to specify initContainers for the various components of flyte-core, but this is not the case. This could allow one to get a secret into the environment variables of an init container and then substitute values in the mounted config.

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

[welcome]

Thank you for opening your first issue here! 🛠

[runllm]

To securely manage secrets like the storage access key in Flyte, you can leverage Kubernetes secrets instead of embedding them in Helm values or ConfigMaps. According to Flyte's documentation on secret management, you can create a Kubernetes secret and reference it in your Flyte deployment. This approach ensures that sensitive information is not exposed in plain text within configuration files.

To implement this, create a Kubernetes secret with your storage access key and configure Flyte to use this secret. For example, you can create a secret using kubectl:

kubectl create secret generic storage-secrets --from-literal=access_key=<ACCESS_KEY> --from-literal=secret_key=<SECRET_KEY> -n flyte

Then, reference this secret in your Flyte configuration, ensuring that the secret is mounted or injected into the necessary pods. This method aligns with how database passwords are securely managed using secrets.

Would you like more detail on setting up and using Kubernetes secrets in Flyte?

Sources:

• Flyte's documentation on secret management

---

This is an AI-generated response and your feedback is appreciated! Please leave a 👍 if this is helpful and 👎 if it is not.

Mention @RunLLM to ask follow-up questions. See runllm.com for more!

[dwo]

This also partially applies to flyte-binary which puts the secret key into a kubernetes Secret (better) but still via values:

flyte/charts/flyte-binary/templates/config-secret.yaml

Lines 31 to 36 in f2a1ad7

	013-storage-secrets.yaml: |
	storage:
	stow:
	config:
	access_key_id: {{ required "Access key required for S3 storage provider" .Values.configuration.storage.providerConfig.s3.accessKey | quote }}
	secret_key: {{ required "Secret key required for S3 storage provider" .Values.configuration.storage.providerConfig.s3.secretKey | quote }}

[Sovietaced]

We have implemented this in our fork so I'll upstream this effort to improve things.

[Sovietaced]

@dwo let me know what you think about this implementation: #6419