I am often asked how the emergence of Containers and Microservices changes the game so far as multi-cloud security is concerned.
In some ways, Containers mean MORE of the same - more speed, more scale, more automation, more controls between resources, more granular need for inspection and security policy enforcement - and we find vArmour’s application-centric approach to endpoint-independent security (because you can’t deploy an agent-like control within a Container without breaking the entire architecture) applies beautifully.
However, it is the enablement of Microservices architectures that really changes the game when it comes to cloud security. Previously, in monolithic architectures, application processes largely communicated via internal data structures and local socket calls. The attack surface was also constrained to a single OS in monolithic applications. Alternatively, with microservices, applications are broken down into functions (which are narrow, and ’small’ enough for a single engineer to build and deploy within 2 weeks, by many definitions) which interact with each other through APIs exposed to the network.
Microservices lead to loosely coupled, (and arguably) more scalable and resilient data center and cloud architectures, but sends the attack surface of a given application through the roof. The application internals are now accessible from the multi-cloud network! This substantial change to the application threat model needs to be addressed through a number of new methods, in a manner that doesn’t negatively impact the agility and operational simplicity of the Container ecosystem.
1. ‘Wrapping’ security controls around each microservice
As microservices are ‘spun up’ by the PaaS orchestration layer, security controls need to be instantiated to ensure access to the microservice is constrained. Think of micro-segmentation at the container level, using the existing DevOps toolchains. If you can insert security controls like vArmour ‘around’ a workload dynamically, then you can use the same approach to wrap a microservice with the same level of independent security policy enforcement.
Alternative security controls are challenged to get this close to the microservice - appliances (NGFWs, IPS, virtual or physical) cannot get ‘between’ containers on a host or scale out in the dynamic manner required. If you are dependent upon agent co-existence within a workload, then the container model breaks down somewhere - you either need to add more ‘bloat’ executing within the container or you need to migrate to a model of enforcement ‘around’ the asset, at the host network ‘interconnect’.
2. Monitoring and control capability
You will need granular, application-layer monitoring, and you will need strong controls. Microservices architectures will add tremendous complexity to our networks, and will ask the network to do things previously unknown. You can think of the new network as a combination of existing network communications plus previously Inter-process (and Intra-process) internal computer communications, constantly changing dynamically by the millisecond. If your cloud security solution does not provide you with the ability to recognize anomalies, new threat vectors, and misuse of protocols at this deep level, then you are ‘operating blind’ and exposing the internals of your most critical applications, and your client’s data, to the world. Application-aware security solutions, like the vArmour DSS Distributed Security System, are designed to provide you with the control and continuous monitoring you will need directly ‘around’ the microservice, unlike simple network controls (such as SDNs or the good old VLAN / ACL partition) and agent-based solutions built upon basic packet filtering technology (such as IPtables or Windows filtering platform, WFP).
3. Dynamic workload instantiation, without sacrificing security policy
Those controls need to dynamically instantiate security using a combination of security policy intent and information being provided by the control plane. You need a model where providing dynamic resource instantiation does not sacrifice your security posture or determinism of control. A flexible, group-based policy model which integrates with the data center orchestration engine(s) will allow you to pre-define your security policies, while accommodating dynamic changes to application topology.
4. Scale and performance
Microservices architectures will typically replace 100s of VMs with thousands or tens of thousands of Containers, as the unit of deployment becomes really fine-grained. Unless you have an architecture to support this level of scale and the associated control plane activity, then it will become challenging to make the security controls fit. Appliance-based security models will be particularly challenged in this respect.
5. Fine grained authentication and authorization of access
Once you have reduced your attack surface with micro-segmentation, then it is critical to ensure authorized access to the permissioned API is provided at the minimal required level of privilege. Typically, this access will be process to process (and you can use micro-segmentation to prevent any human access to ‘internal’ interfaces using basic policy definitions) which can be difficult to implement correctly, involving complex credential management challenges.
6. Kernel attack vectors
Attack vectors through the shared OS kernel (container to container, kernel to container, container to kernel) need to be addressed.
At vArmour, our distributed security architecture allows us to address challenges 1-4 that the major disruption of microservices will bring to data center and cloud security. By reducing the attack surface, and providing powerful, application-layer monitoring and control, we help to bring order to highly dynamic and complex environments, like those built on microservices.