Multitenancy and network security

To make effective use of infrastructure and reduce operational expenses, you can run Cloud Pak for Data in multitenant mode on a single OpenShift® cluster, while still maintaining security, compliance, and independent operability.

Overview

You can achieve multitenancy on a single instance of Cloud Pak for Data or on multiple instance of Cloud Pak for Data. For more information, see Support for multitenancy.

Using network policies

During the installation of the OpenShift cluster, if the network isolation mode is set to NetworkPolicy (the default), then traffic between different project namespaces can be defined by using custom resources of type NetworkPolicy. For more information, see About network policy.

By default, all pods in a project are accessible from other pods and network endpoints. To isolate one or more pods in a project, you can create NetworkPolicy objects in that project to indicate the allowed incoming connections. Project administrators can create and delete NetworkPolicy objects within their own project.

Typically, each tenant would expect isolation inside their dedicated namespace. Therefore, a network policy must be created to:

  • Deny all traffic.
  • Only accept connections from pods within the same namespace.
  • Only accept connections from the Red Hat® OpenShift Container Platform.
  • Only accept ingress traffic at the front door.

To make a project deny all traffic by default, define a network policy that applies to all pods in that namespace and rejects all incoming traffic into that namespace:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1 
metadata:
  name: deny-by-default
spec:
  podSelector:
  ingress: []

To make pods accept connections from other pods in the same project, but reject all other connections from pods in other projects, define the following network policy:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-from-same-namespace
spec:
  ingress:
  - from:
    - podSelector: {}
  podSelector: {}
  policyTypes:
  - Ingress

To make pods in the project accept connections from the OpenShift container platform for example from the OpenShift Ingress Controller and the OpenShift monitoring, define the following network policies:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1 
metadata:
name: allow-from-openshift-ingress 
spec:
ingress: 
- from:
 - namespaceSelector: 
    matchLabels:
     network.openshift.io/policy-group: ingress 
podSelector: {}
policyTypes: 
- Ingress
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1 
metadata:
name: allow-from-openshift-monitoring 
spec:
 ingress: 
 - from:
  - namespaceSelector:
    matchLabels: 
     network.openshift.io/policy-group: monitoring
podSelector: {} 
policyTypes:
- Ingress

Finally, to accept ingress traffic at the front door, define the following network policy:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1 
metadata:
 name: allow-access-to-front-door 
spec:
 podSelector: 
  matchLabels:
   component: "ibm-nginx"
policyTypes:
- Ingress
ingress:
- {}

Enabling access to and from tethered projects

Cloud Pak for Data also supports the concept of a tethered project, a separate namespace from the control plane namespace that can be used to host service instances. However, to provision and manage these service instances, these tethered namespaces must be accessible from the control plane namespace and vice versa.

For more information, see Tethered projects and Configuring network isolation using OpenShift SDN. If you are a cluster administrator, see Joining projects to allow access to and from tethered namespaces.

Example: Defining a tenant namespace group

Since there maybe multiple instances of Cloud Pak for Data, each with its own tethered namespaces, it is important to identify and group each of these namespaces.

  • The Cloud Pak for Data control plane in project namespace dev is associated with two tethered namespaces: apps-dev and db-dev.
  • Another instance of Cloud Pak for Data in project namespace prod is associated with two other tethered namespaces: apps-prod and db-prod.

To group these two sets of namespaces, apply labels to these project namespaces.

oc label namespace dev apps-dev db-dev cpdgroup=dev 
oc label namespace prod apps-prod db-prod cpdgroup=prod

You can validate that the label has been properly applied by using the describe command.

oc describe namespace db-dev

To remove a namespace from a group, remove its assigned label. 

oc label namespace db-dev cpdgroup-

Example: Defining a network policy to allow access only within the group

The following network policy allows all pods from within the dev group to connect with each other.

kind: NetworkPolicy 
apiVersion: networking.k8s.io/v1 
metadata: 
  name: dev-group 
spec: 
  podSelector: 
  ingress: 
  - from: 
    - namespaceSelector: 
       matchLabels:
       cpdgroup: dev

You can also make the network policy even more restrictive. In the following example, pods with the label app: my-https can only be accessed by client pods that are within the same group and that have the client: my-authorized label.

kind: NetworkPolicy 
apiVersion: networking.k8s.io/v1 
metadata: 
  name: restrict-app 
spec: 
  podSelector: 
    matchLabels: 
      app: my-https 
ingress: 
- from: 
  - podSelector: 
      matchLabels: 
        client: my-authorized 
    namespaceSelector: 
      matchLabels: 
        cpdgroup: dev

Network policies can also be defined to apply cumulatively, which means you can combine multiple network policies to satisfy complex network requirements.