Allow the user to pass custom cert validity period with
ClusterConfiguration.CertificateValidityPeriod and
CACertificateValidityPeriod.
The defaults remain 1 year for regular cert and 10 years for CA.
Show warnings if the provided values are more than the defaults.
Additional changes:
- In "certs show-expiration" use HumanDuration() to print
more detailed durations instead of ShortHumanDuration().
- Add a new kubeadm util GetStartTime() which can be used
to consistently get a UTC time for tasks like writing certs
and unit tests.
- Update unit tests to validate the new customizable NotAfter.
The component connection between kube-apiserver and kubelet does not
require the "O" field on the Subject to be set to the
"system:masters" privileged group. It can be a less
privileged group like "kubeadm:cluster-admins".
Change the group in the apiserve-kubelet-client
certificate specification. This cert is passed to
--kubelet-client-certificate.
Add v1beta4.ClusterConfiguration.EncryptionAlgorithm field (string)
and allow the user to configure the cluster asymetric encryption
algorithm to be either "RSA" (default, 2048 pkey size) or "ECDSA" (P-256).
Add validation and fuzzing. Conversion from v1beta3 is not required
because an empty field value is accepted and defaulted to RSA if needed.
Leverage the existing configuration option (feature gate) PublicKeysECDSA
but rename the backend fields, arguments, function names to be more
generic - EncryptionAlgorithm instead of PublicKeyAlgorithm.
That is because once the feature gate is enabled the algorithm
configuration also applies to private keys. It also uses the kubeadm API
type (string) instead of the x509.PublicKeyAlgorithm enum (int).
Deprecate the PublicKeysECDSA feature gate with a message.
It should be removed with the release of v1beta4 or maximum one release
later (it is an alpha FG).
- All certs will be created under the folder of `/etc/kubernetes/tmp/kubeadm-join-dryrunxxx`
if the `dry-run` mode is enabled.
- Try to make each phase idempotent by resetting the cert dir with `dry-run` mode
Signed-off-by: Dave Chen <dave.chen@arm.com>
Currently the "generate-csr" command does not have any output.
Pass an io.Writer (bound to os.Stdout from /cmd) to the functions
responsible for generating the kubeconfig / certs keys and CSRs.
If nil is passed these functions don't output anything.
Client side period validation of certificates should not be
fatal, as local clock skews are not so uncommon. The validation
should be left to the running servers.
- Remove this validation from TryLoadCertFromDisk().
- Add a new function ValidateCertPeriod(), that can be used for this
purpose on demand.
- In phases/certs add a new function CheckCertificatePeriodValidity()
that will print warnings if a certificate does not pass period
validation, and caches certificates that were already checked.
- Use the function in a number of places where certificates
are loaded from disk.
The selected key type is defined by kubeadm's --feature-gates option:
if it contains PublicKeysECDSA=true then ECDSA keys will be generated
and used.
By default RSA keys are used still.
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
kubeadm still generates RSA keys when deploying a node, but also
accepts ECDSA keys if they already exist pregenerated in the
directory specified in --cert-dir.
The function certs.NewCACertAndKey() is just a wrapper around
pkiutil.NewCertificateAuthority() which doesn't add any
additional functionality.
Instead use pkiutil.NewCertificateAuthority() directly.
This avoids ending in a wrong cluster state by assuming that the
present certificates will work. It is specially important when we
are growing etcd from 1 member to 2, in which case in case of failure
upon joining etcd will be unavailable.
Walk the certificate tree, at each step checking for a CACert.
If the CACert is found, try to use it to generate certificates.
Otherwise, generate a new CA cert.
