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
Related
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.
I'm trying to get a SOAP web service set up with Spyne. So far, so good. I have a web service,but not I need to secure the data in-flight with SSL. Is there a way to attach a certificate to the Spyne app so my connection is encrypted?
Thank you!
I've looked at the help guides on Spyne.io and have not found the info I need about SSL.
You need to use either a reverse proxy setup (like nginx) that will terminate the SSL connection outside of the Python process (recommended) or you have to use OpenSSL (or similar) bindings to create an SSL socket for yourself.
You can use twisted's ssl capabilities via the WsgiApplication. Have a look: https://twisted.readthedocs.io/en/twisted-17.9.0/web/howto/using-twistedweb.html
Is there built-in support for enabling SSL on Azure Container Instances? If not, can we hook up to SSL providers like Lets Encrypt?
There is nothing built-in today. You need to load the certs into the container and terminate SSL there. Soon, we will enable support for ACI containers to join an Azure virtual network, at which point you could front your containers with Azure Application Gateway and terminate SSL there.
As said above, no support today for built-in SSL when using ACI. I'm using Azure Application Gateway to publish my container endpoint using the HTTP-to-HTTPS bridge. This way, App Gateway needs a regular HTTPS cert (and you can use whichever model works best for you as long as you can introduce a .PFX file during provisioning or later during configuratiorn) and it will then use HTTP to talk to your (internally facing) ACI-based container. This approach becomes more secure if you bind your ACI-based container to a VNET and restrict traffic from elsewhere.
To use SSL within the ACI-container you'd need to introduce your certification while provisioning the container, and then somehow automate certificate expiration and renewal. As this is not supported in a reasonable way, I chose to use the App Gateway to resolve this. You could also use API Management but that is obviously slightly more expensive and introduces a lot more moving parts.
I blogged about this configuration here and the repo with provisioning scripts is here.
You can add SSL support at the API Gateway and simply configure the underlying API over HTTP.
You will need the secrete key to execute above api method!
You can access the underlying API hosted at the Azure Container Instance. This method does not require jwt token as this is a demo api.
I am looking for ways to authorize each individual client request made through the rest proxy. Is there a mechanism to integrate the proxy with existing Kafka ACL's?
I already configured the HTTPS authentication with client certificates so I have a unique client token I can include with every request for authorization purpose. My preferred approach would be to introduce a custom servlet filter that integrates with Kafka ACL system using something like SimpleAclAuthorizer. Unfortunately, the Rest Proxy is not a standard Web application but runs the embedded Jetty, so configuration is a bit more convoluted.
My question is, what is the least intrusive way to to accomplish this?
Thank you in advance.
You can configure a single kafka client credentials for the REST Proxy to use when connecting to Kafka, but today you cannot pass through the credentials of each HTTP(s) client separately. That feature is being worked on and will likely come out in a future release.
RBAC is available now in Confluent Kafka but it is still in preview here is the link
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.