"I Thought You Would Secure That S3 Bucket"

"Oops, I forgot to secure that S3 bucket."

At the same time, cloud-native applications are more complex by their very nature. It’s what makes them scalable and fast, but this also means that no single person knows the whole thing anymore, and things fall through the cracks between job descriptions.

This is different from before, when a team-lead or more experienced dev would judge security-related aspects and veto riskier solutions.

"I thought you would secure that S3 bucket."

There are many solutions to this problem but, of course, it means the company needs to sit down and think about the risks and then try to mitigate them. Security by design as a principle needs to grow in awareness in the development community as the world relies more and more on devs and cloud native applications.

Devs need the training and the constant reminder that they are now the first line of defense against attacks. On the other side, we don’t have script kiddies anymore, we have merciless, sophisticated state actors that will not forgive any mistake. Just look at the Microsoft Exchange hack.

Kubernetes brings back separation of concerns

One final topic that I might like to add is that Kubernetes should be considered instead of working with the cloud provider’s services directly. For example, one could use Kubernetes services instead of AWS ELB, Kubernetes volumes instead of S3, and so on.

This allows the developer to use an abstract, pre-authenticated service just like S3 or ELB, but moves the responsibility for configuring them clearly to the DevOps team.

This separation of concerns will be crucial in eliminating the confusion regarding who does what in relation to platform security and has the added benefit that you can take your toys and migrate to another service provider (such as Bigstep) if you want to, for added performance, security, data locality, better support, to name a few.