Skip to main content

Security Policy Guide 25.2.10

Virtual Services Overview

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

Use a virtual service in one of these scenarios:

  • Apply rules to a single service: Represents a service or process on a workload using a name or label. This approach enables you to create a policy that allows other entities to communicate only with that specific service. The policy does not need to change when the service is moved to a different workload or a new set of workloads. Only the workload bindings on the virtual service need to be changed. The PCE dynamically calculates the required rules on the updated workloads to allow this service.

  • Apply rules to multiple services (on the same workload): Represents each service or process running on a workload with a different set of labels. You can write rules to allow other entities to communicate only with that service. The policy does not need to change when this service is moved to a different workload or a new set of workloads. Only the workload bindings on the virtual service need to be changed. The PCE dynamically calculates the required rules on the updated workloads to allow the service.

From 18.3.1, Illumination, Policy Generator, and Explorer support virtual services. You must assign labels to a virtual service to create label-based rules. A virtual service does not have an enforcement, so you need to refer to the enforcement of its bound workloads.

Virtual services are provisionable objects. This means that they must be created and provisioned before they can be applied to workloads. However, the bindings are not provisionable objects, so the bindings can be changed without having to provision the changes. Additionally, port overrides have been moved from the virtual service to the workload binding.

How Virtual Services Work

Suppose a single workload runs both an Apache Tomcat and Apache HTTP server, supporting an HRM and ERP application. In that case, you can create a virtual service for each service and label one service as belonging to an HRM application and one to an ERP application. You can then write a set of label-based rules that apply only to the Apache Tomcat process serving the HRM application, effectively isolating it from the ERP application.

In this example, two different virtual services are created: one for an HRM database and one for an ERP database. The following configurations allow the web to communicate with the database for each application (HRM or ERP) in the specified environment (Prod or QA) in the specified 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 applicable for 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

Workloads labeled Database are not impacted by the above rule. 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 Configuration for Virtual Services

Consider these advanced configuration options when configuring a virtual service.

  • Optional Configuration: IP Overrides: This setting allows you to specify IP addresses or ranges (CIDR blocks) to be used for programming the rules associated with the virtual service instead of using the IP address of the bound workload. When IP overrides are specified on a virtual service and the virtual service is used in a rule, the IP addresses programmed on other hosts communicating with the virtual service are the IP addresses and subnets specified in the IP overrides rather than the IP addresses of the workloads bound to the virtual service.

A combination of stateless and forwarding rules on the same host, port. Destination is not supported. For example, when a workload has a service running on a port with stateless rules, a forwarding rule to allow traffic to a container running on the same host using the same port does not work when the destination is the same.

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 for devices that are 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)

Add and Bind a Virtual Service to a Workload

When you add a virtual service, enter a name, select the service, and apply labels to it. Bind it to the workload where the service is running. This binding instructs the PCE where to enforce the rules for this virtual service. When you configure two rules with the same service ports, one is stateless, and the other is stateful. The stateless rule takes precedence.

Add a Virtual Service

Note

A virtual service must be provisioned before it can be bound to a workload.

  1. From the PCE web console menu, choose Policy Objects > Virtual Services.

  2. Click Add.

    The Add Virtual Service page appears.

  3. Enter a name for the service.

  4. Select the service from the Service drop-down list or enter a service name.

  5. Select a Role, Application, Environment, and Location label.

  6. Host-only network: The rules associated with the virtual service are applied over the host network and programmed into the INPUT/OUTPUT chains in Linux iptables.

  7. (Optional) In the IP addresses field, you can override the IP address of the workload bound to the virtual service and specify different IP addresses or CIDR blocks that will be used for programming the virtual service rules.

  8. Click Save.

    The virtual service is created and labeled. Next, it is provisioned and bound to a workload.

Note

SecureConnect is not supported for virtual services.

Bind a Virtual Service to a Workload

Binding a virtual service to a workload enables the PCE to program rules to the VEN on the workload to which the virtual service is bound.

If the workload binding ever changes, the rules of your ruleset are dynamically recalculated for the new binding.

Note

The virtual service must be provisioned before it can be bound to a workload.

  1. From the PCE web console menu, choose Policy Objects > Virtual Services.

  2. Select the virtual service you want to bind to a workload.

    The Virtual Services details page appears.

  3. Click the Workloads tab.

  4. Click Bind.

  5. In the Workloads drop-down list, select the workload to which you want to bind this virtual service.

  6. Select the Override ports checkbox to allow this virtual service to use a port different from the one specified.

    Note

    When you select All Services as the service for the virtual service, you cannot enable port overrides on the workload bindings.

  7. In the Ports/Protocols section, enter the TCP and UDP ports for this virtual service.

  8. Click Save.