Add identity to task execution metadata

[noahjax]

Why are the changes needed?

For our specific use case it is critical to be able to determine the identity for the subject who launches a task. It seems like other information on the security context could also be more generally useful, so I included that in addition to the critical execution_identity field as part of this PR.

What changes were proposed in this pull request?

Add identity to TaskExecutionMetadata. In conjunction with flyteorg/flytekit#2282, this change will make identity available to flyte agents.

How was this patch tested?

Setup process

Screenshots

Check all the applicable boxes

• I updated the documentation accordingly.
• All new and existing tests passed.
• All commits are signed-off.

Related PRs

#3936

Docs link

[welcome]

Thank you for opening this pull request! 🙌

These tips will help get your PR across the finish line:

• Most of the repos have a PR template; if not, fill it out to the best of your knowledge.
• Sign off your commits (Reference: DCO Guide).

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 59.11%. Comparing base (cb6384a) to head (d2f9e0f).
Report is 39 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #5105      +/-   ##
==========================================
+ Coverage   58.49%   59.11%   +0.61%     
==========================================
  Files         627      645      +18     
  Lines       54155    55576    +1421     
==========================================
+ Hits        31680    32854    +1174     
- Misses      19942    20129     +187     
- Partials     2533     2593      +60     

Flag	Coverage Δ
unittests	59.11% <100.00%> (+0.61%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[pingsutw]

@noahjax just curious, so you are going to use OAuth2TokenRequest in the agent not Secret, right?

My PR is going to pass the actual secret value to the agent because we save the secret in AWS/GCP secret manager, and only the propeller has permission to read it.

[noahjax]

@pingsutw For my use case I actually only need the execution_identity, but I wanted to grab that in a way that could be useful in other cases as well. Your PR is probably more useful in general because it actually fetches secret values, but it would be awesome if in addition to those secret values we could also get some information from the run_as field to the agent. That might require some new message type instead of piggy-backing in the existing SecurityContext

[pingsutw]

@noahjax In that case, should we just pass Identity to the agent? flyte won't mount the Secret and OAuth2TokenRequest to the agent, since it's a long-running service

I think passing Identity to an agent is very useful. Many of our use cases will also need that.

[kumare3]

Cc @EngHabu
I agree with @pingsutw - but what are the security implications

[noahjax]

@kumare3 @pingsutw That makes sense, I updated the PR to use Identity instead of SecurityContext

[pingsutw]

cc @ddl-ebrown @noahjax we can merge it, right

[noahjax]

Yeah go for it

[welcome]

Congrats on merging your first pull request! 🎉

[ddl-ebrown]

It looks like this implementation is actually incomplete based on our needs. When scheduling a job, this identity is actually the IdpId for the flytepropeller, not the user that scheduled the workflow

Ultimately we want to capture both values

[eapolinario]

cc: @pingsutw

[pingsutw]

@ddl-ebrown would you create another PR to address it?

[ddl-ebrown]

Yeah, I can do that -- just need to know what we want to capture in the IDL and how we should name it