Writing Application Policy
Illumio allows or denies traffic between applications using policies that you write. For an overview of the Illumio Segmentation for the Cloud policy model, see Policy Model.
For a list of resources against which you can write policy, see Policy Enforcement and Resource Types.
In order to write application policies, you must create rules for the policy. Illumio Segmentation for the Cloud has the following types of rules for application policies:
This topic provides an overview of using rules to write Illumio Segmentation for the Cloud 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, Illumio Segmentation for the Cloud 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, Illumio Segmentation for the Cloud 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 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, Illumio Segmentation for the Cloud 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 Segmentation for the Cloud 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 Segmentation for the Cloud 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 Segmentation for the Cloud 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, consider previewing what its impact will be when it's provisioned. This can help you gauge how the policy will map to destinations, security group rules, 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 security controls from the drop-down menu:
All security controls
Azure NSGs
AWS Security Groups
Network Access Control Lists
Azure Firewall Policies
Each of these show you the following:
CSP
Resource
Account ID
Number of Protected Resources
Rules
If you select any particular affected AWS SG, AWS NACL, Azure NSG, or Azure Firewall, you may see rules that come from other applications and/or policies. Note that only Illumio-written rules will display.) The 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.
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, an Illumio 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.