When we designed the security model for Google Cloud Build (I do not work there anymore), we decided that containers were not valid security barriers. So, all partitioning was done on the VM and network (configured outside the VM) level. It wasn't hard to convince anyone that this was the right way to handle things.
Why are they not?
ChaosDB Explained: Azure's Cosmos DB Vulnerability Walkthrough
31–35 of 35 posts
Re: ChaosDB Explained: Azure's Cosmos DB Vulnerability Walkthrough
#32Re: ChaosDB Explained: Azure's Cosmos DB Vulnerability Walkthrough
#33Earlier quoted context omitted.
not the op but aws made the same determination. the tl;dr is that the surface area of containerization leads to an unacceptable risk of privilege escalation.
That explains what, but not why
Re: ChaosDB Explained: Azure's Cosmos DB Vulnerability Walkthrough
#34Earlier quoted context omitted.
not the op but aws made the same determination. the tl;dr is that the surface area of containerization leads to an unacceptable risk of privilege escalation.
That explains what, but not why
Re: ChaosDB Explained: Azure's Cosmos DB Vulnerability Walkthrough
#35Earlier quoted context omitted.
What kind of development operation is the question I would ask. Security mostly involves convincing developers to do the right thing with a lot of resistance. Not sure I would assume the security team is behind this, rather than some "risk acceptance" forced on them to launch the feature on time.
Tom This feature is due friday at 4pm but we want to review it so we need it done by lunch. Dont forget to make it secure. Sure its as secure as i was givem time to test security none and none. Thanks Tom great work. See ya at 12. This is more the reality than resistance.