On this page
Source - Red Hat Quay 3.17 Usage
Overview
Red Hat usage documentation describes Quay tenancy, organizations, repositories, teams, robot accounts, default permissions, tag expiration, immutable tags, usage logs, Clair security scans, and OCI artifacts.
Context
This source informs the consumer-facing service model for registry and Red Hat Quay. It is used to define namespace governance, access patterns, robot-account use, and evidence requirements for promoted images and artifacts.
Decisions
RWS architecture implications derived from this source:
- Model tenants as Quay organizations with teams and repository permissions, not as unmanaged shared repositories.
- Use robot accounts for automation and prefer short-lived federation where the target IAM integration supports it.
- Keep robot accounts available for controlled mirroring; disabling robot accounts breaks Quay repository mirroring workflows.
- Use immutable tags and tag-expiration policies as registry controls, while enforcing promotion and trust policy outside Quay where admission control is required.
- Treat Clair scan results as evidence and visibility; deployment blocking still belongs to platform policy and release governance.
Current State
The source supports the consumer contract in the solution architecture. It does not specify RWS tenant naming, repository naming, tenant-facing endpoint placement, retention classes, or policy thresholds.
References
- Use Red Hat Quay, version 3.17: Red Hat documentation
- Relevant sections: tenancy model, robot accounts, access management, image tags, immutable tags, logs, Clair scans, OCI artifacts, and API use.
Future Work
- Define organization naming, default team roles, retention classes, and tenant onboarding evidence during service onboarding.
- Record release-promotion controls when the signing and policy engine baseline is selected.