Goal: Alleviate the need of having to set up and distribute pull-secrets from users or robots in Quay across a fleet of OpenShift cluster to enable workloads to pull and push container images from their namespace. Address concerns with the long-lived nature of static pull secrets and the missing ability to rotate or limit the lifetime of robot tokens in Quay.

Background: To enable OpenShift users to leverage Quay for pulling and pushing images, authentication to Quay needs to be sorted out. This is done today by placing pull secrets (which are also used for push) into the cluster. These are generated either from the credentials of a Quay user account or more commonly, a Quay robot account that has the appropriate permissions on the image repository. This process can be tedious, especially when setting up different users either in different namespace or different clusters, to use the same image repositories in Quay. On top of that these pull secrets need to be manually rotated inside OpenShift in parallel with updating the robot accounts in Quay, to regularly change passwords and reduce impact in case of leakage.

Both the missing automation of pull secret creation & distribution and their long-lived nature make it hard for OpenShift users to use Quay at scale effectively and securely.

This exact same problem has been solved by cloud providers and their API credentials by relying on OIDC for identity-based access management. Keyless authentication is achieved by using OIDC to identify a user in two systems and leverage short-lived tokens to authenticate individual transactions, that are regularly refreshed.
These systems are harder to breach because it requires assuming the identity of the user or capturing a temporary token, which has limited impact upon leaking due to its short-lived nature.

Customers these days prefer this method of authentication and authorization across two or more systems.

Acceptance criteria:

• There is a pluggable credential provider for the OpenShift kubelet that supports Red Hat Quay registries
• As a result, OpenShift users can leverage their OIDC identity within the cluster to authenticate against Quay
• the OIDC identity and token is used to by the kubelet provider to create temporary credentials in Quay limited to the permission scope required to execute the operation on OpenShift, push or pull
• Any tokens to authorize individual registry transactions are automatically generated and regularly refreshed, typically every 5 minutes

Notes:

• https://docs.google.com/document/d/12gUO66757pH8KoS2GudFoLfGEjG-QyCD0fd98ktjYNo/edit