Quick question, in Rancher is it possible to use lets-encrypt to sign the k8s TLS certs (etcd, kub-api, etc). I have a compliance requirement to sign my k8s environment with a valid trusted CA chain?
Yes, it is actually one of the recommended options for the source of the certificate used for TLS termination at the Rancher server:
Let’s Encrypt: The Let’s Encrypt option also uses cert-manager.
However, in this case, cert-manager is combined with a special Issuer
for Let’s Encrypt that performs all actions (including request and
validation) necessary for getting a Let’s Encrypt issued cert.
In the links below you will find a walkthrough showing how to:
Install cert-manager
Install Rancher with Helm and Your Chosen Certificate Option
This option uses cert-manager to automatically request and renew Let’s
Encrypt certificates. This is a free service that provides you with a
valid certificate as Let’s Encrypt is a trusted CA.
Please let me know if that helped.
Related
My service (with no ingress) is running in the amazon EKS cluster and I was asked to provide a CA signed cert for a third party that consumes the API hosted in the service. I have tried provisioning my cert using certificates.k8s.io API but it is still self-signed I believe. Is there a CA that provides certification for services in the Kubernetes cluster?
Yes, Certificates created using the certificates.k8s.io API are signed by a dedicated CA. It is possible to configure your cluster to use the cluster root CA for this purpose, but you should never rely on this. Do not assume that these certificates will validate against the cluster root CA.
Refer this Certificate Signing Request Process
Deployed Chaos with helm on AKS. all pods up&running and all resources created.
I try then to create a crd NetworkChaos as in the official documentation but I get a x509 signed by unknown authority when trying to contact the Controller Manager svc. the certificate used is stored in the webhook-certs automatically generated by the helm.
Can anyone help me? Should I put a trusted certificate instead? should I trust the generated certificate by the cluster CA?
I also would be ok on skipping tls but I didn't find how to. Thanks
I'm trying to install metrics-server and I'm not sure what to do with the --tls-cert-file and --tls-private-key-file.
https://github.com/kubernetes-incubator/metrics-server
Can I use a certificate and key that is signed by the Cluster CA? Or is this bad unsafe for production?
It says in the referenced docs,
--tls-cert-file, --tls-private-key-file: the serving certificate and key files. If not specified, self-signed certificates will be generated, but it's recommended that you use non-self-signed certificates in production.
As a general rule, providing certs of your own CA would be the safest option.
Is there a specific method or process to replace all of the certificates required in a Kubernetes 1.7 cluster? Is this even possible?
Client is worried about using certificate auth and not being able to revoke/blacklist certs properly if someone leaves.
I'm going down the path of figuring out the details of securing our SF Clusters. I'm finding that the docs note in a number of places not to use self-signed certs for production workloads. But nowhere does it explain why.
Can anyone from the SF team explain why a self-signed X509 cert is not as secure as one issued from a known CA? I thought the only true difference is that self-signed certs do not chain to a certified root authority, which would mean any clients might not see the cert as valid. But with node-to-node security why would this matter?
So what risk am I taking if I use self-sign certs for node-to-node or even client-to-node security of my production SF Clusters?
For client to node: As anyone can spoof your self signed certificate,
you won't be able to assert from the client you're actually talking
to the correct server. Also, there's no way to revoke a self signed
cert. Finally, end users will see that nasty security warning in the
address bar.
For node to node: same thing applies, but since it's in a vnet behind the load balancer, the
risk of tampering is lower.
Encryption of the data itself will work using either type of certificate, but a MITM attack is made easier.