Shulou(Shulou.com)06/01 Report--

Hi! This is the last article on Tungsten Fabric architecture parsing, which introduces TF's application-based security policy.

A series of articles on Tungsten Fabric architecture analysis, presented to you by the TF Chinese community, are designed to help new entrants to the TF community to answer questions. We will systematically introduce the features of TF, how it works, how to collect / analyze / deploy, how to orchestrate, how to connect to physical networks, and so on.

Regular firewall policies contain rules based on a single IP address or subnet range. In a data center of any size, this can lead to a proliferation of firewall rules that are difficult to manage when created and difficult to understand when troubleshooting.

This is because the IP address of the server or VM is independent of the application, the application owner, the location, or any other attribute. For example, consider an enterprise that has two data centers and deploys three-tier applications in development and production, as shown in the following figure.

In this enterprise, it is required that each instance of each tier application can only communicate with the next tier instance in the same instance. As shown in the figure, this requires a separate policy for each application instance.

When solving the problem, the administrator must know the relationship between the IP address and the application instance, and each time a new instance is deployed, new firewall rules must be written.

Apply label

The Tungsten Fabric controller supports label-based security policies that can be applied to projects, networks, vRouters, VM, and interfaces.

Tags in the object model are propagated to all objects contained in the object to which the tag is applied, and tags applied at a lower level that contain a hierarchy take precedence over tags applied at a higher level. The label has a name and value. Many tag names are used as part of the Tungsten Fabric release.

The following table shows the typical uses of label types:

As shown in the table, in addition to the tag types provided by Tungsten Fabric, users can also create their own custom tag names as needed, and have a _ label _ type tag that can be used to fine-tune the data flow.

Create an application policy

The application policy contains rules based on tag values and service groups, which are collections of TCP or UDP port numbers.

First, the security administrator assigns a label of type _ application _ to the application stack and a label of type _ tier _ to each software component of the application. This is shown in the following figure.

In this example, the application is marked FinancePortal _, and the layer is marked _ web,app_ and _ db. Service groups have been created for traffic entering the application stack and between each layer.

The security administrator then creates an application policy called the _ Portal-3-Tier _ containing rule, which will allow only the required traffic.

Next, the application policy set is associated with the application tag _ FinancePortal and contains the application policy _ Portal-3-Tier.

At this point, you can start the application stack and apply the tags to each VM in the Tungsten Fabric controller. This causes the controller to calculate which routes need to be sent to each vRouter to enforce the application policy set and to send these routes to each vRouter.

If there is one instance for each software component, the routing table in each vRouter is as follows:

Networks and virtual machines are named here as their layers. In fact, the relationship between entity names and layers is usually not that simple.

As you can see from the table, routing enables only the traffic specified in the application policy, but the label-based rules here have been translated into network address-based firewall rules that vRouter can apply.

Control traffic between deployments

After successfully creating the application stack, let's take a look at what happens when we create another deployment of the stack, as shown below.

Nothing in the original policy prevents traffic from flowing between tiers in one deployment to tiers in another deployment.

You can modify this behavior by tagging each component of each stack with _ deployment _ tag and adding _ match _ condition to the application policy to allow traffic to flow between tiers only if the deployment labels match.

The updated policy is as follows:

Now, traffic meets the strict requirement that traffic flows only between components in the same stack.

More advanced application strategy

By applying different types of tags, security policies can be applied to multiple dimensions, all of which can be applied in a single policy.

For example, in the following figure, a single policy can segment traffic within a single stack on a site-by-site basis, but allows the database tier to be shared within the site.

If multiple stacks are deployed in the same site and deployment combination, you can create a custom label for the instance name, and you can use the matching criteria on the instance label to create the desired restrictions, as shown in the following figure.

The application policy feature in Tungsten Fabric provides a very powerful implementation framework while significantly simplifying and reducing the number of policies.

At this point, the series of articles on Tungsten Fabric Carbide architecture analysis has been serialized and reviewed in the past--

Part I: main features and use cases of TF

Article 2: how TF works

Part 3: detailed explanation of vRouter architecture

Part IV: service chain of TF

Part 5: deployment options for vRouter

Part 6: how does TF collect, analyze, and deploy?

Chapter 7: how to arrange TF

Part 8: TF support API list

Article 9: how TF connects to the physical network

About Tungsten Fabric:

The Tungsten Fabric project is an open source project protocol that is developed based on standard protocols and provides all the components necessary for network virtualization and network security. The components of the project include: SDN controller, virtual router, analysis engine, northbound API release, hardware integration functions, cloud orchestration software and extensive REST API.

About the TF Chinese Community:

TF Chinese Community is initiated spontaneously by a group of Chinese volunteers who follow and love SDN, including technology veterans, market veterans, industry experts and experienced users. It will serve as a bridge between the community and China, disseminate information, submit questions, organize activities, and unite all forces interested in the multi-cloud Internet to effectively solve the problems encountered in the process of cloud network construction.

Follow Wechat: TF Chinese Community

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.