Bug 1720770
Summary: | Instructions for adding default API server default certificate fails to configure serving cert | ||
---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | rvanderp |
Component: | Documentation | Assignee: | Vikram Goyal <vigoyal> |
Status: | CLOSED EOL | QA Contact: | scheng |
Severity: | high | Docs Contact: | Vikram Goyal <vigoyal> |
Priority: | unspecified | ||
Version: | 4.1.0 | CC: | ansverma, aos-bugs, chuffman, deads, eparis, jokerman, mfojtik, mmccomas, mtaru, rhowe, wsun |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-05-18 06:56:53 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
rvanderp
2019-06-14 21:33:58 UTC
Do we even do anything with this secret expect for take the name, and set the observed servinginfo fields for the kubeapiserver CR servingInfo: certFile: /etc/kubernetes/static-pod-certs/secrets/user-serving-cert/tls.crt keyFile: /etc/kubernetes/static-pod-certs/secrets/user-serving-cert/tls.key Only function I see is "observeDefaultUserServingCertificate" that does any thing the secret set for defaultServingCertificate in the apiserver CR. https://github.com/openshift/cluster-kube-apiserver-operator cluster-kube-apiserver-operator -- pkg/operator/configobservation/apiserver/observe_apiserver.go After discussion with engineering this is not a docs bug. Reassigning to Master. This setting is inherently dangerous because we rely on the default serving cert to have critical IPs included in valid names to allow the service network to continue to function. Customers should instead use the SNI capabilities we have to provide their certificates. Because it didn't work and carries a lot of risk, we are going to remove this setting entirely, starting in https://github.com/openshift/cluster-kube-apiserver-operator/pull/518 . You should use the SNI configuration instead. @Anshul Verma You seem to have crossed bugs. This bug is about the default serving cert. Do you have a bug open for setting SNI certificates that we've missed? Also, if you do, be sure to add must-gather information. As noted in comment 4, you should use SNI configuration. If that fails, please open a different bug and attach must-gather output. You should remove your default serving certificate configuration entirely. This one here https://docs.openshift.com/container-platform/4.1/authentication/certificates/api-server.html#api-server-certificates linked from the apiserver section of https://docs.openshift.com/container-platform/4.1/installing/install_config/customizations.html should help you through it. Can you write up a bug for the SNI configuration issue and attach must-gather to it? This definitely fixed the default serving cert problem, if we have a different issue we need the configuration and various configmaps, etc to chase it down. This bug is about " Instructions for adding default API server default certificate fails to configure serving cert". We fixed the bug in https://github.com/openshift/openshift-docs/pull/15642 by removing that doc entirely and in https://github.com/openshift/cluster-kube-apiserver-operator/pull/518 by not honoring the setting. For SNI, we'll want the requested gather on a new bug. for completeness, must-gather linked in the case shows a healthy clusteroperator/kube-apiserver and three healthy kube-apiserver pods. This bug was fixed in 4.1 documentation, no code changes merged to payload. The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days |