Rani Osnat, VP Strategy at the cloud security platform company Aqua Security, writes about getting started with your cloud native security.
There are many benefits to a cloud native approach, and it is easy to see why organisations are choosing to go down this route for most, if not all, of their new applications. Cloud native application architectures promise such benefits as portability, scalability and, perhaps most crucially, reduced deployment times. One significant challenge as enterprises move to these emerging platform environments, is how to secure them, especially as many security professionals are less familiar with the rapidly evolving technology stack for cloud native. Luckily, we can learn from others’ missteps and follow their best practices to successfully implement cloud native journeys.
A new approach
Owing to the very nature of how cloud native applications are created and deployed, it is possible to make them even more secure than traditional approaches. Concepts like container immutability and ‘shift-left’ boast security benefits that are only possible via a cloud native architecture. But to take advantage of these benefits, it is still necessary to implement a security strategy and additional security controls that are specific to cloud native architecture and design.
Many security teams may initially assume that traditional security products can be configured or adapted to secure container environments. In truth they are not adequately nuanced for the specific needs of a cloud native environment. For example, the concept of a firewall, to control networking traffic, is valid in a cloud native architecture. But traditional firewalls are not suitable for a cloud native environment because they would monitor the host at an unchanging IP address. In a cloud native environment, IP addresses are constantly being changed, as IP addresses are dynamically assigned to Pods within a cluster in an orchestrated Kubernetes environment. A classic firewall, therefore, could not keep track of this changing information to know which Pod is running, or to which application it belongs.
Catching up on compliance
Achieving compliance is difficult for cloud native environments, primarily because regulators have not yet put in place specific guidelines for cloud native environments. So how do you ensure compliance?
This might seem like an impossible task but, given the lack of specific guidelines, the end goal is to demonstrate an informed ‘best effort’ that shows all the appropriate ‘layers’ of a cloud native architecture are being aligned to the concepts laid out by regulations or standards. The first step to doing this is to acknowledge that classic controls satisfying compliance requirements in other environments will be ineffective for a cloud native environment.
For example, PCI DSS guidelines require that PCI be separated from non-PCI systems. In the guidance methods to “provide reasonable assurance that the out-of-scope system cannot be used to compromise an in-scope system component” are listed. These include firewalls, physical access controls, authentication, active monitoring and the restriction of administrative access, all of which we know do not run in the same way in cloud native environments.
Therefore, to meet these requirements in a multi-tenant Kubernetes cluster, we need to approach it differently. This requires separating registries and pipelines, dividing resources across the separated entities and approving administrators via K8s namespaces. Proper labelling and tagging must then happen in inside these namespaces to further enforce segregation. Controlling access to the firewall policies used by the security tool to prevent violations of the desired segmentation would then require Role-Based Access Control (RBAC).
This is one example of how to approach the compliance problem. Generally, so long as steps like these are taken to show proof that controls are in place, auditors will be satisfied. Regulators should soon catch up and implement cloud native specific compliance guidance, but in the meantime, it is necessary to implement appropriate cloud native security controls.
Who is ultimately responsible for security in the cloud? It’s not the cloud provider if that’s what you were thinking.
In fact, while the cloud provider might offer default security configurations, it is not responsible for checking or enhancing the security of its customers’ accounts and services and have almost no involvement with the applications customers deploy. Misunderstanding the split of roles and responsibilities with cloud providers can lead to a false sense of security. Indeed, Gartner states, in its report on ‘How to Respond to the 2020 Threat Landscape’ that, “Through 2023, at least 99 per cent of cloud security failures will be the customer’s fault.”
Ultimately, the customer is responsible for properly configuring cloud services and for understanding the true extent of the shared model of responsibility with cloud providers.
The main lesson here is to take a step back and properly plan how to implement cloud native security capabilities before, and also as an integral part of beginning or developing along your cloud native journey. Taking cloud native security into account too late will leave teams at the risk of becoming easy prey to dangerous misconceptions.
