Note: this document contains our current thinking on what could be done here and what the challenges are. Please consider it mandatory reading as part of understanding this Feature proposal.

Feature Overview (aka. Goal Summary)  

TAT stands for "temporary access token" and is a generic term for concepts like AWS' short lived token service, in which clients are not given long lived credentials to make service calls, but rather get a short lived/temporary token which is frequently rotated.

Today operators have a fair bit of work to do to enable themselves to run in TAT clusters, see this doc for details on what work needs to be done by each operator owner.

We can eliminate most of this per-operator effort by adding functionality in OLM that manages the credentials request and secret injection on behalf of the operator. This also has the side benefit of better positioning OLM to block operator upgrades when the requested permissions have changed in a new version of an operator. 

Goals (aka. expected user outcomes)

• Operator authors no longer have to include code in their operator to create/manage CredentialsRequest objects and read the resulting Secret
• Operators no longer need to request RBAC permission to create/manage CredentialsRequest objects, which is a significant privilege to give an operator
• OLM creates CredentialRequests on behalf of the operator and mounts the resulting Secret into the operator deployment, at which point the cloud SDK can consume the content directly from the filesystem
   

Requirements (aka. Acceptance Criteria):

• Operators must not need permissions or logic to directly manage CredRequests or Secrets
• Solution must anticipate functioning with AWS, Azure, and GCP's temporary token solutions, this may require slightly different work in both OLM and individual operators to support each, but it should be a substantially similar flow (e.g. different annotations/labels, but same general resources and workflows)
• We cannot put code in upstream OLM that is tied to CredentialsRequests or other OCP-specific apis/behavior. The most we can do is whitelist CredentialsRequests in upstream OLM so that they can be included in bundles, but the current envisioned implementation will require more than that(specifically it requires us mutate the CredRequests object)
   

  Use Cases (Optional):

• As the author of an operator that needs to talk to cloud service apis, I want a way to request TAT-style creds so that my operator can request+receive valid creds when running on OCP clusters that are in TAT mode. I want to minimize the code changes that i must make in my operator to accomplish this.
   

Questions to Answer (Optional):

See this document which sketches out a design+challenges
 

Out of Scope

• Addressing how the STS role is created in the cloud account
• Implications for what happens when an STS-enabled operator runs on a non-OCP cluster: the changes the operator author has to make to request STS creds must be no-op'd when running on a vanilla k8s cluster w/ upstream OLM, but it's not OLM's problem to deal w/ the fact that the operator won't get the necessary creds. The operator will have to have alternate install instructions/logic to get the creds in such an environment.

Background

Current design thoughts
 

Customer Considerations

Provide any additional customer-specific considerations that must be made when designing and delivering the Feature.  Initial completion during Refinement status.

Documentation Considerations

Provide information that needs to be considered and planned so that documentation will meet customer needs.  Initial completion during Refinement status.

Interoperability Considerations

Which other projects and versions in our portfolio does this feature impact?  What interoperability test scenarios should be factored by the layered products?  Initial completion during Refinement status.