Pull Secrets and Customer Account User

Latest response

Guys, building pipelines to deploy OCP 4 and wondering how people are setting up dev teams with pull secrets? Currently I'm using the one from my customer logon but I'd prefer for the teams to have their own dedicated pull secrets as my one contains my e-mails address etc.


how rotate pull secret credentials?

Not rotate but how to setup pull secrets for different teams. Do they need a logon to the customer portal to get one i.e. can a pull secret be generated that not associated with a customer portal account or can a single customer portal account have multiple pulls secrets?

A single pull secret is generated for a single customer portal account. If a user has two accounts, the user has access to two different secrets, each associated with the account and organization of each account. The pull secrets do not appear to expire but clusters deployed using the pull secret will only get a 60-day evaluation license until they are registered with a customer portal account that has a valid subscription entitlement avalable that covers the usage.

An organization administrator can create a portal account for the team with minimal permissions. This should allow them to log into cloud.redhat.com to access the pull secret but without access to user, subscription, or ticket functionality.

I have been instructed to do the following: Can you please obtain the OpenShift pull secret associated with your account from here: https://cloud.redhat.com/openshift/install/pull-secret and send it to us? We need this to download the appropriate OpenShift packages from Red Hat.

The pull secret is used to identify that an account exists and only permits downloading of images. It is not an API token or password for your account and will not allow the bearer to consume subscription allocations or perform any other actions on the Red Hat portal. However, it is important that you follow your organization's policies and practices, these are meant to protect both you and your organization.

Your organization's administrator can create an appropriate level account on behalf of the individual or team in the Red Hat portal. While an individual can create a personal account at redhat.com, using an individual's pull secret may put your business at greater risk as the cluster may not be associated with your organization's account or your clusters will no longer receive security updates if the individual deletes their personal account.

If you or your organization cannot provide a pull secret to the individual, tyou can perform the installation but your pull secret will be accessible to the cluster administrators. You can choose to provide the individual with access to a mirror registry, instructions on how to set one up can be found in the documentation.


It is possible to bind credentials to a pull-through or caching pull-through registry to be used in the imageContentSources for the cluster's installation configuration. This can be a better option as a virtual registry with credentials and pull-through can be maintained should the pull secret be changed and may provide better security with less administration than setting up, synchronizing, and maintaining a conventional mirror.

Please check with your registry vendor's support and offerings for information on mirroring, speak with the individual to their needs, your organization with regard to policy, and with Red Hat with regard to download, support, and licensing questions related to the pull secret.

Brian, thanks for the detailed response. Much appreciated. I will create dedicated accounts for this. Thanks for the steer.