Network Security in the Containers Era

One of the good things about being in the industry for many years is the fact that we can observe how network security trends in the data center have evolved and somewhat predict what is coming next, based on common patterns and intuition.

Networkand security boundaries arechanging

Fifteen years ago, network securitywaspretty simple in the data center. Layer 2 protocols were absolute kings in their realm and the firewall could sit at the edge to protect the Internet or a WAN connection. Servers for a given application were all connected in the same rack, and the boundary between the different pieces of the infrastructure was well-defined. Segmenting this was pretty straightforward.

A few years later, in order to consolidate all these servers and simplify connectivity, chassis and blade servers slowly gained traction,creating thefirst shift in network and security boundaries between people managing servers and people in charge of the network and security. Whos responsible for the connectivity modules in these chassis, and where should we insert the security appliances? Most of the time, the network module ended up being the least important module in the chassis and always a nightmare to connect to the rest of the network and security infrastructure.

But this battle was upstaged by a new technology. VMwares ESX hypervisor quickly democratized the ability to share the same hardware server to run many virtual servers. And as a result, to connect these virtual servers together, the network had to shift once again in a different place: within the hypervisor.Shifts began asa very simple virtual switch, but quicklyexpanded tolayer 3 services and, eventually,security.

And again, despite the evolution of the data center infrastructure, the public cloud started its ascension to offer a range of services to the enterprise market, fully automated and extremely agile. It did not take long for developers to understand the value of this new abstracted infrastructure that can deliver a scalable and highly available service without dealing with the complexity of managing infrastructure.

A few years ago, a new type of workload emerged, lightweight, portable, and easy to spin up or tear down in seconds: containers. With the proliferation of containers, developers quickly realized that there is a need to orchestrate these compute resources, along with the network, to make sure applications can scale up and down without having to depend on an external network and security infrastructure. A container cluster is a new infrastructure element that mixes up compute, network and security and creates, once again, another shift in the networksecurity boundary.

So, what did we learn over15years? What is the common pattern of all theseevolutions?

1. The networksecurity boundary isshifting more and more into the compute layer becausedevelopers arealways pushing the limit togetmore flexibilitywhile developing and testing their applications.
2. Network and security teams are late tothe game and,at best, can recommend choices or solutions,but most of thetime, inheritwhats been decided by applications or cloud teams.
3. Securinginfrastructuresis harder whenthings have not been thoughtoutand designedwith security in mind, and usually createsanextra level of complexity when it's added later on.

What's the Problem with Containers?

Containersand container clusters areactually notan exceptionto thistrend ofmoving the network more and more intothe software andcompute layers.As describedearlier, weve seen thisfor many years, andthere is no reason why it would change ifthe network and security teamsarenotreversingthistrend.

From a network and security perspective, containersdo not introduce anything new or unknown,theyjustcombinewhat we already know(IPs, subnets,DHCP/DNS,zones, segments,encapsulation, NAT,firewallor load balancers), buteverything happens to bein the OSitself, and that is onefundamental problem.

IT teams love boundaries,responsibilities, andownership,andthats the opposite of howcontainer clusters operate.They have been designed to beself-sufficient, orchestrated and opaquefrom the outside world.Onone hand, it is great news that a new piece of infrastructuredoes not require extensive design sessions to be connected andrunning.Onthe other hand,it creates arealsecurityquestion as to how the application flows can be secured if youdont know and understand whats happening within these clusters.

What can be done to change this?

Ideally, developersshould be developing code and handing it over to another team to push the codeinto production in a thoroughlytested andautomated way, on an infrastructuredesigned for scale and availability, and with securityat the top of the priorities at every layer of the stack.

Well, it appears that in many organizations, we havent reached that point yet.DevOps teams areconnected to their peers indevelopment, but this is not always the case fornetwork and security teams, and that needs to changeif we want to see containers asa disruptive technology in the market.

Network and security teams should spend more time understandingwhats been transported and securedby the infrastructure. They shouldlearn what a CI/CD pipeline is,andthey should have an opinion onhow things are built within the applicationso that they can adapt the securitymechanisms to complement what the application is not able to achieve. This requires learning new skills, accepting differences, and being critical but open-minded tonew concepts that at first maynot seem to be a great idea but can actually bevery efficient.

Containersareaperfectexample of atechnology thatforcespeople fromeveryareain an IT departmenttolearn from one another.

Otherwise, it is a recipe for disaster. There is nocontainercluster without networking, there is nocontainerizedapplicationin production without security, and there is no shared infrastructure without segmentation. Network and security teams need touse this opportunity to learnnew ways of doing things,spend more timeunderstanding how things can be done in software, and take ownership ofthe network and securitylayersbyproposing simple, secure, and stable designsto serve the application layer.

Where Should You Start?

There is obviously no magic bullet or secretweaponthat could betheone-size-fits-all answer.But here are some ideas that can helpdriveyour team to success:

Get to know your frenemies:Developers andDevOps teams are notthe enemies of the network and security teams.They are all serving the same purpose:the business.But withoutknowing whatother teamsdo, it is harder to see what can be done to be better as a group.Building complex infrastructureslike container clustersrequiresintertwined decisionsto be successful,especially whenit comes to security.

Acquire the knowledge:Nobody knows everything, but everybody can learn anything.It isokto belight in some areasof your infrastructure, but it is definitely not okay to be unwillingto learn how things are done or should bedone.Containers, orchestration platforms,andservice meshesare not easy to approach.Ittakes time tofeelcomfortable with new terminology orconcepts, but it is sorewardingwhen you cross that threshold ofunderstanding and can turn thatknowledgeinto action.

A network is a networkand securityisuniversal:Keepin mind that a container clusteris a collection of IPaddresses(associated with containers) that communicates between one another.Also, applications are not meant to live in a container cluster without being exposed to the world, so there will be a concept ofopening some doors to the world. Networkand securityengineersare responsible for the flows goingfrom one endof a clusterto the other, as well as getting packets in and out of this cluster. If something is compromised within acontainercluster,itis the responsibility of the network security team to monitor,react, and respond to avoid the spread of a breach. Yes, container clusters have a different approach for network and security, but itis still a networkthat needs to be segmented and secured.

Seek the truth:Itis important to understandand challenge the status quo. When things do not workasyouthoughttheywould,its okay. This means that collectively, as a team, youneed toseekout the truth and agree uponit. A well-understood technology is easier to deploy, secure, and troubleshoot.

Containers, orchestration platforms,and service meshesaregaininga lot oftractionin IT organizations nowadays and it is extremely important that, as a network and security engineer, you understand the concepts of these technologies.Some concepts willsound very familiar, some otherswill soundveryodd, butin order to properlysecure things, youmust know how theyactually work!

Check out our containers page for more information on how to leverage Illumio for container segmentation.