Chapter 1. Red Hat Quay tenancy model
Chapter 1. Red Hat Quay tenancy model Before creating repositories to contain your container images in Red Hat Quay, you should consider how these repositories will be structured. With Red Hat Quay, each repository requires a connection with either an Organization or a User . This affiliation defines ownership and access control for the repositories. 1.1. Tenancy model Organizations provide a way of sharing repositories under a common namespace that does not belong to a single user. Instead, these repositories belong to several users in a shared setting, such as a company. Teams provide a way for an Organization to delegate permissions. Permissions can be set at the global level (for example, across all repositories), or on specific repositories. They can also be set for specific sets, or groups, of users. Users can log in to a registry through the web UI or a by using a client like Podman and using their respective login commands, for example, USD podman login . Each user automatically gets a user namespace, for example, <quay-server.example.com>/<user>/<username> , or quay.io/<username> if you are using Quay.io. Superusers have enhanced access and privileges through the Super User Admin Panel in the user interface. Superuser API calls are also available, which are not visible or accessible to normal users. Robot accounts provide automated access to repositories for non-human users like pipeline tools. Robot accounts are similar to OpenShift Container Platform Service Accounts . Permissions can be granted to a robot account in a repository by adding that account like you would another user or team.