I have certain questions regarding importing the existing certificates.
How are certificates used internally in Kubernetes (e.g. between api server and workers, master controller, etc.)?
Is there a CA in Kubernetes? (how) does it generate certificates for internal use?
What certificates are required at each layer?
Certificates in Kubernetes are primarily used to secure communication from and to the API server. Taken from the official Kubernetes documentation:
Every Kubernetes cluster has a cluster root Certificate Authority
(CA). The CA is generally used by cluster components to validate the
API server’s certificate, by the API server to validate kubelet client
certificates, etc. To support this, the CA certificate bundle is
distributed to every node in the cluster and is distributed as a
secret attached to default service accounts. Optionally, your
workloads can use this CA to establish trust. Your application can
request a certificate signing using the certificates.k8s.io API using
a protocol that is similar to the ACME draft.
When creating a cluster with kubeadm, the tool at first creates a CA in /etc/kubernetes/pki and signs all following certificates with its private key. The ca is later distributed on all nodes for verification and also found base64 encoded in /etc/kubernetes/admin.conf for verification of the api server via kubectl.
It is possible to use your own CA for cluster creation by placing it and your private key as ca.crt and ca.key in /etc/kubernetes/pki before invoking kubeadm init or any folder later specified with --cert-dir.
There are many other ways to install Kubernetes but they all essentially create a CA before any actual Kubernetes code runs or require one to exist beforehand.
Related
I have started working on istio implementation and able to see some progress. Have got few doubts and I see myself missing something in the documentation....
Currently, I am using a gateway, virtual service, destination rules, authorization services for 2 deployments and I am able to see the graph with mTLS enabled in the kiali dashboard. and it's all working fine.
As I have to use now GoDaddy CA certs, gone through the documentation regarding "Plug in certificates and key into the cluster", looks like during the fresh installation of the istio it's picking custom CA certs but with below errors
2022-02-03T16:23:31.337162Z info initializing mesh networks from mesh config watcher
2022-02-03T16:23:31.337167Z info initializing mesh handlers
2022-02-03T16:23:31.337178Z info creating CA and initializing public key
2022-02-03T16:23:31.337214Z info Use local CA certificate
Error: failed to create discovery service: failed to create CA: failed to create an istiod CA: certificate is not authorized to sign other certificates
2022-02-03T16:23:31.338090Z error failed to create discovery service: failed to create CA: failed to create an istiod CA: certificate is not authorized to sign other certificates
I am a bit stuck in this and exploring for any other approaches if I have to look into anything if I am missing.
Can you please advise with some of the inputs regarding this.
If I am understanding you correctly you are talking about this page and trying to issue certs on behalf of GoDaddy. This will not work (unless you are the owner of GoDaddy..)
You most likely do not need this setup unless perhaps you are running two clusters.
If using AWS you would normally have an ALB connected to your Istio Gateway (NodePort) via HTTPS. Let Istio use self signed certs.
I set up a k8s cluster on GKE.
I want to control it via the k8s REST API (so, looking at deployments on pods and whatnot, but not accessing what is actually running on the k8s cluster over SSL). I have gotten the appropriate bearer token (curl --insecure [request] works) and can make API requests. However, the SSL certificate isn't valid for my client (it's java, if that matters). I can't easily modify the client to accept the new root cert at this time.
I have been digging around and have examine the following three options:
incorporate the cluster's root CA cert into another cert chain (from my limited understanding of TLS, I'm not sure this is possible) that exists in my client already.
replace the cluster root CA cert (so that I can use something my client has in its keystore). This implies you can do this with vanilla k8s, but this implies that you cannot using GKE: "An internal Google service manages root keys for this CA, which are non-exportable."
allow k8s API access without TLS. I haven't seen anything about this in the docs, which are pretty explicit that k8s API access over the network must use TLS
Are any of these viable options? Or is my best choice to modify the client?
There is an article named "Access Clusters Using the Kubernetes API" (https://kubernetes.io/docs/tasks/administer-cluster/access-cluster-api/) that addresses your concerns about how to query the REST API using a Java Client (https://kubernetes.io/docs/tasks/administer-cluster/access-cluster-api/#java-client)
If you are using the Java app inside a POD, you can import your cluster's CA to your Java Trust Store (https://docs.oracle.com/cd/E19509-01/820-3503/6nf1il6er/index.html). The CA certificate of for your cluster is inside all pods running within your cluster on /var/run/secrets/kubernetes.io/serviceaccount/ca.crt directory. More information in (https://kubernetes.io/docs/tasks/administer-cluster/access-cluster-api/#without-using-a-proxy)
Regarding your questions:
1.- Import the your cluster's CA cert to your trust store.
2.- You can't set your own CA in GKE, but you can rotate the CA certificate if needed (https://cloud.google.com/kubernetes-engine/docs/how-to/credential-rotation)
3.- You can't deactivate TLS communication in GKE (https://cloud.google.com/kubernetes-engine/docs/concepts/cluster-trust)
Your best option is to use the official Java Client or ADD the CA to your current development.
Based on some other feedback (in a slack), I ended up putting a proxy between my GKE cluster and my client. Then I can just add the GKE cluster k8s ca cert to the proxy's keystore (and don't have to modify the client). For my purposes, I didn't need to have the proxy use SSL, but for production I would.
I'm looking for a CA solution that I can use w/ the webapps running in my private domain. I'm using nginx ingress controller to route to different applications based on path, and I'm using self signed certs to secure the apps w/ https. I want to start using a CA, something that I can run directly on the cluster, that'll handle the signing so that I don't have to distribute the certs manually. Any ideas? What's the goto solution for this scenario?
There are probably multiple solutions for this, but one is the cert-manager:
https://github.com/jetstack/cert-manager
You can install it and create a CA issuer with your CA. Then you can create certificates using k8s yaml manifests, and the cert-manager takes care of creating the secrets.
I am trying to build an HTTPs proxy server in front of another service in Kubernetes, using either an NginX proxy LoadBalancer server, or Ingress. Either way, I need a certificate and key so that my external requests get authenticated.
I'm looking at how to manage tls in a cluster, and I've noticed that the certificate used to connect to the container cluster is the same one as is mounted at /var/run/secrets/kubernetes.io/serviceaccount/ca.crt on a running pod.
So I'm thinking that my node cluster already has a registered certificate, all I need is the key, throw it into a secret and mount that into my proxy server. But I can't find how.
Is it this simple? How would I do that? Or do I need to create a new certificate, sign it etc etc? Would I then need to replace the current certificate?
If you want an external request to get into your K8s cluster then this is the job of an ingress controller, or configuring the service with a loadbalancer, if your cloud provider supports it.
The certificate discussed in your reference is really meant to be used for intra-cluster communications, as it says:
Every Kubernetes cluster has a cluster root Certificate Authority (CA). The CA is generally used by cluster components to validate the API server’s certificate, by the API server to validate kubelet client certificates, etc.
If you go for an ingress approach then here is the doc for tls. At the bottom a list of alternatives, such as the load balancer approach.
I guess you could use the internal certificate externally if you are able to get all your external clients to trust it. Personally I'd probably use kube-lego, which automates getting certificates from Let's Encrypt, since most browsers trust this CA now.
Hope this helps
Was wondering what the best practice for deploying a custom WCF - Security Token Service (STS) in a load balancing environment that uses signs and encrypts the token?
We're using Cirtix NetScaler to handle the load balancing and SSL termination (i.e. certificate is only installed on the NetScaler server). The STS has been specified to sign and encrypt the token via the SigningCertificateName and EncryptionCertificateName app settings. However the current web server configuration does not have a local certificate installed within it's certification store.
So my questions are:-
Do we need to worry about signing and encrypting the token if it's transferred over SSL?
Should we install the certificate on every web server or can we use the load balancer?
Can we use the same certificate on each web server or do we need to buy a certificate for each web server?
An STS which does not sign its tokens is not much use: without a signature, no relying party will be able to distinguish between a valid token issued by the STS and a token spoofed by someone with evil intent.
The certificate you install to support SSL is generally different to the STS's signing certificate. The latter identifies the Service, not the web server. So, by all means carry on installing the SSL certificate just on the load balancer. But you will need another certificate, representing the identity of the Service, installed (with its private key) on each machine which hosts the service, for use as the SigningCertificate. It should be the same certificate on each server (it's the same Service).
However, you typically don't need to buy such a certificate: you can issue your own - you just need to make sure each potential Relying Party is configured to recognise the certificate as a trusted STS, and also trusts the root issuer of the certificate (which will be either the certificate itself, if it is a self-signed certificate, or your root certificate, if you used a certificate server to issue it).