This change updates the CSR API to add a new, optional field called
expirationSeconds. This field is a request to the signer for the
maximum duration the client wishes the cert to have. The signer is
free to ignore this request based on its own internal policy. The
signers built-in to KCM will honor this field if it is not set to a
value greater than --cluster-signing-duration. The minimum allowed
value for this field is 600 seconds (ten minutes).
This change will help enforce safer durations for certificates in
the Kube ecosystem and will help related projects such as
cert-manager with their migration to the Kube CSR API.
Future enhancements may update the Kubelet to take advantage of this
field when it is configured in a way that can tolerate shorter
certificate lifespans with regular rotation.
Signed-off-by: Monis Khan <mok@vmware.com>
Kubernetes-commit: cd91e59f7c351fce47c064a5162c2cb79075159c
Kubelet cert rotation involves two certificate manager instances
(one for client and one for server certs) and the log lines are
identical and confusing. Since certificate manager is a utility
library it is also inappropriate to simply assume klog output is
sufficient.
certificate.Manager now accepts a Name and Logf function on its
config struct to identify the purpose of the manager and to
provide a way to redirect where output should go. If Name is
absent, the name is defaulted from the SignerName, and if that
is not found then the name is set to "client auth" if that is
a provided key usage, or "certificate" otherwise. If Logf is
not provided it defaults to klog.V(2). as today. The name is printed
in "foo: bar" form on every line, but can be converted to structured
logging in the future. The log level is not customizable and it
is up to the caller to decide whether that is an issue.
Some log messages are slightly cleaned up to more clearly indicate
their intent. One log message is removed in a utility function that
was already at v(4) and less likely to be needed.
The default behavior of the certificate manager is as before and
the kubelet now identifies the server and client signerName as
separate entities:
I0414 19:07:33.590419 1539 certificate_manager.go:263] kubernetes.io/kube-apiserver-client-kubelet: Rotating certificates
E0414 19:07:33.594154 1539 certificate_manager.go:464] kubernetes.io/kube-apiserver-client-kubelet: Failed while requesting a signed certificate from the master: cannot create certificate signing request: Post "https://...
Kubernetes-commit: 64c669bd0ac8fda39ba97f48ef887ac1f77fb014
This package contains public/private key utilities copied directly from
client-go/util/cert. All imports were updated.
Future PRs will actually refactor the libraries.
Updates #71004
Kubernetes-commit: 18458392ca24c85c688e655aace1afd04f864cbd
This reverts commit 0af19875add7deb562b2cf7bf6b1d273c44bab1b.
Revert "Ensure the bootstrap rotation code is tested by forcing rotation"
This reverts commit de293b2d7ddb687850258370f2a7f30f224f0ec1.
Kubernetes-commit: 34642222676640b3c1dd255cc453000f2743ccde
Expose both a Stop() method (for cleanup) and a method to force
cert rotation, but only expose Stop() on the interface.
Verify that we choose the correct client.
Kubernetes-commit: de293b2d7ddb687850258370f2a7f30f224f0ec1
Ensure that bootstrap+clientcert-rotation in the Kubelet can:
1. happen in the background so that static pods aren't blocked by bootstrap
2. collapse down to a single call path for requesting a CSR
3. reorganize the code to allow future flexibility in retrieving bootstrap creds
Fetching the first certificate and later certificates when the kubelet
is using client rotation and bootstrapping should share the same code
path. We also want to start the Kubelet static pod loop before
bootstrapping completes. Finally, we want to take an incremental step
towards improving how the bootstrap credentials are loaded from disk
(potentially allowing for a CLI call to get credentials, or a remote
plugin that better integrates with cloud providers or KSMs).
Reorganize how the kubelet client config is determined. If rotation is
off, simplify the code path. If rotation is on, load the config
from disk, and then pass that into the cert manager. The cert manager
creates a client each time it tries to request a new cert.
Preserve existing behavior where:
1. bootstrap kubeconfig is used if the current kubeconfig is invalid/expired
2. we create the kubeconfig file based on the bootstrap kubeconfig, pointing to
the location that new client certs will be placed
3. the newest client cert is used once it has been loaded
Kubernetes-commit: 0af19875add7deb562b2cf7bf6b1d273c44bab1b
This func is only used by the kubelet and there's no need to pollute
client-go API with it.
Kubernetes-commit: 5c073abfe16fc0b9f62310b8276fc3b0c7043e60
This func is only used internally and was copied from
k8s.io/kubernetes/pkg/apis/certificates.
Kubernetes-commit: 41334cfdd3eefc352536943518ffd9eaf570e27c
- Move from the old github.com/golang/glog to k8s.io/klog
- klog as explicit InitFlags() so we add them as necessary
- we update the other repositories that we vendor that made a similar
change from glog to klog
* github.com/kubernetes/repo-infra
* k8s.io/gengo/
* k8s.io/kube-openapi/
* github.com/google/cadvisor
- Entirely remove all references to glog
- Fix some tests by explicit InitFlags in their init() methods
Change-Id: I92db545ff36fcec83afe98f550c9e630098b3135
Kubernetes-commit: 954996e231074dc7429f7be1256a579bedd8344c
With the current behavior, when kubelet starts, a `templateChanged`
event is always fired off because it only checks if `getLastRequest`
matches `getTemplate`. The last request only exists in memory and thus
is initially `nil` and can't ever match the current template during
startup.
This causes kubelet to request the signing of a new CSR every time it's
restarted. This commit changes the behavior so that `templateChanged` is
only fired off if the currently template doesn't match both the current
certificate and the last template.
Fixes#69471
Signed-off-by: Andrew Gunnerson <andrew.gunnerson@us.ibm.com>
Kubernetes-commit: b9ab65d689cc48353ca5dae9f210ff408726a0d2
certificate.FileStore only handles (cert, key) combined PEM files. This
PR allows (key, cert), which is what "openssl req -out foo.pem -keyout
foo.pem" generates.
Kubernetes-commit: 4b6a6a1cd5c8df83b3c51a03ecab975b82057489
The kubelet uses two different locations to store certificates on
initial bootstrap and then on subsequent rotation:
* bootstrap: certDir/kubelet-client.(crt|key)
* rotation: certDir/kubelet-client-(DATE|current).pem
Bootstrap also creates an initial node.kubeconfig that points to the
certs. Unfortunately, with short rotation the node.kubeconfig then
becomes out of date because it points to the initial cert/key, not the
rotated cert key.
Alter the bootstrap code to store client certs exactly as if they would
be rotated (using the same cert Store code), and reference the PEM file
containing cert/key from node.kubeconfig, which is supported by kubectl
and other Go tooling. This ensures that the node.kubeconfig continues to
be valid past the first expiration.
Kubernetes-commit: 368959346af6e06085c63a4cc7c37839f262f636
Otherwise, the certificate store will return nil the first time a store
cert is accessed. When background rotation is being used, prevents the
client from being nil.
Kubernetes-commit: b81f4745546340f08abd3f877c585aac9581d0f0
The certificate manager originally had a "block on startup" rotation
behavior to ensure at least one rotation happened on startup. However,
since rotation may not succeed within the first time window the code was
changed to simply print the error rather than return it. This meant that
the blocking rotation has no purpose - it cannot cause the kubelet to
fail, and it *does* block the kubelet from starting static pods before
the api server becomes available.
The current block behavior causes a bootstrapped kubelet that is also
set to run static pods to wait several minutes before actually launching
the static pods, which means self-hosted masters using static pods have
a pointless delay on startup.
Since blocking rotation has no benefit and can't actually fail startup,
this commit removes the blocking behavior and simplifies the code at the
same time. The goroutine for rotation now completely owns the deadline,
the shouldRotate() method is removed, and the method that sets
rotationDeadline now returns it. We also explicitly guard against a
negative sleep interval and omit the message.
Should have no impact on bootstrapping except the removal of a long
delay on startup before static pods start.
Also add a guard condition where if the current cert in the store is
expired, we fall back to the bootstrap cert initially (we use the
bootstrap cert to communicate with the server). This is consistent with
when we don't have a cert yet.
Kubernetes-commit: 44493de195d89ec43cc7246af921e626e0002c16
