Writing Application Policy

Illumio allows or denies traffic between applications using policies that you write. For an overview of the Illumio CloudSecure policy model, see CloudSecure Policy Model. For a list of resources against which you can write policy, see Resources that Support Policy.

In order to write application policies, you must create rules for the policy. Illumio CloudSecure has the following types of rules for application policies:

  • Override Deny Rules

    This rule type is typically used to deny communication between sources and destinations that might inadvertently be given allow rules by another administrator. Override Deny rules take precedence over all other types of rules.

  • Allow Rules

    You can write rules that allow communication between sources and destinations.

  • Deny Rules

    You can write rules that deny communication between sources and destinations.

This topic provides an overview of using rules to write Illumio CloudSecure policies. For instructions on creating rules for policies, see the in-application help.

Differences between Application and Organization Policies

You can think of application policies as segmentation policies to control network traffic using Illumio labels, services, and IP/IP lists to define what can talk to applications. The guidelines below are generally applicable to writing both organization and application policies. For differences, see Organization Policy versus Application Policy.

Guidelines

Use the following guidelines when creating rules for your policies:

  • From the Source and Destination drop-down lists, you can select a combination of applications, labels, and IP lists. Note that when programming security groups, CloudSecure optimizes the rules by grouping a set of IPs into a CIDR block if possible.
  • From the Destination Services drop-down list, you can select a combination of services and ports. Note that when there are adjacent rules i.e., adjacent ports, with all other parameters same, CloudSecure merges those rules. For example if you have Rule1 (ports 87100-87104), Rule2 (ports 87105), Rule3 (ports 87106-87110), then CS combines those rules to program a single rule with the port range 87100-87110.
  • In the source or destination fields, select All Resources to include all resources at once instead of selecting them individually. By using All Resources in your source or destination, you can write organization policies for all resources in onboarded cloud accounts.
  • The CloudSecure UI will prevent you from selecting disallowed source and destination combinations. For a full list of permitted source and destination combinations in a rule, see Permitted Rule Writing Combinations.
  • After completing your selections, click the Save icon at the end of the row for that rule
  • To edit a rule, click the Edit icon at the end of the row
  • After adding a rule, the Status column displays a green Enabled icon and the Provision Status column displays a green Pending icon
  • Rules can be disabled or removed individually or in groups by selecting the check box next to a rule
  • To enforce a rule, you must provision the policy. For more information about provisioning, see Provisioning
  • Reverting a policy from the Applications > your policy name > Policy tab will cancel pending changes to the policy, including rules with a green Pending icon in the Provision Status column, and revert to the previously provisioned policy
  • From the left navigation Policies menu item, reverting a policy that still has its provisioning pending will cancel that provisioning but leave previously saved policy rules intact

Permitted Rule Writing Combinations

Inter-Application and Inter-Deployment Policy

Illumio allows you to write rules between your applications and between your deployments. However, in order to write these rules, rules must be written in the context of the application on the inbound side of the rules. In other words, you can only write inbound inter-application and inter-deployment policy rules. However, when you do so, CloudSecure implicitly writes outbound rules for the security group containing the source application. This is to avoid the need for you or the security group owner to explicitly write a corresponding outbound rule.

Under a given application, if you want to specify an application in the destination of the rule, the application must match the application in the context. So, the destination application must be the application in which you are writing the rule. The source application can be a different application (or the same) than the application context in which you are writing the policy.

If a deployment is specified, the same principal applies to the destination deployment. You can write the rule for only the deployment context in which you are writing the policy. The source deployment can be a different deployment (or the same) than the application context in which you are writing the policy.

NOTE:

If the source does not match the application or deployment context, Illumio CloudSecure will take the meaning of the labels literally. For example, if the context is app:CRM, deployment:PROD, a rule with the source as app:FINANCE will represent all resources under app:FINANCE, regardless of deployment. This is true of all rule types (allow, deny, etc.).

If Source is And Service is Destination can be
Application and/or deployment (any) Any service The application and/or deployment (if applicable), so long as it is the same as the one providing the context
IP List Any service Application or label

Intra-Application and Intra-Deployment Policy

In order to write rules within your application context, you can specify labels or IP lists on either side of the rule.

NOTE:

These labels must not be of the application or deployment types in order for the following to apply.

If a label is used on either side of the rule, Illumio CloudSecure will calculate which resources match both the context (application and/or deployment) and the label used, and create the rule accordingly.

If Source is And Service is Destination can be
Any label or IP list Any service Any label or IP list

Provisioning

When you provision updates, Illumio CloudSecure recalculates any changes made to rules, and then transmits those changes to all affected enforcement points. All the changes you make to those rules are considered to be in a “draft” state until you provision them.

Previewing the Impact of Provisioning a Policy

This section provides an overview of the Show Impact feature. For instructions on previewing policy impact, see the in-application help.

Before you provision a policy, you may wish to gauge what its impact will be. It can be difficult to see how it may map to destinations, various rules in security groups, enforcement points, and so forth.

To see such mappings on a policy that has not yet been provisioned, click Show Impact. You can then choose one of the following from the drop-down menu:

  • All security controls
  • Azure NSGs
  • AWS Security Gateways
  • Network Access Control Lists

Each of these will show you the following:

  • CSP

  • Resource

  • Account ID

  • Number of Protected Resources

If you select any particular affected AWS SG or Azure NSG , you may see rules that come from other applications and/or policies. Note that only Illumio-written rules will display.) The SG or NSG draft change summary will include the account name, as well as inbound and outbound rules with the following details :

  • Provision Status (this can tell you whether a rule is being added, removed, or is already in place)
  • Source
  • Destination
  • Port
  • Protocol
  • Action (deny, override deny, or allow)

Confirming

Once you have previewed the anticipated impact, you are ready to decide whether to proceed with provisioning.

You are given a description field for adding any comments when provisioning a policy. After you provision your changes, those changes become “active,” which is to say it is in enforcement mode. When you confirm by clicking Confirm & Provision, the Policies page Provision Status column displays the applications with policies, including those that are pending.

To see if CloudSecure experienced errors when provisioning your policies, click the Provisioning errors button in the upper right-hand corner of the page. The Provisioning  errors page will display the cloud, name and ID, status, and modification date for both application and organization policies that experienced errors during provisioning.

Caveats

  • Only rules that use the following attributes are supported: applications, labels, IP lists, and services
  • As AWS does not have a deny rule concept for Security Groups, a CloudSecure override deny rule will only be implemented if there is a matching allow rule that is overlapping in scope. In effect, the override deny rule will constrict where the allow rule is implemented.
  • You cannot write policy rules using metadata, but you can map cloud tags to Illumio labels and then write policy rules using that label

  • Only the following ServiceCategory labels can used when authoring policy: Compute, Serverless, and Network Management. ServiceRole labels can also be used when authoring policy, but the service roles must have resources that support policy. See Resources that Support Policy.

    • NOTE:
    Because CloudSecure may not always discover elastic network interfaces (ENIs), a flow search based on resource IDs will not work for the following supported resources if their Details page does not display the ENI. The workaround is to search using the IP address of the associated ENI, if known:
    - AWS RDS DBInstances
    - AWS RDS DBClusters
    - ElasticLoadBalancingV2 load balancers
    - AWS MemoryDB clusters
    - AWS ElastiCache for Redis clusters
    - AWS Redshift clusters