When I create a kubernetes cluster I'm getting message as
As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use
kubeadm init phase upload-certs --upload-certs to reload certs afterward.
Even if I run the above command when will the new certs expire? Is there any way to set expiration time manually?
Expiry of certificates generated by kubeadm is 365 days. For safety reasons the certificates which are uploaded as secrets into the kubernetes cluster are deleted after 2 hours but that does not mean that the certificates are expired after 2 hours. Certificates will still be valid for 365 days and reside in the file system of the control plane nodes and when you run kubeadm init phase upload-certs --upload-certs it will be uploaded again as secret into the Kubernetes cluster.
From the docs here you can use below command to check expiration of certificates
kubeadm certs check-expiration
Related
I'd like to deploy an ldap server on my kubernetes cluster. The server itself is up and running, but I'd like to enable SSL encryption for it as well.
I already have cert-manager up and running and I also use a multitude of SSL certificates with my ingresses with my HTTP traffic. It would be really nice if I could just use a CertificateRequest with my ldap server as well, managed and updated by cert-manager.
My problem is I have no idea how to mount a Certificate to my kubernetes pod. I know that cert-manager creates a secret and puts the certificate data in it. The problem with that is I have no idea of the validity of that certificate this way, and can't remount/reapply the new certificate.
Has anybody done anything like this? Is there a non-hacky way to incorporate ingresses to terminate SSL encryption?
I have an old kubernetes cluster on v1.8.6, using kOps I have been trying to upgrade the server to v1.20.8.
I run into a CA cert/key issue where kOps was failing to rolling update the cluster returning an error x509: certificate signed by unknown authority.
kOps had created a new ca secret, so there were now two secrets with type ca. Looking through github issues I found what sounds similar to what I was experiencing and I removed the old ca cert/key with kOps delete secret .... thinking I would move forward with the new one only.
I didn't take a backup of the key, I did get a copy of the crt from S3 but also from my local .kube/config and the master servers ~/.kube/config has the same certificate-authority-data. I can connect to the cluster again with tls via kubectl, but kOps is having issues. There are no ca .crt or .key files in my kOps state store on S3.
Can I restore the key file somehow?
Can I create a kOps secret in this case without the key file, if I plan on upgrading the cluster anyway?
If you have not rotated the control plane/master nodes, you will find the certificates on there. The location for those files have changed over the years, but you should hopefully find them in /srv/kubernetes/.
Or you can restore them if you have enabled S3 versioning.
kOps will reprovision any lost secrets next time you run kops update cluster --yes. You can stick with the new certificates, but then be aware you are effectively doing a key rotation and may want to follow the remaining steps mentioned in this document.
I have a kubernetes cluster and I've been experimenting so far with cert-manager and letsencrypt ssl certificates.
Everything goes fine, I have issued an SSL certificate and applied to the cluster and https connection is working excellent.
The problem I face is that I am experimenting with new things and it often leads me to delete the whole cluster and create a new fresh one, which on it's side makes me lose the SSL certificate and issue a new one, but there's a rate limit by 50 certificates per week per domain.
Is there a way I can reuse a certificate in a new k8s cluster?
Copy the secret locally (kubectl get secret -o yaml and then clean up unneeded fields) and then upload it to the new cluster (kubectl apply).
At the moment my kubernetes dashboard shows me that my session in insecure. I have updated the path at with I keep the dashboard certs (/root/certs/) and I need to know how to get kubernetes to use them.
I have tried to:
Delete the secret kubernetes-dashboard-certs which deletes that secret successfully.
Add my new dashboard.crt & dashboard.key to /root/certs/ (readable by all)
Created the secret again with kubectl create secret generic kubernetes-dashboard-certs --from-file=/root/certs -n kubernetes
Logged into dashboard and it still shows insecure (because the SSL cert is not being updated)
Have you created authentication token (RBAC)? You can get more information from here.
Try to regenerate your cluster certificates, check documentation. If you used kubeadm then from control plane node you can run:
$ kubeadm alpha certs renew
Also what can be helpful is to restart apiserver:
user#test-calico:~$ sudo docker ps -a | grep apiserver
834ed10cbce3 5eb2d3fc7a44 "kube-apiserver --ad…" 4 weeks ago Up 4 weeks k8s_kube-apiserver_kube-apiserver-test-calico_kube-system_019eaca18f2defc3759027d8220b3451_0
87c22315ce21 k8s.gcr.io/pause:3.1 "/pause" 4 weeks ago Up 4 weeks k8s_POD_kube-apiserver-test-calico_kube-system_019eaca18f2defc3759027d8220b3451_0
$ sudo docker restart 834ed10cbce3
Please refer to following post
Kubernetes: expired certificate.
I'm reading that the default expiry date for puppet certificates is 5 years, and can set set with the attribute ca_ttl in puppet.conf.
I have 2 questions, given a setup of many agents connecting to a puppet master.
What happens when an agents certificate expires? Does it automatically create a new one on check-in to the master, or does this need to be done manually?
What happens when the CA certificate expires? Does the setup become completely disconnected, requiring you to SSH into each agent to remove expired certificates?
Agent Certificate Expiry
When an agent's certificate expires, future agent check-ins will fail very early on. I can't remember the exact error, but it'll be something like:
err: Could not retrieve catalog from remote server: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed.
When that happens, you have to delete the cert from the master, regenerate the certificate on the agent and then re-sign the certificate on the master: This will only affect the one agent.
The full process is documented here: https://docs.puppet.com/pe/latest/agent_cert_regen.html
NB: This is often fairly rare, as most people try to go for a livestock not pets estate, where machines are spun up and down frequently enough that agent machines don't exist for over 5 years.
PuppetServer/master Certificate Expiry
When the CA certificate itself expires, then everything is stopped: no communication can exist because the authority itself has expired. This is more common because a Puppet Master is more likely to exist for over 5 years.
But yes: if the certificate had already expired you'd need another way to configure things, such as SSH, console access or WinRM.
Puppet actually created a helper module to help with this process, as the OpenSSL steps are a little fiddly to try and do manually:
https://github.com/puppetlabs/puppetlabs-certregen
Manual process is also here:
https://docs.puppet.com/puppet/latest/ssl_regenerate_certificates.html