We are used kong api-gateway on EKS to manage our APIs/microservices.
Our original plan was to use NLB, however we had problem terminating SSL/TLS in kong within EKS, so we ended up terminating SSL in ALB, also using ALB for HTTP to HTTPS redirection.
Wanted to see if you guys see any issues with this?
thanks
Related
I am using an Ingress using Google-managed SSL certs mostly similar to what is described here:
https://cloud.google.com/kubernetes-engine/docs/how-to/managed-certs#setting_up_a_google-managed_certificate
However my backend service is a grpc service that is using HTTP2. According to the same documentation if I am using HTTP2 my backend needs to be "configured with SSL".
This sounds like I need a separate set of certificates for my backend service to configure it with SSL.
Is there a way to use the same Google managed certs here as well?
What are my other options here? I am using, Google managed certs for the Ingress not to manage any certs on my own, if I then use self signed certificates for my service, that kind of defeats the purpose.
i don't think it's required to create SSL for the backend services if you are terminating the HTTPS at LB level. You can attach your certs to at LB level and the backed-end will be HTTPS > HTTP.
You might need to create SSL/TLS new cert in case there is diff version ssl-protocols: TLSv1.2 TLSv1.3, Cipher set in your ingress controller configmap which you are using Nginx ingress controller, Kong etc.
If you are looking for End to End HTTPS traffic definitely you need to create a cert for the backend service.
You can also create/manage the Managed certificate or Custom cert with Cert manager the K8s secret and mount to deployment which will be used further by the service, in that case, no need to manage or create the certs. Ingress will passthrough the HTTPS request to service directly.
In this case, it will be an end-to-end HTTPS setup.
Update :
Note: To ensure the load balancer can make a correct HTTP2 request to
your backend, your backend must be configured with SSL. For more
information on what types of certificates are accepted, see Encryption
from the load balancer to the backends ." end to end tls seems to be a
requirement for HTTP2
This is my site https://findmeip.com it's running on HTTP2 and terminating the SSL/TLS at the Nginx level only.
Definitely, it's good to go with the suggested practice so you can use the ESP option from the Google, setting GKE ingress + ESP + grpc stack.
https://cloud.google.com/endpoints/docs/openapi/specify-proxy-startup-options?hl=tr
If not want to use ESP check above suggested :
You can Mount Managed certificate to
deployment which will be used further by the service, in that case, no
need to manage or create the certs. In other words, cert-manager will create/manage/re-new SSL/TLS on behalf of you in K8s secret which will used by service.
Google Managed Certificates can only be used for the frontend portion of the load balancer (aka client to LB). If you need encryption from the LB to the backends you will have use self-signed certificates or some other way to store said certificates on GKE as secrets and configuring the Ingress to connect to the backend using these secrets.
Like this https://cloud.google.com/kubernetes-engine/docs/concepts/ingress-xlb#setting_up_https_tls_between_client_and_load_balancer
Is it possible to run spring boot containerized apps on port 8443 going through a 443 ALB listener and deployed on ECS Fargate in AWS? The 443 listener would have an issued cert, not a self-signed cert. I would use an NLB but I need to set route paths, so that's a no go. Would using nginx as a proxy be used in a situation like this?
Is it possible to run spring boot containerized apps on port 8443
going through a 443 ALB listener and deployed on ECS Fargate in AWS?
Yes it is absolutely possible, there should be no issue with this at all. What you are describing is actually just a very standard and basic ECS/Fargate setup.
Would using nginx as a proxy be used in a situation like this?
Only if you want to. You don't need Nginx just to make this work.
I have a Global accelerator connected to elastic beanstalk in 3 regions(US, AU, EU).
The issue is whenever I hit the global accelerator it responds with the certificate of the ALB thats connected to the elastic beanstalk which causes the browser to block the response saying incorrect common name.
Each ALB has its own seperate url eg: server-au.domain.com, server-eu.domain.com.
Global accelerator has its own custom domain name and ssl. How do we make sure that the certificate of global accelerator is passed instead of where the request is forwarded to?
All certificates are handled by AWS certificate manager and dns records by Route 53.
You can add multiple certificates for the elastic beanstalk under load balancer of ec2 settings.
I have Kubernetes with Kafka where is also running Istio with Strimzi. Certificates are stored in cert-manager. I want to use TLS passthrough in my ingress but I am a little bit confused of that.
When SIMPLE is used, there is credentialName, which must be the same as secret.
tls:
mode: SIMPLE
credentialName: httpbin-credential
It is nice and simple way. But how about mode: PASSTHROUGH when I have many hosts? I studied demo on istio web (https://istio.io/latest/docs/tasks/traffic-management/ingress/ingress-sni-passthrough/#deploy-an-nginx-server) and their certificate details are stored in server configuration file and they are creating configmap. In official Istio documentation is noted that this parameter is only for MUTUAL and SIMPLE.
What is correct and simple way to expose my hosts using istio ingress to external traffic using cert-manager?
The difference between SIMPLE & PASSTHROUGH is:
SIMPLE TLS instructs the gateway to pass the ingress traffic by terminating TLS.
PASSTHROUGH TLS instructs the gateway to pass the ingress traffic AS IS, without terminating TLS.
Background:
I had 1 instance created for EC2
I had my domain pointing to this instance
I had SSL installed for this instance (things were running great)
Furthermore:
I opted to create a second instance (using custom AMI from first instance)
I create a load balancer (things were working great -- from what i can tell...)
Question:
Why do I need to install the SSL certificate on the load balancer when it seems to have already been working?
I would presume when you say load balancer, you are refering to AWS ELB. If this is no the case, then disregard my answer.
Well the Best practice is to install SSL certs on load balancer and do the SSL termination there. Let the load balacner do SSL encryption/decryption so that your web server can do what they do the BEST...serving hte web pages.
Why do I need to install the SSL certificate on the load balancer
Now, technically You set is fine and you don't have to install SSL on load balancer. But then you have to use TCP Load Balancing feature of AWS ELB where in ELB will simply accespt traffic on 443 and will forward it to Web servers on 443. And then let your web servers do the SSL work.
I think this what you are looking for.