I'm aiming at applying an api pattern as can be described for instance on https://medium.com/design-microservices-architecture-with-patterns/api-gateway-pattern-8ed0ddfce9df
As it mentions, "since API Gateway handle client request in centralized placed, its best practice to implement cross cutting functionality on the API Gateways" such as authentication and authorization.
I'm wondering about MITM attacks.
We can make sure microservices are only called by the gateway when whitelisting only the gateway IP, that would be a network safety. But I think this network-level protection shouldn't exclude application-level protection. Only another security at application level (mutual TLS?) would protect the microservices from MITM attacks.
So as a conclusion for a most-perfectly-safe application platform, is api offloading pattern really recommended? And if mitm is a real risk then what's best to add to the pattern to make it real safe?
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.
Looking for a simpler approach for authentication between microservices in Kubernetes.
I have dug some previous discussion. I am aware that it has many trade-offs. Depend on the situation, there could be many different approaches.
Mutual TLS is probably very safe. There is a tool Istio. But I think it has a learning curve and probably overkill for my application.
My application is simple. It does not contain any privacy or critical data. I would prefer a much simpler approach to meet the tight deadline of release cycle.
Is there any approach that utilize Kubernetes secret and do not need a SSL handshake?
For example, keep a pair of asymmetric key in kubernetes secret. Then when service A what to access service B. service A sign the request with timestamp, send the signed result to service B. So that service B could decrypt and check?
I have several WebApp clients that will be used to serve authenticated users via TLS. On the backend these WebApps communicate to a CloudService via NetTCP using WCF on cloudapp.net endpoints. Both sets of resources are on the same Azure subscription, resource group and geographic location.
My question is in regards to both performance as well as security:
1. Will traffic between the WebApp and CloudService resources stay within the Azure infrastructure to maintain the best performance? If not is there a way to ensure the fastest possible communication between the WebApps and CloudServices?
2. If the traffic does remain internal then are there any concerns about securing the traffic when these calls are made or can I safely keep the calls as http:// requests since they will not be made on any public channels?
3. Are there any other security or performance concerns regarding this scenario?
Not, unless you implement VNet integration and integrate your WebApp into the CloudService VNet.
Well, it depends on how paranoid you are, if you absolutely trust Azure, you can use HTTP, without S. I'm not sure how secure that is, but I can imagine no one would say: "Use HTTP, Azure (or whatever) is secure enough".
If everything is in one region, it should be fine, theoretically.
I have a microservices based web app. Microservices communicate with each other via a REST API exposed. I want an easy, yet secure solution to secure communication between my microservices. I've already used JWT protocol to secure my user-services communication but I can't figure out the best way to secure server-server communication.
Update:
I want an easy way to authenticate APIs. Is is a good way to hardcode key and secret or put them in configurations files and then use them to authenticate to an other end point?
I've heard about OAuth2 protocol but I'm afraid it's an overkill for my need.So What can be the easy and secure way to authenticate APIs?
You should use HTTPS in order to make communication between servers secure. As far as point to point security (transport layer security) is concerned this is the way to go.
But keep in mind that this still doesn't mean that you'll have message-level security (end-to-end security). Intermediaries (i.e. service agents or other services and applications) along the message path will be able to see what is in the message content while processing it.
REST relies on the uniform contract provided by HTTP, so you cannot use the advanced features of WS-Security as you would have with SOAP. The security features of SOAP provide a wider spectrum of options, so if security is key in your case, you should definitely check SOAP web services out.
Also, take a look at this question. It's relevant to yours and I'm sure you'll find it helpful.
Hope this helps!
I have created a REST API that uses Basic HTTP authentication. Is is restricted to SSL only. Now that it is implemented I am hearing criticisms that Basic HTTP over SSL is not secure. It would be detrimental to the project for me to "stop the press" and it would be outside the scope of some of my clients skill set to use OAuth, etc. I need to understand the risk and rewards of this methods. Any examples of big names using Basic HTTP auth would be helpful as support also.
Basic HTTP authentication over SSL is basically secure, with caveats. Security issues predominantly arise from the use of Basic auth without SSL, in which case, the username and password are exposed to a MITM. In a browser, there are also problems with expiring credentials, but this isn't so much of an issue for REST services.
perhaps I am mislead but I don't see a problem with SSL only BASIC... esp. not with a stateless API.
If the callers are forced to use a SSL-sniffing proxy then BASIC means that the password is available in cleartext to the proxy... in this specific case Digest would be better (even with SSL) because the proxy wouldn't know the password (digest means challenge response...).