I am using ISTIO for service mesh in Azure kubernetes. I have configured private DNS to setup the FQDN. Currently the application is accessible over http protocol(eg: http://myapp.contoso.com) and I would like to be secured with https protocol(eg: https://myapp.contoso.com).
I know I have to change the service port to 443 to support https protocol however how/where do I install the SSL certificate for the application (eg: https://myapp.contoso.com)? Is there anything else to be done as well?
That will depend on where do you want the SSL termination to happen, if you want that to happen inside the Azure kubernetes network, then you can do SSL termination at ingress layer.
Or otherwise you can also do the termination at application gateway layer of Azure ( if you want to avail this service from azure, the redirection from http to https, basic firewall features and adding the pfx certificates at the listeners can be done), ingress can also take care of these things although.
You can install the let's encrypt certificates by using this helm chart and for further steps you can follow this stack overflow link, it shall help you in creating configurations for Istio, ppl have used this solution for Istio as well before
I found the answer here Securing Your Istio Ingress Gateway with HTTPS
There is istio documentation about that.
Related
We have a custom domain feature, which allows our clients to use our services with their custom DNS records.
For example, our client ACME has a CNAME to ssl.company.com like so login.acme.com -> ssl.company.com. right now we are using a k8s cluster to provide such traffic. On each custom domain, we create an ingress, external service, and a certificate using LetsEncrypt cert-manager.
We started using Cloudflare WAF and they are providing CustomHostname feature which allows us to do the same as our CD cluster but without changing the host header. So
for the example above we get
host: login.acme.com -> login.acme.com
SNI: login.acme.com -> ssl.company.com
The issue is of course how to map a generic k8s ingress to allow such traffic.
when we did the POC we used this method and it worked, but now it stopped. We have also tried default backend and unhosted ingress path.
We are using nginx-ingress controller but migrating to another API gateway like kong.
Any help will be grateful.
On Google Kubernetes Engine (GKE) you can use the cloud.google.com/app-protocols annotation on a Service to specify what protocol is used on that port (HTTP or HTTPS) docs
When you create an External HTTP(S) Ingress, it will use this protocol between the Ingress and the Service.
How do I set things up so that the Service uses a certificate that is actually trusted by the Ingress?
Does it just trust any certificate signed by the Cluster Root CA? Manage tls in a cluster suggests you need to include the pod IP address in the CSR - does that mean generating the CSR and waiting for the signed certificate to be created should be part of my container startup process?
Turns out when the "GKE Ingress for HTTP(S) Load Balancing" uses HTTPS to connect to the service, it accepts any certificate valid (even a self-signed one), without further configuration.
Apparently it does not use TLS to protect against MITM attacks here (which I guess might be reasonable).
I've got an AWS API GW that I'm trying to hook up to HTTPS REST endpoints in a different VPC. According to AWS support and the docs I've ready the solution is to use a VPC link pointing to an NLB in the GWs VPC with IP targets in the other VPC. My NLB is HTTPS since the backend services are HTTPS. For the NLB SSL certificate I used ACM to generate a private certificate (based on an ACM private CA). When I test the GW, I get the dreaded General SSLEngine problem error. The NLB is working fine, I can hit it from my browser and get data back from the back-end services. Does the VPC link not trust private certificates? I don't see any way to add CAs. This whole arrangement seems very convoluted to me. Any suggestions?
I have encountered the same problem and after many tests found the root of the problem in the documentation of the API-Gateway. Basically, API-Gateway will not work with any certificates derived from the ACM's Private CAs. This is a list of all valid CAs to use with the API-Gateway:
https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-supported-certificate-authorities-for-http-endpoints.html
I am building an app (API) that will be running on the Google Kubernetes engine. I will add a NGINX Proxy (Cloud Endpoints) with SSL such that all external API requests will go through the Cloud Endpoints instance.
Question is, since I already have SSL enabled on the external open interface, do i need to add SSL cvertificates to the Kubernetes engine as well?
In Google Kubernetes Engine, you can use Ingresses to create HTTPS load balancers with automatically configured SSL certificates. Google-managed SSL certificates are provisioned, renewed, and managed for your domain names. Read more about Google-managed SSL certificates here.
No, “You have the option to use Google-managed SSL certificates (Beta) or to use certificates that you manage yourself.”
You added a NGINX Proxy (Cloud Endpoints) with SSL, then you do not need to add SSL certificates to the Kubernetes engine as well.
I am using kubernetes and istio.
I need to call https service outside my mesh, and this called service using internal CA authority, which mean I need to trust the server side certificate.
Can I trust the certificate on istio level instead of each micro-service?
you can do it using cert-manager & ingress probably which will manage the ssl certificates :
you can check it out more at :
https://www.digitalocean.com/community/tutorials/how-to-set-up-an-nginx-ingress-with-cert-manager-on-digitalocean-kubernetes
you can also refer documents of istio where there option for HTTPS for managed gateway: https://istio.io/docs/tasks/traffic-management/secure-ingress/