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>
This test was sometimes using the "inner" REST and sometimes using the
"outer" REST. This commit changes all but one test to use the outer.
The remaining test needs rework.
Given bootstraptoken/v1 is now a separate GV, there is no need
to duplicate the API and utilities inside v1beta3 and the internal
version.
v1beta2 must continue to use its internal copy due, since output/v1alpha1
embeds the v1beta2.BootstrapToken object. See issue 2427 in k/kubeadm.
- Make v1beta3 use bootstraptoken/v1 instead of local copies
- Make the internal API use bootstraptoken/v1
- Update validation, /cmd, /util and other packages
- Update v1beta2 conversion
Package bootstraptoken contains an API and utilities wrapping the
"bootstrap.kubernetes.io/token" Secret type to ease its usage in kubeadm.
The API is released as v1, since these utilities have been part of a
GA workflow for 10+ releases.
The "bootstrap.kubernetes.io/token" Secret type is also GA.
- Will not allow if a container (init or not) sets the proc mount type to anything other than `Default`
- Include fixture for proc mount baseline generation and the consequent genreated test data
Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
During cluster configuration, the hostname is getting resolved to IP,
as etcd requires IP address as listening address.
Due to connectivity flakes or delayed network inititalization, sometimes
the IP fails to be resolved to a name with following error:
```
[Errno -2] Name or service not known
```
that leads to attempt to run etcd with empty flag.
The PR adds a proper retry (up to 5 minutes) in case the connectivity
problems happens.
I considered alternatives like: `getent hosts foo`, but unfortunetelly thay
can return IPv6 that etcd is not ready for (yet).
