Illumio Install, Configure, and Upgrade Guide 24.2.20

A Container Workload Profile is beneficial when you want to assign labels to resources that are deployed in a namespace and also define the state of the policy created for the scope of labels assigned. A new Container Workload Profile can be created in either of the following ways:

When a Container Cluster is created for the first time in the PCE, Kubelink will report the existing namespaces or projects in the cluster. These namespaces will inherit what was defined as part of the Container Workload Profile Template for that cluster.

When the team managing Kubernetes or OpenShift clusters creates a namespace in a cluster, this namespace is reported immediately to the PCE via Kubelink. The new namespace will be listed under Container Workload Profiles and the following scenarios can occur:

The example below shows a new namespace "namespace1" created in a cluster where a Container Workload Profile Template exists with a policy state set to "Build" and a partial label assignment as "Development | Cloud":

For example, to edit the "namespace1" namespace:

The updates are displayed in the Container Workload Profiles list.

To pre-create a profile:

You can view the newly-created Container Workload Profile. The status is in "Pending" state with the hourglass icon displayed next to it.

To edit the namespace configuration file to include the pairing key in order to authenticate this namespace with the PCE:

An example is show below.

apiVersion: v1
kind: Namespace
metadata:
  name: namespace2
  annotations:
    com.illumio.pairing_key: 
    abc8aaffdb2101e13a9da02bf492badb8d09d5ce338af116d076aef77558afcd

The updates are displayed in the Container Workload Profiles list.

Set an Enforcement Boundary to establish how policy rules affect traffic to and from namespace workloads. Enforcement boundaries can be one of:

An enforcement boundary can be applied only to Managed workloads, which means Idle workloads cannot have an enforcement state applied to them.

You can change Enforcement for multiple profiles of the same current Enforcement level by selecting the checkboxes for the desired profiles (or by selecting the checkbox in the table heading row to select all profiles), and then hovering over the Enforcement button, which then shows a list of new Enforcement states and how many profiles will be changed to that state. Note that when you change Enforcement to Selective, then Visibility mode must by Blocked & Allowed, which is automatically done for you.

At a high level, creating policy for containerized applications functions in the same basic way as for other types of applications running on bare-metal servers and virtual machines protected by the Illumio Core. Container workloads are assigned multi-dimensional labels to identify their roles, applications, environments, locations (RAEL), or other custom label types. These labels can then be used to apply security policies to specific parts of the containerized application environment. The PCE converts these label-based policies into rules that can be applied to the container workloads.

In previous releases, the PCE supported two options for assigning labels to container workloads:

These two ways of assigning labels for container workloads are sufficient for most container segmentation uses cases; however, this approach lacks the flexibility with label assignment for namespaces requested by Illumio customers. However, there is an alternative in addition to those two options that still allows developers/DevOps teams to assign their own labels for Kubernetes pods and services, but at the same time restricts the list of labels that they can assign. Illumio administrators now have a way to control which labels can be assigned by the developers managing their Kubernetes environments.

Example: Assigning Labels with a Container Workload Profile

The following example shows how you can use each of the four standard predefined options:

The Role label annotation (com.illumio.role) is ignored when passed at runtime and reported by Kubelink to the PCE when "Role" label is set to "None".

Adding, Editing, or Removing Labels

To add one or more labels:

1. Click a profile name, then click Edit.

   To apply the same label edits to multiple profiles, click the checkboxes for the desired profiles (or click the topmost checkbox in the table heading to select all profiles), then click Edit Labels.

2. Under the Labels heading, add a label type by clicking the field under the Label Type heading and then choose a label type from the list.

3. Choose a Label Assign Type:

   • Use Container Annotations - Use label values for container annotations. See the topic "Using Annotations" for more information.

   • Assign Label - Explicitly set labels from the values configured for this label type.

   • No Label Allowed - Prevent this label type from being used in this profile.

4. Specify labels for this label type by clicking the field under Labels Allowed/Label Assign, and choosing a label from the list.

   Any label type defined from annotations or explicit assignments must also have a label value specified in order to add the label definitions to the profile.

5. Click Save when finished.

To remove label types (and their associated label values):

1. Click the profile name.

2. Click Edit.

3. Under the Labels heading, choose one or more types to delete from this profile by clicking the checkboxes in front of the Label Type name.

4. Click Remove.

To remove or change label values:

1. Click the desired profile name.

2. Click Edit.

3. In the Labels table, remove a label value by clicking the small "x" near the label name under the Labels Allowed/Label Assign column.

   You can replace or add label values by clicking the Select Label or Select Labels field under Labels Allowed/Label Assign column, and then choosing the new label (or in the case of Annotations, multiple labels).

4. Click Save.

Possible Labels for the Example

• Developers can specify any label for Applications, so long as the label matches a preexisting label in the PCE.

• For Environment, a list of two labels (env1 and env2) is available. Developers can set either of these labels in Kubernetes. If a developer sets another value for the Environment label as a Kubernetes annotation, the PCE considers it invalid and, as a result, a label is not assigned to that label key. Because the wrong label is assigned, the policy will not allow expected traffic from other services or applications with the Environment label env1.

• The Location label is fixed as the loc1 label. If a developer assigns another Location label (for example, loc3, which is a label in the PCE) or the developer leaves the Location label empty, the PCE overrides what the developer has specified in the annotation and the PCE assigns loc1 for the Location label.

The label assignments for that namespace appears in the Container Clusters list in the PCE web console.

For this example, you can see the label assignments mirrored in the Kubernetes annotation for the namespace:

Kubernetes Annotation for Namespaces

where developers set role1, app1, env1, and loc100 for the labels in the annotations.

Kubelink passes this data to the PCE at runtime. The PCE ignores the Role label because it's not allowed in the profile. The PCE accepts the Application and Environment labels. It ignores the loc100 label and uses loc1 instead.

In the Container Workloads tab, you can see how the label assignments are applied for the pod in this example.

Note

If a developer sets another value for the Environment label as a Kubernetes annotation, the PCE considers it invalid and, as a result, a label is not assigned to that label key. Because the wrong label is assigned, the policy will not allow expected traffic from other services or applications.

For example, if developers leave the Environment label empty or specify env100 in the Kubernetes annotations, the following labels are used for the namespace, and there are no policy for applications or services with the Environment label env1.