Secure Cloud-Native Development: Avoid The Top Five Security Pitfalls

Build secure cloud-native applications by avoiding the top five security pitfalls we lay out in our Secure Cloud-native Development Series.

The reason organizations are embracing cloud-native development is clear: AWS reports those who migrated saw an average of 20% infrastructure cost savings and 66% increase in administrator productivity. Moving your development process to the cloud offers these benefits and many others, but it also offers a whole new set of security challenges. This series is aimed at helping developers create secure infrastructure for modern, cloud-native applications. You’ll learn the top five security pitfalls you can encounter when building applications in the cloud and how to avoid them.

Why take the time to learn about securing cloud-native development?

As modern applications are integrated closely with cloud technologies (like containers and serverless), developers must now understand these technologies and how to implement them securely from the start. The reason for this is that, like most things that involve security, when they’re done correctly, no one notices. However, when done incorrectly, you may see something along the lines of a dumpster fire.

Applications in today’s landscape are no longer just source code residing on an Apache server in a data center. Though many organizations still have applications with similar architecture, many teams are seeing the benefits of “moving to the cloud.”

This move to the cloud offers an opportunity to create fresh infrastructure that’s secure from the start. If you’re planning to just “lift and shift” your servers up to a public cloud like Azure or AWS, you’re not really gaining the benefits the move to the cloud has to offer. Though it’s a feat to securely rearchitect an application (and its associated services) to use smaller microservices, it is well worth the time and effort because you gain the ability to scale and deploy faster. However, this scale comes with a cost of a broader attack surface to manage. 

Additionally, using cloud-native technologies that are managed by the cloud provider allows you to use a service without having to maintain it. For instance, rather than hosting your own virtual servers to run a Kubernetes cluster, you can utilize a managed version of it where we no longer need to maintain the underlying hardware or software.

We recognize that all of this is much more easily said than done, and that’s why we created this series.

What will this series cover?

In this blog series, we will discuss our topfivepicks of the many security flaws one can introduce with cloud technologies. We picked these because they are each an essential pillar of securing cloud-native development. This series will cover the following five categories of flaws that can be introduced when deploying to the cloud.

1. Secure Container Images

Choosing a secure container image is your baseline. This is the image you build everything on. You could pick the easy route, which usually involves picking a more bloated container that has many packages you “might” need, but also many packages you don’t need. For example, you could choose an ubuntu:20.04 or centos:7 container, as both allow for easy package installation for your application’s dependencies. However, these bloated container images, even the latest, contain Common Vulnerabilities and Exposures (CVEs) that you'll have to deal with. A slim image is going to help in more ways than just CVEs. We will discuss choosing these images in Part 1: Choosing Secure Container Images.

2. Logging

Logging is a critical component for security, troubleshooting, and operations, as well as tuning for efficiency. This may or may not be shocking, but we have heard, “We don’t have logging on that service…”, more times than we can count. Having logging on a service is critical for the kind of visibility that is needed for security that’s efficient. Overall, logging is much easier to build in than to add later as an after-thought. In Part 2: How to Enable Logging, we will look at different logging components and their security capabilities within AWS and Azure clouds.

3. Storage Access (i.e., S3 Buckets)

Storage is a primary component of cloud services. In AWS-land, S3 storage is utilized throughout. However, the question you need to ask is: do we have a handle on access control of our buckets? Many breaches continue to happen because of misconfigured bucket ACLs. Are you really deploying what you intend? We will discuss these common ‘gotchas’ in Part 3: Managing Storage Access.

4. Encryption

Defining encryption should be enabled for all your resources regardless of the level of sensitivity. It’s not only good hygiene, but it’s also a requirement when you’re running in the cloud. Not encrypting your data or resources is like not locking your front door because your community has a gate. Additionally, in most cases if resources are not encrypted from the start, they would need to be destroyed and recreated. This can also be the case with going back and encrypting storage objects. This pillar will be discussed in Part 4: Easily Enable Encryption.

5. Secrets Management

Lastly, we have secrets management. Within your deployment files, you need to define a means to authenticate the resource, but this is perhaps the one category that can be done a hundred different ways. We will discuss different kinds of good, better, and best options. However, all are better than hardcoding passwords into Terraform files, even if they will be changed momentarily by the configuration management tool (don’t do this!). Part 5: Secrets Management Best Practices will discuss which tools we can use for securely managing secrets.

Throughout the series, for each category, we will show: 

• Potential pitfalls you can run into with each category 
• Why it is important to pay attention to them from a security perspective 
• Which tools are available to help you

Click here to go to the first part of the series, and learn what you need to keep in mind when choosing a secure container image for your applications.