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
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
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.
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.
I am getting confused with all the certificates and keys in Kubernetes.
Inside the master I have the following certificates and keys:
/etc/kubernetes/pki/apiserver.crt
/etc/kubernetes/pki/apiserver.key
/etc/kubernetes/pki/apiserver-kubelet-client.crt
/etc/kubernetes/pki/apiserver-kubelet-client.key
/var/lib/kubelet/pki/kubelet.crt
/var/lib/kubelet/pki/kubelet.key
The apiserver-kubelet-client (crt\key) is used for secure communication between the apiserver and the kubelet inside the Master.
Why I have also the kubelet (crt\key)? Isn't the apiserver-kubelet-client (crt\key) is enough ?
Why I need apiserver (crt\key) if I have apiserver-kubelet-client (crt\key) ?
Hope someone can make some order with this.
I read this article about Kubernetes PKI but I am still don't understand what is difference between the above certificates and keys.
While preparing certs, you will end up with at least 1 file.
CA_CERT
put in on node where apiserver runs, for example in /srv/kubernetes/ca.crt.
MASTER_CERT
signed by CA_CERT
put in on node where apiserver runs, for example in /srv/kubernetes/server.crt
MASTER_KEY
put in on node where apiserver runs, for example in /srv/kubernetes/server.key
You can read about it in Kubernetes docs here.
It’s hard to say by the names of your certs what are they used for.
You should refer to the standard configuration.
Besides, you can have a look at kelseyhightower/kubernetes-the-hard-way as he’s showing how and when to use certificates.
You can check this comment posted on Github regarding what kind of certifications are needed between which services.
I was also asking my self similar question.
The first thing u need to know is that both the kubelet and the api-server communicate with each other [0].
The second thing is that Kubernetes uses client certificates to authenticate a client identity to the server and a server certificate to authenticate the server’s identity to the client and establish an encrypted connection .
In case of kubelet -> api-server kubelet needs a client certificate and api-server a server certificate and for api-server -> kubelet then the otherway around.
you can check if a certificate is a server or client one using:
openssl x509 -noout -text -in apiserver.crt
Now back to the question :
/etc/kubernetes/pki/apiserver.crt and /var/lib/kubelet/pki/kubelet.crt are server certificates
/etc/kubernetes/pki/apiserver-kubelet-client.crt and /var/lib/kubelet/pki/kubelet-client-current.pem are client certificates
https://kubernetes.io/docs/concepts/architecture/control-plane-node-communication/
I have a Kubernetes cluster running in High Availability mode with 3 master nodes. When I try to run the DNS cluster add-on as-is, the kube2sky application errors with an x509 signed by unknown certificate authority message for the API Server service address (which in my case is 10.100.0.1). Reading through some of the GitHub issues, it looked like Tim Hockin had fixed this type of issue via using the default service account tokens available.
All 3 of my master nodes generate their own certificates for the secured API port, so is there something special I need to do configuration-wise on the API servers to get the CA certificate included in the default service account token?
It would be ideal to have the service IP of the API in the SAN field of all your server certificates.
If this is not possible in your setup, set the clusters{}.cluster.insecure-skip-tls-verify field to true in your kubeconfig file, or the pass the --insecure-skip-tls-verify flag to kubectl.
If you are trying to reach the API from within a pod you could use the secrets mounted via the Service Account. By default, if you use the default secret, the CA certificate and a signed token are mounted to /var/run/secrets/kubernetes.io/serviceaccount/ in every pod, and any client can use them from within the pod to communicate with the API. This would help you solving the unknown certificate authority error and provide you with an easy way to authenticate against your API servers at the same time.