Many of you may be familiar with the shift left security approach in which security is built in at an early stage of the application development life cycle. It is easier and more effective to do it early, rather than discover security issues later in the game, when applications are already deployed. When issues are found after deployment, it is harder to trace their point of origin and who can fix them, increasing the time it takes to fix them.
Using containers has many advantages over traditional software development models, such as faster development and delivery and greater portability. Instead of two or three releases a year, continuous integration and continuous delivery (CI/CD) can rapidly release new versions of code daily, or even several times a day.
Shift Left employs a policy-driven approach to embed security testing at various stages of development and deployment, to detect vulnerabilities, bad configuration, and other issues before they make it into production.
Shift left is designed to help you deploy software that is as vulnerability-free and well-configured as possible, reducing the attack surface. However, it won’t let you know if an attack was attempted, and obviously whether or not it succeeded. It does not provide visibility into the application, nor block suspicious activity in real time. So shifting security left is a necessary and effective methodology, but it must be complemented by active, responsive, runtime controls.
Shift Up Security
One of the differences between traditional applications and cloud native applications is the increasing abstraction of infrastructure away from the application. With various models of deploying cloud native workloads, especially in public clouds, access to the underlying infrastructure (including the operating system) may be limited or completely blocked. If SecOps teams have traditionally focused on network and host-based security, this new reality compels them to shift their attention up the stack to the application layer – hence “shift up”.
To illustrate the way in which Shift Up security works, we need to understand the shared responsibility model as it’s reflected in various cloud native deployment modes. The shared responsibility model divides security tasks and responsibilities between the cloud provider and the customer. This model can help relieve customers’ operational burden, because a cloud provider, such as AWS, operates, manages, and controls various components from the host operating system and virtualization layer, down to the physical security of the facilities in which the service operates.
Let’s look at several scenarios of running containers in the cloud, and just how much you might need to shift up security in each.
Running your own Kubernetes Cluster
You can run your own Kubernetes cluster (whether open source or a distribution) by spinning up VMs in a public cloud. In such a case, it will be your responsibility to secure the Kubernetes components and the workloads themselves (what’s in the containers). Whether or not you’ll need to secure the VMs’ OS depends upon whether you’ll be using the cloud provider’s default (e.g., Amazon Linux) or bring your own Linux distribution – the latter being your responsibility. You don’t need to address other infrastructure layers of security, such as isolation of your tenancy from other customers – the cloud providers will do that. So there is a moderate degree of shifting up required, since the lower levels of the stack are managed by the cloud provider.
Running a cloud-managed Kubernetes cluster (e.g., Amazon EKS)
In this scenario, the Kubernetes master is managed by the cloud provider, which means that cluster-wide security aspects are managed by them. You can still customize the worker node VMs’ operating system. If you do that, then you’ll also be responsible for managing security for those VMs – patching, hardening, etc. However, not having to deal with Kubernetes infrastructure security is another shift up.
Running containers on a “serverless containers” service (e.g., AWS Fargate)
Services such as Fargate and Azure Container Instances allow you to use containers as a fundamental compute primitive without having to manage the underlying VM instances at all. You can’t manage security for the infrastructure, orchestrator or hosts, because they are not available to you. Your only responsibility is to secure the workloads in the containers. This is currently the most glaring example where “shift happens” – shift up, that is.
Shifting Forward
Both the shift left and shift up approaches have an important role in the security of your software development. Shift up security is an imperative change in focus that security teams should get accustomed to as they increasingly transfer workloads into public clouds.
As we move further into cloud native, the focus of security will continue to change. If your team is still focusing on firewalls and host security, they should start adapting to this new reality where the upper layers of the stack are key, and security shifts up.
