I want to expose an HTTPS K8s service that uses a certificate derived from a custom root CA, outside the cluster using nginx ingress controller. Are the following configurations supported and if yes, how?
client -- (HTTP) -- ingress -- (HTTPS) -- k8s service
client -- (HTTPS) -- ingress -- (HTTPS) -- k8s service
Is it possible to configure nginx ingress controller such that it can do TLS and mutual-TLS with the HTTPS backend service?
How do I provision a root certificate for backend server certificate validation to nginx ingress?
Is it possible to do SSL termination on the ingress and do mutual-TLS with the backend?
I was able to provision the backend server certificates using the nginx.ingress.kubernetes.io/proxy-ssl-secret annotation.
Related
I have deployed an aioquic server application to Kubernetes cluster. This server requires certificate as configuration to start it. I also have an Istio ingress associated with my cluster for outside communication. Is it possible to have SSL cert for both Ingress as well as deployed application? If so, can we use the same SSL cert for both or it should be seperate certs?
I have a kubernetes pod configured as a webserver supporting https. This pod is giving the TLS handshake error logs. When we try to access the loadbalancer service IP on the browser, it gives error - the connection is not secure proceed to unsafe. For secure connection we have a self signed certificate mounted as a secret to the pod volume. If we remove support of https everything works fine. Can somebody suggest what could be the possible reason for such behaviour.
By default a https connection exist only between the browser and the loadbalancer. The loadbalancer communicates with pods using plain http.
browser -------------->|loadbalancer|-----------> POD
https http
In that case, the certificate needs to be present on the loadbalancer, not on the POD, and you should disable HTTPS on the pod.
The loadbalancer can be configured to communicate with PODs using https, but it will be a different https connection:
browser -------------->|loadbalancer|-----------> POD
https https
Here two certificates are needed, one on the loadbalancer and one on the pod itself.
The last option is pass-through SSL, but it's not enabled by default:
loadbalancer
browser --------------|--------------|-----------> POD
https
Here the certificate should be placed on the pod.
The way of configuring HTTPS depends on the used loadbalancer, cloud provider etc. If you are using Ingress, this page might help: Kubernetes: Using Ingress with SSL/TLS termination and HTTP/2
Sidenote: browsers always complain about insecure connection when using a self-signed certificate (unless you configure them not to do it).
I deployed nginx as ingress controller for grpc service in the Kubernetes. Everything works fine with a TLS certificate which is required by nginx ingress controller. This means that I must refactor the code of grpc client to use secure channel. There are lots of work to do and unnecessary.
I wonder if there is any ingress controller are permitted to use for grpc service without TLS
I would like to add multiple certificates for the same IP with different sub domain. I've created cluster and added ingress. i have HTTPS applications installed as well. I succeeded to add certificated to two different hosts (using the same ingress but 2 public IPs).
How can i write in ingress to use cert X for aks-hello-world and in cert Y for ingress-demo? (see attachment)
Is there something i should do in azure as well?
Ingress example
You can deploy the Kubernetes nginx ingress controller and forward the traffic from one (public accessible) load balancer to the exposed node port service of the ingress service (type: LoadBalancer). This forwarding is done via TCP (no TLS happening here). You need to point the multiple DNS entries to the IP of the load balancer.
The ingress controller is capable of SNI and handles the forwarding from there on.
This approach however requires that your TLS certificates are added to Kubernetes as secrets (for example via Cert Manager).
For configuration see the docs.
Moving from VMs to Kubernetes.
We are running our services on multiple VMs. Services are running on multiple VMs and have VIP in front of them. Clients will be accessing VIP and VIP will be routing traffic to services. Here, we use SSL cert for VIP and VIP to VM also using HTTPS.
Here the service will be deployed into VM with a JKS file. This JKS file will have a cert for exposing HTTPS and also to communicate with SSL enabled database.
How to achieve the same thing in Kubernetes cluster? Need HTTPS for VIP and services and also for communication to SSL enabled database from service.
Depends on the platform where you running Kubernetes (on-premises, AWS, GKE, GCE etc.) you have several ways to do it, but I will describe a solution which will work on all platforms - Ingress with HTTPS termination on it.
So, in Kubernetes you can provide access to your application inside a cluster using Ingress object. It can provide load balancing, HTTPS termination, routing by path etc. In most of the cases, you can use Ingress controller based on Nginx. Also, it providing TCP load balancing and SSL Passthrough if you need it.
For providing routing from users to your services, you need:
Deploy your application as a combination of Pods and Service for them.
Deploy Ingress controller, which will manage your Ingress objects.
Create a secret for your certificate.
Create an Ingress object with will point to your service with TLS settings for ask Ingress to use your secret with your certificate, like that:
spec:
tls:
hosts:
- foo.bar.com
secretName: foo-secret
Now, when you call the foo.bar.com address, Ingress with using FQDN-based routing and provide HTTPS connection between your client and pods in a cluster using a service object, which knows where exactly your pod is. You can read how it works here and here.
What about encrypted communication between your services inside a cluster - you can use the same scheme with secrets for providing SSL keys to all your services and setup Service to use HTTPS endpoint of an application instead of HTTP. Technically it is same as using https upstream in installations without Kubernetes, but all configuration for Nginx will be provided automatically based on your Service and Ingress objects configuration.