#2927 [Core feature] Support mapping `principal` to Kubernetes namespace Issue created by hankfanchiu Motivation: Why do you think this is important? At Stripe, Flyte users will be able to register and then launch workflows on an ad hoc basis, without second party review. Within these workflows, some tasks may access sensitive data. From a security perspective, we must be able to thread the identity of a Flyte user through Flyte Admin and Kubernetes to downstream, internal services or resources. To do so for any task execution, we must be able to run a Kubernetes workload in a Kubernetes namespace that is scoped to the user. Then, within this task that makes the outbound request to an internal service or resource, we would first extract the username/principal from the namespace, and then propagate this identity encoded in an access token. Goal: What should the final outcome look like, ideally? In Flyte Admin's `namespace_mapping` configuration, add support for

{{ principal }}

in the template. Then, an example scenario would be as such, given this Flyte Admin configuration:

namespace_mapping:
  template: "{{ principal }}"

When the user

hankfanchiu

triggers a task execution, the Kubernetes workload would run in the

hankfanchiu

namespace. Describe alternatives you've considered None 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