Bug 1734796 - BYOR `/etc/kubernetes/ca.crt` is not managed/updated
Summary: BYOR `/etc/kubernetes/ca.crt` is not managed/updated
Status: CLOSED DUPLICATE of bug 1721586
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Installer
Version: 4.2.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 4.4.0
Assignee: Jeremiah Stuever
QA Contact: Johnny Liu
Depends On:
TreeView+ depends on / blocked
Reported: 2019-07-31 13:25 UTC by Scott Dodson
Modified: 2019-12-10 19:08 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-12-10 19:08:06 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Scott Dodson 2019-07-31 13:25:36 UTC
This bug was initially created as a copy of Bug #1721586

I am copying this bug because: We need to make sure that we account for this in BYOR nodes which may not be using the workers machineconfigpool. Hosts in that machineconfigpool will apply the change already either if MCD is running or if an upgrade playbook is run.

For hosts not in that MCP we need to pull the CA out of the cluster and update it when upgrading hosts. It'd also be nice if there were a standalone playbook to complete the same.

Description of problem:

`/etc/kubernetes/ca.crt` is not managed, yet looking at the default content it contains:

- root-ca (10y)
- admin-kubeconfig-signer (10y)
- kubelet-signer (1d)
- kube-control-plane-signer (1y)
- kube-apiserver-to-kubelet-signer (1y)
- kubelet-bootstrap-kubeconfig-signer (10y)

If `kube-apiserver-to-kubelet-signer` is rotated, `/etc/kubernetes/ca.crt` requires update or logs won't work.

I am not sure which of these CAs in the bundle is actually used but if it is also another one then the `kube-apiserver-to-kubelet-signer`
this recovery step (from https://docs.openshift.com/container-platform/4.1/disaster_recovery/scenario-3-expired-certs.html)

`oc get configmap kube-apiserver-to-kubelet-client-ca -n openshift-kube-apiserver-operator --template='{{ index .data "ca-bundle.crt" }}' > /etc/kubernetes/ca.crt`

is probably not a great way to solve it as it wipes the other ones.

Also when the cert is rotated in normal flow (which might be about 1/2 of a year) logs will stop working.

Setting to urgent as the suspected outcome is logs stopping to work. Feel free to adjust if this proves not to be the case, but I have force rotated the `kube-apiserver-to-kubelet-signer` and logs stopped working until executing the above mentioned recovery step.

Note You need to log in before you can comment on or make changes to this bug.