Would like to know in API Connect, is there a built-in way to check health of an API in Prod? (Like Springboot actuator/health)
If not, best way recommended to implement health check for each of our APIs that we are about to develop in API Connect
Regards,
Martand
API Connect v2018 portals do not have an inbuilt health check, they removed it in v5. There is a RFE to request this functionality.
For the gateway component the best way is to use a tcp_half_open health check on the IP/Port that your gateway is listening on. Note it has to be tcp_half_open otherwise your appliance will be spammed with TLS handshake errors.
This will confirm that the gateway is up and running and serving requests. You should also check the management port is running, as your gateway might not be synchronizing with the APIM and it's possible that it is serving up an old API.
Health checks on an individual API are a little more difficult, and would need to be added as a separate operation in your spec.
Related
We need to protect our reserved instance of IBM API Connect that we have in the Cloud with a WAF of our own company and we do not know if this is possible and the steps to perform or if it is only possible with a WAF of IBM's own cloud.
thanks in advance
For this answer, I'm going to assume you're asking primarily about the DataPower API Gateway.
You can either deploy your own gateway in an environment of your choosing (i.e. you're managing it) or leverage the one that IBM provides to you by default.
If you deploy your own, then you control the networking and adding your own WAF is relatively straightforward.
If you use an IBM-managed gateway, then a little creativity is required. You would likely need to set up a Mutual TLS contract between your WAF and the Gateway. You'd terminate the incoming TLS connection at the WAF (e.g. Cloudflare) and then re-encrypt the traffic from the WAF to the Gateway using the client certificate exchange. You'd potentially need to apply a Mutual TLS-enforcing profile to each deployed API on the Gateway. In this scenario, no client can call an API on your gateway without the proper TLS client key/certificate in hand.
You may want to open a support ticket for further/deeper assistance on this topic.
I want to to use an API gateway like Traefik to protect my apps deployed in CF. E.g. by only allowing requests from the internet to the gateway and restrict the apps behind to internal traffic only (probably via route configurations).
Unfortunately, I could not find any guidance how such a setup could be achieved in CF.
I have an AWS environment that seems to lose connectivity to a server we are connected to via a static route. I want to be able to monitor the situation by sending an HTTP GET request to this remote server. Is this possible using CloudWatch? I am new to AWS and I have not found anything on this topic. My guess is that I am using the wrong lingo. Any guidance would be appreciated.
You can do it using Route53 health check on HTTP or TCP, you don't need to use Route53 as DNS service, you can simply use Health check service and trigger lambda/Cloudwatch/SNS etc.
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-types.html
All calls are made through the tyk proxy to access the remote api.
How to make the remote api available only through the tyk proxy?
The two options mentioned here How to secure remote api for calls not coming from tyk? are very good. Either could work. I don't think there is a setting withing Tyk to limit this. Would have to be done from upstream
More of a theoretical question, but I'm really curious!
I have a two part application:
Apache server hosting my UI
Back-end that services all http requests from the UI
The apache service proxies all http requests from the UI to the server. So, if the user is reasonably adept, they can reverse engineer our API by inspecting the calls in the browser's developer tools.
Thus, how do I prevent a user from using the server API directly and instead force them to use the UI?
The server can't determine whether a call came from the UI or not because a user can make a call to myapp.com/apache-proxy/blah/blah/blah from outside of the UI, apache will get the request and forward it to the server, which will have no idea it's not coming from a UI.
The option I see is to inject a header into the request from the UI, that indicates the origin of the request as the UI. This seems ripe for exploitation though.
To me, this is more of a networking question since its something I'd resolve at the network level. If you run your backend application in a private network (or on a public network with firewall rules) you can configure the backend host to only accept communication from your Apache server.
That way the end-user can't connect directly to the API, since its not accessible to the public. Only the allowed Apache server will be able to communicate with the backend API. That way the Apache server acts as an intermediary between the end-user (client side) and the backend API server.
An example diagram from AWS.
You could make the backend server require connections to be authenticated before accepting any requests from them. Then make it so only the Apache server can successfully authenticate in a way that end users cannot replicate. For example, by using SSL/TLS between Apache and the backend, where the backend requires client certificates to be used, and then issue Apache a private certificate that the backend will accept. Then end users will not be able to authenticate with the backend directly.