DEV Community

Discussion on: Microservices communications. Why you should switch to message queues.

 
orubel profile image
Owen Rubel

You haven't answered anything. You dodge. You merely state 'this is not an api' but neglect to answer how AMQO provides equivalent services to what HTTP provides

Thread Thread
 
dkbrummitt profile image
Delicia Brummitt • Edited

Hi Mateo,
Great article. Addressing the security aspect for any future readers exploring messaging for their Microservice architecture.

About REST

  1. REST is an architectural pattern that is by convention used over HTTP but does not have to be over HTTP.
  2. A RESTful Web API is an API over HTTP that follows the REST architectural pattern.
  3. In theory, you could have a RESTful SOAP (but OMG why would you do that to yourself???). Here is an example of a RESTful UDP RFC coap.technology/

About Security

  1. IMO it is probably best practice to secure your Microservice even when communicating with other microservices. Why? The safest possible stance is to assume that incoming data is harmful; so you authenticate, authorize, and scan for an attack.
  2. Do most microservices do this? I don't know. But I would be willing to bet that any multi-billion dollar company that deals in personal identifiable information(PII) or financial data does. If they didn't I would avoid them like the plague.
  3. How to do it? Here are a few ways:
    • some type of firewall and/or ACL combined with
    • place some services on the private network (no access to public network)
    • entire message is encrypted with a shared secret between the services. Each service has its own unique secret.
    • single-use, short-lived token used in headers or a part of the body. (usually when there is money involved, credit cards etc)
    • signed certificates (with passwords)
  4. Would I secure every microservice? Probably not.
  5. When would I definitely secure a micros service? Any service that touches PII/financial data, OR tangentially touches PII/financial data. For example:
    • Service A deals with credit cards (secure it).
    • Service B talks to Service A (secure it).
    • Service C does not talk to Service A nor Service B (may not secure it).
    • Service E talks to Service B but not Service A (secure it)
    • so on and so forth.

Can this approach lead to a slower microservice? Yes, but there are occasions where security is more important than latency.

NOTES:
- The methods discussed above are top of mind solutions and not specific to any type of transport(HTTP, AMQP, SQS, etc) between microservices...
- Google "defense in depth microservices" for more info on item 5 of About Security.
- Checkout what OWASP has to say about security.

Lastly, I love using messaging for my microservices. Especially where high volume is a concern.

Happy Coding!!

Thread Thread
 
matteojoliveau profile image
Matteo Joliveau

Very good points. In light of the main topic (AMQP-based microservices), advanced brokers like Rabbit do have ACL systems that can and should be used to restrict what each service can do. Maybe you have a topic where sensible data are exchanged and only some services can access them, with Rabbit you can set up ACL rules to block read access to those topics.

Or even segregate them on their own virtual hosts (kinda like namespaces or tenants) so that they are completely separated. Services don't need to know that this kind of access control is happening, it's enforced by the broker itself (which I prefere compared to security-aware microservices).