929b1559a0
Close outbound connections when using a cert callback and certificates rotate. This means that we won't get into a situation where we have open TLS connections using expires certs, which would get unauthorized errors at the apiserver Attempt to retrieve a new certificate if open connections near expiry, to prevent the case where the cert expires but we haven't yet opened a new TLS connection and so GetClientCertificate hasn't been called. Move certificate rotation logic to a separate function Rely on generic transport approach to handle closing TLS client connections in exec plugin; no need to use a custom dialer as this is now the default behaviour of the transport when faced with a cert callback. As a result of handling this case, it is now safe to apply the transport approach even in cases where there is a custom Dialer (this will not affect kubelet connrotation behaviour, because that uses a custom transport, not just a dialer). Check expiry of the full TLS certificate chain that will be presented, not only the leaf. Only do this check when the certificate actually rotates. Start the certificate as a zero value, not nil, so that we don't see a rotation when there is in fact no client certificate Drain the timer when we first initialize it, to prevent immediate rotation. Additionally, calling Stop() on the timer isn't necessary. Don't close connections on the first 'rotation' Remove RotateCertFromDisk and RotateClientCertFromDisk flags. Instead simply default to rotating certificates from disk whenever files are exclusively provided. Add integration test for client certificate rotation Simplify logic; rotate every 5 mins Instead of trying to be clever and checking for rotation just before an expiry, let's match the logic of the new apiserver cert rotation logic as much as possible. We write a controller that checks for rotation every 5 mins. We also check on every new connection. Respond to review Fix kubelet certificate rotation logic The kubelet rotation logic seems to be broken because it expects its cert files to end up as cert data whereas in fact they end up as a callback. We should just call the tlsConfig GetCertificate callback as this obtains a current cert even in cases where a static cert is provided, and check that for validity. Later on we can refactor all of the kubelet logic so that all it does is write files to disk, and the cert rotation work does the rest. Only read certificates once a second at most Respond to review 1) Don't blat the cert file names 2) Make it more obvious where we have a neverstop 3) Naming 4) Verbosity Avoid cache busting Use filenames as cache keys when rotation is enabled, and add the rotation later in the creation of the transport. Caller should start the rotating dialer Add continuous request rotation test Rebase: use context in List/Watch Swap goroutine around Retry GETs on net.IsProbableEOF Refactor certRotatingDialer For simplicity, don't affect cert callbacks To reduce change surface, lets not try to handle the case of a changing GetCert callback in this PR. Reverting this commit should be sufficient to handle that case in a later PR. This PR will focus only on rotating certificate and key files. Therefore, we don't need to modify the exec auth plugin. Fix copyright year |
||
|---|---|---|
| .github | ||
| api | ||
| build | ||
| CHANGELOG | ||
| cluster | ||
| cmd | ||
| docs | ||
| Godeps | ||
| hack | ||
| logo | ||
| pkg | ||
| plugin | ||
| staging | ||
| test | ||
| third_party | ||
| translations | ||
| vendor | ||
| .bazelrc | ||
| .bazelversion | ||
| .generated_files | ||
| .gitattributes | ||
| .gitignore | ||
| .kazelcfg.json | ||
| BUILD.bazel | ||
| CHANGELOG.md | ||
| code-of-conduct.md | ||
| CONTRIBUTING.md | ||
| go.mod | ||
| go.sum | ||
| LICENSE | ||
| Makefile | ||
| Makefile.generated_files | ||
| OWNERS | ||
| OWNERS_ALIASES | ||
| README.md | ||
| SECURITY_CONTACTS | ||
| SUPPORT.md | ||
| WORKSPACE | ||
Kubernetes
Kubernetes is an open source system for managing containerized applications across multiple hosts. It provides basic mechanisms for deployment, maintenance, and scaling of applications.
Kubernetes builds upon a decade and a half of experience at Google running production workloads at scale using a system called Borg, combined with best-of-breed ideas and practices from the community.
Kubernetes is hosted by the Cloud Native Computing Foundation (CNCF). If your company wants to help shape the evolution of technologies that are container-packaged, dynamically scheduled, and microservices-oriented, consider joining the CNCF. For details about who's involved and how Kubernetes plays a role, read the CNCF announcement.
To start using Kubernetes
See our documentation on kubernetes.io.
Try our interactive tutorial.
Take a free course on Scalable Microservices with Kubernetes.
To use Kubernetes code as a library in other applications, see the list of published components.
Use of the k8s.io/kubernetes module or k8s.io/kubernetes/... packages as libraries is not supported.
To start developing Kubernetes
The community repository hosts all information about building Kubernetes from source, how to contribute code and documentation, who to contact about what, etc.
If you want to build Kubernetes right away there are two options:
You have a working Go environment.
mkdir -p $GOPATH/src/k8s.io
cd $GOPATH/src/k8s.io
git clone https://github.com/kubernetes/kubernetes
cd kubernetes
make
You have a working Docker environment.
git clone https://github.com/kubernetes/kubernetes
cd kubernetes
make quick-release
For the full story, head over to the developer's documentation.
Support
If you need support, start with the troubleshooting guide, and work your way through the process that we've outlined.
That said, if you have questions, reach out to us one way or another.