Technically Speaking

The Official Bigstep Blog


"I Thought You Would Secure That S3 Bucket"

As a Romanian Real Estate company recently found out the hard way, diving head first into the cloud can have some devastating consequences, at least from a security perspective, leaving your company much more exposed than it was in a self-managed environment.

This is because security was typically done at the perimeter of your stack, by (internal or external) sysadmins/DevOps, whereas cloud-native solutions security needs to be done at the component level by - or at least in conjunction with - developers.

The difference is important as developers that suddenly find themselves moving into an unfamiliar territory don’t spend enough (any?) time understanding the security characteristics of the component they are using since that was not their job and most likely have more pressing deadlines to meet.

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

Got a question? Need advice? We're just one click away.
Sharing is caring:TwitterFacebookLinkedinPinterestEmail

Readers also enjoyed:

Kubernetes Benchmark: Bigstep vs AWS [part 1]

This two-part study compares the performance aspects of running a Kubernetes environment on two different cloud providers: Bigstep Metal Cloud versus…

Kubernetes on Bare Metal Cloud

Kubernetes is gaining increasingly more ground in many companies and many applications. Most of you already use GCP and AWS to deploy a Kubernetes cluster…

Leave a Reply

Your email address will not be published.

* Required fields to post your comments.
Please review our Privacy Notice in order to understand how we process your personal data and what are your rights in this respect.