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/
Related
I am using azure kubernetes for backend deployment. I have 2 URLs one is API URL(api.project.com) and other one is BFF URL(bff.project.com).
From Web application, instead of calling API URL(api.project.com) they use BFF URL(bff.project.com) which internally calls the API URL(api.project.com) and sends the response.
I now want to restrict direct usage of API URL(api.project.com) even from any REST API Clients(like postman, insomnia, ...) it should only work when triggered from BFF URL(bff.project.com).
We have used nginx-ingress for subdomain creation and both the URLs(BFF and API) are in same cluster.
Is there any firewall or inbuilt azure services to resolve the above mentioned problem ?
Thanks in Advance :)
You want to keep your api private, only accessible from another K8S service, so don't expose it using your ingress controller and it simply won't be accessible outside K8S to any client.
This means that you lose the api.project.com address (although you can get that back if you really want to, it seems unnecessary). The BFF would then access the API via the URL: http://<service-name>.<namespace>.svc.cluster.local:<service-port>, which in your case might be:
http://api.api_ns.svc.cluster.local
Assuming you haven't used TLS (http rather than https), the service is called api, it's running on port 80 (which it should be) and the namespace is called api_ns.
Should you need to provide temporary access to the API for developers to use, say, postman, then they can use port-forwarding to provide that in a dev environment without allowing external access all the time.
However, this won't restrict access to BFF alone. Any service running in K8S could access the API. If you need/want to restrict things further, then you have a lot of options.
I cannot for the life of me get the AWS API Gateway HTTP Proxy to work, i.e. redirect http://<my-domain>.com to https://<my-domain>.com. Here is how I set it up:
Using the Test functionality on the ANY method inside the resource works. But if I simply do curl http://<my-domain>.com or run http://<my-domain>.com in Chrome, it fails to connect; https://<my-website>.com works just fine. I'm driving myself crazy trying to figure out what I'm missing here; it seems like it should just redirect http://<my-domain>.com to https://<my-domain>.com, but it doesn't (even on different devices).
So, it turns out that API Gateway's HTTP Proxy allows HTTPS traffic to go to an HTTP endpoint, but not the reverse. In fact, API Gateway won't even establish a connection on port 80; from the FAQ:
Q: Can I create HTTPS endpoints?
Yes, all of the APIs created with Amazon API Gateway expose HTTPS
endpoints only. Amazon API Gateway does not support unencrypted (HTTP)
endpoints.
API Gateway doesn't support unencrypted HTTP traffic. Here are the possible options you can do to secure your website:
If you have access to the server that hosts the website, install an SSL certificate to the webserver.
If the website is hosted on EC2, you can set up a load balancer and let it do the SSL termination.
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.
Initial disclosure:
I’m new to nginx and reverse proxy configuration in general.
Background
I have a Swagger-derived, FOSS, https-accessible REST API [written by another party] running on a certain port of an EC2 CentOS 7 instance behind an nginx 1.16.1 reverse proxy (to path https://foo_domain/bar_api/); for my purposes, this API needs to be reachable from a broad variety of services not all of which publish their IP ranges, i.e., the API must be exposed to traffic from any IP.
Access to the API’s data endpoints (e.g., https://foo_domain/bar_api/resource_id) is controlled by a login function located at
https://foo_domain/bar_api/foobar/login
supported by token auth, which is working fine.
Problem
However, the problem is that an anonymous user is able to GET
https://foo_domain/bar_api
without logging in, which results in potentially sensitive data about the API server configuration being returned, such as the API’s true port, server version, some of the available endpoints and parameters, etc. This is not acceptable for the purpose, from a security standpoint.
Question
How do I prevent anonymous GET requests to the /bar_api/ endpoint, while allowing login and authenticated data requests to endpoints beyond /bar_api/ to proceed unhindered? Or, otherwise, how do I prevent any data from being returned upon such requests?
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.