In order to utilize a provided ServiceAccount to install and manage content, operator-controller needs to be capable of fetching an authentication token for a given ServiceAccount. Once retrieved, this token can then be used to create clients that authenticate as the ServiceAccount to perform operations on the cluster.

The scope of this issue is limited to specifically implementing a Go type to fetch and cache these authentication tokens and does not include utilizing the token retrieved.

While the exact implementation may vary, here are some things to consider:

• Use the TokenRequest API to fetch an authentication token for a provided ServiceAccount
• Cache the authentication token so that when subsequent requests for the same ServiceAccount are made we can return a valid token without hitting the Kube API server (limits load on Kube API server)
• Token rotation. Tokens are not always long-lived and may require rotation, especially when caching tokens. If we identify that the token in the cache is no longer valid, another request for a valid token should be made.

A high-level overview of what the logic flow could look like:

graph LR
  A(ServiceAccount)
  B(TokenGetter)
  C(TokenRequest)
  D(Token)
  E(Token Cache)
  F{In Cache?}
  G{Expired?}
  
  A -- Provided To --> B
  B --> F
  F -- Yes --> G
  F -- No --> C
  G -- Yes --> C
  G -- No --> E
  C -- Returns --> D
  E -- Returns --> D
  D -- Stored in --> E

Acceptance Criteria:

• A new Go library/type is created that:
  • Fetches authentication tokens for a provided ServiceAccount
  • Caches tokens
  • Rotates cached tokens when no longer valid
• Unit tests