Summary and Problem Description restated from ["MTX: User Auth"|https://docs.google.com/document/d/1XIiWTgiv-NGpDDYhsF3kFOJyG7_TLdPM6OoSaGQkkrk].

Summary

When migrating workloads and state between source and destination clusters, we need access to each cluster in order to perform the migration. Currently, what is being proposed for access to the source cluster is a URL and token saved as a Kubernetes Secret which is later used for accessing the source cluster. We also need a solution for accessing the destination cluster that, in MTX, is assumed to be the cluster where the Pipeline is running.

So the MTX UI asks for credentials to access the source cluster, but what about the destination cluster? Problems:

1. While requests made through the UI are made as the currently logged in user, it is not trivial to make the workloads that run at the user's request run with the same level of permissions.
2. We can not know ahead of time, all of the permissions the currently logged in user will require to successfully complete the migration.

Problem

When a PipelineRun is submitted, we want for the underlying pods to access the destination cluster (assumed to be the cluster where the pod is running) AS the user who submitted it. We want to as best we can prevent leaking credentials, privilege escalation, etc.

A lot of the initial investigation can be found in this google doc: https://docs.google.com/document/d/1XIiWTgiv-NGpDDYhsF3kFOJyG7_TLdPM6OoSaGQkkrk and 

Summary

The goal of this spike is to clearly define a solution where our PipelineRuns run AS the user who submitted it. We should decide how to approach this for GA via the enhancement process.