5 Tips to Simplify Workload Labelling for Microsegmentation

IP has a structure that everyone and every machine can understand. If you show someone a 4-dimensional set of numbers like 192.168.1.254, many will recognize this immediately. The simple structure makes the information easy to consume and understand. It’s what makes the internet scale and work. And to those that work with it, its hierarchy provides immediate insights.

Imagine the alternative: a world where people define arbitrary structures. What if one minute you saw 192.179.134.56.245.23 and the next you saw 24.87? How do we work out how these relate to each other?

While we view flexibility and free will as positive, in the world of network addressing — and equally in workload labelling (especially in microsegmentation) — it can result in confusion and complexity. Ultimately, this leads to inconsistent policies and problems similar to those experienced with traditional firewall policies.

For some years, we have tagged objects with a wide range of attributes to identify and group assets, which has time and again caused challenges with scale and manageability. Without structure, creating an architecture that can endure increasingly becomes a problem over time. At Illumio, we identified this early and decided that structure and simplicity returns huge operational benefits over arbitrary object tagging.

Simply speaking, labels should be easy to use, repeatable, predictable, and simple to comprehend later.

So with this in mind, here are 5 tips to simplify the labelling of workloads:

1. Stick to a 4-dimensional labelling scheme

This works by classifying workloads with some simple and obvious dimensional parameters. For example:

1. Location: Where is the workload located? This could be a country, a city, in a cloud provider, etc.
2. Environment: Does this object reside in Production, Development or Test?
3. Application: Is it serving a finance, HR or CRM application?
4. Role: Is it an application server, a webserver or a database?

By sticking with the four simple groups of Role, Application, Environment and Location (RAEL), we can create a labelling model that is not only easy to understand, but portable and extensible.

This structure allows users to pivot on any of the four labels and use a single section to simplify control and reduce computing time. If our labels were for vehicles and took the form of “Type | Make | Model | Color,” then identifying just BMWs or red vehicles makes the exercise very simple and quick.

And remember, object labelling is most simply used to define the object and its primary purpose, not its relationships. Sticking to this principle and using the policy to define relationships, is the path to happiness — trust me on this.

2. Standardize on a format

Although we may see similar things for networking and computing, there is a big difference between ‘Production,’ ‘Prod,’ and ‘prod’. There will always be occasions where misspelling occurs, and in a structured, 4-dimensional model, it is easy to troubleshoot.

However, in a loose freestyle environment, trying to find the error in “prod.fin.win.UK.CRM.web.bldg1.10” will be a long process.

3. Use caution when shortening label names

For example, you shorten a label, such as “Production” to “Prod,” but don’t shorten “Database.” Inconsistently shortening label names can result in the duplication of labels, which in turn can lead to inconsistent policy application or supportability challenges.

We recommend you use the full names (Production, Development, and Test) unless a shortened version or acronym is the commonly used nomenclature in your organization (such as UAT). A classic example where this can cause problems is when both a 'Prod' and 'Production' label is created. If some workloads are labelled as 'Prod,' then rules created for 'Production' will not be applied to them.

Defining a naming standard isn’t a new concept, and there is a good reason for this.

4. Stay consistent across all systems

In addition to consistency within your labelling scheme for micro-segmentation, we recommend you maintain consistency with external sources of metadata.

If you have established metadata naming conventions, perhaps in your configuration management database (CMDB), host naming conventions, or use of IP address blocks, do not create alternate conventions for your labelling scheme. During your deployment project, if you discover that your standard data source also has inconsistencies, this is an opportunity to address this and improve the quality of that data source. This is hugely beneficial for a plethora of reasons, and your organization will benefit.

Your initial deployment use case may be limited to a specific environment or application. However, structuring your label design with your entire organization in mind will save work if the deployment expands. Simpler label schemas are more scalable and supportable.

5. Use labels to allow differentiation between objects

When you need to differentiate policy between objects, use different labels. There are often cases where it may be tempting to use distinct labels, but actually there is no policy differentiation, so it is unnecessary. And remember that policy in this respect includes security policy, but also RBAC, reporting, change control, and other types of policy.

Bearing this in mind, use common names for your labels where possible. For example, Apache, Nginx, and IIS use similar service ports and protocols, such as 80/TCP or 443/TCP. Consequently, we recommend you use a common label name, such as ‘Web Server’. In most cases, you likely won’t need to write different policies for these.

Vary label names only when workloads require different security policy. For example, Oracle, IBM DB2, and MS SQL Server use different service ports and protocols, and each has unique security policy elements, such as cluster traffic flows. Therefore, we recommend you assign them three different Role labels to the workloads running these applications. For example, this will allow you to write specific policy to allow your Oracle Enterprise Manager servers to only access your Oracle Database servers, and not your Sybase servers.

How Illumio Can Help

Illumio Core uses a multi-dimensional design, with a combination of four labels identifying policy objects. Other products using tagging may allow you to create any number of tags. Although it may seem that this makes labelling more flexible, it results in challenges that become more pronounced over time.

If you keep adding different label dimensions, you very quickly end up with a single-dimensional model where any given tag indicates a unique policy application. A great analogy to this is a Directory Service, where a new group (tag) may be created for each new requirement and applied to users. These groups grow rapidly in number and are often associated with the same objects, causing duplication. It is not uncommon for a scenario to exist where there are more groups than users. Similarly, in a tag-based solution, you may end up with more tags than objects with each object associated with large numbers of tags.

It is then incumbent on the administrators to associate all objects with all the tags they require. The result of this is that every time a new object is created, it needs to be tagged with an ever-growing collection of tags to get its required access. In this scenario, scalability becomes challenging and consistency starts to fail.

Many of us have been in a situation where our access isn't quite the same as another member of our team, and it turns out we are missing a group (or tag). By using a simple 4-dimensional model, labelling new objects is straightforward, predictable, repeatable, and supportable, and inheritance in the policy design significantly improves manageability.

Defining a scalable and consistent labelling scheme requires a mind shift in how you think about policy design, but once understood, its simplicity will make managing policy more effective.

For more information on how we think about labelling at Illumio, check out this great video from our Chief Evangelist, Nathanael Iversen.