Zero Trust Security Strategy

September 2, 2022

by Matt Conran: The Visual Age Publications

Zero Trust Security Strategy

In this fast-paced digital era, where cyber threats are constantly evolving, traditional security measures alone are no longer sufficient to protect sensitive data. This is where the concept of Zero Trust Security Strategy comes into play. In this blog post, we will delve into the principles and benefits of implementing a Zero Trust approach to safeguard your digital assets.

Zero Trust Security is a comprehensive and proactive security model that challenges the traditional perimeter-based security approach. Instead of relying on a trusted internal network, Zero Trust operates on the principle of “never trust, always verify.” It requires continuous authentication, authorization, and strict access controls to ensure secure data flow throughout the network.

Highlights: Zero Trust Security Design

Networks are Complex

Today’s networks are complex beasts, and considering yourself an entirely zero trust network design is a long journey. It means different things to different people. Networks these days are heterogeneous, hybrid, and dynamic. Over time, technologies have been adopted, from punch card coding to the modern-day cloud, container-based virtualization, and distributed microservices.

This complex situation leads to a dynamic and fragmented network along with fragmented processes. The problem is that enterprises over-focus on connectivity without fully understanding security. Just because you connect does not mean you are secure.

Rise in Security Breaches

Unfortunately, this misconception may allow the most significant breaches. As a result, those who can move towards a zero-trust environment with a zero-trust security strategy provide the ability to enable some new techniques that can help prevent breaches, such as zero trust and microsegmentation, zero trust networking along with Remote Browser Isolation technologies that render web content remotely.

Related: For pre-information, you may find the following posts helpful:

Zero Trust and Microsegmentation Key Zero Trust Security Strategy Discussion points:	People overfocus on connectivity and forget security. Control vs visibilty. Starting a data-centric model. Automation and Orchestration. Starting a Zero Trust security journey.

Back to basics with the Zero Trust Security Design

Traditional perimeter model

The security zones are formed with a firewall/NAT device between the internal network and the internet. There is the internal “secure” zone, the DMZ (also known as the demilitarized zone), and the untrusted zone (the internet). If this organization needed to interconnect with another at some point in the future, a device would be placed on that boundary similarly. The neighboring organization will likely become a new security zone, with particular rules about traffic going from one to the other, just like the DMZ or the secure area.

Key Components of Zero Trust

To effectively implement a Zero Trust Security Strategy, several crucial components need to be considered. These include:

1. Identity and Access Management (IAM): Implementing strong IAM practices ensures that only authenticated and authorized users can access sensitive resources.

2. Microsegmentation: By dividing the network into smaller segments, microsegmentation limits lateral movement and prevents unauthorized access to critical assets.

3. Least Privilege Principle: Granting users the least amount of privileges necessary to perform their tasks minimizes the risk of unauthorized access and potential data breaches.

Advantages of Zero Trust Security

Adopting a Zero Trust Security Strategy offers numerous benefits for organizations:

1. Enhanced Security: Zero Trust ensures a higher level of security by continually verifying and validating access requests, reducing the risk of insider threats and external breaches.

2. Improved Compliance: With stringent access controls and continuous monitoring, Zero Trust aids in meeting regulatory compliance requirements.

3. Reduced Attack Surface: Microsegmentation and strict access controls minimize the attack surface, making it harder for cybercriminals to exploit vulnerabilities.

Challenges and Considerations

While Zero Trust Security Strategy offers great potential, its implementation comes with challenges. Some factors to consider include:

1. Complexity: Implementing Zero Trust can be complex, requiring careful planning, collaboration, and integration of various security technologies.

2. User Experience: Striking a balance between security and user experience is crucial. Overly strict controls may hinder productivity and frustrate users.

Zero trust and microsegmentation

The concept of zero trust and micro segmentation security allows organizations to execute a Zero Trust model by erecting secure micro-perimeters around distinct application workloads. Organizations can eliminate zones of trust that increase their vulnerability by acquiring granular control over their most sensitive applications and data. It enables organizations to achieve a zero-trust model and helps ensure the security of workloads regardless of where they are located.

Control vs. visibility

Zero trust and microsegmentation overcome this with an approach that provides visibility over the network and infrastructure to ensure you follow security principles such as least privilege. Essentially, you are giving up control but also gaining visibility. This provides the ability to understand all the access paths in your network.

For example, within a Kubernetes environment, administrators probably don’t know how the applications connect to your on-premises data center or get Internet connectivity visibility. Hence, one should strive to give up control for visibility to understand all the access paths. Once all access paths are known, you need to review them consistently in an automated manner.

Zero Trust Security Strategy

The move to zero trust security strategy can assist in gaining the adequate control and visibility needed to secure your networks. However, it consists of a wide spectrum of technologies from multiple vendors. For many, embarking on a zero trust journey is considered a data- and identity-centric approach to security instead of what we initially viewed as a network-focused journey.

Zero Trust Security Strategy: Data-Centric Model

Zero trust and microsegmentation

In pursuit of zero trust and microsegmentation, abandoning traditional perimeter-based security and focusing on the zero trust reference architecture and its data is recommended. One that understands and maps data flows can then create a micro perimeter of control around their sensitive data assets to gain visibility into how they use data. Ideally, you need to identify your data and map its flow. Many claims that zero trust starts with the data. And the first step to building a zero trust security architecture is identifying your sensitive data and mapping its flow.

We understand that you can’t protect what you cannot see; gaining the correct visit of data and understanding the data flow is critical. However, securing your data, even though it is the most crucial step, may not be your first zero trust step. Why? It’s a complex task.

zero trust environment — Diagram Data: Zero trust environment. The importance of data.

Start a zero trust security strategy journey

For a successful Zero Trust Network ZTN, I would start with one aspect of zero trust as a project recommendation. And then work your way out from there. When we examine implementing disruptive technologies that are complex to implement, we should focus on outcomes, gain small results and then repeat and expand.

A key point. Zero trust automation

This would be similar to how you may start an automation journey. Rolling out automation is considered risky. It brings consistency and a lot of peace of mind when implemented correctly. But simultaneously, if you start with advanced automation use cases, there could be a large blast radius.

As a best practice, I would start your automation journey with config management and continuous remediation. And then move to move advanced use cases throughout your organization. Such as edge networking, full security ( Firewall, PAM, IDPS, etc.), and CI/CD integration.

A key point: You can’t be 100% zero trust

It is impossible to be 100% secure. You can only strive to be as secure as possible without hindering agility. It is similar to that of embarking on a zero-trust project. It is impossible to be 100% zero trust as this would involve turning off everything and removing all users from the network. We could use single-packet authorization without sending the first packet!

Do not send a SPA packet

When doing so, we would keep the network and infrastructure dark without sending the first SPA packet to kick off single-packet authentication. However, lights must be on, services must be available, and users must access the services without too much interference. Users expect some downtime. Nothing can be 100% reliable all of the time.

Then you can balance velocity and stability with practices such as Chaos Engineering Kubernetes. But users don’t want to hear of a security breach.

zero trust journey — Diagram: Zero trust journey. What is your version of trust?

A key point. What is trust?

So the first step toward zero trust is to determine a baseline. This is not a baseline for network and security but a baseline of trust. And zero trust is different for each organization, and it boils down to the level of trust; what level does your organization consider zero trust? What mechanism do you have in place?

There are many avenues of correlation and enforcement to reach the point where you can call yourself a zero trust environment. It may never become a zero trust environment but is limited to certain zones, applications, and segments that share a standard policy and rule base.

A key point: Choosing the vendor

Also, can zero trust security vendors be achieved with a single vendor regarding vendor selection? No one should consider implementing zero trust with one vendor solution. However, many zero trust elements can be implemented with a SASE definition known as Zero Trust SASE.

In reality, there are too many pieces to a zero-trust project, and not one vendor can be an expert on them. Once you have determined your level of trust and what you expect from a zero-trust environment, you can move to the main zero-trust element and follow the well-known zero-trust principles. Firstly, automation and orchestration. You need to automate, automate and automate.

zero trust reference architecture — Diagram: Zero trust reference architecture.

Zero Trust Security Strategy: The Components

Automation and orchestration

Zero trust is impossible to maintain without automation and orchestration. Firstly, you need to have identification of data along with access requirements. All of this must be defined along with the network components and policies. So if there is a violation, here is how we reclaim our posture without human intervention. This is where automation comes to light; it is a powerful tool in your zero trust journey and should be enabled end-to-end throughout your enterprise.

An enterprise-grade zero trust solution must work quickly with the scaling ability to improve the automated responses and reactions to internal and external threats. The automation and orchestration stage defines and manages the micro perimeters to provide the new and desired connectivity. Ansible architecture consists of Ansible Tower and the Ansible Core based on the CLI for a platform approach to automation.

Zero trust automation

With the matrix of identities, workloads, locations, devices, and data continuing to grow more complicated, automation provides a necessity. And you can have automation in different parts of your enterprise and at different levels.

You can have pre-approved playbooks stored in a Git repository that can be version controlled with a Source Control Management system (SCM). Storing playbooks in a Git repository puts all playbooks under source control, so everything is better managed.

Then you can use different security playbooks already approved for different security use cases. Also, when you bring automation into the zero-trust environments, the Ansible variables can separate site-specific information from the playbooks. This will be your playbooks more flexible. You can also have a variable specific to the inventory known as the Ansible inventory variable.

Schedule zero trust playbooks under version control

For example, you can kick off a playbook to run at midnight daily to check that patches are installed. If there is a deviation from a baseline, the playbook could send notifications to relevant users and teams.

Ansible Tower: Delegation of Control

I use Ansible Tower, which has a built-in playbook, scheduling, and notifications for many of my security baselines. I can combine this with the “check” feature so less experienced team members can run playbook “sanity” checks and don’t have the need or full requirement to perform change tasks.

Role-based access control can be tightly controlled for even better delegation of control. You can integrate Ansible Towers with your security appliances for advanced security uses. Now we have tight integration with security and automation. Integration is essential; unified automation approaches require integration between your automation platform and your security technologies.

Security integration with automation

For example, we can have playbooks that automatically collect logs for all your firewall devices. These can be automatically sent back to a log storage backend for analysts, where machine learning (ML) algorithms can perform threat hunting and examine for any deviations.

Also, I find Ansible Towers workflow templates handy and can be used to chain different automation jobs into one coherent workflow. So now we can chain different automation events together. Then you can have actions based on success, failure, or always.

A key point – Just alert and not block

You could just run a playbook to raise an alert. It does not necessarily mean you should block. I would only block something when necessary. So we are using automation to instantiate a playbook to bring those entries that have deviated from the baseline back into what you consider to be zero trust. Or we can automatically move an endpoint into a sandbox zone. So the endpoint can still operate but with less access.

Consider that when you first implemented the network access control (NAC), you didn’t block everything immediately; you allowed it to bypass and log in for some time. From this, you can then build a baseline. I would recommend the same thing for automation and orchestration. When I block something, I recommend human approval to the workflow.

zero trust automation — Diagram: Zero trust automation. Adaptive access.

Zero Trust Least Privilege, and Adaptive Access

Enforcement points and flows

As you build out the enforcement points, it can be yes or no. Similar to the concept of the firewall’s binary rules, they are the same as some of the authentication mechanisms work. However, it would be best to monitor anomalies regarding things like flows. You must stop trusting packets as if they were people. Instead, they must eliminate the idea of trusted and untrusted networks.

Identity centric design

Rather than using IP addresses to base policies on, zero trust policies are based on logical attributes. This ensures an identity-centric design around the user identity, not the IP address. This is a key component of zero trust, how you can have adaptive access for your zero trust versus a simple yes or no. Again, following a zero trust identity approach is easier said than done.

A key point: Zero trust identity approach

With a zero trust identity approach, the identity should be based on logical attributes, for example, the multi-factor authentication (MFA), transport layer security (TLS) certificate, the application service, or the use of a logical label/tag. Tagging and labeling are good starting points as long as those tags and labels make sense when they flow across different domains. Also, consider the security controls or tagging offered by different vendors.

How do you utilize the different security controls from different vendors, and more importantly, how do you use them adjacent to one another? For example, Palo Alto utilizes an App-ID, a patented traffic classification system. Please keep in mind vendors such as Cisco have end-to-end tagging and labeling when you integrate all of their products, such as the Cisco ACI and SD-Access.

Zero trust environment and adaptive access

Adaptive access control uses policies that allow administrators to control user access to applications, files, and network features based on multiple real-time factors. Not only are there multiple factors to consider, but these are considered in real-time. What we are doing is responding to potential threats in real-time by continually monitoring user sessions for a variety of factors. We are not just looking at IP or location as an anchor for trust.

Pursue adaptive access

Anything tied to an IP address is useless. Adaptive access is more of an advanced zero trust technology, likely later in the zero trust journey. Adaptive access is not something you would initially start with.

Diagram: Micro segmentation and zero trust security.

Zero Trust and Microsegmentation

VMware introduced the concept of microsegmentation to data center networking in 2014 with VMware NSX micro-segmentation. And it has grown in usage considerably since then. It is challenging to implement and requires a lot of planning and visibility.

Zero trust and microsegmentation security enforce the security of a data center by monitoring the flows inside the data center. The main idea is that in addition to network security at the perimeter, data center security should focus on the attacks and threats from the internal network.

Small and protected isolated sections

With zero trust and microsegmentation security, the traffic inside the data center is differentiated into small isolated parts, i.e., micro-segments depending on the traffic type and sensitivity level. A strict micro-granular security model that ties security to individual workloads can be adopted.

Security is not simply tied to a zone; we are going to the workload level to define the security policy. By creating a logical boundary between the requesting resource and protected assets, we have minimized lateral movement elsewhere in the network, gaining east-west segmentation.

Zero trust and microsegmentation

It is often combined with micro perimeters. By shrinking the security perimeter of each application, we can control a user’s access to the application from anywhere and any device without relying on large segments that may or may not have intra-segment filtering.

Use case: Zero trust and microsegmentation: 5G

Micro segmentation is the alignment of multiple security tooling along with aligning capabilities with certain policies. One example of building a micro perimeter into a 5G edge is with containers. The completely new use cases and services included in 5G bring large concerns as to the security of the mobile network. Therefore, require a different approach to segmentation.

Micro segmentation and 5G

In a 5G network, a micro segment can be defined as a logical network portion decoupled from the physical 5G hardware. Then we can chain several micro-segments chained together to create end-to-end connectivity that maintains application isolation. So we have end-to-end security based on micro segmentation, and each micro segment can have fine-grained access controls.

A key point: Zero trust and microsegmentation: The solutions

A significant proposition for enabling zero trust is micro segmentation and micro perimeters. Their use must be clarified upfront. Essentially, their purpose is to minimize and contain the breach (when it happens). Rather than using IP addresses to base segmentation policies, the policies are based on logical constructs. Not physical attributes.

Monitor flows and alert

Ideally, favor vendors with micro segmentation solutions that monitor baseline flows and alert on anomalies. These should also assess the relative level of risk/trust and alert on anomalies. They should also continuously assess the relative level of risk/trust on the network session behavior observed. This may include unusual connectivity patterns, excessive bandwidth, excessive data transfers, and communication to URLs or IP addresses with a lower level of trust.

Micro segmentation in networking

The level of complexity comes down to what you are trying to protect. This can be something on the edges, such as a 5G network point, IoT, or something central to the network. Both of which may need physical and logical separation. A good starting point for your micro segmentation journey is to build a micro segment but not in enforcement mode. So you are starting with the design but not implementing it fully. The idea is to watch and gain insights before you turn on the micro segment.

Containers and Zero Trust

Let us look at a practical example of applying the zero trust principles to containers. There are many layers within the container-based architecture to which you can apply zero trust. For communication with the containers, we have two layers. Nodes and services in the containers with a service mesh type of communication with a mutual TLS type of solutions.

The container is already a two-layer. We have the nodes and services. The services communicate with an MTLS solution to control the communication between the services. Then we have the application. The application overall is where you have the ingress and egress access points.

The OpenShift secure route

OpenShift networking SDN is similar to a routing control platform based on Open vSwitch that operates with the OVS bridge programmed with OVS rules. OVS networking has what’s known as a route construct. These routes provide access to specific services. Then, the service acts as a software load balancer to the correct pod. So we have a route construct that sits in front of the services. This abstraction layer and the OVS architecture bring many benefits to security.

The service is the first level of exposing applications, but they are unrelated to DNS name resolution. To make servers accepted by FQDN, we use the OpenShift route resource, and the route provides the DNS. In Kubernetes’s words, we use Ingress, which exposes services to the external world. However, in Openshift, it is a best practice to use a routing set. Routes are an alternative to Ingress.

OpenShift security: OpenShift SDN and the secure route

One of the advantages of the OpenShift route construct is that you can have secure routes. Secure routes provide advanced features that might not be supported by standard Kubernetes Ingress controllers, such as TLS re-encryption, TLS passthrough, and split traffic for blue-green deployments.

Securing containerized environments is considerably different from securing the traditional monolithic application because of the inherent nature of the microservices architecture. A monolithic application has few entry points, for example, ports 80 and 443.

Not every monolithic component is exposed to external access and must accept requests directly. Now with a secure openshift route, we can implement security where it matters most and at any point in the infrastructure.

Context Based Authentication

For zero trust, it depends on what you can do with the three different types of layers. The layer you want to apply zero trust depends on the context granularity. For context-based authentication, you need to take in as much context as possible to make access decisions, and if you can’t, what are the mitigating controls?

You can’t just block. We have identity versus the traditional network-type parameter of controls. If you cannot rely on the identity and context information, you rely on and shift to network-based controls as we did initially. Network-based controls have been around for decades and create holes in the security posture.

However, suppose you are not at a stage to implement access based on identity and context information. In that case, you may need to keep the network-based control and look deeper into your environment where you can implement zero trust to regain a good security posture. This is a perfect example of why you implement zero trust in isolated areas.

Examine zero trust layer by layer.

So it would help if you looked layer by layer for specific use cases and then at what technology components you can apply zero trust principles. So it is not a question of starting with identity or micro segmentation. The result should be a combination of both. However, identity is the critical jewel to look out for and take in as much context as possible to make access decisions and keep threats out.

Take a data-centric approach. Zero trust data

Gaining visibility into the interaction between users, apps, and data across many devices and locations is imperative. This allows you to set and enforce policies irrespective of location. A data-centric approach takes location out of the picture. It comes down to “WHAT,” which is always the data. What are you trying to protect? So you should build out the architecture method over the “WHAT.”

Zero Trust Data Security

Step 1: Identify your sensitive data

You can’t protect what you can’t see. Everything managed desperately within a hybrid network needs to be fully understood and consolidated into a single console. Secondly, once you know how things connect, how do you ensure they don’t reconnect through a broader definition of connectivity?

You can’t just rely on IP addresses anymore to implement security controls. So here, we need to identify and classify sensitive data. By defining your data, you can identify sensitive data sources to protect. Next, simplify your data classification. This will allow you to segment the network based on data sensitivity. When creating your first zero trust micro perimeter, start with a well-understood data type or system.

Step2: Zero trust and microsegmentation

Micro segmentation software that segments the network based on data sensitivity

Secondly, you need to segment the network based on data sensitivity. Here we are defining a micro perimeter around sensitive data. Once you determine the optimal flow, identify where to place the micro perimeter. Remember that virtual networks are designed to optimize network performance; they can’t prevent malware propagation, lateral movement, or unauthorized access to sensitive data. Like the VLAN, it was used for performance but became a security tool.

A final note: Firewall micro segmentation

Enforce micro perimeter with physical or virtual security controls. There are multiple ways to enforce micro perimeters. For example, we have NGFW from a vendor like Check Point, Cisco, Fortinet, or Palo Alto Networks. If you’ve adopted a network virtualization platform, you can opt for a virtual NGFW to insert into the virtualization layer of your network. You don’t always need an NGFW to enforce network segmentation; software-based approaches to microsegmentation are also available.

Conclusion:

In conclusion, Zero Trust Security Strategy is an innovative and robust approach to protect valuable assets in today’s threat landscape. By rethinking traditional security models and enforcing strict access controls, organizations can significantly enhance their security posture and mitigate risks. Embracing a Zero Trust mindset is a proactive step towards safeguarding against ever-evolving cyber threats.

ACI Cisco

August 28, 2022

by Matt Conran: The Visual Age Publications

Cisco ACI Components

In today's rapidly evolving digital landscape, businesses constantly seek innovative solutions to streamline their network infrastructure. Enter Cisco ACI (Application Centric Infrastructure), a groundbreaking technology that promises to revolutionize how networks are designed, deployed, and managed.

In this blog post, we will delve into the intricacies of Cisco ACI, its key features, and the benefits it brings to organizations of all sizes.

Matt Conran

Cisco ACI is an advanced software-defined networking (SDN) solution that enables organizations to build and manage their networks in a more holistic and application-centric manner. By abstracting network policies and services from the underlying hardware, ACI provides a unified and programmable approach to network management, making it easier to adapt to changing business needs.

Highlights: Cisco ACI Components

Hardware-based Underlay

In ACI, hardware-based underlay switching offers a significant advantage over software-only solutions due to specialized forwarding chips. Furthermore, thanks to Cisco’s ASIC development, ACI brings many advanced features, including security policy enforcement, microsegmentation, dynamic policy-based redirect (inserting external L4-L7 service devices into the data path), or detailed flow analytics—besides the vast performance and flexibility.

The Legacy data center

The legacy data center topologies have a static infrastructure that specifies the constructs to form the logical topology. We must configure the VLAN, Layer 2/Layer 3 interfaces, and the protocols we need on the individual devices. Also, the process we used to define these constructs was done manually. We may have used Ansible playbooks to backup configuration or check for specific network parameters, but we generally operated with a statically defined process.

Poor Resources

The main roadblock to application deployment was the physical bare-metal server. It was chunky and could only host one application due to the lack of process isolation. So, the network has one application per server to support and provide connectivity. This is the opposite of how ACI Cisco, also known as Cisco SDN ACI networks operate.

Related: For pre-information, you may find the following helpful:

Cisco SDN ACI Key ACI Cisco Discussion points:	Birth of virtualization and SDN. Cisco ACI integrations. ACI design and components. VXLAN networking and ECMP. Focus on ACI and SD-WAN.

Back to Basics: Cisco ACI components

Key Features of Cisco ACI

a) Application-Centric Policy Model: Cisco ACI allows administrators to define and manage network policies based on application requirements rather than traditional network constructs. This approach simplifies policy enforcement and enhances application performance and security.

b) Automation and Orchestration: With Cisco ACI, network provisioning and configuration tasks are automated, reducing the risk of human error and accelerating deployment times. The centralized management framework enables seamless integration with orchestration tools, further streamlining network operations.

c) Scalability and Flexibility: ACI’s scalable architecture ensures that networks can grow and adapt to evolving business demands. Spine-leaf topology and VXLAN overlay technology allow for seamless expansion and simplify the deployment of multi-site and hybrid cloud environments.

Cisco Data Center Cisco ACI Key Features Application-Centric Policy Model Automation and Orchestration Scalability and Flexibility Built-in Security	Cisco Data Center Cisco ACI Key Advantages Enhanced Security Agility and Time-to-Market Simplified Operations Open software flexibility for DevOps teams.

Benefits of Cisco ACI

a) Enhanced Security: By providing granular microsegmentation and policy-based controls, Cisco ACI helps organizations strengthen their security posture. Malicious lateral movement within the network can be mitigated, reducing the attack surface and preventing data breaches.

b) Agility and Time-to-Market: The automation capabilities of Cisco ACI significantly reduce the time and effort required for network provisioning and changes. This agility enables organizations to respond faster to market demands, launch new services, and gain a competitive edge.

c) Simplified Operations: The centralized management and policy-driven approach of Cisco ACI simplify network operations, leading to improved efficiency and reduced operational costs. The intuitive user interface and comprehensive analytics provide administrators with valuable insights, enabling proactive troubleshooting and optimization.

The Cisco ACI SDN Solution

Cisco ACI is a software-defined networking (SDN) solution that integrates with software and hardware. With the ACI, we can create software policies and use hardware for forwarding, an efficient and highly scalable approach offering better performance. The hardware for ACI is based on the Cisco Nexus 9000 platform product line. The APIC centralized policy controller drives the software, which stores all configuration and statistical data.

Nexus Family

To build the ACI underlay, you must exclusively use the Nexus 9000 family of switches. You can choose from modular Nexus 9500 switches or fixed 1U to 2U Nexus 9300 models. Specific models and line cards are dedicated to the spine function in ACI fabric; others can be used as leaves, and some can be used for both purposes. You can combine various leaf switches inside one fabric without any limitations.

Spine and Leaf

For Nexus 9000 switches to be used as an ACI spine or leaf, they must be equipped with powerful Cisco CloudScale ASICs manufactured using 16-nm technology. The following figure shows the Cisco ACI based on the Nexus 9000 series. Cisco Nexus 9300 and 9500 platform switches support Cisco ACI. As a result, organizations can use them as the spine or leaf switches to fully utilize an automated, policy-based systems management approach.

Diagram: Cisco ACI Components. Source is Cisco

A key point: The birth of virtualization

Server virtualization helped to a degree where we could decouple workloads from the hardware, making the compute platform more scalable and agile. However, the server is not the main interconnection point for network traffic. So, we need to look at how we could virtualize the network infrastructure in a way similar to the agility gained from server virtualization.

This is carried out with software-defined networking and overlays that could map network endpoints and be spun up and down as needed without human intervention. In addition, the SDN architecture includes an SDN controller and an SDN network that enables an entirely new data center topology.

ACI Cisco: Integrations

Routing Control Platform

Then came along Cisco SDN ACI, the ACI Cisco, which operates differently from the traditional data center with an application-centric infrastructure. The Cisco application-centric infrastructure achieves resource elasticity with automation through standard policies for data center operations and consistent policy management across multiple on-premises and cloud instances.

It uses a Software-Defined Networking (SDN) architecture like a routing control platform. The Cisco SDN ACI also provides a secure networking environment for Kubernetes. In addition, it integrates with various other solutions, such as Red Hat OpenShift networking.

Cisco ACI: Integration Options

What makes the Cisco ACI interesting is its several vital integrations. I’m not talking about extending the data center with multi-pod and multi-site, for example, with AlgoSec, Cisco AppDynamics, and SD-WAN. AlgoSec enables secure application delivery and policy across hybrid network estates, while AppDynamic lives in a world of distributed systems Observability. SD-WAN enabled path performance per application with virtual WANs.

Cisco ACI Components: ACI Cisco and Multi-Pod

Cisco ACI Multi-Pod is part of the “Single APIC Cluster / Single Domain” family of solutions, as a single APIC cluster is deployed to manage all the interconnected ACI networks. These separate ACI networks are named “pods,” Each looks like a regular two-tier spine-leaf topology. The same APIC cluster can manage several pods, and to increase the resiliency of the solution, the various controller nodes that make up the cluster can be deployed across different pods.

Cisco ACI Components: ACI Cisco and AlgoSec

With AlgoSec integrated with the Cisco ACI, we can now provide automated security policy change management for multi-vendor devices and risk and compliance analysis. The AlgoSec Security Management Solution for Cisco ACI extends ACI’s policy-driven automation to secure various endpoints connected to the Cisco SDN ACI fabric.

These simplify the network security policy management across on-premises firewalls, SDNs, and cloud environments. It also provides the necessary visibility into the security posture of ACI, even across multi-cloud environments.

Cisco ACI Components: ACI Cisco and AppDynamics

Then, with AppDynamics, we are heading into Observability and controllability. Now, we can correlate app health and network for optimal performance, deep monitoring, and fast root-cause analysis across complex distributed systems with numbers of business transactions that need to be tracked. This will give your teams complete visibility of your entire technology stack, from your database servers to cloud-native and hybrid environments. In addition, AppDynamics works with agents that monitor application behavior in several ways. We will examine the types of agents and how they work later in this post.

Cisco ACI Components: ACI Cisco and SD-WAN

SD-WAN brings a software-defined approach to the WAN. These enable a virtual WAN architecture to leverage transport services such as MPLS, LTE, and broadband internet services. So, SD-WAN is not a new technology; its benefits are well known, including improving application performance, increasing agility, and, in some cases, reducing costs.

The Cisco ACI and SD-WAN integration makes active-active data center design less risky than in the past. The following figures give a high-level overview of the Cisco ACI and SD-WAN integration. For pre-information generic to SD-WAN, go here: SD-WAN Tutorial

The Cisco SDN ACI and SD-WAN Integration

The Cisco SDN ACI with SD-WAN integration helps ensure an excellent application experience by defining application Service-Level Agreement (SLA) parameters. Cisco ACI releases 4.1(1i) and adds support for WAN SLA policies. This feature enables admins to apply pre-configured policies to specify the packet loss, jitter, and latency levels for the tenant traffic over the WAN.

When you apply a WAN SLA policy to the tenant traffic, the Cisco APIC sends the pre-configured policies to a vManage controller. The vManage controller, configured as an external device manager that provides SDWAN capability, chooses the best WAN link that meets the loss, jitter, and latency parameters specified in the SLA policy.

Cisco ACI Components: Openshift and Cisco SDN ACI

OpenShift Container Platform (formerly known as OpenShift Enterprise) or OCP is Red Hat’s offering for the on-premises private platform as a service (PaaS). OpenShift is based on the Origin open-source project and is a Kubernetes distribution, the defacto for container-based virtualization. The foundation of the OpenShift networking SDN is based on Kubernetes and, therefore, shares some of the same networking technology along with some enhancements, such as the OpenShift route construct.

Cisco ACI Components: Other data center integrations

Cisco SDN ACI has another integration with Cisco DNA Center/ISE that maps user identities consistently to endpoints and apps across the network, from campus to the data center. Cisco Software-Defined Access (SD-Access) provides policy-based automation from the edge to the data center and the cloud.

Cisco SD-Access provides automated end-to-end segmentation to separate user, device, and application traffic without redesigning the network. This integration will enable customers to use standard policies across Cisco SD-Access and Cisco ACI, simplifying customer policy management using Cisco technology in different operational domains.

Let us recap before we look at the ACI integrations in more detail.

The Cisco SDN ACI Design

Introduction to leaf and spine

The Cisco SDN ACI works with a Clos architecture, a fully meshed ACI network. Based on a spine leaf architecture. As a result, every Leaf is physically connected to every Spine, enabling traffic forwarding through non-blocking links. Physically, we have a set of Leaf switches creating a Leaf layer attached to the Spines in a full BIPARTITE graph.

This means that each Leaf is connected to each Spine, and each Spine is connected to each Leaf. The ACI uses a horizontally elongated Leaf and Spine architecture with one hop to every host in an entirely messed ACI fabric, offering good throughput and convergence needed for today’s applications.

The ACI fabric: Aggregate

A key point to note in the spine-and-leaf design is the fabric concept, which is like a stretch network. And one of the core ideas around a fabric is that they do not aggregate traffic. This does increase data center performance along with a non-blocking architecture. With the spine-leaf topology, we are spreading a fabric across multiple devices.

The result of the fabric is that each edge device has the total bandwidth of the fabric available to every other edge device. This is one big difference from traditional data center designs; we aggregate the traffic by either stacking multiple streams onto a single link or carrying the streams serially.

SDN data center — Diagram: Cisco ACI fabric checking.

The issues with oversubscription

With the traditional 3-tier design, we aggregate everything at the core, leading to oversubscription ratios that degrade performance. With the ACI Leaf and Spine design, we spread the load across all devices with equidistant endpoints. Therefore, we can carry the streams parallel.

Horizontal scaling load balancing

Then, we have horizontal scaling load balancing. Load balancing with this topology uses multipathing to achieve the desired bandwidth between the nodes. Even though this forwarding paradigm can be based on Layer 2 forwarding ( bridging) or Layer 3 forwarding ( routing), the ACI leverages a routed approach to the Leaf and Spine design, and we have Equal Cost Multi-Path (ECMP) for both Layer 2 and Layer 3 traffic.

Highlighting the overlay and underlay

Mapping Traffic

So you may be asking how we can have Layer 3 routed core and pass Layer 2 traffic. This is done using the overlay, which can map different traffic types to other overlays. So, we can have Layer 2 traffic mapped to an overlay over a routed core. ACI links between the Leaf and the Spine switches are L3 active-active links. Therefore, we can intelligently load balance and traffic steer to avoid issues. And we don’t need to rely on STP to block links or involve STP to fix the topology.

When networks were first developed, there was no such thing as an application moving from one place to another while it was in use. So the original architects of IP, the communication protocol used between computers, used the IP address to mean both the identity of a device connected to the network and its location on the network. Today, in the modern data center, we need to be able to communicate with an application or application tier, no matter where it is.

Overlay Encapsulation

One day, it may be in location A and the next in location B, but its identity, which we communicate with, is the same on both days. An overlay is when we encapsulate an application’s original message with the location to which it needs to be delivered before sending it through the network.

Once it arrives at its final destination, we unwrap it and deliver the original message as desired. The identities of the devices (applications) communicating are in the original message, and the locations are in the encapsulation, thus separating the place from the identity. This wrapping and unwrapping is done per-packet basis and, therefore, must be done quickly and efficiently.

Overlay and underlay components

The Cisco SDN ACI has a concept of overlay and underlay, forming a virtual overlay solution. The role of the underlay is to glue together devices so the overlay can work and be built on top. So, the overlay, which is VXLAN, runs on top of the underlay, which is IS-IS. In the ACI, the IS-IS protocol provides the routing for the overlay, which is why we can provide ECMP from the Leaf to the Spine nodes. The routed underlay provides an ECMP network where all leaves can access Spine and have the same cost links.

ACI overlay — Diagram: Overlay. Source Cisco

Example:

Let’s take a simple example to illustrate how this is done. Imagine that application App-A wants to send a packet to App-B. App-A is located on a server attached to switch S1, and App-B is initially on switch S2. When App-A creates the message, it will put App-B as the destination and send it to the network; when the message is received at the edge of the network, whether a virtual edge in a hypervisor or a physical edge in a switch, the network will look up the location of App-B in a “mapping” database and see that it is attached to switch S2.

It will then put the address of S2 outside of the original message. So, we now have a new message addressed to switch S2. The network will forward this new message to S2 using traditional networking mechanisms. Note that the location of S2 is very static, i.e., it does not move, so using traditional mechanisms works just fine.

Upon receiving the new message, S2 will remove the outer address and thus recover the original message. Since App-B is directly connected to S2, it can easily forward the message to App-B. App-A never had to know where App-B was located, nor did the network’s core. Only the edge of the network, specifically the mapping database, had to know the location of App-B. The rest of the network only had to see the location of switch S2, which does not change.

Let’s now assume App-B moves to a new location switch S3. Now, when App-A sends a message to App-B, it does the same thing it did before, i.e., it addresses the message to App-B and gives the packet to the network. The network then looks up the location of App-B and finds that it is now attached to switch S3. So, it puts S3’s address on the message and forwards it accordingly. At S3, the message is received, the outer address is removed, and the original message is delivered as desired.

The movement of App-B was not tracked by App-A at all. The address of App-B identified App-B, while the address of the switch, S2 or S3, identified App-B’s location. App-A can communicate freely with App-B no matter where App-B is located, allowing the system administrator to place App-B in any location and move it as desired, thus achieving the flexibility needed in the data center.

Multicast Distribution Tree (MDT)

We have a Multicast Distribution Tree MDT tree on top that is used to forward multi-destination traffic without having loops. The Multicast distribution tree is dynamically built to send flood traffic for specific protocols. Again, it does this without creating loops in the overlay network. The tunnels created for the endpoints to communicate will have tunnel endpoints. The tunnel endpoints are known as the VTEP. The VTEP addresses are assigned to each Leaf switch from a pool that you specify in the ACI startup and discovery process.

Normalize the transports

VXLAN tunnels in the ACI fabric are used to normalize the transports in the ACI network. Therefore, traffic between endpoints can be delivered using the VXLAN tunnel, resulting in any transport network regardless of the device connecting to the fabric.

Building the VXLAN tunnels

So, using VXLAN in the overlay enables any network, and you don’t need to configure anything special on the endpoints for this to happen. The endpoints that connect to the ACI fabric do not need special software or hardware. The endpoints send regular packets to the leaf nodes they are connected to directly or indirectly. As endpoints come online, they send traffic to reach a destination.

Bridge domain and VRF

Therefore, the Cisco SDN ACI under the hood will automatically start to build the VXLAN overlay network for you. The VXLAN network is based on the Bridge Domain (BD), or VRF ACI constructs deployed to the leaf switches. The Bridge Domain is for Layer 2, and the VRF is for Layer 3. So, as devices come online and send traffic to each other, the overlay will grow in reachability in the Bridge Domain or the VRF.

Diagram: Horizontal scaling load balancing.

Routing for endpoints

Routing within each tenant, VRF is based on host routing for endpoints directly connected to the Cisco ACI fabric. For IPv4, the host routing is based on the /32, giving the ACI a very accurate picture of the endpoints. Therefore, we have exact routing in the ACI.

In conjunction, we have a COOP database that runs on the Spines that offers remarkably optimized fabric in terms of knowing where all the endpoints are located. To facilitate this, every node in the fabric has a TEP address, and we have different types of TEPs depending on the role of the device. The Spine and the Leaf will have TEP addresses but will differ from each other.

The VTEP and PTEP

The Leaf’s nodes are the Virtual Tunnel Endpoints (VTEP). In ACI, this is known as PTEP, the physical tunnel endpoints. These PTEP addresses represent the “WHERE” in the ACI fabric that an endpoint lives in.

Cisco ACI uses a dedicated VRF and a subinterface of the uplinks from the Leaf to the Spines as the infrastructure to carry VXLAN traffic. In Cisco ACI terminology, the transport infrastructure for VXLAN traffic is known as Overlay-1, which is part of the tenant “infra.”

The Spine TEP

The Spines also have a PTEP and an additional proxy TEP. This is used for forwarding lookups into the mapping database. The Spines have a global view of where everything is, which is held in the COOP database synchronized across all Spine nodes. All of this is done automatically for you.

For this to work, the Spines have an Anycast IP address known as the Proxy TEP. The Leaf can use this address if they do not know where an endpoint is, so they ask the Spine for any unknown endpoints, and then the Spine checks the COOP database. This brings many benefits to the ACI solution, especially for traffic optimizations and reducing flooded traffic in the ACI. Now, we have an optimized fabric for better performance.

The ACI optimizations

Mouse and elephant flows

This provides better performance for load balancing different flows. For example, in most data centers, we have latency-sensitive flows, known as mouse flows, and long-lived bandwidth-intensive flows, known as elephant flows.

The ACI has more precisely load-balanced traffic using algorithms that optimize mouse and elephant flows and distribute traffic based on flow lets: flow let load-balancing. Within a Leaf, Spine latency is low and consistent from port to port. The max latency of a packet from one port to another in the architecture is the same regardless of the network size. So you can scale the network without degrading performance. Scaling is often done on a POD-by-POD basis. For more extensive networks, each POD would be its Leaf and Spine network.

ARP optimizations: Anycast gateways

The ACI comes by default with a lot of traffic optimizations. Firstly, instead of using an ARP and broadcasting across the network, that can hamper performance. The Leaf can assume that the Spine will know where the destination is ( and it does via the COOP database ), so there is no need to broadcast to everyone to find a destination.

If the Spine knows where the endpoint is, it will forward it to the other Leaf. If not, it will drop the traffic.

Fabric anycast addressing

This again adds performance benefits to the ACI solution as the table sizes on the Leaf switches can be kept smaller than they would if they needed to know where all the destinations were, even if they were not or never needed to communicate with them. On the Leaf, we have an Anycast address too.

These fabric anycast addresses are available for Layer 3 interfaces. On the Leaf ToR, we can establish an SVI that uses the same MAC address on every ToR; therefore, when an endpoint needs to route to a ToR. It doesn’t matter which ToR you use. The Anycast Address is spread across all ToR leaf switches.

Pervasive gateway

Now we have predictable latency to the first hop, and you will use the local route VRF table within that ToR instead of traversing the fabric to a different ToR. This is the Pervasive Gateway feature that is used on all Leaf switches. The Cisco ACI has many advanced networking features, but the pervasive gateway is my favorite. It does take away all the configuration mess we had in the past.

The Cisco SDN ACI Integrations

OpenShift and Cisco ACI

OpenSwitch virtual network

OpenShift does this with an SDN layer and enhances Kubernetes networking to have a virtual network across all the nodes. It is created with the Open Switch standard. For OpenShift SDN, this pod network is established and maintained by the OpenShift SDN, configuring an overlay network using a virtual switch called the OVS bridge, forming an OVS network that gets programmed with several OVS rules. The OVS is a popular open-source solution for virtual switching.

OpenShift SDN plugin

We mentioned that you could tailor the virtual network topology to suit your networking requirements, which can be determined by the OpenShift SDN plugin and the SDN model you select. With the default OpenShift SDN, there are several modes available. This level of SDN mode you choose is concerned with managing connectivity between applications and providing external access to them. Some modes are more fine-grained than others. The Cisco ACI plugins offer the most granular.

Integrating ACI and OpenShift platform

The Cisco ACI CNI plugin for the OpenShift Container Platform provides a single, programmable network infrastructure, enterprise-grade security, and flexible micro-segmentation possibilities. The APIC can provide all networking needs for the workloads in the cluster. Kubernetes workloads become fabric endpoints, like Virtual Machines or Bare Metal endpoints.

The Cisco ACI CNI plugin extends the ACI fabric capabilities to OpenShift clusters to provide IP Address Management, networking, load balancing, and security functions for OpenShift workloads. In addition, the Cisco ACI CNI plugin connects all OpenShift Pods to the integrated VXLAN overlay provided by Cisco ACI.

The Cisco SDN ACI and AppDynamics

AppDynamis overview

So, you have multiple steps or services for an application to work. These services may include logging in and searching to add something to a shopping cart. These services will invoke various applications, web services, third-party APIs, and databases, known as business transactions.

The user’s critical path

A business transaction is the essential user interaction with the system and is the customer’s critical path. Therefore, business transactions are the things you care about. If they start to go, it will cause your system to degrade. So, you need ways to discover your business transactions and determine if there are any deviations from baselines. This should also be done automated, as learning baseline and business transitions in deep systems is nearly impossible using the manual approach.

So, how do you discover all these business transactions?

AppDynamics automatically discovers business transactions and builds an application topology map of how the traffic flows. A topology map can view usage patterns and hidden flows, acting as a perfect feature for an Observability platform.

AppDynamic topology

AppDynamics will discover the topology for all of your application components. All of this is done automatically for you. It can then build a performance baseline by capturing metrics and traffic patterns. This allows you to highlight issues when services and components are slower than usual.

AppDynamics uses agents to collect all the information it needs. The agent monitors and records the calls that are made to a service. This is from the entry point and follows executions along its path through the call stack.

Types of Agents for Infrastructure Visibility

If the agent is installed on all critical parts, you can get information about that specific instance. This can help you build a global picture. So we have an Application Agent, Network Agent, and Machine Agent for Server visibility and Hardware/OS.

App Agent: This agent will monitor apps and app servers, and example metrics will be slow transitions, stalled transactions, response times, wait times, block times, and errors.
Network Agent: This agent monitors the network packets, TCP connection, and TCP socket. Example metrics include performance impact Events, Packet loss and retransmissions, RTT for data transfers, TCP window size, and connection setup/teardown.
Machine Agent Server Visibility: This agent monitors the number of processes, services, caching, swapping, paging, and querying. Example Metrics include hardware/software interrupts, virtual memory/swapping, process faults, and CPU/DISK/Memory utilization by the process.
Machine Agent: Hardware/OS – disks, volumes, partitions, memory, CPU. Example metrics: CPU busy time, MEM utilization, and pieces file.

Automatic establishment of the baseline

A baseline is essential, a critical step in your monitoring strategy. Doing this manual is hard, if not impossible, with complex applications. Having this automatically done for you is much better. You must automatically establish the baseline and alert yourself about deviations from the baseline. This will help you pinpoint the issue faster and resolve issues before the problem can be affected. Platforms such as AppDynamics can help you here. Any malicious activity can be seen from deviations from the security baseline and performance issues from the network baseline.

Summary: Cisco ACI Components

In the ever-evolving world of networking, organizations are constantly seeking ways to enhance their infrastructure’s performance, security, and scalability. Cisco ACI (Application Centric Infrastructure) presents a cutting-edge solution to these challenges. By unifying physical and virtual environments and leveraging network automation, Cisco ACI revolutionizes how networks are built and managed.

Section 1: Understanding Cisco ACI Architecture

At the core of Cisco ACI lies a robust architecture that enables seamless integration between applications and the underlying network infrastructure. The architecture comprises three key components:

1. Application Policy Infrastructure Controller (APIC):

The APIC serves as the centralized management and policy engine of Cisco ACI. It provides a single point of control for configuring and managing the entire network fabric. Through its intuitive graphical user interface (GUI), administrators can define policies, allocate resources, and monitor network performance.

2. Nexus Switches:

Cisco Nexus switches form the backbone of the ACI fabric. These high-performance switches deliver ultra-low latency and high throughput, ensuring optimal data transfer between applications and the network. Nexus switches provide the necessary connectivity and intelligence to enable the automation and programmability features of Cisco ACI.

3. Application Network Profiles:

Application Network Profiles (ANPs) are a fundamental aspect of Cisco ACI. ANPs define the policies and characteristics required for specific applications or application groups. By encapsulating network, security, and quality of service (QoS) policies within ANPs, administrators can streamline the deployment and management of applications.

Section 2: The Power of Network Automation

One of the most compelling aspects of Cisco ACI is its ability to automate network provisioning, configuration, and monitoring. Through the APIC’s powerful automation capabilities, network administrators can eliminate manual tasks, reduce human errors, and accelerate the deployment of applications. With Cisco ACI, organizations can achieve greater agility and operational efficiency, enabling them to rapidly adapt to evolving business needs.

Section 3: Security and Microsegmentation with Cisco ACI

Security is a paramount concern for every organization. Cisco ACI addresses this by providing robust security features and microsegmentation capabilities. With microsegmentation, administrators can create granular security policies at the application level, effectively isolating workloads and preventing lateral movement of threats. Cisco ACI also integrates with leading security solutions, enabling seamless network enforcement and threat intelligence sharing.

Conclusion:

Cisco ACI is a game-changer in the realm of network automation and infrastructure management. Its innovative architecture, coupled with powerful automation capabilities, empowers organizations to build agile, secure, and scalable networks. By leveraging Cisco ACI’s components, businesses can unlock new levels of efficiency, flexibility, and performance, ultimately driving growth and success in today’s digital landscape.

Container Based Virtualization

February 24, 2016

by Matt Conran Blog

Container Based Virtualization

Container-based virtualization, or containerization, is a popular technology revolutionizing how we deploy and manage applications. In this blog post, we will explore what container-based virtualization is, why it is gaining traction, and how it differs from traditional virtualization techniques.

Container-based virtualization is a lightweight alternative to traditional methods such as hypervisor-based virtualization. Unlike virtual machines (VMs), which require a separate operating system (OS) instance for each application, containers share the host OS. This means containers can be more efficient regarding resource utilization and faster to start and stop.

Container-based virtualization, also known as operating system-level virtualization, is a lightweight virtualization method that allows multiple isolated user-space instances, known as containers, to run on a single host operating system. Unlike traditional virtualization techniques, which rely on hypervisors and full-fledged guest operating systems, containerization leverages the host operating system's kernel to provide resource isolation and process separation. This streamlined approach eliminates the need for redundant operating system installations, resulting in improved performance and efficiency.

Enhanced Portability: Containers encapsulate all the dependencies required to run an application, making them highly portable across different environments. Developers can package their applications with all the necessary libraries, frameworks, and configurations, ensuring consistent behavior regardless of the underlying infrastructure.

Scalability and Resource Efficiency: Containers enable efficient resource utilization by sharing the host's operating system and kernel. With their lightweight nature, containers can be rapidly provisioned, scaled up or down, and migrated across hosts, ensuring optimal resource allocation and responsiveness.

Isolation and Security: Containers provide isolation at the process level, ensuring that each application runs in its own isolated environment. This isolation prevents interference and minimizes security risks, making container-based virtualization an attractive choice for multi-tenant environments and cloud-native applications.

Container-based virtualization has gained significant traction across various industries and use cases. Some notable examples include:

Microservices Architecture: Containerization seamlessly aligns with the principles of microservices, allowing applications to be broken down into smaller, independent services. Each microservice can be encapsulated within its own container, enabling rapid development, deployment, and scaling.

DevOps and Continuous Integration/Continuous Deployment (CI/CD): Containers play a crucial role in modern DevOps practices, streamlining the software development lifecycle. With container-based virtualization, developers can easily package, test, and deploy applications across different environments, ensuring consistency and reducing deployment complexities.

Hybrid and Multi-Cloud Environments: Containers facilitate hybrid and multi-cloud strategies by abstracting away the underlying infrastructure dependencies. Applications can be packaged as containers and seamlessly deployed across different cloud providers or on-premises environments, enabling flexibility and avoiding vendor lock-in.

Matt Conran

VMware and KVM are virtualization systems that allow you to run Linux kernels and operating systems on top of a virtualized layer, commonly known as a hypervisor. Because each VM is based on its operating system kernel in its memory space, this approach provides extreme isolation between workloads.

Containers differ fundamentally from shared kernel systems since they implement isolation between workloads entirely within the kernel. This is called operating system virtualization.

A major advantage of containers is resource efficiency, since each isolated workload does not require a whole operating system instance. Sharing a kernel reduces the amount of indirection between isolated tasks and their real hardware. The kernel only manages a container when a process is running inside a container. An actual machine does not have a second layer, unlike a virtual machine. The process would have to bounce into and out of privileged mode twice when calling the hardware or hypervisor in a VM, significantly slowing down many operations.

Traditional Deployment Models

So, how do containers facilitate virtualization? Firstly, the traditional application deployment was based on a single-server approach. As a result, one application was installed per physical server, wasting server resources, and components such as RAM and CPU were never fully utilized. There was also considerable vendor lock-in, making moving applications from one hardware vendor to another hard.

Then, the world of hypervisor-based virtualization was introduced, and the concept of a virtual machine (VM) was born. Soon after, we had container-based applications. Container-based virtualization introduced container networking, and new principles arose for security around containers, specifically, Docker container security.

Introducing hypervisors

We still deployed physical servers but introduced hypervisors on the physical host, enabling the installation of multiple VMs on a single server. Each VM is isolated from its operating system. Hypervisor-based virtualization introduced better resource pooling as one physical server could now be divided into multiple VMs, each hosting a different application type. This was years better than single-server deployments and opened the doors to open networking.

The VM deployment approach increased agility and scalability, as applications within a VM are scaled by simply spinning up more VMs on any physical host. While hypervisor-based virtualization was a step in the right direction, a guest operating system for each application is pretty intensive. Each VM requires RAM, CPU, storage, and an entire guest OS, all-consuming resources.

Introducing Virtualization

Another advantage of virtualization is the ability to isolate applications or services. Each virtual machine operates independently, with its resources and configurations. This enhances security and stability, as issues in one virtual machine do not affect others. It also allows for easy testing and development, as virtual machines can be quickly created and discarded.

Virtualization also offers improved disaster recovery and business continuity. By encapsulating the entire virtual machine, including its operating system, applications, and data, into a single file, organizations can quickly back up, replicate, and restore virtual machines. This ensures that critical systems and data are protected and can rapidly recover during a failure or disaster.

Furthermore, virtualization enables workload balancing and dynamic resource allocation. Virtual machines can be dynamically migrated between physical servers to optimize resource utilization and performance. This allows for better utilization of computing resources and the ability to respond to changing workload demands.

Related: You may find the following helpful post before proceeding to how containers facilitate virtualization.

Container Virtualization. Key Container Based Virtualization Discussion points:	Introduction to containerized technologies. The role of container based applications. Discussion on container networking and Linux kernel. A final note on microsegmentation.

Back to Basics: Containers and Container Virtualization

The Traditional World

Before we address how containers facilitate virtualization, let’s address the basics. In the past, we could solely run one application per server. However, the open-systems world of Windows and Linux didn’t have the technologies to safely and securely run multiple applications on the same server.

So, every time we needed a new application, we would buy a new server. We had the virtual machine (VM) to solve the waste of resources. With the VM, we had a technology that permitted us to safely and securely run applications on a single server. Unfortunately, the VM model also has additional challenges.

Migrating VMs

For example, VMs are slow to boot, and portability isn’t great — migrating and moving VM workloads between hypervisors and cloud platforms is more complicated than it needs to be. All of which drove the need for a new technology of containers with container virtualization.

How do containers facilitate virtualization? So, we needed a lightweight tool without losing the scalability and agility benefits of the VM-based application approach. The lightweight tool is container-based virtualization, and Docker acts at the forefront. The container offers a similar capability to that of object-oriented programming. They let you build composable modular building blocks, making it easier to design distributed systems.

1st Lab Guide on Container Networking

In the following example, we have one Docker host. We can list the available networks for these Docker hosts with the command docker network ls. These are not WAN or VPN networks; they are only Docker networks.

Docker networks are virtual networks that allow containers to communicate with each other and the outside world. They provide isolation, security, and flexibility to manage network traffic flow between containers. By default, when you create a new Docker container, it is connected to a default bridge network, which allows communication with other containers on the same host.

Notice the subnets assigned of 172.17.0.0/16. So, the default gateway ( exit point) is set to the docker0 bridge.

Types of Docker Networks:

Docker offers various types of networks, each serving a specific purpose:

1. Bridge Network:

The bridge network is the default network that enables communication between containers on the same host. Containers connected to the bridge network can communicate using IP addresses or container names. It provides a simple way to connect containers without exposing them to the outside world.

2. Host Network:

In the host network mode, a container shares the network stack with the host, using its network interface directly. This mode provides maximum network performance as no network address translation (NAT) is involved. However, it also means the container is directly exposed to the host’s network, potentially introducing security risks.

3. Overlay Network:

The overlay network allows containers to communicate across multiple Docker hosts, even in different physical or virtual networks. It achieves this by encapsulating network packets and routing them to the appropriate destination. Overlay networks are essential for creating distributed and scalable applications.

4. Macvlan Network:

The Macvlan network mode allows containers to have MAC addresses and appear as separate devices. This mode is useful when assigning IP addresses to containers and making them accessible from the external network. It is commonly used when containers must be treated as physical devices.

5. None Network:

The non-network mode isolates a container from all networking. It effectively disables all networking capabilities and prevents the container from communicating with other containers or the outside world. This mode is typically used when networking is not required or desired.

A key point: Lab Guide on Container Networking

You can attach as many containers as you like to a bridge. They will be assigned IP addresses within the same subnet, meaning they can communicate by default. You can have a container with two Ethernet interfaces ( virtual interfaces ) connected to two different bridges on the same host and have connectivity to two networks simultaneously.

Also, remember that the scope is local when you are doing this, and even if the docker hosts are on the same underlying network but with different hosts, they won’t have IP reachability. In this case, you may need a VXLAN overlay network to connect containers on different docker hosts.

inspecting container networks — Diagram: Inspecting container networks

Container-based Virtualization

One critical benefit of container-based virtualization is its portability. Containers encapsulate the application and all its dependencies, allowing it to run consistently across different environments, from development to production. This portability eliminates the “it works on my machine” problem and makes it easier to maintain and scale applications.

Scalability

Another advantage of containerization is its scalability. Containers can be easily replicated and distributed across multiple hosts, making it straightforward to scale applications horizontally. Furthermore, container orchestration platforms, like Kubernetes, provide automated management and scaling of containers, simplifying the deployment and management of complex applications.

Security

Security is crucial to any virtualization technology, and container-based virtualization is no exception. Containers provide isolation between applications, preventing them from interfering with each other. However, it is essential to note that containers share the same kernel as the host OS, which means a compromised container can potentially impact other containers. Proper security measures, such as regular updates and vulnerability scanning, are essential to ensure the security of containerized applications.

Tooling

Container-based virtualization also offers various tools and platforms for application development and deployment. Docker, for example, is a popular containerization platform that provides a user-friendly interface for building, running, and managing containers. It simplifies container image creation and enables developers to package their applications and dependencies.

Applications of Container-Based Virtualization:

1. DevOps and Continuous Integration/Continuous Deployment (CI/CD): Containerization enables developers to package applications, libraries, and configurations into portable and reproducible containers. This simplifies the deployment process and ensures consistency across different environments, facilitating faster software delivery.

2. Microservices Architecture: Container-based virtualization aligns well with the microservices architectural pattern. Organizations can develop, deploy, and scale each service independently using containers by breaking down complex applications into more minor, loosely coupled services. This approach enhances modularity, scalability, and fault tolerance.

3. Hybrid Cloud and Multi-Cloud Environments: Containers provide a unified platform for deploying applications across hybrid and multi-cloud environments. With container orchestration tools, organizations can leverage the benefits of multiple cloud providers while ensuring consistent deployment and management practices.

Application Landscape Changes

The application landscape has changed from a monolithic design to a design consisting of microservices. Today, applications are constantly developed. Patches usually patch only certain parts of the application, and the entire application is built from loosely coupled components instead of existing tightly coupled ones.

The entire application stack is broken into components and spread over multiple servers and locations, all requiring cross-communication.

For example, users connect to a presentation layer, the presentation layer then connects to some shopping cart, and the shopping cart connects to a catalog library. These components are potentially stored on different servers, maybe different data centers.

The application is built from several small parts, known as microservices. Each component or microservice can now be put into a lightweight container—a scaled-down VM.

container based virtualization — Diagram: Container based virtualization.

How do containers facilitate virtualization?

Container-Based Applications

Now, we have complex distributed software stacks based on microservices. Its base consists of loosely coupled components that may change and software that runs on various hardware, including test machines, in-house clusters, cloud deployments, etc. The web front end may include the following:

Ruby + Rail.
API endpoints with Python 2.7.
Stack website with Nginx.
A variety of databases.

We have a very complex stack on top of various hardware devices. While the traditional monolithic application will likely remain for some time, containers still exhibit the use case to modernize the operational model for conventional stacks. Both monolithic and container-based applications can live together.

Container-based virtualization

The application’s complexity, scalability, and agility requirements have led us to the market of container-based virtualization. Container-based virtualization uses the host’s kernel to run multiple guest instances. Now, we can run multiple guest instances (containers), and each container will have its root file system, process, and network stack.

Containers allow you to package up an application with all its parts in an isolated environment. It is a complete abstraction and does not need to run dependencies on the hosts. Docker, a type of container (first based on Linux Containers but now powered by runC), separates the application from infrastructure using container technologies.

Similar to how VMs separate the operating system from bare metal, containers let you build a layer of isolation in software that reduces the burden of human communication and specific workflows. An excellent way to understand containers is to accept that they are not VMs—they are simple wrappers around a single Unix process. Containers contain everything they need to run (runtime, code, libraries, etc.).

Linux kernel namespaces

Isolation or variants of isolation have been around for a while. We have mount namespacing in 2.4 kernels and userspace namespacing in 3.8. These technologies allow the kernel to create partitions and isolate PIDs. Linux containers (Lxc) started in 2008, and Docker was introduced in Jan 2013, with a public release of 1.0 in 2014. We are now at version 1.9, which has some new networking enhancements.

Docker uses Linux kernel namespaces and control groups, providing an isolated workspace, which offers the starting grounds for the Docker security options. Namespaces offer an isolated workspace that we call a container. They help us fool the container.

We have PID for process isolation, MOUNT for storage isolation, and NET for network-level isolation. The Linux network subsystem has the correct information for additional Linux network information.

how do containers facilitate virtualization — Diagram: How do containers facilitate virtualization

Container based application: Container operations

Containers use schedulers. A scheduler starts containers on the correct host and then connects them. It also needs to manage container failover and handle container scalability when there is too much data to process for a single instance. Popular container schedulers include Docker Swarm, Apache Mesos, and Google Kubernetes.

The correct host is selected depending on the type of scheduler used. For example, Docker Swarm will have three strategies: spread, binpack, and random. Spread means node selection is based on the fewest containers, disregarding their states. Binpack selection is based on hosts with minimum resources, i.e., the most packed. Finally, random strategy selections are chosen randomly.

Containers are quick to start.

How do containers facilitate virtualization? First, they are quick. Starting a container is much faster than starting a VM—lightweight containers can be started in as little as 300ms. Initial tests on Docker revealed that a newly created container from an existing image takes up only 12 kilobytes of disk space.

A VM could take up thousands of megabytes. The container is lightweight as it references points to a layered filesystem image. Container deployment is also swift and network-efficient.

Fewer data needs to travel across the network and storage fabrics. Elastic applications that have frequent state changes can be built more efficiently. Both Docker and Linux containers fundamentally change application consumption.

As a side note, not all workloads are suitable for containers, and heavy loads like databases are put into VMs to support multi-cloud environments.

Docker networking

Docker networking is an essential aspect of containerization that allows containers to communicate with each other and external networks. In this document, we will explore the different networking options available in Docker and how they can facilitate seamless communication between containers.

By default, Docker provides three networking options: bridge, host, and none. The bridge network is the default network created when Docker is installed. It allows containers to communicate with each other using IP addresses. Containers within the same bridge network can communicate with each other directly without the need for port mapping.

As the name suggests, the host network allows containers to share the network namespace with the host system. This means that containers using the host network can directly access the host system’s network interfaces. This option is helpful for scenarios where containers must bind to specific network interfaces on the host.

On the other hand, the non-network option completely isolates the container from the network. Containers using the none network cannot communicate with other containers or external networks. This option is useful when running a container in complete isolation.

Creating custom networks

In addition to these default networking options, Docker also provides the ability to create custom networks. Custom networks allow containers to communicate with each other, even if they are not in the same network namespace. Custom networks can be made using the `docker network create` command, specifying the desired driver (bridge, overlay, macvlan, etc.) and any additional options.

One of the main benefits of using custom networks is the ability to define network-level access control. Docker provides the ability to define network policies using network labels. These labels can control which containers can communicate with each other and which ports are accessible.

Closing Points on Docker networking

Networking is very different in Docker than what we are used to. Networks are domains that interconnect sets of containers. So, if you give access to a network, you can access all containers. However, if you want external access to other networks or containers, you must specify rules and port mapping.

A driver backs every network, be it a bridge or overlay driver. These Docker-based drivers can be swapped out with any ecosystem driver. The team at Docker views them as pluggable batteries.

Docker utilizes the concept of scope—local (default) and Global. The local scope is a local network, and the global scope has visibility across the entire cluster. If your driver is a global scope driver, your network belongs to a global scope. A local scope driver corresponds to the local scope.

Containers and Microsegmentation

Microsegmentation is a security technique that divides a network into smaller, isolated segments, allowing organizations to create granular security policies. This approach provides enhanced control and visibility over network traffic, preventing lateral movement and limiting the impact of potential security breaches.

Microsegmentation offers organizations a proactive approach to network security, allowing them to create an environment more resilient to cyber threats. By implementing microsegmentation, organizations can enhance their security posture, minimize the risk of lateral movement, and protect their most critical assets. As the cyber threat landscape continues to evolve, microsegmentation is an effective strategy to safeguard network infrastructure in an increasingly interconnected world.

Docker and Micro-segmentation

Docker 0 is the default bridge. They have now extended into bundles of multiple networks, each with independent bridges. Different bridges cannot directly talk to each other. It is a private, isolated network offering micro-segmentation and multi-tenancy features.

The only way for them to communicate is via host namespace and port mapping, which is administratively controlled. Docker multi-host networking is a new feature in 1.9. A multi-host network comprises several docker hosts that form a cluster.

Several containers in each host form the cluster by pointing to the same KV (example -zookeeper) store. The KV store that you point to defines your cluster. Multi-host networking enables the creation of different topologies and lets the container belong to several networks. The KV store may also be another container, allowing you to stay in a 100% container world.

Final points on container-based virtualization

In recent years, container-based virtualization has become famous for deploying and managing applications. Unlike traditional virtualization, which relies on hypervisors to run multiple virtual machines on a single physical server, container-based virtualization leverages lightweight, isolated containers to run applications.

So, what exactly is container-based virtualization, and why is it gaining traction in the technology industry? In this blog post, we will explore the concept of container-based virtualization, its benefits, and how it differs from traditional virtualization.

Operating system-level virtualization

Container-based virtualization, also known as operating system-level virtualization, is a form of virtualization that allows multiple containers to run on a single operating system kernel. Each container is isolated from the others, ensuring that applications and their dependencies are encapsulated within their runtime environment. This isolation eliminates application conflicts and provides a consistent environment across deployment platforms.

Critical advantages of container virtualization

One of the critical advantages of container-based virtualization is its lightweight nature. Containers are designed to be portable and efficient, allowing for rapid deployment and scaling of applications. Unlike virtual machines, which require an entire operating system to run, containers share the host operating system kernel, reducing resource overhead and improving performance.

Another benefit of container-based virtualization is its ability to facilitate microservices architecture. By breaking down applications into more minor, independent services, containers enable developers to build and deploy applications more efficiently. Each microservice can be encapsulated within its container, making it easier to manage and update without impacting other application parts.

Greater flexibility and scalability

Moreover, container-based virtualization offers greater flexibility and scalability. Containers can be easily replicated and distributed across hosts, allowing for seamless horizontal scaling. This ability to scale quickly and efficiently makes container-based virtualization ideal for modern, dynamic environments where applications must adapt to changing demands.

Container virtualization is not a complete replacement.

It’s important to note that container-based virtualization is not a replacement for traditional virtualization. Instead, it complements it. While traditional virtualization is well-suited for running multiple operating systems on a single physical server, container-based virtualization is focused on maximizing resource utilization within a single operating system.

In conclusion, container-based virtualization has revolutionized application deployment and management. Its lightweight nature, isolation capabilities, and scalability make it a compelling choice for modern software development and deployment. As technology continues to evolve, container-based virtualization will likely play a significant role in shaping the future of application deployment.

Container-based virtualization has transformed how we develop, deploy, and manage applications. Its lightweight nature, scalability, portability, and isolation capabilities make it an attractive choice for modern software development. By adopting containerization, organizations can achieve greater efficiency, agility, and cost savings in their software development and deployment processes. As container technologies continue to evolve, we can expect even more exciting possibilities in virtualization.

Summary: Container Based Virtualization

In recent years, container-based virtualization has emerged as a game-changer in technology. This innovative approach offers numerous advantages over traditional virtualization methods, providing enhanced flexibility, scalability, and efficiency. This blog post delved into container-based virtualization, exploring its key concepts, benefits, and real-world applications.

Understanding Container-Based Virtualization

Container-based virtualization, or operating system-level virtualization, is a lightweight alternative to traditional hypervisor-based virtualization. Unlike the latter, where each virtual machine runs on a separate operating system, containerization allows multiple containers to share the same OS kernel. This approach eliminates redundant OS installations, resulting in a more efficient and resource-friendly system.

Benefits of Container-Based Virtualization

2.1 Enhanced Performance and Efficiency

Containers are lightweight and have minimal overhead, enabling faster deployment and startup times than traditional virtual machines. Additionally, the shared kernel architecture reduces resource consumption, allowing for higher density and better utilization of hardware resources.

2.2 Improved Scalability and Portability

Containers are highly scalable, allowing applications to be easily replicated and deployed across various environments. With container orchestration platforms like Kubernetes, organizations can effortlessly manage and scale their containerized applications, ensuring seamless operations even during periods of high demand.

2.3 Isolation and Security

Containers provide isolation between applications and the host operating system, enhancing security and reducing the risk of malicious attacks. Each container operates within its own isolated environment, preventing interference from other containers and mitigating potential vulnerabilities.

Section 3: Real-World Applications

3.1 Microservices Architecture

Container-based virtualization aligns perfectly with the microservices architectural pattern. By breaking down applications into more minor, decoupled services, organizations can leverage the agility and scalability containers offer. Each microservice can be encapsulated within its container, enabling independent development, deployment, and scaling.

3.2 DevOps and Continuous Integration/Continuous Deployment (CI/CD)

Containerization has become a cornerstone of modern DevOps practices. By packaging applications and their dependencies into containers, development teams can ensure consistent and reproducible environments across the entire software development lifecycle. This facilitates seamless integration, testing, and deployment processes, leading to faster time-to-market and improved collaboration between development and operations teams.

Conclusion:

Container-based virtualization has revolutionized how we build, deploy, and manage applications. Its lightweight nature, scalability, and efficient resource utilization make it an ideal choice for modern software development and deployment. As organizations continue to embrace digital transformation, containerization will undoubtedly play a crucial role in shaping the future of technology.

Zero Trust Security Strategy

Highlights: Zero Trust Security Design

Back to basics with the Zero Trust Security Design

Control vs. visibility

Zero Trust Security Strategy

Zero Trust Security Strategy: Data-Centric Model

Zero trust and microsegmentation

Start a zero trust security strategy journey

Do not send a SPA packet

A key point: Choosing the vendor

Zero Trust Security Strategy: The Components

Automation and orchestration

Zero trust automation

Ansible Tower: Delegation of Control

Security integration with automation

A key point – Just alert and not block

Zero Trust Least Privilege, and Adaptive Access

Enforcement points and flows

Identity centric design

A key point: Zero trust identity approach

Zero trust environment and adaptive access

Zero Trust and Microsegmentation

Small and protected isolated sections

Zero trust and microsegmentation

Containers and Zero Trust

The OpenShift secure route

OpenShift security: OpenShift SDN and the secure route

Context Based Authentication

Take a data-centric approach. Zero trust data

Zero Trust Data Security

Step 1: Identify your sensitive data

Step2: Zero trust and microsegmentation

A final note: Firewall micro segmentation

Cisco ACI Components

Table of Contents

Highlights: Cisco ACI Components

Back to Basics: Cisco ACI components

The Cisco ACI SDN Solution

ACI Cisco: Integrations

Cisco ACI: Integration Options

The Cisco SDN ACI Design

Highlighting the overlay and underlay

Overlay and underlay components

Building the VXLAN tunnels

Routing for endpoints

The ACI optimizations

The Cisco SDN ACI Integrations

The Cisco SDN ACI and AppDynamics

Summary: Cisco ACI Components

Container Based Virtualization

Back to Basics: Containers and Container Virtualization

1st Lab Guide on Container Networking

Container-based Virtualization

Application Landscape Changes

How do containers facilitate virtualization?

Container-based virtualization

Linux kernel namespaces

Container based application: Container operations

Containers are quick to start.

Docker networking

Closing Points on Docker networking

Final points on container-based virtualization

Critical advantages of container virtualization

Summary: Container Based Virtualization

Quick Links

Contact

Subscribe Now