In this post series, you will see how to split your OpenShift workers into multiple Security Zones.

I don’t want this post to be a “quick-guide to”. I will explain a lot of details, options, explanations, tips&tricks, worst-case scenarios, caveats, tests, day2 ops, etc… and that’s why it’s SO LONG…

This is more intended to be read by people that want to know more about Kubernetes/OpenShift infrastructure in general with the excuse of creating Security Zones in worker nodes, more than for those ones that want to check a quick review about how to perform the actual configuration. If you are more in the second group, go directly to the last part of the post where I will present a summary of the steps done during the configuration.

You will need to know some basic concepts of OpenShift/Kubernetes but I will try to cover as much as possible without writing a complete book to explain everything.

Finally, if you conclude that having multiple OpenShift clusters to cover this use case, instead of having a single big OpenShift cluster, is easier and cleaner, I won’t disagree, but it would depend on your specifics since multiple OpenShift Clusters means multiple API and apps entry points that you need to take into account, along with more nodes for the control plane, and the Management and configuration multiplied, but to be honest, that last part is becoming less and less a problem due to products like the Advanced Cluster Management. As I told you, that will depend on you and your needs, but in regards to this post, the topic is more an excuse to explain some infrastructure concepts than a recommended architecture.

Going back to the topic, Why setting up security zones in your workers is useful? because you can cover some use cases, like for example:

• Create a Secure Zone where you can run your most sensible applications and where only a subset of users can deploy workloads

Workloads:      Trusted
OCP Users:      Trusted
Management:     Restricted to some users/projects

• Create a DMZ where you can put your user-facing applications, which have more risk to be attacked by an external intrusion, and where only a subset of users can create resources

Workloads:      Untrusted (they can be compromised)
OCP Users:      Trusted
Management:     Restricted to some users/projects

• Create a Zone where you force to run the applications from non-trusted (or less-trusted) users of your cluster. Those users won’t be able to access or use resources in other zones.

Workloads:      Untrusted (they can be compromised)
OCP Users:      Untrusted
Management:     Enforced (users only have access to those resources)

This method is using a single OpenShift cluster so all PODs are connected to the same SDN even though we include “Security Zones”. We can prevent connectivity inside the SDN using Network Policies, but those work at layer 3/4, thus if you would need full isolation you will need to deploy a separate OpenShift Cluster.

In this post, I will focus on the first use case (create a Secure Zone) but I will make some comments on the differences when you try to create a DMZ (so the opposite to a Secure Zone).

How we can define a Security Zone? we will need to:

1. Create a group of nodes for the new Zone
2. Configure specific networking rules for the Zone
3. Configure usage restrictions on the new Zone

Each post will cover one of these points above, and in the last one, I will include a recap of everything. If you want to jump directly to any of the posts:

#security #kubernetes #ingresscontroller #rbac #openshift