Really? How do you make it so that different modules in the same process have different IAM credentials and can't get the credentials for a different module? How do you make sure a buffer overflow in you analytics module doesn't allow an attacker to read memory from you login module? How do you make sure an RCE in your image upload code doesn't give an attacker access to credentials for your payment processor?

Maybe it is possible with some low-level system calls, but at the very least it is a lot more difficult than using separate VMs or containers.

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.

> 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".

> 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")