Rules for Containerized Applications
This section covers different scenarios on writing rules for containerized applications.
Access Services from within the Cluster
For connections to a service from within the cluster, the Pods connect to a Service IP and the connections get distributed to the Pods.
Kubernetes
The rules you need to write are:
Example Ruleset
Scope
Application | Environment | Location |
|---|---|---|
Risk Assessment | Development | Cloud |
Intra-Scope Rule
OpenShift
The rules you need to write are:
Example Ruleset
Scope
Application | Environment | Location |
|---|---|---|
Risk Assessment | Production | HQ |
Intra-Scope Rule
Access Services from Outside the Cluster
Kubernetes
With Kubernetes, connections to a containerized application from the outside world can be handled in many different ways. In this release, Illumio supports only configurations which expose applications via the Kubernetes NGINX ingress controller (HostNetwork type only). Exposing applications using HostPort are not supported.
In typical Kubernetes deployments, connections to a containerized application from the outside world go through the ingress controllers, then the connection goes directly from controllers to the pods - not the service. Example of scenario and rule coverage are shown below.
Scenario:
The Kubernetes cluster and containerized applications are in the Development environment
The containerized application is called RiskAssessment and each Pod within the application listens on TCP 8080
The RiskAssessment application is exposed to the outside world via the ingress controller. The controller listens on TCP port 80 for the RiskAssessment application
In Illumio, the RiskAssessment workloads (Pods) provide to the controller on TCP 8080. The controller provides TCP 80 to the outside world.
The rules you need to write are:
Example Ruleset 1
Scope
Application | Environment | Location |
|---|---|---|
Risk Assessment | Development | Cloud |
Intra-Scope Rule
Source | Destination | Destination Service |
|---|---|---|
All Workloads | All Workloads | All Services |
Extra-Scope Rule
Source | Destination | Destination Service | Notes |
|---|---|---|---|
Worker | Risk Assessment | TCP 8080 | The source should be the role label of the nodes which nest the Ingress controllers. |
Example Ruleset 2
The second ruleset opens the ingress controller to the external network. The rule and ruleset below should have been created from the Rules for Kubernetes or OpenShift Cluster section of this guide. You can modify the ruleset as needed.
Scope
Application | Environment | Location | Notes |
|---|---|---|---|
Kubernetes Infrastructure | Development | Cloud | The scope of the ruleset should match the Kubernetes infrastructure scope. |
Intra-Scope Rule
Source | Destination | Destination Service | Notes |
|---|---|---|---|
External Network | Worker Node(s) | TCP 80 | This rule should exist from the Rules for Kubernetes or OpenShift Cluster section. The source should be the Kubernetes node(s) which contain the ingress controller. The destination can be an IP List such as 0.0.0.0/0 (any), HQ, Corporate, or employee subnet that requires connectivity into the exposed container workloads. |
OpenShift
Connections to a containerized application from the outside world go through the OpenShift Router, then the connection goes directly from router to the Pods - not the service. Example of scenario and rule coverage are shown below.
Scenario:
The OpenShift cluster and containerized applications are in the development environment
The containerized application is called RiskAssessment and each Pod within the application listens on TCP 8080
The RiskAssessment application is exposed to the outside world via the router. The router listens on TCP port 80 for the RiskAssessment application
In Illumio, the RiskAssessment workloads (Pods) provide to the router on TCP 8080. The router provides TCP 80 to the outside world.
The rules you need to write are:
Example Ruleset 1
Scope
Application | Environment | Location |
|---|---|---|
Risk Assessment | Production | HQ |
Intra-Scope Rule
Source | Destination | Destination Service |
|---|---|---|
All Workloads | All Workloads | All Services |
Extra-Scope Rule
Source | Destination | Destination Service | Notes |
|---|---|---|---|
IST Infra (Role) | Risk Assessment | TCP 8080 | Source refers to the Illumio Segmentation Template. The source should be the role label of the node(s) that nest the OpenShift Router. |
Example Ruleset 2
The following Ruleset is from the Segmentation Template and you can modify it as needed.
Scope
Application | Environment | Location | Notes |
|---|---|---|---|
IST OpenShift Infrastructure | IST Production | IST HQ | Ruleset is derived from Illumio Segmentation Template. The scope should match the OpenShift cluster. |
Intra-Scope Rule
Source | Destination | Destination Service | Notes |
|---|---|---|---|
External Network | IST Infra (Role) | TCP 80 | This rule is included in Illumio Segmentation Template. The destination should be the OpenShift cluster node(s) that nest the router. The source can be an IP list such as 0.0.0.0/0 (any), HQ, Corporate, or employee subnet. The IST default includes 0.0.0.0/0 (any) IP list. |
Outbound Connections
The outbound connections are required to access repositories.
Kubernetes and OpenShift
The rules you need to write are:
Example Ruleset
Scope
Application | Environment | Location |
|---|---|---|
Risk Assessment | Development | Cloud |
Intra-Scope Rule
Source | Destination | Destination Service | Notes |
|---|---|---|---|
All Workloads | docker.io (IP List) | All Services | Containerized environments depend on various external resources to perform basic operations such as pulling a docker image. In this rule, All pods in the Risk Assessment application are allowed to pull the image from the |
Liveness Probes
Containerized applications may require periodic health checks known as liveness probes and readiness probes. Each application includes a health check YAML file that contains configurations for liveness and readiness probes. The health checks between the container node and the local container workload may rely on TCP ports. Illumio has included a source object called Container Host for this use case. The Container Host object represents the container node or nodes that host the Pod(s). The example below uses the Container Host object as a source for Liveness and Readiness Probes.
Note
The Container Host must always fall under an Extra-Scope rule.
The rules you need to write are:
Kubernetes and OpenShift
The rules you need to write are:
Example Ruleset
Scope
Application | Environment | Location |
|---|---|---|
Risk Assessment | Development | Cloud |
Extra-Scope Rule
NodePort Support on Kubernetes and OpenShift
Kubernetes and OpenShift provide a mechanism to access cluster services from the outside world, of type NodePort. This service exposes a port on all nodes in the cluster on which traffic will be forwarded to any of the backing pods that match the service's selector.
Scenario:
The Kubernetes cluster and containerized applications are in the Production environment.
The containerized application is called RiskAssessment, and each Pod within the application listens on TCP 8080.
The RiskAssessment application is exposed to the outside world via a FrontEnd service with type NodePort.
The exact NodePort in use is not specified, but is automatically allocated by Kubernetes.
There may be clients to the FrontEnd service within the cluster or outside the cluster - in both cases, they are labeled as Client.
The rules you need to write are:
Example Ruleset 1: Internal and External Access to Service
Scope
Application | Environment | Location |
|---|---|---|
Risk Assessment | Production | Cloud |
Extra-Scope Rule
Source | Destination | Destination Service | Notes |
|---|---|---|---|
Client (Role label for Web pods and external workloads) | FrontEnd (Virtual Service Role label for Risk Assessment service) + Use Virtual Services Only | Derived from Destination Virtual Service | After the Risk Assessment service gets discovered by the PCE it becomes a virtual service object in the PCE. The destination here should be the role label of the virtual service plus the "Use Virtual Service Only" option. |