[Core feature] Per-domain secrets mounting

[slauth-io-tal]

Motivation: Why do you think this is important?

When running a task within a certain domain (production/staging/development), it should be (security-)isolated from other domains. Meaning, secrets should be bound to a single domain and shouldn't be accessible to other domains.

An example - while the same task in different domains might require a database secret, the tasks running in the development domain shouldn't have access to the production database. Nor should a task determine what secret to request/use based on its domain - secrets should be treated like an environment configuration.

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

Tasks are able to request a secret, and during runtime the control plane determines which secret to mount according to the task domain. So, a task running in development and requesting the database secret will get a secret representing the development database.

Describe alternatives you've considered

Currently implementing this mechanism within the code of tasks. Preferably this'll be included in Flyte itself.

Propose: Link/Inline OR Additional context

No response

Are you sure this issue hasn't been raised already?

• [X] Yes

Have you read the Code of Conduct?

• [X] Yes

[welcome[bot]]

Thank you for opening your first issue here! 🛠

[eapolinario]

cc: @katrogan , do you have a good idea of how this could be implemented? Also in terms of prioritization, where this should fall?

[katrogan]

@eapolinario unfortunately flyteadmin has no concept of domain-default values, matchable attributes are per-project or per-workflow currently. Ideally I'd like us to add domain-wide matchable attributes for this and all other use-cases

Ideally we could add default secrets to the WorkflowExecutionConfig and introduce domain-level attrs.

As a proposal: we could, at create execution time we can add the domain-appropriate secret to a new field in the ExecutionConfig when we build the workflow CRD. This can be passed to the TaskExecutionContext, specifically in the TaskExecutionMetadata and used by the plugins handler to inject the secrets by folding them into the existing task secrets at runtime

Not sure if others have preferences. We could also do something prior to creating the workflow CRD and updating the compiled workflow closure's task templates but these execution-time overrides seems like a propeller-type responsibility

[github-actions[bot]]

Hello 👋, This issue has been inactive for over 9 months. To help maintain a clean and focused backlog, we'll be marking this issue as stale and will close the issue if we detect no activity in the next 7 days. Thank you for your contribution and understanding! 🙏

[github-actions[bot]]

Hello 👋, This issue has been inactive for over 9 months and hasn't received any updates since it was marked as stale. We'll be closing this issue for now, but if you believe this issue is still relevant, please feel free to reopen it. Thank you for your contribution and understanding! 🙏