Container Clusters
The Illumio Core uses three groups of APIs to manage container clusters:
Container Cluster API (GET, POST, PUT, DELETE)
Container Cluster Workload Profiles API (GET, POST, PUT, DELETE)
Container Cluster Service Backend API (GET)
Container Cluster API
A container cluster object stores all the information about a Kubernetes cluster in the PCE by collecting telemetry from Kubelink. Each Kubernetes cluster maps to one container cluster object in the PCE.
Use these methods to get, create, update, or delete container clusters:
Functionality | HTTP | URI |
---|---|---|
Get the list of container clusters. |
|
|
Get the specified container cluster. |
|
|
Create a container cluster. |
|
|
Update the specified container cluster. |
|
|
Delete the specified container cluster. |
|
|
Container Cluster Workload Profiles
When you install an Illumio VEN on a container cluster, all pods are unmanaged or not visible in the PCE. However, Kubelink reports all namespaces on the container clusters, which are then visible via the Container Workload Profiles API.
Each container workload profile maps to a Kubernetes namespace and can be managed or unmanaged. The default state for a profile is unmanaged.
Use these methods to get, create, update, or delete container cluster workload profiles:
Functionality | HTTP | URI |
---|---|---|
Get the list of container cluster workload profiles. |
|
|
Create container cluster workload profiles. |
|
|
Update the specified container cluster workload profile. |
|
|
Supports the UI feature for bulk update of container workload profiles. |
|
|
Delete the specified container cluster workload profile. |
|
|
Label Restrictions
Kubernetes pods and services running in a namespace (Kubernetes) or project (OpenShift) must be labeled (RAEL) to be included in the policy within Illumio Core. The container workload profile defines how labels will be assigned to pods and services within a namespace.
Using annotations, Illumio labels can be statically assigned from the PCE or defined in the Kubernetes manifest files. For each label key (RAEL), the PCE administrator can define four options:
No label will be assigned.
One label will be assigned from PCE.
Using annotations, Kubernetes can assign a restricted list of labels. Label restrictions prevent the misuse of Illumio labels by the people managing the Kubernetes platform and ensure that the labels inherit the policy they should receive.
Any label can be assigned from Kubernetes.
You can set role labels for the following APIs:
PUT /api/v2/orgs/:xorg_id/container_clusters/<:cluster_id>/ container_workload_profiles
POST /api/v2/orgs/:xorg_id/container_clusters/<:cluster_id>/ container_workload_profiles
Label Assignment Configuration
To clear the label assignment option and go back to the default option (any labels passed at runtime using Kubernetes annotations will be allowed), two options:
Option 1: explicit statement
{ "labels": [ { "key": "role", "restriction": [] } ] }
Option 2: empty payload
{ "labels": [] }
Backend Services Associated with Container Clusters
The Illumio policy model represents Kubernetes services as virtual services. For these services, Kubelink creates virtual services in the PCE and reports the list of Replication Controllers, Daemon Sets, and Replica Sets responsible for managing the pods that support them.
When a match between the Replication Controller and ReplicaSet managing a pod, the PCE creates a binding between the virtual service and the container workload.
The Service Backend matches a virtual service and an application type, such as Deployment or ReplicaSet.
Use this method to get the service backend:
Functionality | HTTP | URI |
---|---|---|
Get data about the service backend. |
|
|
Kubernetes APIs
Kubernetes Workload Endpoints
Customers must see the details of Kubernetes workloads in PCE to write policies and troubleshoot any issues.
Two new endpoints have been created for Kubernetes workloads:
GET /api/v2/orgs/:xorg_id/kubernetes_workloads
This API lists all new Kubernetes Workloads in a separate tab/page with separate sorts and filters.
It contains required properties such as
name
,kind
,namespace
, as well as optional properties:href
,labels
,enforcement_mode
,visibility_level
,container_workload_profile
,container_cluster
,security_policy_applied_at
,security_policy_sync_state
,created_at
,k8s_label
, andk8s_annotations
.GET /api/v2/orgs/:xorg_id/kubernetes_workloads
For this API, these changes have been made in release 23.5.0:
two arrays have been removed,
k8s_labels
and sk8s_annotation
, and replaced with propertymetadata
.HREF description has been changed from
URI of the container workload
, toURI of the kubernetes workload
.
"metadata": { "$ref": " ../common/kubernetes_workloads_metadata.schema.json"
GET /api/v2/orgs/:xorg_id/kubernetes_workloads/:kubernetes_workload_uuid
This API provides a detailed page for the specified Kubernetes workload with custom K8S attributes.
common non_empty_label_scopes.schema.json
This new common schema provides a collection of assigned list of labels. Minimum number is one.
common kubernetes_workloads_metadata
The new common schema
kubernetes_workloads_metadata
was added in release 23.5.0, referenced fromkubernetes_workload_get
.It provides Kubernetes properties such as labels, annotations, and the external service's UID.