Multitenancy
Overview
This section presents how to achieve multitenancy with WorkflowGen images and Kubernetes. By the nature of containers and tools present in Kubernetes, a single cluster can have multiple instances of WorkflowGen with relative isolation from one another. The best isolation can be achieved with multiple clusters.
As reference for best practices, see the following links to Google Kubernetes Engine and Azure Kubernetes Service documentation:
Security concerns
Before beginning with the recommended architectures, it is important to note some security concerns that derive from using Windows containers. The WorkflowGen image is a Windows container image. Some security features present in Linux containers are not necessarily available in Windows containers, such as AppArmor and SELinux profiles and Linux capabilities. See Intro to Windows support in Kubernetes for all of the current limitations.
The important thing in multitenant clusters is isolating tenants from one another and limiting possible actions in case of intrusion. You can achieve a good isolation level with network policies on Kubernetes. These are specifications that require third-party software to be installed to enforce those policies. At this time, only the Calico project has a Windows support (see Calico for Windows for more information).
For in-container security, at this time, only runAsUserName is available to run the container instance as a different username than ContainerAdministrator (see Configure RunAsUserName for Windows pods and containers for more information). It's not necessary for the WorkflowGen container since the web applications run as a user of the IIS_IUSRS group.
Recommendations
Make sure that the WorkflowGen Windows Services pod has inbound traffic denied. It should not be public facing.
Make sure that the WorkflowGen database pods are not public facing. They are only used by the WorkflowGen container.
The WorkflowGen web applications' pods should only be publicly available through HTTPS. HTTP is highly discouraged. However, you should not be able to access WorkflowGen at all from inside the cluster, even in HTTPS.
Every WorkflowGen pod in a namespace should not be able to contact other pods in other namespaces. Be sure to have a network policy for this.
In general, you should always deny any inbound traffic unless you explicitly need it.
Architecture
The basic idea behind multitenancy is to have reproducible deployment. This schema shows two identical deployments but in different namespaces. Each has its own data, configuration, and license. Isolation between the namespaces should be enforced by network policies. Optionally, you might want to use an Ingress controller with cert-manager to manage routing and certificates easily.
This architecture also applies to multicluster (multiregion) environments. The only thing that will change is how you route to the correct instance. The same security concerns apply.
Last updated
