I'm trying to move an existing backend over to Google Cloud Run. Some of the endpoints (under a specific subdomain) require SSL Client Authentication. The way this is handled at the moment is on Nginx configuration level:
server {
listen 443 ssl http2;
server_name secure.subdomain.example.com;
[...]
# SSL Client Certificate:
ssl_client_certificate xxx.pem;
ssl_verify_client on;
[...]
location / {
if ($ssl_client_verify != "SUCCESS") { return 403 $ssl_client_verify; }
[...]
}
}
What would be the best approach to handle SSL client certificate authentication with Google Cloud Run? I assume this would need some sort of load balancer on the correct network layer and with support for cloud run?
Of course there is always the option to authenticate in the ExpressJS app, but if possible I would prefer it to happen before even reaching Cloud Run.
What would be the best approach to handle SSL client certificate
authentication with Google Cloud Run?
Cloud Run does not support SSL Client Certificate Authentication. The GFE (Google Front End) proxies requests for Cloud Run applications and does not pass-through requests. The only Google Cloud load balancers that support SSL client certificates are based on Google Maglev.
None of the Google Cloud managed compute services support SSL client certificate authentication (mutual TLS authentication).
Consider using Compute Engine instead of Cloud Run.Then configure Nginx to handle client authentication. For load balancing, use a pass-through load balancer such as External TCP/UDP Network Load Balancer
You can't achieve that with Cloud Run. The SSL connection is terminated at the load balancer side (On an HTTPS load balancer, or on the Cloud Run built-in load balancer). You only receive HTTP traffic to your service.
Indeed, you can add additional security information, in the request header, but you lost the SSL flavor.
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
I have set up a Google Cloud Http(s) Load Balancer with Frontend of Https and Backend of Http. I am getting the following error through Postman for my service:
Error: write EPROTO 140566936757448:error:10000410:SSL routines:OPENSSL_internal:SSLV3_ALERT_HANDSHAKE_FAILURE:../../third_party/boringssl/src/ssl/tls_record.cc:594:SSL alert number 40 140566936757448:error:1000009a:SSL routines:OPENSSL_internal:HANDSHAKE_FAILURE_ON_CLIENT_HELLO:../../third_party/boringssl/src/ssl/handshake.cc:603:
The VM itself works if I call it directly with Http. Is this setup possible or what am I missing?
SSLV3 is not supported by HTTPS load balancer. Please, use a newer (and more secure) version to call your HTTPS load balancer
We have 10 different kubernetes pods which runs inside a private VPN, this pods are HTTP serving endpoints(not HTTPS). But this services would interact with HTTPS serving endpoints. Logically to make call to HTTP-S serving endpoints from a HTTP serving pod , the SSL server certificate trust is required. Hence we decided to store the SSL certificates inside each HTTP Service pods to make call to HTTPS serving pods.
I am wondering is there are any alternative approaches for managing SSL certificates across different pods in Kubernetes cluster? How about kubeadm for K8s certificate management ... any suggestions ?
This is more of a general SSL certificate question rather than specific to Kubernetes.
If the containers/pods providing the HTTPS endpoint already have their SSL correctly configured and the SSL certificate you are using was purchased/generated from a known, trusted CA (like letsencrypt or any one of the known, trusted certificate companies out there) then there is no reason your other container apps that are making connections to your HTTPS endpoint serving pods would need anything special stored in them.
The only exception to this is if you have your own private CA and you've generated certificates on that internally and are installing them in your HTTPS serving containers. (Or if you are generating self-signed certs). Your pods/containers connecting to the https endpoints would then need to know about the CA certificate. Here is a stackoverflow question/answer that deals with this scenario:
How do I add a CA root certificate inside a docker image?
Lastly, there are better patterns to manage SSL in containers and container schedulers like Kubernetes. It all depends on your design/architecture.
Some general ideas:
Terminate SSL at a load balancer before traffic hits your pods. The load balancer then handles the traffic from itself to the pods as HTTP, and your clients terminate SSL at the Load Balancer. (This doesn't really tackle your specific use case though)
Use something like Hashicorp Vault as an internal CA, and use automation around this product and Kubernetes to manage certificates automatically.
Use something like cert-manager by jetstack to manage SSL in your kubernetes environment automatically. It can connect to a multitude of 'providers' such as letsencrypt for free SSL. https://github.com/jetstack/cert-manager
Hope that helps.
new Cloudflare user here.
I have an A record, but I don't have the any cert installed on the server that I'm pointing to. I know you can proxy through CF and CF has free SSL set up on the proxy endpoint.
My question is: how does CF connect to my endpoint securely? Or am I understanding incorrectly?
My understanding:
me --[SSL-enabled]--> CF Proxy --[no SSL?]--> my server
The short answer is that CloudFlare doesn't connect to your endpoint securely through their free SSL certificate.
CloudFlare offers three types of SSL setups, with 'flexible' being the default:
Flexible: They'll serve content over HTTPS from their infrastructure, but the connection between them and the origin is unencrypted
Full: Still HTTPS from CloudFlare to the browser but they'll also talk HTTPS to the origin although they won't validate the certificate
Full (strict): CloudFlare issues the certificate and they'll intercept your traffic, but then it's all HTTPS to the origin and the cert is validated as well
While a flexible, free SSL certificate from CloudFlare will show your visitors a secure HTTPS padlock, this method of SSL only exists between CloudFlare and the ISP, not between CloudFlare and your server. The flexible certificate is shared between 50 different domains (revealing each of these to your visitors), though does indeed protect from common attacks such as WiFi snooping.
Flexible:
Full:
A Full certificate also encrypts traffic between CloudFlare and the origin, but CloudFlare doesn't validate the cert. A strict certificate remedies this.
If unsure on the quality of your SSL, I'd recommend checking out Qualys' SSL Labs test.
For more information see Troy Hunt's article on the issue.
how does CF connect to my endpoint securely?
Since you don't offer a secure connection to your endpoint Cloudflare cannot use a secure connection to your endpoint. This is, only the connection between the browser and Cloudflare is secure but not the final connection from Cloudflare to your server.
See also the description of the Flexible SSL option you are talking about which explicitly points of the problems:
Flexible SSL: A Secure connection between your visitor and Cloudflare, but no secure connection between Cloudflare and your web server. ... This option is not recommended if you have any sensitive information on your website. ...It should only be used as a last resort if you are not able to setup SSL on your own web server. ...
I'm looking for information on how to configure an HTTP load balancer or proxy server (squid, nginx, HAProxy, etc.) to handle the SSL for my domain as an alternative to adding Heroku's SSL Endpoint add-on for $20/month.
The load balancer or proxy server would terminate the SSL connection and the last leg to the heroku server would be over http.
SSL is now included on all paid dynos. Thus, you pay only the certificate price.
https://blog.heroku.com/ssl-is-now-included-on-all-paid-dynos
A new add-on was added a few short months ago called Expedited SSL. This add-on provides you with both the registration of an SSL certificate along with the endpoint for serving it, whereas SSL Endpoint is only the endpoint used to serve the SSL certificate you've already purchased from an SSL provider.