We live in a reality where companies around the globe get breached each day. The criminals are well organized and well paid. Companies have an increasing focus on protecting the business-critical network, compute and data assets. But what happens when the network and compute infrastructure to protect get highly abstracted? An old saying is, “you can’t protect what you can’t see”.
We are witness to an IT evolution (or yet another paradigm shift), where our IT workloads and its data becomes even more abstracted from its underlying infrastructure (network and compute). The infrastructure becomes software-defined. We call this cloud in a broad term.
For many years now our model for software development has been on a journey from monolithic to microservices. We benefit from Speed and Agility in the new model and take advantage of the highly abstracted network and compute infrastructure and automation. We call this DevOps.
Same security disciplines – new adoption of our security tools and services
But the new software development model brings new challenges like complexity in interactions. The fundamental security disciplines like network segmentation, threat detection, identity, and access control and others, are the same, but now we must perform them in a highly abstracted infrastructure that complicates the situation and calls for another adoption of our proven security tools and methodology.
The level of abstraction grows – security problems follow
We try to address the challenges by abstracting even more. Some good examples are the container evolution from native Linux Namespaces, manual deployment of Docker containers to container orchestration like Docker Swarm, Mesosphere or Kubernetes and lately into Service Mesh, technologies like Istio, and on top of the containers serverless abstraction like Google Knative and Amazon Lambda.
Another example is the significant move from IaaS to PaaS, where IaaS is moderately abstracted from the network and compute, PaaS is highly abstracted from the network and compute. Of cause serverless (functions) are almost completely abstracted from the network and compute, and SaaS is 100% abstracted as the users have no insight into network and compute that run the service.
The criminal hacker community may not have the same focus on attacking workloads in highly abstracted infrastructures then the less abstracted today, but this is probably only a matter of time. The hacker community also need to adapt their tools. Criminal actors go where the profit is the highest. As the deployment of business-critical workloads and data move into highly abstracted infrastructures, so does the risk of being breached.
Attributes of the network, compute and data objects get a more significant role
When our network and compute resources get abstracted it is obvious that our security solutions must adapt likewise. Eventual all security products and services must adapt to a new infrastructure.
The attributes of the network, compute and data objects play another and more significant role in a highly abstracted infrastructure.
Normally the IP address, region, and geolocation in static, less abstracted infrastructures, are significant to describe the security nature of the asset. In highly abstracted infrastructures we can’t rely on either IP address, region or geolocation. We need more attributes to build our security policy, and we get a lot more assets as workloads get smaller in size (microservices) and multiply in numbers.
To cope with this problem all modern infrastructure takes advantage of labels, which is a placeholder for workload attributes. As our workloads move from a static definition to a dynamic elastic scaling definition our labels follow the workloads on its move around in the infrastructure and by defining the security policy using labels, the policy can seamlessly follow (and protect) the workloads when they move around.
IP addresses may be abstracted in container, functions and PaaS infrastructures
Almost all infrastructures still have a network using IP addresses, although they may be hidden (abstracted). The service name and its DNS resolution at a specific time are important, not the IP address itself.
A good example of this is Label and DNS usage In Kubernetes Container networks.
Labels:
Labels are key/value pairs that are attached to objects, such as pods. Labels are intended to be used to specify identifying attributes of objects that are meaningful and relevant to users but do not directly imply semantics to the core system. Labels can be used to organize and to select subsets of objects. Labels can be attached to objects at creation time and subsequently added and modified at any time. Each object can have a set of key/value labels defined. Each Key must be unique for a given object.
DNS:
A POD is the smallest object in Kubernetes. Namespace is a collection of PODs. A POD contains one or a few containers. PODs in a Kubernetes cluster communicate via service objects. Every Service defined in the cluster (including the DNS server itself) is assigned a DNS name. By default, a client Pod’s DNS search list will include the Pod’s own namespace and the cluster’s default domain. This is best illustrated by example:
Assume a Service named foo in the Kubernetes namespace bar. A Pod running in namespace bar can look up this service by simply doing a DNS query for foo. A Pod running in namespace quux can look up this service by doing a DNS query for foo.bar.
Kubernetes deployment in production networks
Kubernetes is the dominating OS for Docker container deployment in the production network. Kubernetes comes in many flavors. From the below list only the Amazon ECS, Docker Swarm, and Mesosphere DC/OS are not based upon Kubernetes.
Firewalls are adopted quite differently to Container, Functions, and PaaS
Kubernetes and other container clusters support network plugin’s through the CNI (Container network interface). A firewall or another security product must install its network plugin and register it in the CNI.
Then the firewall or other security product can manage security functions within the cluster. These could be for segmentation, detect and response, DLP, etc. The network plugin normally runs in its own separate container and must be present on all nodes (compute instances) in the cluster. This is normally done through a daemon set in Kubernetes that automatically populate the network plugin on every node in the cluster, also for nodes to be added to the cluster at a later stage.
Major firewall brands release such a firewall for container clusters later this year. Many startups, open-source, and established cloud-native security companies, like Twistlock, Aqua already have security products that can act within container clusters.
For PaaS and Serverless Functions the adoption is different. As the network and compute instances are highly abstracted, the external security products leverage the API for events and visibility and IAM for enforcement. IAM (Identity Access Management) is just as frequently used as ACL (Access Control Lists) when it comes to segmentation in PaaS and Serverless Functions. IAM and ACL are used interchangeably to protect access to cloud-native contructs. The security policy in such highly abstracted infrastructures enforces utilizing service-accounts and RBAC (Role-based access control).
Functions are small independent, single-action pieces of code. The code is invoked by an event trigger. The firewall that adopts functions can act by monitoring these events in the log through API access and enforce by manipulation of the IAM policy.
The cloud service providers (CSP) develop many native security products. These solutions often compete with well-established security products and services. Most security challenges are from an overall perspective independent of the abstraction level of the infrastructure targeted. Example: Stealing or encrypting data from a company uses the same method and have the same impact no matter if the data was hosted on a less or highly abstracted infrastructure.
The difference is how the hacker and the security teams adapt to the infrastructure. CSP provided security services that have the advantage that they are well adapted into highly abstracted infrastructures, but the disadvantage that they are new in the game and have far fewer features and capability to stop threats efficiently.
Well established security products and service players have the advantage that they have many features and skillsets to efficiently stop treats, but the disadvantage that they lack behind in adoption into highly abstracted infrastructures.
We are on a journey to smoothen the differences and encourage better collaboration with CSP’s and software-defined infrastructure frameworks.
The Orange Cyberdefense strategy has focused on adopting our services into highly abstracted infrastructures to offer the same security protection independent of how the customers choose to deploy their business-critical applications and data.
2019 Container Adoption Survey