We have requirement where we have to access some external APIs that are exposed to HTTP/2 (only) from our microservices (EKS kubernetes cluster, Perl based) through SQUID Proxy.
It seems, SQUID proxy doesn't support HTTP/2 so we are trying to get some alternative solution like:
Different proxy to support HTTP/2 outbound call
Or convert HTTP1.1 to HTTP/2
Could someone suggest the best alternative as per their experience on this and let me know the proxy information which will work in this scenario?
Many Thanks in advance.
Related
Question
Is there a specific reason why API Gateway requires the HTTP/S client to support SNI?
Which AWS document clearly states the SNI requirement?
About Question 2
I believe SNI is an extension to TLS and TLS version 1.2 does not require to support SNI as far as I looked into RFC. TLS 1.3 requires it as mandatory but it looks AWS API Gateway has not adopted 1.3 yet as per the AWS document Supported SSL/TLS Protocols and Ciphers for Regional, Private, and WebSocket API Endpoints in API Gateway.
Hence, I suppose enforcing SNI, if AWS API Gateway actually does so, seems to be AWS specific requirement or limitation to be clearly noted, but so far I could not find the AWS documentation stating as such.
Hence I believe there should be an AWS documentation which states below, but please correct if wrong.
HTTP/S client to use API gateway must support SNI
For SNI unsupported HTTP/S client, use CloudFront (or other ways if available) and do not forward HOST header.
References
Unable to invoke AWS API Gateway GET URL with GPRS connection
API Gateway requires a https connection with a client that support server name indicator (SNI)
How do you add CloudFront in front of API Gateway
You can indeed put CF dist in front of APIG, the trick is to force HTTPS only "Viewer Protocol Policy" AND to NOT forward the HOST header because APIG needs SNI.
As far as I know SNI is not required for the API Gateway, this is a configuration option, but not a requirement.
The documentation I once used to understand a similar scenario clearly states that SNI is an option, but a dedicated IP address can be used to support users that can't use a modern TLS client (browser) which support SNI.
Server Name Indication (SNI) is one way to associate a request with a
domain. Another way is to use a dedicated IP address. If you have
users who can't upgrade to a browser or client released after 2010,
you can use a dedicated IP address to serve HTTPS requests.
Per your question I will assume your API Gateway is configured to use SNI with CloudFront, since as also described in the following API Gateway documentation:
API Gateway supports edge-optimized custom domain names by leveraging
Server Name Indication (SNI) on the CloudFront distribution.
Can we use Two Way SSL feature using AWS API Gateway ? We want to use API Gateway as proxy for kinesis in our real-time streaming application.
Below is my requirement
The client make request to apigateway and apigateway needs to put the data in kinesis streams.
The only way to authenticate the clients is using two way SSL. our clients doesnt support other options.
Currently on-premise F5 loadbalancer does this work for us and we have tomcats running behind F5 placing data into kinesis.
Will i be able to achieve the same using API Gateway ? looks like even aws ELB seems to be not supporting this option.
I have taken a look at below link but this to authenticate API Gateway at server not apigateway authenticating the client.
https://docs.aws.amazon.com/apigateway/latest/developerguide/getting-started-client-side-ssl-authentication.html
Regards
Kalyan
API Gateway can authenticate itself to your back-end with TLS, as you have found, but it does not work in the opposite direction -- it does not support authenticating clients with TLS.
Kubernetes surfaces an API proxy, which allows querying the internal services via eg: https://myhost.com/api/v1/proxy/namespaces/kube-system/services/kubernetes-dashboard/
This is all well, and good. However, for security & compliance reasons, all of our services expose an HTTPS endpoint. Attempting to access them by going to https://myhost/api/v1/proxy/namespaces/default/services/myhttpsservice:3000/ results in
Error: 'read tcp 172.20.122.129:48830->100.96.29.113:3000: read: connection reset by peer'
Trying to reach: 'http://100.96.29.113:3000/'
Because the endpoint, 100.96.29.113:3000 is in fact https.
Is there any way to configure the proxy to apply SSL to specific service endpoints?
(Edit: If this is not currently possible, a relevant github issue link for tracking the feature request is also acceptable answer until it will be)
As documented at https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls, (and pointed out on slack), you can access services behind HTTPS by prefixing the servicename with "https:" ;
Using the example from above, correctly it would be: https://myhost/api/v1/proxy/namespaces/default/services/https:myhttpsservice:3000/
Almost every spring-cloud guide suggests Ribbon with Feign for RPC.
I wonder why Http Rest takes precedence over binary transport protocol for inner micro-services communication behind the API gateway?
What are the binary alternatives to http that support async invocation and all great features that Netflix OSS provides ? (auto-discovery, load-balancing, circuit breaker, retry policy etc.)
Thanks
There is nothing preventing you from using binary RPC like thrift or protobuffs or msgpack with spring cloud. You can use LoadBalancerClient.choose(<serviceId>) to get a host and port you could supply to any network client. Our integrations were the simple rest clients.
Here is a guide that integrates Spring MVC with google protocol buffers.
I'm building a RESTful API which is only accessible by TLS. Where should SSL connection be implemented?
by RESTful API itself, my API is written in golang, which handles SSL easily.
by a SSL reverse proxy, here I'm using nginx.
I would prefer 2nd approach because nginx handles caching and static deliveries better.
Should I implement my API HTTP-only now? In my opinion the system is secure, as long as nginx the reverse proxy is serving SSL only and my API exposes itself to nginx only.
I'm not sure if there is a 3rd approach, while I keep my API SSL only and nginx passes through all requests transparently.
TL;DR: I will choose between the 2nd or 3rd option, depending on the scenario. If you want to publish the API on Internet, never opt for the first one.
The most secure option is the third one: implement your API to allow SSL connections only, and publish to Internet using a reverse proxy anyway.
The pros are the communication with your API will be secure even for internal connections. That will give you protection from internal attackers. The cons are the extra processing load on your server to manage the SSL security and that can impact on the performance.
Anyway, you should look for cost-benefit. That's the reason why it will depend on the scenario. For example, if your API will not be accessed by internal users, but only for internal services, and the load on the server is heavy, you can consider the 2nd approach: plain HTTP por internal communications and SSL termination for Internet.