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.
Related
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.
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 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/
I am using Google Kubernetes Engine and have the Google HTTPS Load Balancer as my ingress.
Right now the load balancer uses Let's Encrypt certificates. However, is there a simple way to ensure that the certificates are automatically renewed prior to their 90 day expiry?
You can now use "Google-managed SSL certificates" which is currently in beta: https://cloud.google.com/load-balancing/docs/ssl-certificates#managed-certs
You have not specified how you configured Let's Encrypt for your load balancer. Right now Google does not offer this for you, so I assume you mean you set the Let's Encrypt certificate yourself. In this case, Google can't renew your certificate.
Until there's an official support you can install a third-party add-on like cert-manager to automate certificate configuration and renewal. There's a GKE tutorial for doing this at https://github.com/ahmetb/gke-letsencrypt.
I want to proxy API Gateway requests to a container in an ECS cluster. As API Gateway can not be placed in a security group, I have to expose the service through an internet-facing ALB load balancer. To verify that the service only handles traffic from API GW, I'm looking to use client certificates.
Is there a way to have ELB verify the API Gateway client certificate for me and terminate the SSL connection before handing the request off to my HTTP backend?
If ELB cannot verify the certificate, it seems to me that I have to "downgrade" the proxy to a TCP proxy, and perform the SSL handshake in my service. However, to do this, I also need to serve the certificate from the service. This is a problem because I'm using AWS provisioned SSL certificates, and I do not possess the private key. Thus I would have to not only recreate the SSL handshake, but also get my SSL certificate from somewhere else, is this correct?
Hoping there's a low-effort way to set up the trust between API Gateway and an ECS service behind an ALB.
Unfortunately, ELB does not support validating the client certificate for you. You can implement SSL termination on your service and use the ELB in TCP mode (or use the newer NLB). You don't need the private key of the client certificate, you simply add the public key/cert to your trusted CA on the service so that the service only trusts the API GW client certificate.