5 ms·

Giving me an example that is created to work explicitly at system/container level isn't the "gotcha" you think it is.(IAM profiles have their own limitations)

Giving me an example that is created to work explicitly at system/container level isn't the "gotcha" you think it is.(IAM profiles have their own limitations) Separate process vaults, HSMs and other techniques of offloading security credentials - are the same for microservice architecture, as "monolith". The implication that anything other than a microservice architecture must be exclusively an uber executable doing literally everything, is naive.

thayne 4y ago
> Separate process vaults, HSMs and other techniques of offloading security credentials How do give one module access to the vault/HSM without also giving any other code in the same process access? Even in the event of a security compromise. And that still doesn't address the problem of a vulnerability anywhere in the monolith potentially exposing any sensitive data in processes memory (such as user data including password). > The implication that anything other than a microservice architecture must be exclusively an uber executable doing literally everything, is naive. Ok, replace "microservices" with "service oriented architecture". I'm comparing specifically against a monolith where you have an "uber executable doing literally everything".
- JAlexoid 4y ago
  > I'm comparing specifically against a monolith where you have an "uber executable doing literally everything". I doubt that anyone here is advocating for a system that it literally everything in one OS process. I bet even you would say that a process with a RDMBS connection is a monolith, even though it doesn't fit your definition. As for modules - they can run as a separate process on the same machine, to isolate security critical elements. Conversely, I doubt that any reasonable microservices architecture has every instance of a microservice in its own subnet with a firewall and strict network access permissions... including one off generated API keys. Most, at best, use a static API key per microsoervice inside one large "secure" network... which leads me back to my point - they're not exactly easier to secure. Methods may differ a little bit, but the techniques are the same. Then your example of a buffer overflow is going to be as bad for microservices, as for monolith. Unless you're going to invest in a variety of systems, programming languages and OSes in your stack - your one buffer overflow, turns into buffer overflow on every other microservice... making your claim of "easier to isolate" a little bit delusional. (Classic example of Log4J bug, where monolith or microservices - once you're breached "game over")

thayne 4y ago

> Separate process vaults, HSMs and other techniques of offloading security credentials How do give one module access to the vault/HSM without also giving any other code in the same process access? Even in the event of a security compromise. And that still doesn't address the problem of a vulnerability anywhere in the monolith potentially exposing any sensitive data in processes memory (such as user data including password). > The implication that anything other than a microservice architecture must be exclusively an uber executable doing literally everything, is naive. Ok, replace "microservices" with "service oriented architecture". I'm comparing specifically against a monolith where you have an "uber executable doing literally everything".

JAlexoid 4y ago
> I'm comparing specifically against a monolith where you have an "uber executable doing literally everything". I doubt that anyone here is advocating for a system that it literally everything in one OS process. I bet even you would say that a process with a RDMBS connection is a monolith, even though it doesn't fit your definition. As for modules - they can run as a separate process on the same machine, to isolate security critical elements. Conversely, I doubt that any reasonable microservices architecture has every instance of a microservice in its own subnet with a firewall and strict network access permissions... including one off generated API keys. Most, at best, use a static API key per microsoervice inside one large "secure" network... which leads me back to my point - they're not exactly easier to secure. Methods may differ a little bit, but the techniques are the same. Then your example of a buffer overflow is going to be as bad for microservices, as for monolith. Unless you're going to invest in a variety of systems, programming languages and OSes in your stack - your one buffer overflow, turns into buffer overflow on every other microservice... making your claim of "easier to isolate" a little bit delusional. (Classic example of Log4J bug, where monolith or microservices - once you're breached "game over")