in older versions of Istio, when you wanted to use an egress gateway to allow the communication with a arbitrary domains, you could use wildcards with a SNI proxy as it's explained in https://istio.io/v1.13/docs/tasks/traffic-management/egress/wildcard-egress-hosts/#setup-egress-gateway-with-sni-proxy
I don't see how to do it in version 1.14. Any help?
Regards.
Related
I have a passthrough Network Load Balance forwarding TCP requests to a target group of backend servers on AWS. We require mutual TLS authentication so all requests require client certificates to be passed for encryption and authentication. However, I am struggling to figure out how I would do health checks to target group servers as the health checks would also require a client certificate in order to communicate to the backend servers.
Would it be possible to give the NLB a certificate via ACM and update my servers' truststores in order to then do healthchecks over TLS? I however have not been able to find how to import the AWS certificate chain into a truststore. If this would not work, what other methods would be appropriate for my scenario?
As far as the AWS documentation is considered we can't add client side certs in the LB and that too on the fly. TLS Listeners are supported but certificate support is limited there. Reference docs on the TLS LB Listeners: https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-tls-listener.html
Yes it's possible to use ACM cert with LBs Reference here: https://aws.amazon.com/premiumsupport/knowledge-center/associate-acm-certificate-alb-nlb/
but there's again no reference of exporting (public cert) anything out of ACM.
I have a requirement where GCP VM instance which is behind a squid proxy and NAT gateway should be able to send emails to AWS SES.
SES: email-smtp.eu-west-1.amazonaws.com
as far as I know, GCP has port 25 blocked and after referring to few articles on stackoverflow, it seems squid does not support SMTP as well.
can someone please help if they have worked on similar thing before?.
Thanks
Max
Use port 587. As per AWS SES and GCP documentation port 587 is without any restriction.
Option 1, AWS SES HTTP API:
If the email sending application could support sending emails via AWS SES with the use of their HTTP API instead of the SMTP protocol, you could allow that regional HTTPS endpoint in the outbound firewall (Squid in your case.)
The advantages of this approach address your concerns on bypassing the proxy by going through Cloud NAT directly, and maintaining restrictions on traffic originating from the source subnet.
Option 2, AWS SES SMTP over TLS:
Configure the application to connect with AWS SES SMTP endpoints on port 465 or 2465 while using TLS. This is also called SMTPS (where the trailing S stands for SSL/TLS, just like in HTTPS.) This is documented under TLS Wrapper in AWS' documentation.
Since Squid is primarily a proxy for HTTP, you will be better of replacing it with an outbound firewall that supports filtering traffic by FQDNs for SSL/TLS connections wrapping any protocol within. (In this case, SMTP wrapped in TLS.) These are typically called NGFW and available from the GCP marketplace on a free trial. One advantage of using these is the applications don't need explicit proxy settings for connecting to the Internet as the operation is completely transparent.
We are using EKS and Nginx-ingress(NLB). I'm trying to configure multiple AWS ACM certificates in the AWS-load-balancer-SSL-cert annotation for NLB. But with no luck. Could someone help if it possible at all? Thanks
If that not possible, Please guide me any other way on how to use multiple ACM cert in the ingress object-level if possible.
My EXACT Scenario:-
I am using an NLB (FYI)
If we able to add multiple ACM certificate at controller level that also works for me (I am using a single certificate in my NLB currently see below annotations)
At the controller level, these flags help me to add a single certificate:-
service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:ap-south-1:1234556677:certificate/3a1d5a-469b-dffe4bad3182
service.beta.kubernetes.io/aws-load-balancer-type: nlb
or
I am maintaining an ingress object as per NameSpace. if we are able to attach a Certificate at the ingress object level, which also solves my problem.
Good question.
There is no support for multiple ACM certificates on an ALB/NLB that points to an nginx ingress controller (or any other ingress controller AFAIK).
The dirty hack from Kubernetes is to create another Service that points to the same nginx ingress controller (same selectors) but in this case, it will just create another ALB/NLB and you may not want that.
The non-Kubernetes way which is the way might work better for you is just to do it from AWS itself and modify the ALB/NLB that sends traffic to your nginx ingress.
✌️
To add in Rico's answer.
It's not possible to attach multiple certificates to the Nginx ingress controller or any other ingress with annotation : service.beta.kubernetes.io/aws-load-balancer-ssl-cert.
Closed PR : https://github.com/kubernetes/kubernetes/pull/95208
Issue thread: https://github.com/kubernetes/cloud-provider-aws/issues/80#issuecomment-686722657
It's not working with NLB However if you are using the ALB you can use this annotation
Single cert with ALB
alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-west-2:xxxxx:certificate/xxxxxxx
Multiple certificates
alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-west-2:xxxxx:certificate/cert1,arn:aws:acm:us-west-2:xxxxx:certificate/cert2,arn:aws:acm:us-west-2:xxxxx:certificate/cert3
alb.ingress.kubernetes.io/certificate-arn specifies the ARN of one or more certificates managed by ACM
Another Option For NLB
Create an ACM certificate with multiple Wild card domains and use this single Cert with ingress. this will work with NLB also
So your ACM certificate will be storing certs for multiple domains example
*.example.com
*.hello.io
*.so.in
single ACM certificate now you can use with NLB Ingress, and no need worry about attaching multiple certs.
Option : 2 using cert-manager and storing cert in secret
It would be better if you planning to use multiple domains use wild card certificates with Cert-manager store them into Secret of K8s and use it as pluggable solution with ingress.
I think both the other answers are old and not valid now as I got confused reading those as they mention that its not possible to add 2 certs for NLB. However, you can easily add certs on nginx ingress controller with the annotation in a comma separated string. I myself have deployed AWS LB Controller and using nginx ingress controller to deploy NLB. My annotations on nginx ingress controller service
service.beta.kubernetes.io/aws-load-balancer-ssl-cert=arn:aws:acm:eu-central-1:123456:certificate/123abc,arn:aws:acm:eu-central-1:123456:certificate/123xyz
and I have 2 ACM certs attached to my load balancer both with separate URLs
abc.com
xyz.com
I am using the prepackaged Istio on GKE, which comes with a pre-configured ingress gateway that takes a single SSL certificate.
Is there a way to add additional certificates to Google's standard configuration which will survive reset by their configuration tool and persist through upgrades?
The Istio docs describe how to specify multiple certificates if installing the ingress gateway yourself. I could do this if I configured a separate ingress gateway, but would like to use the default one if I could. Google's docs do not list certificates as a modifiable property.
I found a post from Medium which explains how to use multiple Certificates for Istio through Cert-Manager, Let's Encrypt for TLS and Certificate Merge.
Could you please take a look at the post and let me know if it's useful?
In the deployment scenario I am using, there is a single ELB, balancing multiple EC2 instances, serving a multi-domain system. Since ELB doesn't support multiple SSL certificates on HTTPS, ELB port 443 is configured as TCP 443, which points to port 9443 on EC2 instances (with Proxy Protocol enabled).
This way installing multiple SSL certificates using a single ELB is possible, as described in this blog post.
The problem now is that stickiness policy cannot be associated only with a listener with HTTPS as frontend protocol.
However, I cannot use HTTPS as frontend protocol, because of the multiple domains/SSL certificates point made above.
What would be the best way to handle the issue?
As it was suggested by #Castaglia, I ended up with configuration of separate ELBs, one for each domain/certificate pair.
In the auto scaling configuration, you have option to specify multiple ELBs.