Manage Red Hat Quay

Procedure

1. Add, or set, the FEATURE_USER_METADATA configuration field to true in your config.yaml file. For example:

1. Redeploy Red Hat Quay.

2. Now, when prompted to log in, users are requested to enter the following information:

   

Procedure

1. Generate the server key by entering the following command:

   $ openssl genrsa -out ssl.key 2048

2. Generate a signing request by entering the following command:

   $ openssl req -new -key ssl.key -out ssl.csr

3. Enter the information that will be incorporated into your certificate request, including the server hostname, for example:

   Country Name (2 letter code) [XX]:IE
   State or Province Name (full name) []:GALWAY
   Locality Name (eg, city) [Default City]:GALWAY
   Organization Name (eg, company) [Default Company Ltd]:QUAY
   Organizational Unit Name (eg, section) []:DOCS
   Common Name (eg, your name or your server's hostname) []:quay-server.example.com
   Email Address []:

4. Create a configuration file openssl.cnf, specifying the server hostname, for example:

   openssl.cnf

   [req]
   req_extensions = v3_req
   distinguished_name = req_distinguished_name
   [req_distinguished_name]
   [ v3_req ]
   basicConstraints = CA:FALSE
   keyUsage = nonRepudiation, digitalSignature, keyEncipherment
   subjectAltName = @alt_names
   [alt_names]
   DNS.1 = <quay-server.example.com>
   IP.1 = 192.168.1.112

5. Use the configuration file to generate the certificate ssl.cert:

   $ openssl x509 -req -in ssl.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out ssl.cert -days 356 -extensions v3_req -extfile openssl.cnf

Procedure

1. Create a Splunk account by navigating to Splunk and entering the required credentials.
2. Navigate to the Splunk Enterprise Free Trial page, select your platform and installation package, and then click Download Now.
3. Install the Splunk software on your machine. When prompted, create a username, for example, splunk_admin and password.
4. After creating a username and password, a localhost URL will be provided for your Splunk deployment, for example, http://<sample_url>.remote.csb:8000/. Open the URL in your preferred browser.
5. Log in with the username and password you created during installation. You are directed to the Splunk UI.

Procedure

1. Configure Red Hat Quay to use Splunk or the Splunk HTTP Event Collector (HEC).

   1. If opting to use Splunk, open your Red Hat Quay config.yaml file and add the following configuration fields:

      # ...
      LOGS_MODEL: splunk
      LOGS_MODEL_CONFIG:
          producer: splunk
          splunk_config:
              host: http://<user_name>.remote.csb 1
              port: 8089 2
              bearer_token: <bearer_token> 3
              url_scheme: <http/https> 4
              verify_ssl: False 5
              index_prefix: <splunk_log_index_name> 6
              ssl_ca_path: <location_to_ssl-ca-cert.pem> 7
      # ...

      1

      String. The Splunk cluster endpoint.

      2

      Integer. The Splunk management cluster endpoint port. Differs from the Splunk GUI hosted port. Can be found on the Splunk UI under Settings → Server Settings → General Settings.

      3

      String. The generated bearer token for Splunk.

      4

      String. The URL scheme for access the Splunk service. If Splunk is configured to use TLS/SSL, this must be https.

      5

      Boolean. Whether to enable TLS/SSL. Defaults to true.

      6

      String. The Splunk index prefix. Can be a new, or used, index. Can be created from the Splunk UI.

      7

      String. The relative container path to a single .pem file containing a certificate authority (CA) for TLS/SSL validation.

   2. If opting to use Splunk HEC, open your Red Hat Quay config.yaml file and add the following configuration fields:

      # ...
      LOGS_MODEL: splunk
      LOGS_MODEL_CONFIG:
        producer: splunk_hec 1
        splunk_hec_config: 2
          host: prd-p-aaaaaq.splunkcloud.com 3
          port: 8088 4
          hec_token: 12345678-1234-1234-1234-1234567890ab 5
          url_scheme: https 6
          verify_ssl: False 7
          index: quay 8
          splunk_host: quay-dev 9
          splunk_sourcetype: quay_logs 10
      # ...

      1

      Specify splunk_hec when configuring Splunk HEC.

      2

      Logs model configuration for Splunk HTTP event collector action logs configuration.

      3

      The Splunk cluster endpoint.

      4

      Splunk management cluster endpoint port.

      5

      HEC token for Splunk.

      6

      The URL scheme for access the Splunk service. If Splunk is behind SSL/TLS, must be https.

      7

      Boolean. Enable (true) or disable (false) SSL/TLS verification for HTTPS connections.

      8

      The Splunk index to use.

      9

      The host name to log this event.

      10

      The name of the Splunk sourcetype to use.

2. If you are configuring ssl_ca_path, you must configure the SSL/TLS certificate so that Red Hat Quay will trust it.

   1. If you are using a standalone deployment of Red Hat Quay, SSL/TLS certificates can be provided by placing the certificate file inside of the extra_ca_certs directory, or inside of the relative container path and specified by ssl_ca_path.

   2. If you are using the Red Hat Quay Operator, create a config bundle secret, including the certificate authority (CA) of the Splunk server. For example:

      $ oc create secret generic --from-file config.yaml=./config_390.yaml --from-file extra_ca_cert_splunkserver.crt=./splunkserver.crt config-bundle-secret

      Specify the conf/stack/extra_ca_certs/splunkserver.crt file in your config.yaml. For example:

      # ...
      LOGS_MODEL: splunk
      LOGS_MODEL_CONFIG:
          producer: splunk
          splunk_config:
              host: ec2-12-345-67-891.us-east-2.compute.amazonaws.com
              port: 8089
              bearer_token: eyJra
              url_scheme: https
              verify_ssl: true
              index_prefix: quay123456
              ssl_ca_path: conf/stack/splunkserver.crt
      # ...

Procedure

1. Log in to your Red Hat Quay deployment.
2. Click on the name of the organization that you will use to create an action log for Splunk.
3. In the navigation pane, click Robot Accounts → Create Robot Account.
4. When prompted, enter a name for the robot account, for example spunkrobotaccount, then click Create robot account.
5. On your browser, open the Splunk UI.
6. Click Search and Reporting.

7. In the search bar, enter the name of your index, for example, <splunk_log_index_name> and press Enter.

   The search results populate on the Splunk UI. Logs are forwarded in JSON format. A response might look similar to the following:

   {
     "log_data": {
       "kind": "authentication", 1
       "account": "quayuser123", 2
       "performer": "John Doe", 3
       "repository": "projectQuay", 4
       "ip": "192.168.1.100", 5
       "metadata_json": {...}, 6
       "datetime": "2024-02-06T12:30:45Z" 7
     }
   }

   1

   Specifies the type of log event. In this example, authentication indicates that the log entry relates to an authentication event.

   2

   The user account involved in the event.

   3

   The individual who performed the action.

   4

   The repository associated with the event.

   5

   The IP address from which the action was performed.

   6

   Might contain additional metadata related to the event.

   7

   The timestamp of when the event occurred.

Procedure

1. Enter the following command to log in to your Red Hat Quay PostgreSQL database:

   $ psql -h <quay-server.example.com> -p 5432 -U <user_name> -d <database_name>

   Example output

   psql (16.1, server 13.7)
   Type "help" for help.

2. Optional. Enter the following command to display the tables list of your PostgreSQL database:

   quay=> \dt

   Example output

                      List of relations
    Schema |            Name            | Type  |  Owner
   --------+----------------------------+-------+----------
    public | logentry                   | table | quayuser
    public | logentry2                  | table | quayuser
    public | logentry3                  | table | quayuser
    public | logentrykind               | table | quayuser
   ...

3. You can enter the following command to return a list of repository_ids that are required to return log information:

   quay=> SELECT id, name FROM repository;

   Example output

    id |        name
   ----+---------------------
     3 | new_repository_name
     6 | api-repo
     7 | busybox
   ...

4. Enter the following command to use the logentry3 relation to show log information about one of your repositories:

   SELECT * FROM logentry3 WHERE repository_id = <repository_id>;

   Example output

    id | kind_id | account_id | performer_id | repository_id | datetime | ip |    metadata_json
   
    59 | 14 | 2 | 1 | 6 | 2024-05-13 15:51:01.897189 | 192.168.1.130 | {"repo": "api-repo", "namespace": "test-org"}

   In the above example, the following information is returned:

   {
     "log_data": {
       "id": 59 1
       "kind_id": "14", 2
       "account_id": "2", 3
       "performer_id": "1", 4
       "repository_id": "6", 5
       "ip": "192.168.1.100", 6
       "metadata_json": {"repo": "api-repo", "namespace": "test-org"} 7
       "datetime": "2024-05-13 15:51:01.897189" 8
     }
   }

   1

   The unique identifier for the log entry.

   2

   The action that was done. In this example, it was 14. The key, or table, in the following section shows you that this kind_id is related to the creation of a repository.

   3

   The account that performed the action.

   4

   The performer of the action.

   5

   The repository that the action was done on. In this example, 6 correlates to the api-repo that was discovered in Step 3.

   6

   The IP address where the action was performed.

   7

   Metadata information, including the name of the repository and its namespace.

   8

   The time when the action was performed.

Procedure

1. In the Settings tab, set the Repository State to Mirror:

   

2. In the Mirror tab, enter the details for connecting to the external registry, along with the tags, scheduling and access information:

   

3. Enter the details as required in the following fields:

   • Registry Location: The external repository you want to mirror, for example, registry.redhat.io/quay/quay-rhel8
   • Tags: This field is required. You may enter a comma-separated list of individual tags or tag patterns. (See Tag Patterns section for details.)
   • Start Date: The date on which mirroring begins. The current date and time is used by default.
   • Sync Interval: Defaults to syncing every 24 hours. You can change that based on hours or days.
   • Robot User: Create a new robot account or choose an existing robot account to do the mirroring.
   • Username: The username for accessing the external registry holding the repository you are mirroring.
   • Password: The password associated with the Username. Note that the password cannot include characters that require an escape character (\).

Procedure

1. Navigate to the Red Hat Single Sign-On Admin Console.

   1. On the OpenShift Container Platform Web Console, navigate to Network → Route.
   2. Select the Red Hat Single Sign-On project from the drop-down list.
   3. Find the Red Hat Single Sign-On Admin Console in the Routes table.
2. Select the Realm that you will use to configure Red Hat Quay.
3. Click Clients under the Configure section of the navigation panel, and then click the Create button to add a new OIDC for Red Hat Quay.

4. Enter the following information.

   • Client ID: quay-enterprise
   • Client Protocol: openid-connect
   • Root URL: https://<quay_endpoint>/
5. Click Save. This results in a redirect to the Clients setting panel.
6. Navigate to Access Type and select Confidential.

7. Navigate to Valid Redirect URIs. You must provide three redirect URIs. The value should be the fully qualified domain name of the Red Hat Quay registry appended with /oauth2/redhatsso/callback. For example:

   • https://<quay_endpoint>/oauth2/redhatsso/callback
   • https://<quay_endpoint>/oauth2/redhatsso/callback/attach
   • https://<quay_endpoint>/oauth2/redhatsso/callback/cli
8. Click Save and navigate to the new Credentials setting.
9. Copy the value of the Secret.

Procedure

1. Update your config.yaml file with the following information:

   AUTHENTICATION_TYPE: OIDC
   # ...
   OIDC_LOGIN_CONFIG:
     CLIENT_ID: 1
     CLIENT_SECRET: 2
     OIDC_SERVER: 3
     SERVICE_NAME: 4
     PREFERRED_GROUP_CLAIM_NAME: 5
     LOGIN_SCOPES: [ 'openid', '<example_scope>' ] 6
     OIDC_DISABLE_USER_ENDPOINT: false 7
   # ...
   FEATURE_TEAM_SYNCING: true 8
   FEATURE_NONSUPERUSER_TEAM_SYNCING_SETUP: true 9
   FEATURE_UI_V2: true
   # ...

   1

   Required. The registered OIDC client ID for this Red Hat Quay instance.

   2

   Required. The registered OIDC client secret for this Red Hat Quay instance.

   3

   Required. The address of the OIDC server that is being used for authentication. This URL should be such that a GET request to <OIDC_SERVER>/.well-known/openid-configuration returns the provider’s configuration information. This configuration information is essential for the relying party (RP) to interact securely with the OpenID Connect provider and obtain necessary details for authentication and authorization processes.

   4

   Required. The name of the service that is being authenticated.

   5

   Required. The key name within the OIDC token payload that holds information about the user’s group memberships. This field allows the authentication system to extract group membership information from the OIDC token so that it can be used with Red Hat Quay.

   6

   Required. Adds additional scopes that Red Hat Quay uses to communicate with the OIDC provider. Must include 'openid'. Additional scopes are optional.

   7

   Whether to allow or disable the /userinfo endpoint. If using Azure Entra ID, set this field to true. Defaults to false.

   8

   Required. Whether to allow for team membership to be synced from a backing group in the authentication engine.

   9

   Optional. If enabled, non-superusers can setup team synchronization.

2. Restart your Red Hat Quay registry.

1. Log in to your Red Hat Quay registry via your OIDC provider.
2. On the Red Hat Quay v2 UI dashboard, click Create Organization.
3. Enter and Organization name, for example, test-org.
4. Click the name of the Organization.
5. In the navigation pane, click Teams and membership.
6. Click Create new team and enter a name, for example, testteam.

7. On the Create team pop-up:

   1. Optional. Add this team to a repository.
   2. Add a team member, for example, user1, by typing in the user’s account name.
   3. Add a robot account to this team. This page provides the option to create a robot account.
8. Click Next.
9. On the Review and Finish page, review the information that you have provided and click Review and Finish.
10. To enable team synchronization for your Red Hat Quay OIDC deployment, click Enable Directory Sync on the Teams and membership page.

11. You are prompted to enter the group Object ID if your OIDC authenticator is Azure Entra ID, or the group name if using a different provider. Note the message in the popup:

    Warning

    Please note that once team syncing is enabled, the membership of users who are already part of the team will be revoked. OIDC group will be the single source of truth. This is a non-reversible action. Team’s user membership from within Quay will be ready-only.

12. Click Enable Sync.

13. You are returned to the Teams and membership page. Note that users of this team are removed and are re-added upon logging back in. At this stage, only the robot account is still part of the team.

    A banner at the top of the page confirms that the team is synced:

    This team is synchronized with a group in OIDC and its user membership is therefore read-only.

    By clicking the Directory Synchronization Config accordion, the OIDC group that your deployment is synchronized with appears.

14. Log out of your Red Hat Quay registry and continue on to the verification steps.

1. Log back in to your Red Hat Quay registry.
2. Click Organizations → test-org → test-team Teams and memberships. user1 now appears as a team member for this team.

1. Navigate to your OIDC provider’s administration console.
2. Navigate to the Users page of your OIDC provider. The name of this page varies depending on your provider.
3. Click the name of the user associated with Red Hat Quay, for example, user1.
4. Remove the user from group in the configured identity provider.
5. Remove, or unassign, the access permissions from the user.
6. Log in to your Red Hat Quay registry.
7. Click Organizations → test-org → test-team Teams and memberships. user1 has been removed from this team.

Procedure

1. Deploy Red Hat Quay 3.9 with the following config.yaml settings:

   FEATURE_QUOTA_MANAGEMENT: true
   FEATURE_GARBAGE_COLLECTION: true
   PERMANENTLY_DELETE_TAGS: true
   QUOTA_TOTAL_DELAY_SECONDS: 1800 1
   RESET_CHILD_MANIFEST_EXPIRATION: true

   1

   The QUOTA_TOTAL_DELAY_SECONDS flag defaults to 1800 seconds, or 30 minutes. This allows Red Hat Quay 3.9 to successfully deploy before the quota management feature begins calculating storage consumption for every blob that has been pushed. Setting this flag to a lower number might result in miscalculation; it must be set to a number that is greater than the time it takes your Red Hat Quay deployment to start. 1800 is the recommended setting, however larger deployments that take longer than 30 minutes to start might require a longer duration than 1800.

2. Navigate to the Red Hat Quay UI and click the name of your Organization.
3. The Total Quota Consumed should read 0.00 KB. Additionally, the Backfill Queued indicator should be present.
4. After the allotted time, for example, 30 minutes, refresh your Red Hat Quay deployment page and return to your Organization. Now, the Total Quota Consumed should be present.

Procedure

1. Deploy Red Hat Quay 3.9 with the following config.yaml settings:

   FEATURE_GARBAGE_COLLECTION: true
   FEATURE_QUOTA_MANAGEMENT: true
   QUOTA_BACKFILL: false
   QUOTA_TOTAL_DELAY_SECONDS: 0
   PERMANENTLY_DELETE_TAGS: true
   RESET_CHILD_MANIFEST_EXPIRATION: true

2. Navigate to the Red Hat Quay UI and click the name of your Organization.
3. The Total Quota Consumed should read 0.00 KB.

4. Redeploy Red Hat Quay and set the QUOTA_BACKFILL flag set to true. For example:

   QUOTA_BACKFILL: true

   Note

   If you choose to disable quota management after it has calculated totals, Red Hat Quay marks those totals as stale. If you re-enable the quota management feature again in the future, those namespaces and repositories are recalculated by the backfill worker.

Procedure

1. Ensure that the PERMANENTLY_DELETE_TAGS and RESET_CHILD_MANIFEST_EXPIRATION parameters are set to true in your config.yaml file. For example:

   PERMANENTLY_DELETE_TAGS: true
   RESET_CHILD_MANIFEST_EXPIRATION: true

2. In the navigation pane, click Repositories.
3. Click the name of the repository, for example, quayadmin/busybox.
4. Check the box of the image tag that will be deleted, for example, test.

5. Click Actions → Permanently Delete.

   Important

   This action is permanent and cannot be undone.

Procedure

1. Ensure that the PERMANENTLY_DELETE_TAGS and RESET_CHILD_MANIFEST_EXPIRATION parameters are set to true in your config.yaml file. For example:

   PERMANENTLY_DELETE_TAGS: true
   RESET_CHILD_MANIFEST_EXPIRATION: true

2. On the Red Hat Quay UI, click Repositories and the name of the repository that contains the image tag you will delete, for example, quayadmin/busybox.
3. In the navigation pane, click Tags.
4. Check the box of the name of the tag you want to delete, for example, test.
5. Click the Actions drop down menu and select Delete Tags → Delete Tag.
6. Click Tag History in the navigation pane.

7. On the name of the tag that was just deleted, for example, test, click Delete test under the Permanently Delete category. For example:

   Permanently delete image tag

   

   Important

   This action is permanent and cannot be undone.

Procedure

1. Update your config.yaml file to add the DEFAULT_NAMESPACE_AUTOPRUNE_POLICY configuration field:

   1. To set the policy method to remove the oldest tags by their creation date until the number of tags provided is left, use the number_of_tags method:

      # ...
      DEFAULT_NAMESPACE_AUTOPRUNE_POLICY:
        method: number_of_tags
        value: 2 1
      # ...

      1

      In this scenario, two tags remain.

   2. To set the policy method to remove tags with a creation date older than the provided time span, for example, 5d, use the creation_date method:

      DEFAULT_NAMESPACE_AUTOPRUNE_POLICY:
        method: creation_date
        value: 5d

2. Restart your Red Hat Quay deployment.

3. Optional. If you need to tag and push images to test this feature:

   1. Tag four sample images that will be pushed to a Red Hat Quay registry. For example:

      $ podman tag docker.io/library/busybox <quay-server.example.com>/<quayadmin>/busybox:test

      $ podman tag docker.io/library/busybox <quay-server.example.com>/<quayadmin>/busybox:test2

      $ podman tag docker.io/library/busybox <quay-server.example.com>/<quayadmin>/busybox:test3

      $ podman tag docker.io/library/busybox <quay-server.example.com>/<quayadmin>/busybox:test4

   2. Push the four sample images to the registry with auto-pruning enabled by entering the following commands:

      $ podman push <quay-server.example.com>/quayadmin/busybox:test

      $ podman push <quay-server.example.com>/<quayadmin>/busybox:test2

      $ podman push <quay-server.example.com>/<quayadmin>/busybox:test3

      $ podman push <quay-server.example.com>/<quayadmin>/busybox:test4

4. Check that there are four tags in the registry that you pushed the images to.
5. By default, the auto-pruner worker at the registry level runs every 24 hours. After 24 hours, the two oldest image tags are removed, leaving the test3 and test4 tags if you followed these instructions. Check your Red Hat Quay organization to ensure that the two oldest tags were removed.

Procedure

1. Tag four sample images, for example, busybox, that will be pushed to the repository with auto-pruning enabled. For example:

   $ podman tag docker.io/library/busybox <quay-server.example.com>/<quayadmin>/busybox:test

   $ podman tag docker.io/library/busybox <quay-server.example.com>/<quayadmin>/busybox:test2

   $ podman tag docker.io/library/busybox <quay-server.example.com>/<quayadmin>/busybox:test3

   $ podman tag docker.io/library/busybox <quay-server.example.com>/<quayadmin>/busybox:test4

2. Push the four sample images, for example, busybox, to the repository with auto-pruning enabled by entering the following commands:

   $ podman push <quay-server.example.com>/quayadmin/busybox:test

   $ podman push <quay-server.example.com>/<quayadmin>/busybox:test2

   $ podman push <quay-server.example.com>/<quayadmin>/busybox:test3

   $ podman push <quay-server.example.com>/<quayadmin>/busybox:test4

3. Check that there are four tags in your repository.
4. On the Red Hat Quay v2 UI, click Organizations in the navigation pane.
5. Select the name of an organization that you will apply the auto-pruning feature to, for example, test_organization.
6. Click Settings.

7. Click Auto-Prune Policies. For example:

   

8. Click the drop down menu and select the desired policy, for example, By number of tags.
9. Select the desired number of tags to keep. By default, this is set at 20 tags. For this example, the number of tags to keep is set at 3.
10. Click Save. A notification that your auto-prune policy has been updated appears.

Procedure

1. Enter the following POST command create a new policy that limits the number of tags allowed in an organization:

   $ curl -X POST -H "Authorization: Bearer <access_token>" -H "Content-Type: application/json" -d '{"method": "number_of_tags", "value": 10}' http://<quay-server.example.com>/api/v1/organization/<organization_name>/autoprunepolicy/

   Alternatively, you can can set tags to expire for a specified time after their creation date:

   $ curl -X POST -H "Authorization: Bearer <access_token>" -H "Content-Type: application/json" -d '{
   "method": "creation_date", "value": "7d"}' http://<quay-server.example.com>/api/v1/organization/<organization_name>/autoprunepolicy/

   Example output

   {"uuid": "73d64f05-d587-42d9-af6d-e726a4a80d6e"}

   Attempting to create multiple policies returns the following error:

   {"detail": "Policy for this namespace already exists, delete existing to create new policy", "error_message": "Policy for this namespace already exists, delete existing to create new policy", "error_type": "invalid_request", "title": "invalid_request", "type": "http://<quay-server.example.com>/api/v1/error/invalid_request", "status": 400}

2. Check your auto-prune policy by entering the following command:

   $ curl -X GET -H "Authorization: Bearer <access_token>" http://<quay-server.example.com>/api/v1/organization/<organization_name>/autoprunepolicy/

   Example output

   {"policies": [{"uuid": "73d64f05-d587-42d9-af6d-e726a4a80d6e", "method": "creation_date", "value": "7d"}]}

3. You can delete the auto-prune policy by entering the following command. Note that deleting the policy requires the UUID.

   $ curl -X DELETE -H "Authorization: Bearer <access_token>" http://<quay-server.example.com>/api/v1/organization/<organization_name>/autoprunepolicy/73d64f05-d587-42d9-af6d-e726a4a80d6e

Procedure

1. Enter the following POST command create a new policy that limits the number of tags for the current user:

   $ curl -X POST -H "Authorization: Bearer <access_token>" -H "Content-Type: application/json" -d '{"method": "number_of_tags", "value": 10}' http://<quay-server.example.com>/api/v1/<user>/autoprunepolicy/

   Example output

   {"uuid": "8c03f995-ca6f-4928-b98d-d75ed8c14859"}

2. Check your auto-prune policy by entering the following command:

   $ curl -X GET -H "Authorization: Bearer <access_token>" http://<quay-server.example.com>/api/v1/<user>/autoprunepolicy/8c03f995-ca6f-4928-b98d-d75ed8c14859

   Alternatively, you can include the UUID:

   $ curl -X GET -H "Authorization: Bearer <access_token>" http://<quay-server.example.com>/api/v1/<user>/autoprunepolicy/

   Example output

   {"policies": [{"uuid": "8c03f995-ca6f-4928-b98d-d75ed8c14859", "method": "number_of_tags", "value": 10}]}

3. You can delete the auto-prune policy by entering the following command. Note that deleting the policy requires the UUID.

   $ curl -X DELETE -H "Authorization: Bearer <access_token>" http://<quay-server.example.com>/api/v1/<user>/autoprunepolicy/8c03f995-ca6f-4928-b98d-d75ed8c14859

   Example output

   {"uuid": "8c03f995-ca6f-4928-b98d-d75ed8c14859"}

Procedure

1. Tag four sample images, for example, busybox, that will be pushed to the repository with auto-pruning enabled. For example:

   $ podman tag docker.io/library/busybox <quay-server.example.com>/<organization_name>/<repository_name>:test

   $ podman tag docker.io/library/busybox <quay-server.example.com>/<organization_name>/<repository_name>:test2

   $ podman tag docker.io/library/busybox <quay-server.example.com>/<organization_name>/<repository_name>:test3

   $ podman tag docker.io/library/busybox <quay-server.example.com>/<organization_name>/<repository_name>:test4

2. Push the four sample images, for example, busybox, to the repository with auto-pruning enabled by entering the following commands:

   $ podman push <quay-server.example.com>/<organization_name>/<repository_name>:test

   $ podman push <quay-server.example.com>/<organization_name>/<repository_name>:test2

   $ podman push <quay-server.example.com>/<organization_name>/<repository_name>:test3

   $ podman push <quay-server.example.com>/<organization_name>/<repository_name>:test4

3. Check that there are four tags in your repository.
4. On the Red Hat Quay v2 UI, click Repository in the navigation pane.
5. Select the name of an organization that you will apply the auto-pruning feature to, for example, <organization_name>/<repository_name>.
6. Click Settings.
7. Click Repository Auto-Prune Policies.
8. Click the drop down menu and select the desired policy, for example, By number of tags.
9. Select the desired number of tags to keep. By default, this is set at 20 tags. For this example, the number of tags to keep is set at 3.
10. Click Save. A notification that your auto-prune policy has been updated appears.

Procedure

1. Enter the following POST command create a new policy that limits the number of tags allowed in an organization:

   $ curl -X POST -H "Authorization: Bearer <access_token>" -H "Content-Type: application/json" -d '{"method": "number_of_tags","value": 2}' http://<quay-server.example.com>/api/v1/repository/<organization_name>/<repository_name>/autoprunepolicy/

   Alternatively, you can can set tags to expire for a specified time after their creation date:

   $ curl -X POST -H "Authorization: Bearer <access_token>" -H "Content-Type: application/json" -d '{"method": "creation_date", "value": "7d"}' http://<quay-server.example.com>/api/v1/repository/<organization_name>/<repository_name>/autoprunepolicy/

   Example output

   {"uuid": "ce2bdcc0-ced2-4a1a-ac36-78a9c1bed8c7"}

   Attempting to create multiple policies returns the following error:

   {"detail": "Policy for this namespace already exists, delete existing to create new policy", "error_message": "Policy for this namespace already exists, delete existing to create new policy", "error_type": "invalid_request", "title": "invalid_request", "type": "http://quay-server.example.com/api/v1/error/invalid_request", "status": 400}

2. Check your auto-prune policy by entering the following command:

   $ curl -X GET -H "Authorization: Bearer <access_token>" http://<quay-server.example.com>/api/v1/repository/<organization_name>/<repository_name>/autoprunepolicy/

   Alternatively, you can include the UUID:

   $ curl -X GET -H "Authorization: Bearer <access_token>" http://<quay-server.example.com>/api/v1/repository/<organization_name>/<repository_name>/autoprunepolicy/ce2bdcc0-ced2-4a1a-ac36-78a9c1bed8c7

   Example output

   {"policies": [{"uuid": "ce2bdcc0-ced2-4a1a-ac36-78a9c1bed8c7", "method": "number_of_tags", "value": 10}]}

3. You can delete the auto-prune policy by entering the following command. Note that deleting the policy requires the UUID.

   $ curl -X DELETE -H "Authorization: Bearer <access_token>" http://<quay-server.example.com>/api/v1/repository/<organization_name>/<repository_name>/autoprunepolicy/ce2bdcc0-ced2-4a1a-ac36-78a9c1bed8c7

   Example output

   {"uuid": "ce2bdcc0-ced2-4a1a-ac36-78a9c1bed8c7"}

Procedure

1. Enter the following POST command create a new policy that limits the number of tags for the current user:

   $ curl -X POST -H "Authorization: Bearer <access_token>" -H "Content-Type: application/json" -d '{"method": "number_of_tags","value": 2}' http://<quay-server.example.com>/api/v1/repository/<user_account>/<user_repository>/autoprunepolicy/

   Example output

   {"uuid": "7726f79c-cbc7-490e-98dd-becdc6fefce7"}

2. Check your auto-prune policy by entering the following command:

   $ curl -X GET -H "Authorization: Bearer <access_token>" http://<quay-server.example.com>/api/v1/repository/<user_account>/<user_repository>/autoprunepolicy/

   Alternatively, you can include the UUID:

   $ curl -X GET -H "Authorization: Bearer <access_token>" http://<quay-server.example.com>/api/v1/repository/<user_account>/<user_repository>/autoprunepolicy/7726f79c-cbc7-490e-98dd-becdc6fefce7

   Example output

   {"policies": [{"uuid": "7726f79c-cbc7-490e-98dd-becdc6fefce7", "method": "number_of_tags", "value": 2}]}

3. You can delete the auto-prune policy by entering the following command. Note that deleting the policy requires the UUID.

   $ curl -X DELETE -H "Authorization: Bearer <access_token>" http://<quay-server.example.com>/api/v1/user/autoprunepolicy/7726f79c-cbc7-490e-98dd-becdc6fefce7

   Example output

   {"uuid": "7726f79c-cbc7-490e-98dd-becdc6fefce7"}

Procedure

1. Update your config.yaml file to include the storage engines to which data will be replicated. You must list all storage engines to be used:

   # ...
   FEATURE_STORAGE_REPLICATION: true
   # ...
   DISTRIBUTED_STORAGE_CONFIG:
       usstorage:
           - RHOCSStorage
           - access_key: <access_key>
             bucket_name: <example_bucket>
             hostname: my.noobaa.hostname
             is_secure: false
             port: "443"
             secret_key: <secret_key>
             storage_path: /datastorage/registry
       eustorage:
           - S3Storage
           - host: s3.amazon.com
             port: "443"
             s3_access_key: <access_key>
             s3_bucket: <example bucket>
             s3_secret_key: <secret_key>
             storage_path: /datastorage/registry
   DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
   DISTRIBUTED_STORAGE_PREFERENCE:
       - usstorage
       - eustorage
   # ...

2. Optional. If complete replication of all images to all storage engines is required, you can replicate images to the storage engine by manually setting the DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS field. This ensures that all images are replicated to that storage engine. For example:

   # ...
   DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS:
       - usstorage
       - eustorage
   # ...

   Note

   To enable per-namespace replication, contact Red Hat Quay support.

3. After adding storage and enabling Replicate to storage engine by default for geo-replication, you must sync existing image data across all storage. To do this, you must execute into the container by running the following command:

   $ podman exec -it <container_id>

4. To sync the content after adding new storage, enter the following commands:

   # scl enable python27 bash

   # python -m util.backfillreplication

   Note

   This is a one time operation to sync content after adding new storage.

1. Copy the config.yaml to all machines running Red Hat Quay

2. For each machine in each region, add a QUAY_DISTRIBUTED_STORAGE_PREFERENCE environment variable with the preferred storage engine for the region in which the machine is running.

   For example, for a machine running in Europe with the config directory on the host available from $QUAY/config:

   $ sudo podman run -d --rm -p 80:8080 -p 443:8443  \
      --name=quay \
      -v $QUAY/config:/conf/stack:Z \
      -e QUAY_DISTRIBUTED_STORAGE_PREFERENCE=europestorage \
      registry.redhat.io/quay/quay-rhel8:v3.12.4

   Note

   The value of the environment variable specified must match the name of a Location ID as defined in the config panel.

3. Restart all Red Hat Quay containers

Procedure

1. Sync the blobs between all of your defined sites by running the following command:

   $ python -m util.backfillreplication

   Warning

   Prior to removing storage engines from your Red Hat Quay config.yaml file, you must ensure that all blobs are synced between all defined sites. Complete this step before proceeding.

2. In your Red Hat Quay config.yaml file for site usstorage, remove the DISTRIBUTED_STORAGE_CONFIG entry for the eustorage site.

3. Enter the following command to obtain a list of running containers:

   $ podman ps

   Example output

   CONTAINER ID  IMAGE                                                                     COMMAND         CREATED         STATUS             PORTS                                        NAMES
   92c5321cde38  registry.redhat.io/rhel8/redis-5:1                                        run-redis       11 days ago     Up 11 days ago     0.0.0.0:6379->6379/tcp                       redis
   4e6d1ecd3811  registry.redhat.io/rhel8/postgresql-13:1-109                              run-postgresql  33 seconds ago  Up 34 seconds ago  0.0.0.0:5432->5432/tcp                       postgresql-quay
   d2eadac74fda  registry-proxy.engineering.redhat.com/rh-osbs/quay-quay-rhel8:v3.9.0-131  registry        4 seconds ago   Up 4 seconds ago   0.0.0.0:80->8080/tcp, 0.0.0.0:443->8443/tcp  quay

4. Enter the following command to execute a shell inside of the PostgreSQL container:

   $ podman exec -it postgresql-quay -- /bin/bash

5. Enter psql by running the following command:

   bash-4.4$ psql

6. Enter the following command to reveal a list of sites in your geo-replicated deployment:

   quay=# select * from imagestoragelocation;

   Example output

    id |       name
   ----+-------------------
     1 | usstorage
     2 | eustorage

7. Enter the following command to exit the postgres CLI to re-enter bash-4.4:

   \q

8. Enter the following command to permanently remove the eustorage site:

   Important

   The following action cannot be undone. Use with caution.

   bash-4.4$ python -m util.removelocation eustorage

   Example output

   WARNING: This is a destructive operation. Are you sure you want to remove eustorage from your storage locations? [y/n] y
   Deleted placement 30
   Deleted placement 31
   Deleted placement 32
   Deleted placement 33
   Deleted location eustorage

Procedure

1. Deploy a postgres instance for Red Hat Quay.

2. Login to the database by entering the following command:

   psql -U <username> -h <hostname> -p <port> -d <database_name>

3. Create a database for Red Hat Quay named quay. For example:

   CREATE DATABASE quay;

4. Enable pg_trm extension inside the database

   \c quay;
   CREATE EXTENSION IF NOT EXISTS pg_trgm;

5. Deploy a Redis instance:

   Note
   • Deploying a Redis instance might be unnecessary if your cloud provider has its own service.
   • Deploying a Redis instance is required if you are leveraging Builders.
   1. Deploy a VM for Redis
   2. Verify that it is accessible from the clusters where Red Hat Quay is running
   3. Port 6379/TCP must be open

   4. Run Redis inside the instance

      sudo dnf install -y podman
      podman run -d --name redis -p 6379:6379 redis

6. Create two object storage backends, one for each cluster. Ideally, one object storage bucket will be close to the first, or primary, cluster, and the other will run closer to the second, or secondary, cluster.
7. Deploy the clusters with the same config bundle, using environment variable overrides to select the appropriate storage backend for an individual cluster.
8. Configure a load balancer to provide a single entry point to the clusters.

Procedure

1. Sync the blobs between all of your defined sites by running the following command:

   $ python -m util.backfillreplication

   Warning

   Prior to removing storage engines from your Red Hat Quay config.yaml file, you must ensure that all blobs are synced between all defined sites.

   When running this command, replication jobs are created which are picked up by the replication worker. If there are blobs that need replicated, the script returns UUIDs of blobs that will be replicated. If you run this command multiple times, and the output from the return script is empty, it does not mean that the replication process is done; it means that there are no more blobs to be queued for replication. Customers should use appropriate judgement before proceeding, as the allotted time replication takes depends on the number of blobs detected.

   Alternatively, you could use a third party cloud tool, such as Microsoft Azure, to check the synchronization status.

   This step must be completed before proceeding.

2. In your Red Hat Quay config.yaml file for site usstorage, remove the DISTRIBUTED_STORAGE_CONFIG entry for the eustorage site.

3. Enter the following command to identify your Quay application pods:

   $ oc get pod -n <quay_namespace>

   Example output

   quay390usstorage-quay-app-5779ddc886-2drh2
   quay390eustorage-quay-app-66969cd859-n2ssm

4. Enter the following command to open an interactive shell session in the usstorage pod:

   $ oc rsh quay390usstorage-quay-app-5779ddc886-2drh2

5. Enter the following command to permanently remove the eustorage site:

   Important

   The following action cannot be undone. Use with caution.

   sh-4.4$ python -m util.removelocation eustorage

   Example output

   WARNING: This is a destructive operation. Are you sure you want to remove eustorage from your storage locations? [y/n] y
   Deleted placement 30
   Deleted placement 31
   Deleted placement 32
   Deleted placement 33
   Deleted location eustorage

Procedure

1. If your Red Hat Quay registry is readily available, you can generate service keys inside of the Quay registry container.

   1. Enter the following command to generate a key pair inside of the Quay container:

      $ podman exec quay python3 tools/generatekeypair.py quay-readonly

2. If your Red Hat Quay is not readily available, you must generate your service keys inside of a virtual environment.

   1. Change into the directory of your Red Hat Quay deployment and create a virtual environment inside of that directory:

      $ cd <$QUAY>/quay && virtualenv -v venv

   2. Activate the virtual environment by entering the following command:

      $ source venv/bin/activate

   3. Optional. Install the pip CLI tool if you do not have it installed:

      $ venv/bin/pip install --upgrade pip

   4. In your Red Hat Quay directory, create a requirements-generatekeys.txt file with the following content:

      $ cat << EOF > requirements-generatekeys.txt
      cryptography==3.4.7
      pycparser==2.19
      pycryptodome==3.9.4
      pycryptodomex==3.9.4
      pyjwkest==1.4.2
      PyJWT==1.7.1
      Authlib==1.0.0a2
      EOF

   5. Enter the following command to install the Python dependencies defined in the requirements-generatekeys.txt file:

      $ venv/bin/pip install -r requirements-generatekeys.txt

   6. Enter the following command to create the necessary service keys:

      $ PYTHONPATH=. venv/bin/python /<path_to_cloned_repo>/tools/generatekeypair.py quay-readonly

      Example output

      Writing public key to quay-readonly.jwk
      Writing key ID to quay-readonly.kid
      Writing private key to quay-readonly.pem

   7. Enter the following command to deactivate the virtual environment:

      $ deactivate

Procedure

1. Enter the following command to enter your Red Hat Quay database environment:

   $ podman exec -it postgresql-quay psql -U postgres -d quay

2. Display the approval types and associated notes of the servicekeyapproval by entering the following command:

   quay=# select * from servicekeyapproval;

   Example output

    id | approver_id |          approval_type           |       approved_date        | notes
   ----+-------------+----------------------------------+----------------------------+-------
     1 |             | ServiceKeyApprovalType.AUTOMATIC | 2024-05-07 03:47:48.181347 |
     2 |             | ServiceKeyApprovalType.AUTOMATIC | 2024-05-07 03:47:55.808087 |
     3 |             | ServiceKeyApprovalType.AUTOMATIC | 2024-05-07 03:49:04.27095  |
     4 |             | ServiceKeyApprovalType.AUTOMATIC | 2024-05-07 03:49:05.46235  |
     5 |           1 | ServiceKeyApprovalType.SUPERUSER | 2024-05-07 04:05:10.296796 |
   ...

3. Add the service key to your Red Hat Quay database by entering the following query:

   quay=# INSERT INTO servicekey
     (name, service, metadata, kid, jwk, created_date, expiration_date)
     VALUES ('quay-readonly',
              'quay',
              '{}',
              '{<contents_of_.kid_file>}',
              '{<contents_of_.jwk_file>}',
              '{<created_date_of_read-only>}',
              '{<expiration_date_of_read-only>}');

   Example output

   INSERT 0 1

4. Next, add the key approval with the following query:

   quay=# INSERT INTO servicekeyapproval ('approval_type', 'approved_date', 'notes')
     VALUES ("ServiceKeyApprovalType.SUPERUSER", "CURRENT_DATE",
              {include_notes_here_on_why_this_is_being_added});

   Example output

   INSERT 0 1

5. Set the approval_id field on the created service key row to the id field from the created service key approval. You can use the following SELECT statements to get the necessary IDs:

   UPDATE servicekey
   SET approval_id = (SELECT id FROM servicekeyapproval WHERE approval_type = 'ServiceKeyApprovalType.SUPERUSER')
   WHERE name = 'quay-readonly';

   UPDATE 1

Procedure

1. Shutdown all Red Hat Quay instances on all virtual machines. For example:

   $ podman stop <quay_container_name_on_virtual_machine_a>

   $ podman stop <quay_container_name_on_virtual_machine_b>

2. Enter the following command to copy the contents of the quay-readonly.kid file and the quay-readonly.pem file to the directory that holds your Red Hat Quay configuration bundle:

   $ cp quay-readonly.kid quay-readonly.pem $Quay/config

3. Enter the following command to set file permissions on all files in your configuration bundle folder:

   $ setfacl -m user:1001:rw $Quay/config/*

4. Modify your Red Hat Quay config.yaml file and add the following information:

   # ...
   REGISTRY_STATE: readonly
   INSTANCE_SERVICE_KEY_KID_LOCATION: 'conf/stack/quay-readonly.kid'
   INSTANCE_SERVICE_KEY_LOCATION: 'conf/stack/quay-readonly.pem'
   # ...

5. Distribute the new configuration bundle to all Red Hat Quay instances.

6. Start Red Hat Quay by entering the following command:

   $ podman run -d --rm -p 80:8080 -p 443:8443  \
      --name=quay-main-app \
      -v $QUAY/config:/conf/stack:Z \
      -v $QUAY/storage:/datastorage:Z \
      {productrepo}/{quayimage}:{productminv}

7. After starting Red Hat Quay, a banner inside in your instance informs users that Red Hat Quay is running in read-only mode. Pushes should be rejected and a 405 error should be logged. You can test this by running the following command:

   $ podman push <quay-server.example.com>/quayadmin/busybox:test

   Example output

   613be09ab3c0: Preparing
   denied: System is currently read-only. Pulls will succeed but all write operations are currently suspended.

   With your Red Hat Quay deployment on read-only mode, you can safely manage your registry’s operations and perform such actions as backup and restore.

8. Optional. After you are finished with read-only mode, you can return to normal operations by removing the following information from your config.yaml file. Then, restart your Red Hat Quay deployment:

   # ...
   REGISTRY_STATE: readonly
   INSTANCE_SERVICE_KEY_KID_LOCATION: 'conf/stack/quay-readonly.kid'
   INSTANCE_SERVICE_KEY_LOCATION: 'conf/stack/quay-readonly.pem'
   # ...

   $ podman restart <container_id>

Procedure

1. Click Organization in the navigation pane.
2. Click Create Organization.
3. Enter an Organization Name, for example, testorg.
4. Click Create.

Procedure

1. On the Organizations page, select the name of the organization you want to delete, for example, testorg.
2. Click the More Actions drop down menu.

3. Click Delete.

   Note

   On the Delete page, there is a Search input box. With this box, users can search for specific organizations to ensure that they are properly scheduled for deletion. For example, if a user is deleting 10 organizations and they want to ensure that a specific organization was deleted, they can use the Search input box to confirm said organization is marked for deletion.

4. Confirm that you want to permanently delete the organization by typing confirm in the box.

5. Click Delete.

   After deletion, you are returned to the Organizations page.

   Note

   You can delete more than one organization at a time by selecting multiple organizations, and then clicking More Actions → Delete.

Procedure

1. Click Repositories on the navigation pane.
2. Click Create Repository.

3. Select a namespace, for example, quayadmin, and then enter a Repository name, for example, testrepo.

   Important

   Do not use the following words in your repository name: * build * trigger * tag

   When these words are used for repository names, users are unable access the repository, and are unable to permanently delete the repository. Attempting to delete these repositories returns the following error: Failed to delete repository <repository_name>, HTTP404 - Not Found.

4. Click Create.

   Now, your example repository should populate under the Repositories page.

Procedure

1. On the Repositories page of the v2 UI, click the name of the image you want to delete, for example, quay/admin/busybox.
2. Click the More Actions drop-down menu.

3. Click Delete.

   Note

   If desired, you could click Make Public or Make Private.

4. Type confirm in the box, and then click Delete.
5. After deletion, you are returned to the Repositories page.

Procedure

1. Pull a sample image from an external registry:

   $ podman pull busybox

2. Tag the image:

   $ podman tag docker.io/library/busybox quay-server.example.com/quayadmin/busybox:test

3. Push the image to your registry:

   $ podman push quay-server.example.com/quayadmin/busybox:test

4. Navigate to the Repositories page on the v2 UI and ensure that your image has been properly pushed.
5. You can check the security details by selecting your image tag, and then navigating to the Security Report page.

Procedure

1. On the Repositories page of the v2 UI, click the name of the image you want to delete, for example, quay/admin/busybox.
2. Click the More Actions drop-down menu.

3. Click Delete.

   Note

   If desired, you could click Make Public or Make Private.

4. Type confirm in the box, and then click Delete.
5. After deletion, you are returned to the Repositories page.

Procedure

1. On the Red Hat Quay v2 UI, click the name of an organization.
2. On your organization’s page, click Teams and membership.
3. Click the Create new team box.
4. In the Create team popup window, provide a name for your new team.
5. Optional. Provide a description for your new team.
6. Click Proceed. A new popup window appears.
7. Optional. Add this team to a repository, and set the permissions to one of Read, Write, Admin, or None.
8. Optional. Add a team member or robot account. To add a team member, enter the name of their Red Hat Quay account.

9. Review and finish the information, then click Review and Finish. The new team appears under the Teams and membership page. From here, you can click the kebab menu, and select one of the following options:

   • Manage Team Members. On this page, you can view all members, team members, robot accounts, or users who have been invited. You can also add a new team member by clicking Add new member.
   • Set repository permissions. On this page, you can set the repository permissions to one of Read, Write, Admin, or None.
   • Delete. This popup windows allows you to delete the team by clicking Delete.

10. Optional. You can click the one of the following options to reveal more information about teams, members, and collaborators:

    • Team View. This menu shows all team names, the number of members, the number of repositories, and the role for each team.
    • Members View. This menu shows all usernames of team members, the teams that they are part of, the repository permissions of the user.
    • Collaborators View. This menu shows repository collaborators. Collaborators are users that do not belong to any team in the organization, but who have direct permissions on one or more repositories belonging to the organization.

Procedure

1. On the v2 UI, click Organizations.
2. Click the name of the organization that you will create the robot account for, for example, test-org.
3. Click the Robot accounts tab → Create robot account.
4. In the Provide a name for your robot account box, enter a name, for example, robot1.

5. Optional. The following options are available if desired:

   1. Add the robot to a team.
   2. Add the robot to a repository.
   3. Adjust the robot’s permissions.

6. On the Review and finish page, review the information you have provided, then click Review and finish. The following alert appears: Successfully created robot account with robot name: <organization_name> + <robot_name>.

   Alternatively, if you tried to create a robot account with the same name as another robot account, you might receive the following error message: Error creating robot account.

7. Optional. You can click Expand or Collapse to reveal descriptive information about the robot account.
8. Optional. You can change permissions of the robot account by clicking the kebab menu → Set repository permissions. The following message appears: Successfully updated repository permission.
9. Optional. To delete your robot account, check the box of the robot account and click the trash can icon. A popup box appears. Type confirm in the text box, then, click Delete. Alternatively, you can click the kebab menu → Delete. The following message appears: Successfully deleted robot account.

Procedure

1. Click the name of an organization.
2. Click Default permissions.
3. Click create default permissions. A toggle drawer appears.

4. Select either Anyone or Specific user to create a default permission when a repository is created.

   1. If selecting Anyone, the following information must be provided:

      • Applied to. Search, invite, or add a user/robot/team.
      • Permission. Set the permission to one of Read, Write, or Admin.

   2. If selecting Specific user, the following information must be provided:

      • Repository creator. Provide either a user or robot account.
      • Applied to. Provide a username, robot account, or team name.
      • Permission. Set the permission to one of Read, Write, or Admin.
5. Click Create default permission. A confirmation box appears, returning the following alert: Successfully created default permission for creator.

Procedure

1. On the v2 UI, click Organizations.
2. Click the name of the organization that you will create the robot account for, for example, test-org.
3. Click the Settings tab.
4. Optional. Enter the email address associated with the organization.

5. Optional. Set the allotted time for the Time Machine feature to one of the following:

   • 1 week
   • 1 month
   • 1 year
   • Never
6. Click Save.

Procedure

1. On the v2 UI, click Repositories.
2. Click the name of a repository, for example, quayadmin/busybox.

3. Click the name of the tag, for example, test. You are taken to the Details page of the tag. The page reveals the following information:

   • Name
   • Repository
   • Digest
   • Vulnerabilities
   • Creation
   • Modified
   • Size
   • Labels
   • How to fetch the image tag
4. Optional. Click Security Report to view the tag’s vulnerabilities. You can expand an advisory column to open up CVE data.
5. Optional. Click Packages to view the tag’s packages.
6. Click the name of the repository, for example, busybox, to return to the Tags page.
7. Optional. Hover over the Pull icon to reveal the ways to fetch the tag.
8. Check the box of the tag, or multiple tags, click the Actions drop down menu, and then Delete to delete the tag. Confirm deletion by clicking Delete in the popup box.

Procedure

1. On the v2 UI, click Repositories.
2. Click the name of a repository, for example, quayadmin/busybox.
3. Click the Settings tab.
4. Optional. Click User and robot permissions. You can adjust the settings for a user or robot account by clicking the dropdown menu option under Permissions. You can change the settings to Read, Write, or Admin.

5. Optional. Click Events and notifications. You can create an event and notification by clicking Create Notification. The following event options are available:

   • Push to Repository
   • Package Vulnerability Found
   • Image build failed
   • Image build queued
   • Image build started
   • Image build success

   • Image build cancelled

     Then, issue a notification. The following options are available:

   • Email Notification
   • Flowdock Team Notification
   • HipChat Room Notification
   • Slack Notification

   • Webhook POST

     After selecting an event option and the method of notification, include a Room ID #, a Room Notification Token, then, click Submit.

6. Optional. Click Repository visibility. You can make the repository private, or public, by clicking Make Public.
7. Optional. Click Delete repository. You can delete the repository by clicking Delete Repository.