Bug 1883790 - revert "force cert rotation every couple days for development" in 4.7
Summary: revert "force cert rotation every couple days for development" in 4.7
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: kube-apiserver
Version: 4.6
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: ---
: 4.7.0
Assignee: Stefan Schimanski
QA Contact: Ke Wang
URL:
Whiteboard: LifecycleFrozen
Depends On: 1926123
Blocks: 1921139
TreeView+ depends on / blocked
 
Reported: 2020-09-30 09:12 UTC by Stefan Schimanski
Modified: 2021-06-08 11:32 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of: 1840116
: 1921139 1925446 1926123 (view as bug list)
Environment:
Last Closed: 2021-02-24 15:21:54 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift cluster-kube-apiserver-operator pull 1037 0 None closed Bug 1883790: Revert "force cert rotation every couple days for development: aggregator-client-signer" 2021-02-18 01:18:23 UTC
Red Hat Product Errata RHSA-2020:5633 0 None None None 2021-02-24 15:22:21 UTC

Comment 1 Michal Fojtik 2020-10-30 10:12:07 UTC
This bug hasn't had any activity in the last 30 days. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're marking this bug as "LifecycleStale" and decreasing the severity/priority. If you have further information on the current state of the bug, please update it, otherwise this bug can be closed in about 7 days. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. Additionally, you can add LifecycleFrozen into Keywords if you think this bug should never be marked as stale. Please consult with bug assignee before you do that.

Comment 4 Xingxing Xia 2021-02-10 07:50:25 UTC
Tested in fresh env:
$ oc get clusterversion
version   4.7.0-0.nightly-2021-02-09-192846   True        False         87m     Cluster version is 4.7.0-0.nightly-2021-02-09-192846


$ cat scripts/check_secret_expiry_within.sh
#!/bin/bash
# usage: ./check_secret_expiry_within.sh 1day # or 15min, 2days, 2day, 2month, 1year
WITHIN=${1:-24hours}
echo "Checking validity within $WITHIN ..."
oc get secret --insecure-skip-tls-verify -A -o json | jq -r '.items[] | select(.metadata.annotations."auth.openshift.io/certificate-not-after" | . != null and fromdateiso8601<='$( date --date="+$WITHIN" +%s )') | "\(.metadata.annotations."auth.openshift.io/certificate-not-before")  \(.metadata.annotations."auth.openshift.io/certificate-not-after")  \(.metadata.namespace)\t\(.metadata.name)"'

$ scripts/check_secret_expiry_within.sh 
Checking validity within 24hours ...
2021-02-10T05:40:16Z  2021-02-11T05:40:16Z  openshift-kube-apiserver-operator   aggregator-client-signer
2021-02-10T05:52:50Z  2021-02-11T05:40:16Z  openshift-kube-apiserver    aggregator-client
2021-02-10T05:52:40Z  2021-02-11T05:40:18Z  openshift-kube-controller-manager-operator  csr-signer
2021-02-10T05:40:18Z  2021-02-11T05:40:18Z  openshift-kube-controller-manager-operator  csr-signer-signer

$ scripts/check_secret_expiry_within.sh 30day
Checking validity within 30day ...
2021-02-10T05:52:47Z  2021-03-12T05:52:48Z  openshift-config-managed    kube-controller-manager-client-cert-key
2021-02-10T05:52:47Z  2021-03-12T05:52:48Z  openshift-config-managed    kube-scheduler-client-cert-key
2021-02-10T05:40:16Z  2021-02-11T05:40:16Z  openshift-kube-apiserver-operator   aggregator-client-signer
2021-02-10T05:52:50Z  2021-02-11T05:40:16Z  openshift-kube-apiserver    aggregator-client
2021-02-10T05:52:50Z  2021-03-12T05:52:51Z  openshift-kube-apiserver    check-endpoints-client-cert-key
2021-02-10T05:52:49Z  2021-03-12T05:52:50Z  openshift-kube-apiserver    control-plane-node-admin-client-cert-key
2021-02-10T05:52:49Z  2021-03-12T05:52:50Z  openshift-kube-apiserver    external-loadbalancer-serving-certkey
2021-02-10T05:52:50Z  2021-03-12T05:52:51Z  openshift-kube-apiserver    internal-loadbalancer-serving-certkey
2021-02-10T05:52:50Z  2021-03-12T05:52:51Z  openshift-kube-apiserver    kubelet-client
2021-02-10T05:52:50Z  2021-03-12T05:52:51Z  openshift-kube-apiserver    localhost-serving-cert-certkey
2021-02-10T05:52:49Z  2021-03-12T05:52:50Z  openshift-kube-apiserver    service-network-serving-certkey
2021-02-10T05:52:40Z  2021-02-11T05:40:18Z  openshift-kube-controller-manager-operator  csr-signer
2021-02-10T05:40:18Z  2021-02-11T05:40:18Z  openshift-kube-controller-manager-operator  csr-signer-signer
2021-02-10T05:52:47Z  2021-03-12T05:52:48Z  openshift-kube-controller-manager   kube-controller-manager-client-cert-key
2021-02-10T05:52:47Z  2021-03-12T05:52:48Z  openshift-kube-scheduler    kube-scheduler-client-cert-key

The certs' rotation time (i.e. expiry) is not the intentionally-shortened 12h, rather, is reverted to normal time (24h or 30d) now before release

Comment 5 Praveen Kumar 2021-02-10 08:17:55 UTC
@Xingxing Is it also part of rc.0 bits which is available on http://mirror.openshift.com/pub/openshift-v4/clients/ocp/4.7.0-rc.0/ ?

Comment 6 Xingxing Xia 2021-02-10 08:54:39 UTC
@Praveen Kumar, this is server side change, instead of "clients". It landed only since https://openshift-release.apps.ci.l2s4.p1.openshiftapps.com/releasestream/4.7.0-0.nightly/release/4.7.0-0.nightly-2021-02-09-003138 , while https://openshift-release.apps.ci.l2s4.p1.openshiftapps.com/releasestream/4-stable/release/4.7.0-rc.0 "was created from registry.ci.openshift.org/ocp/release:4.7.0-0.nightly-2021-02-06-084550". So 4.7.0-rc.0 does not include it.

Comment 9 errata-xmlrpc 2021-02-24 15:21:54 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: OpenShift Container Platform 4.7.0 security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:5633


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