Skip to main content

Illumio Segmentation (formerly Illumio Core) for Kubernetes

Prepare Your Environment

You need to do these steps before creating clusters or pairing profiles in the PCE, or subsequent deployment.

Caution

If the prerequisite steps are not done before deployment, then containerized environments and Kubelink can get disrupted.

Unique Machine ID

Some of the functionality and services provided by the Illumio C-VEN and Kubelink depend on the Linux machine ID of each Kubernetes cluster node. Each machine ID must be unique in order to take advantage of the functionality. By default, the Linux operating system generates a random machine IDto give each Linux host uniqueness. However, there are cases when machine IDs can be duplicated across machines. This is common across deployments that clone machines from a golden image, for example, spinning up virtual machines from VMware templates, creating compute instances from a reference image, or from a template from a Public Cloud source.

Important

Illumio Core requires a unique machine ID on all nodes. This issue is more likely to occur with on-premises or IaaS deployments, rather than with Managed Kubernetes Services (from Cloud Service Providers). For more information, see "Troubleshooting".

Create Labels

For details on creating labels, see "Labels and Label Groups" in Security Policy Guide. The labels shown below are used in examples throughout this document. You are not required to use the same labels.

Name

Label Type

Kubernetes Cluster

Application

OpenShift Cluster

Application

Production

Environment

Development

Environment

Data Center

Location

Cloud

Location

Kubelink

Role

Node

Role

Control Plane Node (formerly Master)

Role

Worker

Role

Note

Starting in Illumio Core for Kubernetes 4.2.0, you can map Kubernetes labels to Illumio labels by using a Container Resource Definition in your illumio-values.yaml with the Helm Chart deployment. See Map Kubernetes Labels to Illumio Labels.

Create a ConfigMap to Store Your Root CA Certificate

This section describes how to implement Kubelink with a PCE using a certificate signed by a private PKI. It describes how to configure Kubelink and C-VEN to accept the certificate from the PCE signed by a private root or intermediate Certificate Authority (CA), and ensure that Kubelink can communicate in a secure way with the PCE.

Prerequisites

  • Access to the root CA to download the root CA certificate

  • Access to your Kubernetes cluster and can run kubectl commands

  • Correct privileges in your Kubernetes cluster to create resources like ConfigMaps, secrets, and Pods

  • Access to the PCE web console as a Global Organization Owner

Resource Allocation Guidelines

New resource allocation guidelines have been developed to help configure deployments to achieve optimal performance and cost-efficiency.

These guidelines are grouped into the following general deployment sizes:

  • Small-scale: Customers with limited Kubernetes deployments and moderate workloads.

  • Medium-scale: Customers with moderate-sized Kubernetes environments and growing workloads.

  • Large-scale: Customers with extensive Kubernetes deployments and high-performance requirements.

The following variables determine the deployment sizes listed above:

  • Number of nodes per cluster

  • Total number of workloads per cluster

  • Total policy size per cluster

Set the resources values in the appropriate pod spec (Kubelink or C-VEN) yaml file under the storage section, as shown in the following example:

storage:
  sizeGi: 1
  resources:
    limits:
      memory: 600Mi
    requests:
      memory: 500Mi
      cpu: 500m

If you have two parameters that match one category, and a third parameter that matches another, it’s important to select the category based on the highest value among them.

For instance, if the number of nodes per cluster is 8, and the total number of Kubernetes workloads is 500, but the average size of the policy is 1 Gi, the resource allocation should align with the large-scale resource allocation. This ensures that your resources are appropriately scaled to meet the demands of your workloads, optimizing performance and stability.

In practice, monitor these resources, and if usage is at 80% of these limits, then consider increasing.

NOTE that amounts are expressed in mebibytes (Mi) and gibibytes (Gi) and not in megabytes (MB) or gigabytes (GB).

Small-scale resource allocation

Customer Category

Nodes per Cluster

Total K8s Workloads

Total Policy Size

Small-scale

1 - 10

0 - 1000

0 - 1.5 Mi

Resources 

C-VEN 

Kubelink 

Storage 

Requests

CPU

0.5

0.5

0.5

Requests

memory

600 Mi

500 Mi

500 Mi

Limits

CPU

1

1

1

Limits

memory

700 Mi

600 Mi

600 Mi

Volumes

size limits

n/a

n/a

1 Gi

Medium-scale resource allocation

Customer Category

Nodes per Cluster

Total K8s Workloads

Total Policy Size

Medium-scale

10 - 20

1000 - 5000

1.5 Mi - 500 Mi

Resources 

C-VEN 

Kubelink 

Storage 

Requests

CPU

2

2

1

Requests

memory

3 Gi

5 Gi

5 Gi

Limits

CPU

3

2

2

Limits

memory

5 Gi

7 Gi

7 Gi

Volumes

size limits

n/a

n/a

5 Gi

Large-scale resource allocation

Customer Category

Nodes per Cluster

Total K8s Workloads

Total Policy Size

Large-scale

20+

5000 - 8000

500 Mi - 1.5 Gi

Resources 

C-VEN 

Kubelink 

Storage 

Requests

CPU

2

3

1

Requests

memory

6 Gi

10 Gi

10 Gi

Limits

CPU

3

4

2

Limits

memory

8 Gi

12 Gi

12 Gi

Volumes

size limits

n/a

n/a

10 Gi

Download the Root CA Certificate

Before you begin, ensure that you have access to the root CA certificate. The root CA certificate is a file that can be exported from the root CA without compromising the security of the company. It is usually made available to external entities to ensure a proper SSL handshake between a server and its clients.

You can download the root CA certificate in the CRT format on your local machine. Below is an example of a root CA certificate:

$ cat root.democa.illumio-demo.com.crt
-----BEGIN CERTIFICATE-----
MIIGSzCCBDOgAwIBAgIUAPw0NfPAivJW4YmKZ499eHZH3S8wDQYJKoZIhvcNAQEL
---output suppressed---
wPG0lug46K1EPQqMA7YshmrwOd6ESy6RGNFFZdhk9Q==
-----END CERTIFICATE-----

You can also get the content of your root CA certificate in a readable output format by using the following command:

$ openssl x509 -text -noout -in ./root.democa.illumio-demo.com.crt
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            fc:34:35:f3:c0:8a:f2:56:e1:89:8a:67:8f:7d:78:76:47:dd:2f
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=California, L=Sunnyvale, O=Illumio, 
         OU=Technical Marketing, CN=Illumio Demo Root 
         CA 1/[email protected]
        Validity
            Not Before: Jan 20 00:05:36 2020 GMT
            Not After : Jan 17 00:05:36 2030 GMT
        Subject: C=US, ST=California, L=Sunnyvale, O=Illumio, 
        OU=Technical Marketing, CN=Illumio Demo Root 
        CA 1/[email protected]
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
                    00:c0:e5:48:7d:97:f8:5b:8c:ef:ac:16:a8:8c:aa:
                    68:b8:48:af:28:cd:17:8f:02:c8:82:e9:69:62:e2:
                    89:2b:be:bd:34:fc:e3:4d:3f:86:5e:d7:e6:89:34:
                    71:60:e6:54:61:ac:0f:26:1c:99:6f:80:89:3f:36:
                    b3:ad:78:d1:6c:3f:d7:23:1e:ea:51:14:48:74:c3:
                    e8:6e:a2:79:b1:60:4c:65:14:2a:f1:a0:97:6c:97:
                    50:43:67:07:b7:51:5d:2c:12:49:81:dc:01:c9:d1:
                    57:48:32:2e:87:a8:d2:c0:b9:f8:43:b2:58:10:af:
                    54:59:09:05:cb:3e:f0:d7:ef:70:cc:fc:53:48:ee:
                    a4:a4:61:f1:d7:5b:7c:a9:a8:92:dc:77:74:f4:4a:
                    c0:4a:90:71:0f:6d:9e:e7:4f:11:ab:a5:3d:cd:4b:
                    8b:79:fe:82:1b:16:27:94:8e:35:37:db:dd:b8:fe:
                    fa:6d:d9:be:57:f3:ca:f3:56:aa:be:c8:57:a1:a8:
                    c9:83:dd:5a:96:5a:6b:32:2d:5e:ae:da:fc:85:76:
                    bb:77:d5:c2:53:f3:5b:61:74:e7:f3:3e:4e:ad:10:
                    7d:4f:ff:90:69:7c:1c:41:2f:67:e4:13:5b:e6:3a:
                    a3:2f:93:61:3b:07:56:59:5a:d9:bc:34:4d:b3:54:
                    b5:c6:e5:0a:88:e9:62:7b:4b:85:d2:9e:4c:ee:0b:
                    0d:f4:72:b1:1b:44:04:93:cf:cc:bb:18:31:3a:d4:
                    83:4a:ff:15:42:2d:91:ca:d0:cb:36:d9:8d:62:c0:
                    41:59:1a:93:c7:27:79:08:94:b2:a2:50:3c:57:27:
                    33:af:f0:b6:92:44:49:c5:09:15:a7:43:2a:0f:a9:
                    02:61:b3:66:4f:c3:de:d3:63:1e:08:b1:23:ea:69:
                    90:db:e8:e9:1e:21:84:e0:56:e1:8e:a1:fa:3f:7a:
                    08:0f:54:0a:82:41:08:6b:6e:bb:cf:d6:5b:80:c6:
                    ea:0c:80:92:96:ab:95:5d:38:6d:4d:da:38:6b:42:
                    ef:7c:88:58:83:88:6d:da:28:62:62:1f:e5:a7:0d:
                    04:9f:0d:d9:52:39:46:ba:56:7c:1d:77:38:26:7c:
                    86:69:58:4d:b0:47:3a:e2:be:ee:1a:fc:4c:de:67:
                    f3:d5:fe:e6:27:a2:ef:26:86:19:5b:05:85:9c:4c:
                    02:24:76:58:42:1a:f8:e0:e0:ed:78:f2:8f:c8:5a:
                    20:a9:2d:0b:d4:01:fa:57:d4:6f:1c:0a:31:30:8c:
                    32:7f:b0:01:1e:fe:94:96:03:ee:01:d7:f4:4a:83:
                    f5:06:fa:60:43:15:05:9a:ca:88:59:5c:f5:13:09:
                    82:69:7f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                3D:3D:3D:61:E6:88:09:FE:34:0F:1D:5E:5E:52:72:71:C7:DE:15:92
            X509v3 Authority Key Identifier:
                keyid:3D:3D:3D:61:E6:88:09:FE:34:0F:1D:5E:5E:52:72:71:C7:
                DE:15:92

            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
    Signature Algorithm: sha256WithRSAEncryption
         28:24:86:91:a6:4a:88:e4:8d:6b:fc:67:2a:68:08:67:35:e5:
         a6:77:ff:07:4b:89:53:99:2e:6d:95:df:12:81:28:6a:8e:6f:
         5a:98:95:5b:4a:21:ae:f0:20:a4:4e:06:b2:4e:5a:67:c1:6a:
         06:f1:0f:c1:f7:7e:f2:e0:b3:9d:d8:54:26:6a:b2:1c:19:b8:
         b5:5c:c7:03:6b:f7:70:9e:72:85:c9:29:55:f9:f4:a4:f2:b4:
         3b:3d:ce:25:96:67:32:1e:8d:e2:00:22:55:4b:05:4f:ee:0e:
         67:ac:db:1b:61:da:5f:9c:10:1c:0c:05:66:c0:5b:5f:b9:95:
         59:a9:58:5b:e7:69:ac:b0:bd:b3:c2:a3:35:58:01:a4:ff:c0:
         8d:ac:1c:19:21:41:50:fb:8e:e0:f5:a9:ad:ec:de:cb:53:04:
         a9:d8:ac:76:8a:09:0d:7c:c6:1a:bc:06:74:bb:10:1c:aa:07:
         f6:cb:b2:1b:0c:0c:65:03:45:2b:51:d5:6e:a0:4d:91:ce:c5:
         ed:8d:a9:e7:f6:37:7d:ab:1b:a4:a2:a3:3b:76:17:5b:d9:3a:
         9c:c1:df:cc:cd:a0:b0:a9:5c:74:61:d7:a0:1d:04:67:68:ee:
         a6:7b:1e:41:a4:02:fc:65:9e:e3:c1:c2:57:b2:2e:b0:ff:a9:
         86:82:35:4d:29:b2:fe:74:2e:b8:37:5d:2b:e8:69:f2:80:29:
         19:f1:1e:7a:5d:e3:d2:51:50:46:30:54:7e:b8:ad:59:61:24:
         45:a8:5a:fe:19:ff:09:31:d0:50:8b:e2:15:c0:a2:f1:20:95:
         63:55:18:a7:a2:ad:16:25:c7:a3:d1:f2:e5:be:6d:c0:50:4b:
         15:ac:e0:10:5e:f3:7b:90:9c:75:1a:6b:e3:fb:39:88:e4:e6:
         9f:4c:85:60:67:e8:7d:2e:85:3d:87:ed:06:1d:13:0b:76:d7:
         97:a5:b8:05:76:67:d6:41:06:c5:c0:7a:bd:f4:c6:5b:b2:fd:
         23:6f:1f:57:2e:df:95:3f:26:a5:13:4d:6d:96:12:56:98:db:
         2e:7d:fd:56:f5:71:b7:19:2b:c9:de:2d:b9:c8:17:cc:20:de:
         7c:19:7a:aa:12:97:1c:80:b7:d3:67:d3:b7:a7:96:f0:c9:4d:
         f5:8b:0e:10:3b:b9:4e:09:90:5a:3b:51:c9:48:a2:ca:9f:db:
         72:44:87:59:db:49:fa:75:44:b5:f6:7f:c5:26:e1:01:ae:7b:
         6f:4a:75:d1:b5:b3:68:c0:31:48:f8:5c:06:c0:f1:b4:96:e8:
         38:e8:ad:44:3d:0a:8c:03:b6:2c:86:6a:f0:39:de:84:4b:2e:
         91:18:d1:45:65:d8:64:f5
Create a ConfigMap in the Kubernetes Cluster

After downloading the certificate locally on your machine, create a ConfigMap in the Kubernetes cluster that will copy the root CA certificate on your local machine into the Kubernetes cluster.

To create a ConfigMap, use the following command:

$ kubectl -n illumio-system create configmap root-ca-config \
	--from-file=./certs/root.democa.illumio-demo.com.crt

The --from-file option points to the path where the root CA certificate is stored on your local machine.

To verify that ConfigMap was created correctly, use the following command:

$ kubectl -n illumio-system create configmap root-ca-config \
> --from-file=./certs/root.democa.illumio-demo.com.crt
configmap/root-ca-config created
$
$ kubectl -n illumio-system get configmap
NAME                                 DATA   AGE
root-ca-config                       1      12s
$
$ kubectl -n illumio-system describe configmap root-ca-config
Name:         root-ca-config
Namespace:    illumio-system
Labels:       <none>
Annotations:  <none>

Data
====
root.democa.illumio-demo.com.crt:
----
-----BEGIN CERTIFICATE-----
MIIGSzCCBDOgAwIBAgIUAPw0NfPAivJW4YmKZ499eHZH3S8wDQYJKoZIhvcNAQEL
---output suppressed---
wPG0lug46K1EPQqMA7YshmrwOd6ESy6RGNFFZdhk9Q==
-----END CERTIFICATE-----

Events:  <none>
$

root-ca-config is the name used to designate the ConfigMap. You can modify it according to your naming convention.

Configure Calico in Append Mode

In case your cluster is configured with Calico as the network plugin (usually for Kubernetes and not for OpenShift), both Calico and Illumio Core will write iptables rules on the cluster nodes.

  • Calico - Needs to write iptables rules to instruct the host how to forward packets (overlay, IPIP, NAT, and so on).

  • Illumio Core - Needs to write iptables rules to secure communications between nodes and/or Pods.

You should establish a hierarchy to make the firewall coexistence work smoothly because Illumio Core and Calico will write rules at the same time. By default, both solutions are configured to insert rules first in the iptables chains/tables and Illumio Core will remove other rules added by a third-party software (in the Exclusive mode).

To allow Calico to write rules along with Illumio without flushing rules from one another, you should:

  • Configure Illumio to work in Firewall Coexistence mode (default for workloads that are part of a container cluster).

  • Configure Calico to work in Append mode (default is Insert mode).

To configure Calico to work in Append mode with iptables:

  1. Edit the Calico DaemonSet:

    kubectl -n kube-system edit ds calico-node

  2. Locate the spec: > template: > spec: > containers: section inside the YAML file and change ChainInsertMode by adding the following code block:

    - name: FELIX_CHAININSERTMODE
  value: Append

  3. Save your changes and exit.

  4. Kubernetes will restart all Calico Pods in a rolling update.

For more information on changing Calico ChainInsertMode, see Calico documentation.