Another question about passing secrets to Flyte workflow executions. I have a service that kicks off Flyte workflows on behalf of many users. In the Flyte workflow, I would like to access my service and identify which user is making the request. I was looking at the secrets documentation and it's not clear if that's going to fit use cases where different secrets need to be passed in for different executions. E.g. if user A runs workflow A, and user B runs workflow B, we want each workflow to receive a different token. I see that I can probably pass a token as an input to the Flyte task, but then I am concerned that the input would be stored in Flyte or accidentally logged. Any recommendations?

I don't think secrets are a good fit for your use case. And yes, a task input is stored. @freezing-airport-6809, what do you recommend?

Ya secrets are not the right way. Secrets are like standard api keys etc, fairly constant per workflow. We have 2 options for this 1. Soon you will be able to pass env vars to workflows. You can encrypt your token with a public key and use private key as the secret to decrypt it 2. LinkedIn and stripe are working on passing the user identity down into an execution- which will include the auth tokens

Hi @bumpy-television-667, we are adding

user_identity

to security_context, which is in execution_spec (WIP). You can parse

user_identity

from the access_token issued by oauth2 vendor and inject into ``user_identity` here. Tasks can therefore access

user_identity

in taskCtx.

Thanks all, I have two options that should work for me: 1. pass an encrypted token as an input and decrypt it with a secret private key. 2. use

user_identity

from the task's context. Any ideas when the user_identity feature might land? We aren't currently authenticating our Flyte instance with an oauth2 provider, but we can start doing so if it means that our Flyte jobs have a clean way of running with a user's identity.

I think the second is the cleaner way. We will merge

user_identity

pr by EOW i believe