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:
Workloads: Trusted
OCP Users: Trusted
Management: Restricted to some users/projects
Workloads: Untrusted (they can be compromised)
OCP Users: Trusted
Management: Restricted to some users/projects
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:
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