[ezandamela-lila]

Why are the changes needed?

Any authenticated user can terminate any other user's execution. TerminateExecution checks nothing beyond the project/domain scope every caller already has, even though flyteadmin already records who launched each execution.

What changes were proposed in this pull request?

Adds an opt-in terminateAuthz config block. When it's enabled, a terminate is allowed if:

• the caller launched the execution
• the execution has no recorded user, or was scheduled
• the launcher is in exemptLaunchers, for shared service accounts
• it's a child execution and the caller is in systemIdentities, for flytepropeller's cascading aborts
• the caller is in adminIdentities, or has one of adminGroups in the groupsClaim claim

Anything else gets PermissionDenied. It's off by default, so nothing changes until you turn it on.

This is for Flyte v1 (master). It needs flyteadmin auth turned on with an identity provider, so the access token carries a sub, plus the group claim if you use adminGroups.

terminateAuthz:
  enabled: true
  adminIdentities: []
  adminGroups: []
  groupsClaim: groups
  exemptLaunchers: []
  systemIdentities: []

How was this patch tested?

Unit tests in auth/authz_test.go, and TestAuthorizeTerminate in execution_manager_test.go covering each allowed and denied case above. They pass on current master.

We've also been running it in production since September, in this setup:

• Flyte v1.16.4, multi-cluster on Kubernetes: one flyteadmin, with flytepropeller on separate data-plane clusters
• flyteadmin auth with an external authorization server, using Keycloak for both user login and access tokens
• groupsClaim: groups from Keycloak for adminGroups, and flytepropeller's client id in systemIdentities, since propeller calls flyteadmin with its own credentials from the other clusters

We haven't tested it with any other identity provider.

To try it you need flyteadmin auth on and two users:

1. Set terminateAuthz.enabled: true, and add propeller's client id to systemIdentities if propeller authenticates to flyteadmin.
2. As user A, launch an execution.
3. As user B, run flytectl delete execution -p <project> -d <domain> <name>. It fails with PermissionDenied: only the user who launched this execution may terminate it.
4. As user A, run the same command. The execution aborts.

Labels

• added
• security

Check all the applicable boxes

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

[Sovietaced]

As someone who wrote an RBAC implementation that never landed due to lack of upstream support I don't think it makes much sense to make targeting authorization point fixes like this imo. TerminateExecution is very specific.