Isolation on IBM Cloud Private

IBM Cloud Private offers multi-tenancy support through user, compute, and network isolation within a cluster. Dedicated physical and logical resources are required for the cluster to achieve workload isolation. Multi-tenancy requires applying various isolation techniques that are described in this topic.

User, compute, and network isolation is enforced by confining workload deployments to virtual and physical resources. The enforced isolation also allows the cluster administrator to control the footprint that is allocated to various teams based on their requirements. The following are some key prerequisites to achieve isolation of deployments on cluster nodes.

Plan deployment model for isolation

There are several levels of multi-tenancy. The cluster administrator must analyze workload requirements to determine which levels are required. The following isolation features can be used to satisfy these requirements:

• Host groups: As part of preinstall configuration, the cluster administrator can configure groups of nodes to worker host groups and proxy host groups. This operation also involves pre-planning the namespaces, as each host group is mapped to a namespace.
• VLAN subnet: The network infrastructure administrator can plan various subnet ranges for each node or host groups before IBM Cloud Private installation.
• Multiple LDAP supports: Multiple LDAP servers can be configured and the cluster administrator can form teams of users and user groups from various LDAP domains.
• Namespaces: The cluster administrator can create namespaces for logical grouping of resources. The namespaces can be created after IBM Cloud Private installation. If the cluster administrator chooses to have host groups, then the namespace planning is done before installation.
• Network ingress controllers: The cluster administrator must plan the ingress controllers before installation to allow the installer to create ingress controllers for each controller that are mapped to one host group and one namespace.
• Users, user groups, teams: The users and user groups can be on boarded on to IBM Cloud platform and they can be grouped in teams that are mapped to namespaces and other resources.
• Network policies: Team administrators and Operators can create network policies to create firewall rules at the namespace scope.
• Pod Security policies: The cluster administrator can create policies that either allow or deny container images from running in select namespaces or nodes.

Scenarios

The following section covers various use case scenarios and has more details on configuration to achieve the isolation in each scenario.

Scenario 1: Isolated teams and namespaces across users and user groups

You want to use a single IBM Cloud Private cluster for multiple application project teams with complete isolation. There might be an Operations team that manages a single cluster with high availability configured. Members of the Operations team define individual namespaces for separate project teams. They assign the administrator role to one or more persons per project team, who in turn, 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.

• Planning
  • Plan the groups of users and user groups across various teams
• Installation
  • Install IBM Cloud Private
• Postinstallation
  • Map teams to one or more Namespaces based on resource grouping requirement
  • Create teams and assign users and resources; see Teams for more information

Scenario 2: Isolated teams and namespaces and dedicated nodes to namespaces

There are multiple teams in your organization with 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, which are physical servers or virtual machines, that are added to the cluster. This cluster can have many other nodes from various teams that are configured and managed as part of the same IBM Cloud Private cluster. All the deployments that are made by a specific team should be hosted only on the group of nodes that the team has been assigned to.

• Planning
  • Plan the groups of users and user groups across various teams
  • Plan various custom host groups of worker nodes
  • Plan namespaces ahead, which will be mapped to each worker host group
• Installation
  • Configure the custom host groups for workers in the hosts file
  • Configure namespaces, which will be mapped to each host group that is configured in <installation_directory>/cluster/config.yaml as an isolated_namespaces parameter
  • Install IBM Cloud Private
• Postinstallation
  • Map teams to one or more namespaces based on resource grouping requirement
  • Create teams and assign users and resources; see Teams for more information

Scenario 3: Isolated teams and namespaces, dedicated nodes to namespaces, and dedicated VLAN networks and ingress controlled namespaces

Workloads run on a shared network infrastructure with a cluster where multiple teams of the organization have 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 can be grouped and assigned with a dedicated VLAN subnet range.

• Planning
  • Plan the groups of users and user groups across various teams
  • Plan various custom host groups for worker and proxy nodes
  • Plan the namespace mappings to worker and proxy host groups
  • Plan VLAN subnets for each host group
• Installation
  • Configure the custom host groups for workers and proxy nodes in the hosts file
  • Configure namespaces, which will be mapped to each worker host group configured in <installation_directory>/cluster/config.yaml
  • Configure namespaces, which will be mapped to each proxy host group configured in <installation_directory>/cluster/config.yaml as an isolated_proxies parameter
  • Configure the network for host groups by using either single or multiple VLANs
  • Install IBM Cloud Private
• Postinstallation
  • Map teams to either one or more namespaces based on resource grouping requirement
  • Create teams and assign users and resources; see Teams for more information

Scenario 4: Isolated teams and namespaces, dedicated nodes to namespaces, dedicated VLAN networks, ingress controlled namespaces, and persistence volume claims and persistence volumes

You want to share the storage class server, such as NFS and GlusterFS across the multi-tenant namespaces. You create persistence volumes based on the storage class. To isolate the storage environment to dedicated namespaces, persistence volume with labels must be created. When the pods are deployed in an isolated namespace, the persistence volume claims can be configured to bind to specific persistence volume by using selectors.

• Planning
  • Plan the groups of users and user groups across various teams
  • Plan various custom host groups for worker and proxy nodes
  • Plan the namespace mappings to worker and proxy host groups
  • Plan VLAN subnets for each host group
  • Plan persistence volumes for each namespace that is required
• Installation
  • Configure the custom host groups for workers and proxy nodes in the hosts file
  • Configure namespaces, which will be mapped to each worker host group configured in <installation_directory>/cluster/config.yaml
  • Configure namespaces, which will be mapped to each proxy host group configured in <installation_directory>/cluster/config.yaml as an isolated_proxies parameter
  • Configure the network for host groups by using single or multiple VLANs
  • Install IBM Cloud Private
• Postinstallation
  • Map teams to either one or more namespaces based on resource grouping requirement
  • Create teams and assign users and resources; see Teams for more information.
  • Deploy pods that have persistence volume claims. The persistent volume claims have label selectors that map to the appropriate persistence volume created for their namespace. For more details on creating PVs and PVC's refer to Storage isolation

Scenario 5: Isolated teams and namespaces, dedicated nodes to namespaces, isolated networks, and pod isolation

This scenario builds on Scenario 2, providing both user, network, and compute isolation that includes increasing stability, performance and security for container images. Container images, running in pods, are isolated to select node groups by using namespaces. Therefore, application namespaces must be subdivided into extra namespaces. Proxy ingress isolation can’t be used for network segregation when you use 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 by using VLANs

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

Pod and network isolation by using network policies

Kubernetes network policies can be used to traffic between namespaces or pods using labels. To implement pod and network isolation by using network policies, separate namespaces into two or more pod privilege categories that range 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.

• Planning

  • Pod security policy security context groups must be defined
  • Namespaces must be identified for applications and pod security policies
  • Host groups must be mapped to namespaces to isolate application compute
  • VLANs can optionally be created to firewall host groups from one another

• Installation

  • Configure nodes for IBM Cloud Private.
  • Configure network for nodes using single or multiple VLANs
  • Configure and install IBM Cloud Private, specifying the isolated host groups by namespace

• Postinstallation

  • Configure teams, assigning users to namespaces
  • Configure pod security policies for namespaces
  • Configure network policies for namespaces

Scenario 6: Multiple LDAP configured to a single cluster

There are multiple LDAP servers, such as Open LDAP and Active Directory, that are set up for various departments in an organization. The members of each department are isolated to their own group of users, forming a team. Each team has dedicated namespaces thereby achieving isolated namespace environments for the various departments accessing the same IBM Cloud Private cluster.

• Planning
  • Plan the groups of user and user groups across various LDAP servers to teams
• Installation
  • Configure multiple LDAP domain servers for IBM Cloud Private
  • Install IBM Cloud Private
• Postinstallation
  • Configure teams of users from multiple LDAP
  • Map teams to one or more Namespaces based on resource grouping requirement.
  • Create teams and assign users and resources; see Teams for more information

Isolation techniques on an IBM Cloud Private cluster environment are more detailed in the following sections:

• RBAC-based isolation
  
• LDAP isolation
  
• Pod isolation