Skip to main content

Illumio Core 23.5 Install, Configure, Upgrade

Concepts

This section describes some key concepts of the Illumio Core for Kubernetes solution, which includes, as its main components, the Containerized VEN (C-VEN) and Kubelink.

Containerized VEN

Containerized VEN (C-VEN) is an Illumio-provided software component that provides visibility and enforcement on nodes and Pods. In a standard Illumio deployment, the Virtual Enforcement Node (VEN) is installed on the host as a package. The C-VEN is not installed on the host but runs as a Pod on the Kubernetes nodes. The C-VEN functions in the same manner as a standard VEN. However, to program iptables on the node and Pod namespaces, the C-VEN requires privileged access to the host.

The C-VENs are delivered as a DaemonSet with one replica per host in the Kubernetes cluster. A C-VEN Pod instance is required on each node in the cluster to ensure proper segmentation in your environment. In self-managed deployments, C-VENs are deployed on all nodes in the cluster. In cloud-managed deployments, C-VENs are deployed only on the Worker nodes and not on the Master nodes (Cloud customers do not manage master nodes).

Container Cluster

A container cluster object is used to store all the information about a Kubernetes cluster in the PCE by collecting telemetry from Kubelink. Each Kubernetes cluster is mapped to a single container cluster object in the PCE. Each Pod network(s) that exists on a container cluster is uniquely identified on the PCE to handle overlapping subnets. This helps the PCE in differentiating between container workloads that may have the same IP address but are running on two different container clusters. This differentiation is required for both illumination and policy enforcement.

You can view the workloads associated with a container cluster in the PCE Web Console. This mapping between the host workload and the container cluster is done using machine-ids reported by Kubelink and C-VEN.

Container Workloads

Container workloads are basic containers (as with Docker) or the smallest resource that can be assimilated within a container in an orchestration system (as with Kubernetes). In the context of Kubernetes and OpenShift, a Pod is a container workload. Similar to workloads, these container workloads (managed Pods) can have labels assigned to them. Container workloads with their associated Illumio labels are also displayed in Illumination. In Illumio Core, containers are differentiated based on whether they are on the Pod network or the host network:

  • Containers on the Pod network are considered container workloads and can be managed similarly to workloads.

  • Containers sharing the host network stack (i.e., Pods that are host-networked) are not considered container workloads and therefore inherit the labels and policies of the host.

To manage container workloads, you can define the policy state (Idle, Visibility Only, Selective, and Full enforcement) in container workload profiles.

Container Workload Profiles

A container workload profile maps to a Kubernetes namespace and defines:

  • Policy state (Idle, Visibility Only, Selective, and Full enforcement) for the Pods and services that belong to the namespace.

  • Labels are assigned to the Pods and services. Standard predefined label types were Role, Application, Environment, and Location. Newer releases of Core allow you to define your own custom label types and label values for these types.

Once Illumio Core is installed on a container cluster, all namespaces that exist on the cluster are reported by Kubelink to the PCE and made visible via Container Workload Profiles. Each time Kubelink detects the creation of a namespace from Kubernetes, a corresponding Container Workload Profile object gets dynamically created in the PCE.

Each profile can either be in a managed or unmanaged state. The default state for a profile is unmanaged. The main difference between the two states:

  • Unmanaged: no policy applied to Pods by the PCE and no visibility

  • Managed: The policy is controlled by the PCE and has full visibility through Illumination and Traffic Explorer.

A container workload profile is a convenient way to dynamically secure new applications with Illumio Core just by inheriting security policies associated with the scope of that profile.

Virtual Services

Virtual services are labeled objects and can be utilized to write policies for the respective services and the member Pods they represent.

Kubernetes services are represented as virtual services in the Illumio policy model. Kubelink creates a virtual service in the PCE for services in the Kubernetes cluster. Kubelink reports the list of Replication Controllers, DaemonSets, and ReplicaSets that are responsible for managing the Pods supporting that service.

Workloads

A workload is commonly referred to as a host OS in Illumio Core. In the context of container clusters, a workload is referred to as a node. Usually, a Kubernetes cluster is composed of two types of nodes:

  • One or more Master Node(s) - In the control plane of the cluster, these nodes control and manage the cluster.

  • One or more Worker Node(s) - In the data plane of the cluster, these nodes run the application (containers).

In Illumio, Master and Worker nodes are referred to as workloads and are part of a container cluster. Labels and policies can be applied to these workloads, similar to any other workload that does not run containers. For a managed Kubernetes solution, only the Worker nodes are visible to the administrator, and the Master nodes are not displayed in the list of Workloads.