-
Notifications
You must be signed in to change notification settings - Fork 581
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Obfuscate sensitive data in TaskConfig #5385
Comments
To obfuscate sensitive data in Flyte's TaskConfig, you can use Flyte's secret management feature. This allows you to securely pass sensitive information to your tasks without exposing it in the UI or logs. Here's an example of how to use Flyte's secret management:
import flytekit
from flytekit import Secret, task, workflow
SECRET_NAME = "user_secret"
SECRET_GROUP = "user-info"
@task(secret_requests=[Secret(group=SECRET_GROUP, key=SECRET_NAME)])
def secret_task() -> str:
secret_val = flytekit.current_context().secrets.get(SECRET_GROUP, SECRET_NAME)
# Use the secret value securely
return secret_val
@workflow
def wf() -> str:
return secret_task() Would you like more detail on this approach? Sources:
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! |
We should not store sensitive information in task config. Secrets should be used for this |
@kumare3
Do you mean these fields should not be exposed in TaskConfig, but the plugin / agent should be responsible to fill them from Secrets? |
Correct |
@pingsutw , can you list the remaining work here? |
@pingsutw i think this was handled right? |
Motivation: Why do you think this is important?
Flyte dumps all TaskConfig to the UI and logs, including sensitive data (such as access tokens).
This is a critical security issue in enterprise environments.
Goal: What should the final outcome look like, ideally?
Flyte admins can mark certain fields as sensitive in the config, sensitive fields are obfuscated throughout the application.
Describe alternatives you've considered
If this approach does not fit the design, perhaps we should consider a more generic approach similar to the one implemented in Databricks. All the values retrieved from the secret store are treated as sensitive data and obfuscated throughout the application.
Propose: Link/Inline OR Additional context
https://docs.databricks.com/en/security/secrets/redaction.html
Are you sure this issue hasn't been raised already?
Have you read the Code of Conduct?
The text was updated successfully, but these errors were encountered: