Case studies

IBM Cloud Pak® for Multicloud Management platform allows using cluster resources across applications in shared and dedicated models. There are various types of configuration requirements from different users of IBM Cloud Pak for Multicloud Management that require isolation at various levels. This section highlights scenarios that are supported in IBM Cloud Pak for Multicloud Management that help in achieving isolation at various levels of the cluster stack; such as application, user management, infrastructure, and network.

User roles and namespace isolation

The user wants to use a single cluster for multiple application project teams with complete isolation. The user has an Operations team that manages a single cluster with high availability configured. Members of the Operations team define individual namespaces for the separate project teams. They assign the cluster administrator role to one or more persons per project team, who then define the team members and roles for that namespace. Members of the Operations team who have the role of the cluster administrator are responsible for setting up shared storage and monitoring all namespaces.

Isolated workloads to nodes

The user has multiple teams in their organization and has dedicated namespaces for each team. The application and workload deployments of any team should happen only within the namespace assigned to the team. Each team has a planned group of nodes, either physical servers or virtual machines, that are added to the cluster where there might be many other nodes from various teams configured and are managed as part of the same cluster. All the deployments made by a specific team should only be hosted on the group of nodes that the team has been assigned to.

Multiple LDAP supported clusters

There are multiple LDAP servers, such as OpenLDAP and Active Directory that are set up for various departments in an organization. Each department is isolated to its own group of users as teams. Each team has dedicated namespaces thereby achieving isolated namespace environments for the various departments accessing the same cluster.

Workloads with controlled network isolation

Workloads on the user's site run on a shared network infrastructure. The user runs on a cluster where multiple teams in their organization host workloads on their dedicated isolated namespaces. The network traffic to the applications on the namespace of a cluster shouldn’t have any interference with network traffic on other namespaces and all the traffic should be confined within the deployment's namespace. Also, the nodes are grouped and assigned with dedicated virtual local area network (VLAN) subnet ranges.

Pod isolation

Image containers run in pods on a shared set of worker nodes. These pods can either be self-contained, not accessing any features from the host node, or the pods can request privileged access to host features. When requesting privileged access to the host, the pod can cause other pods on the same host to fail.

Isolate pods with different security context requirements to specific host groups and networks to increase stability, performance, and security.

Proxy ingress isolation can’t be used for network segregation when using pod isolation since multiple namespaces are used. Use VLANs or network policies to segregate the worker node networks from one another.

Pod and network isolation with VLANs

Network VLANs at the infrastructure level can be used to isolate traffic in one application from another and in host groups. To implement pod and network isolation by using VLANs, separate namespaces into two or more pod privilege categories ranging from the most unprivileged to the most privileged.

Pod and network isolation by using network policies

Kubernetes network policies can be used to isolate traffic between namespaces or pods by using labels. To implement pod and network isolation by using network policies, separate namespaces into two or more pod privilege categories ranging from the most unprivileged to the most privileged and use a common namespace label to allow ingress and egress traffic between namespaces in the same application.