Epic Goal

• When using S3 as an object store, Quay is able to use the STS Protocol to authenticate with S3.

Why is this important?

• This request comes from working with a customer who is deploying an on-prem Quay whose S3 store is backed by a on prem Red Hat Ceph system. The customer has positioned STS as the way their user base will authenticate against the Ceph RGW system for all S3 activities.
• STS behind the scenes uses OpenID connect in order to authenticate a user before providing a temporary token to a client application on behalf of the user. When using STS with Ceph no local users are kept within the Ceph system.
• Currently it isn't possible for Quay to use STS which means a Ceph local user must be configured.

Scenarios

1. When running on-prem or in the cloud, Quay is able to use STS in order to facilitate access to AWS S3

Acceptance Criteria

• At startup, the config tool must prevent Quay from running with a bad STS configuration
• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• Docs/release notes have been updated

Dependencies (internal and external)

1. AWS

Previous Work (Optional):

1. TBD

Open questions::

1. TBD

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>