Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove Need for SANs in Provided Cert/Key Pair #406

Merged
merged 1 commit into from
Mar 25, 2021

Conversation

alecmerdler
Copy link
Contributor

@alecmerdler alecmerdler commented Mar 18, 2021

Issue: https://issues.redhat.com/browse/PROJQUAY-1737

Changelog: Remove the need for SANs of internal k8s service hosts in provided cert/key pair for Quay.

Docs: quay/quay-docs#157

Testing: There are a few different situations which must be tested:

Route SERVER_HOSTNAME Custom cert/key pair Expected result
Managed None None Uses generated Route hostname, self-signed certs
Managed None Provided (for generated Route hostname) Uses generated Route hostname and provided certs
Managed None Provided (for random hostname) Blocked rollout, error in status.conditions
Managed registry.company.com Provided (invalid) Blocked rollout, error in status.conditions
Managed registry.company.com None Uses provided hostname and self-signed certs
Managed registry.company.com Provided (valid) Uses provided hostname and certs
Unmanaged None None Error because SERVER_HOSTNAME is unset
Unmanaged None Provided (for random hostname) Error because SERVER_HOSTNAME is unset
Unmanaged registry.company.com None Uses provided hostname and self-signed certs
Unmanaged registry.company.com Provided (invalid) Blocked rollout, error in status.conditions
Unmanaged registry.company.com Provided (valid) Uses provided hostname and provided certs

Details: Most public key infrastructure cannot generate cert/key pairs for the internal Kubernetes Service hostnames (quay.namespace.svc). Previously, the Operator would reject provided certs which did not include these hostnames as Subject Alternative Names (SANs) because they were believed to be needed for TLS connections within the cluster. This is not the case, so this check is removed.

To use a Route with the included OpenShift cluster cert/key pair, mark the route component as managed: false, include SERVER_HOSTNAME as the future generated Route hostname (follows the pattern <route-name>-<namespace>.apps.<cluster>), then create your own Route which points to the Quay app Service and uses re-encrypt TLS termination, with the destinationCACertificate set to the generated tls.cert found in the Secret mounted into the Quay app pods.

@alecmerdler alecmerdler changed the title Remove Need for SANs in Provided Cert/Key Pair [WIP] Remove Need for SANs in Provided Cert/Key Pair Mar 18, 2021
@alecmerdler alecmerdler force-pushed the PROJQUAY-1737 branch 2 times, most recently from b756145 to 015801f Compare March 24, 2021 18:24
@alecmerdler alecmerdler force-pushed the PROJQUAY-1737 branch 7 times, most recently from 38a765c to 0c150b0 Compare March 25, 2021 04:01
@alecmerdler alecmerdler changed the title [WIP] Remove Need for SANs in Provided Cert/Key Pair Remove Need for SANs in Provided Cert/Key Pair Mar 25, 2021
@alecmerdler alecmerdler force-pushed the PROJQUAY-1737 branch 4 times, most recently from 1952296 to acb2b11 Compare March 25, 2021 19:33
@alecmerdler alecmerdler merged commit aba17b8 into quay:master Mar 25, 2021
@alecmerdler alecmerdler deleted the PROJQUAY-1737 branch March 25, 2021 19:37
alecmerdler added a commit to alecmerdler/quay-operator that referenced this pull request May 11, 2021
Backport the fix from (quay#406) to remove the requirement for
provided TLS cert/key pair to be valid for internal k8s
service hostnames as SAN entries.

Signed-off-by: Alec Merdler <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants