Rules for Containerized Applications
This section covers different scenarios on writing rules for containerized applications.
Access Services from within the Cluster
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
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 NodePort or 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
Provider | Providing Service | Consumer |
|---|---|---|
All Workloads | All Services | All Workloads |
Extra-Scope Rule
Provider | Providing Service | Consumer | Notes |
|---|---|---|---|
Risk Assessment | TCP 8080 | Worker | The consumer 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
Provider | Providing Service | Consumer | Notes |
|---|---|---|---|
Worker Node(s) | TCP 80 | External Network | This rule should exist from the Rules for Kubernetes or OpenShift Cluster section. The provider should be the Kubernetes node(s) which contain the ingress controller. The consumer 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
Provider | Providing Service | Consumer |
|---|---|---|
All Workloads | All Services | All Workloads |
Extra-Scope Rule
Provider | Providing Service | Consumer | Notes |
|---|---|---|---|
Risk Assessment | TCP 8080 | IST Infra (Role) | Consumer refers to the Illumio Segmentation Template. The consumer should be the role label of the node(s) which 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
Provider | Providing Service | Consumer | Notes |
|---|---|---|---|
IST Infra (Role) | TCP 80 | External Network | This rule is included in Illumio Segmentation Template. The provider should be the OpenShift cluster node(s) which nest the router. The consumer 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
This section covers different scenarios on writing rules for containerized applications.
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
Provider | Providing Service | Consumer | Notes |
|---|---|---|---|
docker.io (IP List) | All Services | Database (Role for Postgres Pods) | Once the database service gets discovered by the PCE it becomes a virtual service object in the PCE - not a container workload. The provider should be the role label of the virtual service plus the "Use Virtual Service Only" option. The Consumer in this example is the Web Pod. Use the Web Role label which describes the Pod. Leave the Providing Service empty. Once the rule is saved, it will automatically populate with Derived from Provider Virtual Service. |
Liveness Probes
Liveness Probes
Containerized applications may require periodic health checks known as liveness probes and readiness probes. Each application includes a health check YAML file which contains liveness and readiness probe configurations. The health checks between the container node and the local container workload may rely on TCP ports. Illumio has included a consumer object called Container Host for this use case. The Container Host object represents the container node or nodes which host the Pod(s). The example below uses the Container Host object as a consumer 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