Skip to main content

Illumio Security Policy Guide 25.4

Virtual Services

Virtual services (previously known as bound services) allow you to label processes or services on workloads. Virtual services can be used directly in rules, or the labels applied to virtual services can be used to write rules.

Virtual Services Scenarios

Utilize a virtual service in the following situations:

  • Apply rules to a single service: Represents a workload service or process using a name or label. This method allows you to enforce a policy that permits only specific communication with that service. If the service moves to a different workload or a new set of workloads, adjustments to workload bindings on the virtual service suffice. The PCE dynamically computes necessary rules on updated workloads to facilitate this service access.

  • Apply rules to multiple services (on the same workload): Each service or process running on a workload is represented using distinct labels. Rules can be written to enable communication exclusively with individual services. If any service is relocated to a different workload or new workloads, changes solely to workload bindings on the virtual service are needed. The PCE dynamically computes essential rules on the updated workloads for service access.

Policy Generator and Explorer support virtual services. To create rules based on labels, assign labels to a virtual service. A virtual service lacks enforcement and relies on the enforcement of its bound workloads.

Virtual services are provisionable objects, necessitating the creation and provisioning of applications on workloads beforehand. Workload bindings, however, can be altered without the need for provisioning. The most recent changes have moved port overrides from the virtual service to the workload binding.

How Virtual Services Work

Imagine a single workload running an Apache Tomcat and an Apache HTTP server, catering to HRM and ERP applications. To manage these services efficiently, virtual services can be established for each, labeling one for the HRM app and another for ERP. With label-based rules, you can distinctly control the Apache Tomcat serving the HRM app, segregating it from the ERP application.

In this scenario, two distinct virtual services are generated: one for an HRM database and one for an ERP database. Using these configurations, communication between the web and database for each application (HRM or ERP) can be controlled, considering the specific environment (Prod or QA) and location (US or EU).

Virtual Service - HRM

  • Name: HRM-DB

  • Labels: DB | HRM | Prod | US

  • Service: MySQL

  • Bound to: Workload - Database 1, Port Override: 3308

  • Scope: HRM | Prod | US

  • Rule: DB ← From Source ← Web

Virtual Service - ERP

  • Name: ERP-DB

  • Labels: DB | ERP | QA | EU

  • Service: MySQL

  • Bound to: Workload - Database 1, Port Override: 3309

  • Scope: ERP | QA | EU

  • Rule: DB ← From Source← Web

Virtual Services in Rule Writing

When you create rules for virtual services using the Policy Generator or from Illumination, add the “Uses Virtual Services only” option or “Uses Virtual Services and Workloads” option in the Source or Destination field of the generated rules. You can configure virtual services using a port or a port range.

Note

Custom iptables rules and SecureConnect are not supported with virtual services.

When you write a rule in a ruleset, specify these values:

  • A service

  • Source of the service

  • Destination of the service

For example:

The web provides Apache Tomcat service to All Workloads.

When you write rules using virtual services, you do not need to select a service in the rule, because the virtual service is both the service and the source of the service.

For example:

Virtual Service Apache Tomcat is provided to All Workloads

When you want to treat the source as a virtual service, select Uses Virtual Services or Uses Virtual Services and Workloads from the Source drop-down list as the service.

To write a rule that applies to all virtual services labeled Database, write it the same way and select Uses Virtual Services or Uses Virtual Services and Workloads as the providing service.

Note

The above rule does not impact workloads labeled "Database". You need an additional rule listing the specific service applicable to include them.

When you select a specific service, the rule applies only to workloads with the selected label.

For example, for the following virtual service rule:

  • DB | MySQL | Web

The rule is only applied to workloads that use the DB label.

However, when the virtual service rule is the following type of rule:

  • DB | Uses virtual services or uses virtual services and workloads | Web

The inbound side of the rule is applied to all workloads bound to the virtual service using the DB label.

Advanced Virtual Services Configuration

Consider these advanced configuration options when configuring a virtual service.

  • Optional Configuration: IP Overrides: This feature permits specifying IP addresses or ranges (CIDR blocks) for virtual service rules, overriding the default IP addresses of bound workloads. Hosts communicating with the virtual service use the specified IP addresses and subnets instead when enabled.

Combining stateless and forwarding rules on the same host and port isn't supported. For instance, if a service on a port has stateless rules, a forwarding rule allowing traffic to a container on the same host and port doesn't function if the destination is identical.

Host-only network

Example of a virtual service rule using host network (default):

Source

Services

Destination

Virtual Service X

Virtual Service X is bound to workload A, with service 80 TCP

Workload A has IP address 192.168.0.100

From Source

Workload B

Workload B has IP address 192.168.0.200

This rule programs the following security policy:

  • An inbound rule on workload A for 80 TCP with source address 192.168.0.200

  • An outbound rule on workload B for 80 TCP with destination address 192.168.0.100

When you add an IP override, the subnet 172.16.0.0/16 on the BPS, this rule programs the following security policy:

  • An inbound rule on workload A for 80 TCP with source address 192.168.0.200

  • An outbound rule on workload B for 80 TCP with destination subnet 172.16.0.0/16

The IP override dictates that devices allowed to communicate with this virtual service use the addresses/subnets specified in the IP overrides.

Filter the Virtual Services List

You can filter the Virtual Services list by using the properties filter at the top of the list. For example, you can filter and search by label. In the case of DNS-based rules, you can also filter and search by the following objects:

  • Service or port

  • IP entry or DNS entry (for example, search for *.google.com)