Virtual Services

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

Overview of Virtual Services

A virtual service can be used in the following scenarios: 

  • Apply rules to a single service: Represents a service or process on a workload using a name or label. This approach allows you to write policy to allow other entities to communicate only with that 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 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 the 18.3.1 release on, Illumination, Policy Generator, and Explorer support virtual services. You have to assign labels to a virtual service in order to write 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, which means 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. See Provisioning and Bind a Virtual Service to a Workloadfor more information.

How Virtual Services Work

For example, if a single workload is running both an Apache Tomcat and Apache HTTP server, supporting an HRM and ERP application respectively, you can create a virtual service for each service and then label one service as belonging to an HRM application and one belonging 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 the following example, two different virtual services are created: one for an HRM database and one for an ERP database. The following configurations would 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 Providers ← 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 Providers ← Web

Virtual Services in Rule Writing

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

NOTE:

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

When you write a rule in a ruleset, you need to specify the following values:

  • A service
  • Providers of the service
  • Consumers of the service

For example:

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 provider of the service.

For example:

Virtual Service Apache Tomcat is provided to All Workloads

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

When you want to write a rule applicable for all virtual services labeled “Database,” you would 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 be impacted by the above rule. To include them, you need an additional rule listing the specific service applicable.

When you want to use a virtual service as a provider, select “Uses Virtual Services” or “Uses Virtual Services and Workloads” from the Provider drop-down list.

When you select a specific service, then the rule applies only to workloads that have 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 rule is applied to all workloads bound to the virtual service using the DB label.

Advanced Configuration for Virtual Services

You have two advanced configuration options to consider when configuring a virtual service:

  • Apply To: Host Network or Internal Bridge Network: This optional setting allows you to determine if the rules associated with the virtual service are applied over an internal bridged network or the host network. If you choose Internal Bridge Network, the rules associated with the virtual service are programmed into the FORWARD chain on Linux iptables (rules to internal bridge are ignored by Windows in this current implementation). Or, you can specify that a virtual service's rules are applied over the host network, programmed into the INPUT/OUTPUT chains in Linux iptables. Stateless rules are not supported when associated with FORWARD chain; instead, stateful rules are programmed.
  • Optional Configuration: IP Overrides: 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 rules and forwarding rules on the same host, port, and consumer 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 consumer is the same.

Host-Only Network

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

Providers Services Consumers

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 Providers

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 device that is allowed to communicate with this virtual service, use the addresses/subnets specified in the IP overrides.

Internal Bridge Network

When you remove the IP override and change to Internal Bridge Network, this rules programs the following security policy:

  • An inbound rule on workload A for 80 TCP with source address 192.168.0.200 on the FORWARD chain of the firewall

    This means that the rule applies to traffic destined for somewhere other than the host network namespace that hits the host firewall.

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

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 a Virtual Service

When adding a virtual service, you need to give it a name, select the service, and apply labels to it.

Then, you need to 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 and one of the rules is stateless and the other stateful, the stateless rule takes precedence.

NOTE:

A virtual service must be provisioned before binding it to a workload. See Provisioning for more information.

  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. From the Service drop-down list, select the service or enter a service name.
  5. Select a Role, Application, Environment, and Location label.

  6. (Optional) Choose whether you want the rules associated with the virtual service to be applied over an internal bridged network instead of a host network (default behavior).

    • Internal Bridge Network: The rules associated with the virtual service are programmed into the FORWARD chain on Linux iptables.

    • Host only network: The rules associated with the virtual service are applied over the host network, 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 block that will be used for programming the virtual service rules.

  8. Click Save.

    The virtual service is created and labeled; next, provision it and bind it to a workload. See Provisioning for more information.

NOTE:

SecureConnect is not supported for virtual services.

Bind a Virtual Service to a Workload

When you bind a virtual service to a workload, it enables the PCE to program rules to the VEN on the workload the virtual service is bound to.

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

NOTE:

Before binding a virtual service to a workload, the virtual service must be provisioned. See Provisioning for more information.

  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. To allow this virtual service to use a different port than the one specified, select the Override ports checkbox.

    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 to use.
  8. Click Save.