Skip to content
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

Open
2 tasks done
rambrus opened this issue May 17, 2024 · 5 comments
Open
2 tasks done

Obfuscate sensitive data in TaskConfig #5385

rambrus opened this issue May 17, 2024 · 5 comments
Labels
backlogged For internal use. Reserved for contributor team workflow. enhancement New feature or request

Comments

@rambrus
Copy link

rambrus commented May 17, 2024

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?

  • Yes

Have you read the Code of Conduct?

  • Yes
@rambrus rambrus added enhancement New feature or request untriaged This issues has not yet been looked at by the Maintainers labels May 17, 2024
Copy link

runllm bot commented May 17, 2024

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:

  1. Define Secrets: Use the Secret class to define the secrets required by your task.
  2. Access Secrets: Retrieve the secrets within your task using flytekit.current_context().secrets.get.
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!

@kumare3
Copy link
Contributor

kumare3 commented May 17, 2024

We should not store sensitive information in task config. Secrets should be used for this

@rambrus
Copy link
Author

rambrus commented May 17, 2024

@kumare3
When Databricks TaskConfig is defined, sensitive data (auth) needs to be passed in these fields:

  • databricksConf / new_cluster / docker_image / basic_auth / password
  • databricksToken

Do you mean these fields should not be exposed in TaskConfig, but the plugin / agent should be responsible to fill them from Secrets?

@kumare3
Copy link
Contributor

kumare3 commented May 17, 2024

Correct

@eapolinario eapolinario added backlogged For internal use. Reserved for contributor team workflow. and removed untriaged This issues has not yet been looked at by the Maintainers labels May 23, 2024
@eapolinario
Copy link
Contributor

@pingsutw , can you list the remaining work here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backlogged For internal use. Reserved for contributor team workflow. enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants