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.
Related
I'm trying to understand the security implications for using self-signed certificates for a Kubernetes validating webhook.
If I'm understanding correctly, the certificate is simply used to be able to serve the validating webhook server over https. When the Kubernetes api-server receives a request that matches the configuration for a validating webhook, it'll first check with the validating webhook server over https. If your validating webhook server lives on the Kubernetes cluster (is not external) then this traffic is all internal to a Kubernetes cluster. If this is the case is it problematic that the cert is self-signed?
If I'm understanding correctly, the certificate is simply used to be
able to serve the validating webhook server over https.
Basically yes.
If your validating webhook server lives on the Kubernetes cluster (is
not external) then this traffic is all internal to a Kubernetes
cluster. If this is the case is it problematic that the cert is
self-signed?
If the issuing process is handled properly and in secure manner, self-signed certs shouldn't be a problem at all. Compare with this example.
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 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/
I have an rest HTTP endpoint that is sitting outside of AWS, but I want to use AWS API Gateway to proxy through to that endpoint. What would be the best way to only allow requests to the HTTP endpoint to process that come through the API gateway?
One possibility would be to make your non-AWS endpoint require a client TLS certificate. AWS API Gateway can generate client certificates, and your non-AWS endpoint can:
require a client certificate (if not provided, then ignore / don't allow)
use the API Gateway cert public key to verify the client is your API Gateway.
This would give you good assurance that traffic to your non-AWS endpoint is only coming through the AWS API Gateway, so long as the client certificate generated by AWS is not compromised.
From the AWS FAQs:
Q: Can I verify that it is API Gateway calling my backend?
Yes. Amazon API Gateway can generate a client-side SSL certificate and make the public key of that certificate available to you. Calls to your backend can be made with the generated certificate, and you can verify calls originating from Amazon API Gateway using the public key of the certificate.