Chapter 2. Registry-wide access management

By default, all Red Hat Quay members part of a registry can create repositories and upload content to their own user account. For example, when user1 pushes an artifact tag such as /<user1>/<image>:<tag>, a repository of the name user1/image is created. Inside of that repository is information about the artifact tag.

With the FEATURE_RESTRICTED_USERS configuration field, Red Hat Quay administrators can restrict all users that are part of their registry from pushing images or artifacts to the registry. This configuration field effectively renders all users from creating new organizations or pushing content altogether unless they are already part of that organization and defined as a team member of that organization; that is, restricted users still have normal permissions in organizations based on the teams that they are members of.

For example, a Red Hat Quay administrator sets the FEATURE_RESTRICTED_USERS configuration field in their config.yaml file as follows:

FEATURE_RESTRICTED_USERS: true

When set as shown, user1 is unable to create a new organization by using the Red Hat Quay UI. Upon attempt, the following error message is returned: Unauthorized. Additionally, if user1 attempts to push an image to their own namespace by using the CLI (that is, /<user1>/<image>:<tag>), the following error message is returned: Error: writing blob: initiating layer upload to /v2/user1/<image>/blobs/uploads/ in <quay-server.example.com>: unauthorized: access to the requested resource is not authorized. However, if user1 is part of an organization’s team as defined by an administrator, they maintain the permissions capable of that team. For example, if user1 is added to an organization’s team and given the Admin role, they have administrative privileges for that organization. If they are given the

When FEATURE_RESTRICTED_USERS is leveraged with the RESTRICTED_USERS_WHITELIST configuration field, however, Red Hat Quay administrators can allow specified members the ability to continue to push to the registry or make organizations. In general, when FEATURE_RESTRICTED_USERS is set, Red Hat Quay administrators might also set RESTRICTED_USERS_WHITELIST, otherwise all members of the registry (with the exception of those defined by a team) are rendered incapable of doing basic tasks.

For example, a Red Hat Quay administrator sets the FEATURE_RESTRICTED_USERS and RESTRICTED_USERS_WHITELIST configuration fields in their config.yaml file as follows:

# ...
FEATURE_RESTRICTED_USERS: true
RESTRICTED_USERS_WHITELIST:
      - user2
# ...

With this configuration, all users except user2 are restricted from pushing images or creating organizations. Other users part of a team will also have these privileges. Users part of the registry that are either not defined by the RESTRICTED_USERS_WHITELIST field or part of an organization’s team have no permissions within the registry, and will therefor be unable to perform basic tasks.

When a user, for example, user1 creates an organization within a registry, they own the access and permissions to that organization. As such, they can create repositories, define teams and memberships, create robot accounts, set default permissions, view logs, and adjust other settings as warranted. It is, for all intents and purposes, the user’s organization.

By default, superusers do not have access to a user’s organization. However, Red Hat Quay administrators can use the FEATURE_SUPERUSERS_FULL_ACCESS configuration field to grant superusers the ability to read, write, and delete content from other repositories in namespaces or organizations that they do not own or have explicit permissions for.

To grant superusers full access to all organizations within the registry, you can use the following YAML configuration:

# ...
FEATURE_SUPERUSERS_FULL_ACCESS: true
# ...

After sitting FEATURE_SUPERUSERS_FULL_ACCESS: true, all organizations will be visible on the superuser’s Organization page.