Basic security features on Red Hat OpenShift Container Platform

Cloud Pak for Data builds on Red Hat® OpenShift® Container Platform security features that protect sensitive customer data with strong encryption controls and enforce access control across applications and the platform.

Features

Red Hat OpenShift Container Platform enables an improved security posture with the addition of many capabilities that greatly increase the security of the platform.

Feature Learn more
Uses Red Hat CoreOS as the immutable host operating system. See Red Hat Enterprise Linux CoreOS in the Red Hat OpenShift Container Platform documentation:
Enables Security Enhanced Linux® (SELinux) as mandatory on Red Hat OpenShift Container Platform. See Securing containers on Red Hat Enterprise Linux CoreOS in the Red Hat OpenShift Container Platform documentation:
Provides stronger platform security with FIPS (Federal Information Processing Standard) compliant encryption (FIPS 140-2 Level 1). See Support for FIPS cryptography in the Red Hat OpenShift Container Platform documentation:
Uses the Node Tuning Operator, which provides opportunities to further reduce privilege requirements in the security context constraints (SCC). See Using the Node Tuning Operator in the Red Hat OpenShift Container Platform documentation:
Provides the Compliance Operator, which runs compliance scans and recommends remediation strategies to enable you to achieve and maintain compliance. The Compliance Operator includes profiles that represent various benchmarks, such as the CIS Benchmark for Red Hat OpenShift Container Platform 4. See Understanding the Compliance Operator in the Red Hat OpenShift Container Platform documentation:
Supports encrypting data that is stored in etcd, which provides extra protection for secrets that are stored in the etcd database. See Encrypting etcd data in the Red Hat OpenShift Container Platform documentation:
Provides a Network Bound Disk Encryption (NBDE) feature that can be used to automate remote enablement of LUKS encrypted volumes, making it better protected against physical theft of host storage. See Network-Bound Disk Encryption (NBDE) in the Red Hat OpenShift Container Platform documentation:

Service accounts and roles

Cloud Pak for Data runs in a dedicated namespace or project on the OpenShift cluster. In the OpenShift project, Cloud Pak for Data creates service accounts and RBAC role bindings for pods to use within that namespace.

Roles

When you install the Cloud Pak for Data control plane, two roles are created: cpd-admin-role and cpd-viewer-role.

These roles allow Cloud Pak for Data to ensure that the principle of least privilege can be applied even within the same namespace.

The services that you install introduce additional roles.

The roles that are associated with an instance of Cloud Pak for Data are scoped to the operands project and any tethered projects for the instance. The roles are not given cluster authority.

Service accounts

The default service account that is automatically created in every OpenShift project:

  • Is associated with the restricted or restricted-v2 security context constraint (SCC).
  • Is used for user workloads such as Notebooks and Python jobs.
  • Is not granted any RBAC privileges. No roles are bound to the default service account.
  • Is not allowed to perform any kind of actions inside the namespace.

When you install the Cloud Pak for Data control plane, four service accounts are created: zen-admin-sa, zen-editor-sa, zen-viewer-sa, and zen-norbac-sa.

No SCCs are explicitly bound to these service accounts, so they pick up the restricted or restricted-v2 SCC by default.

The services that you install introduce additional service accounts. Most of these service accounts use the restricted or restricted-v2 SCC. However, some services need custom SCCs, for example to support inter process communication (IPC). For more information about services that require custom SCCs, see Creating custom security context constraints for services.

The service accounts that are associated with an instance of Cloud Pak for Data are scoped to the operands project and any tethered projects for the instance. The service accounts are not given cluster authority.

Service UIDs

Services use UIDs based on the Red Hat OpenShift Container Platform project where they are installed.

When you create a project, Red Hat OpenShift assigns a unique range of UIDs to the project. To determine the UIDs that are associated with a project, run the following command:

oc describe project project-name

Replace project-name with the name of the project where Cloud Pak for Data is installed.

Additionally, if a service uses a custom SCC, it reserves one or more UIDs:
  • The Informix® SCC reserves UID 1000.
  • The Db2® as a service restricted SCC reserves UID 500.

For details on which services use these SCCs, see Creating custom security context constraints for services.

Security hardening

Security hardening is enforced on Cloud Pak for Data on Red Hat OpenShift. The following security hardening actions are taken:

  • In general, only non-root processes run in containers.

    Depending on how you configure your cluster, services with a dependency on Db2U might have the allowPrivilegedContainer: true setting and run with sudo access. If you want these services to run with allowPrivilegedContainer: false, you must change the kernel parameter settings to allow Db2U to make unsafe sysctl changes.

  • In general, the UIDs of the processes used by containers are in the range defined by the OpenShift project and are enforced by the restricted or restricted-v2 SCC, which prevents containers from running as root.

    Services that require a fixed UID use a custom SCC to reserve the required UID. For more information, see Creating custom security context constraints for services.

  • At runtime, Cloud Pak for Data workloads do not require cluster-admin privileges or host access. The SCCs that Cloud Pak for Data services use prevent the workloads from accessing host paths and networks on the cluster.
    Important: Depending on how you configure your cluster, services with a dependency on Db2U temporarily access the host path on the cluster. Specifically, the init containers mount the host's /proc directory as /host/proc. After the init container completes, the Db2U container does not have elevated privileges. This occurs only if the services have the allowPrivilegedContainer: true setting.
  • The use of service accounts with RBAC privileges is strictly enforced, and the principle of least privilege is applied. Cloud Pak for Data ensures that any pod that is running user code, such as scripts or analytics environments, is not granted any RBAC privileges.
  • Cloud Pak for Data pods restrict resource consumption. Each pod has predefined requests and limits for vCPU and memory., which restricts the consumption. This approach helps protect against noisy neighbors that cause resource contention.
    Tip: Install the scheduling service to reduce the impact of noisy neighbors and malicious activities. For more information, see Determining which IBM Cloud Pak® for Data components to install.
  • Cloud Pak for Data pods include liveness and readiness probes to ensure that the pods are working correctly.
  • For consumption monitoring, each of the pods on Cloud Pak for Data is annotated with metering annotations to uniquely identify add-on service workloads on the cluster. You can use the integrated monitoring interface to understand how Cloud Pak for Data is using resources. For more information, see Monitoring the platform
  • Typically, Cloud Pak for Data users are not granted OpenShift access.

    You can optionally give a Cloud Pak for Data user access to the cluster as an instance administration privileges to enable the user to install or upgrade the software associated with their instance of Cloud Pak for Data. An instance administrator has access only to the projects associated with an instance of Cloud Pak for Data.

Best practices for installation

Run the installation from a client workstation
You can install and manage the Cloud Pak for Data software from a client workstation by using the following command-line interfaces:
  • Cloud Pak for Data command-line interface (cpd-cli CLI)
  • Red Hat OpenShift Container Platform command-line interface oc CLI

You do not need to SSH into the cluster.

Store software images in a private container registry

IBM Cloud Pak for Data software images are accessible from the IBM® Entitled Registry. In most situations, it is strongly recommended that you mirror the necessary software images from the IBM Entitled Registry to a private container registry.

You must mirror the Cloud Pak for Data software images to your private container registry in the following situations:
  • Your cluster is air-gapped (also called an offline or disconnected cluster).
  • Your cluster uses an allowlist to permit direct access by specific sites, and the allowlist does not include the IBM Entitled Registry.
  • Your cluster uses a blocklist to prevent direct access by specific sites, and the blocklist includes the IBM Entitled Registry.
Even if these situations do not apply to your environment, you should consider using a private container registry if you want to:
  • Run security scans against the software images before you install them on your cluster
  • Ensure that you have the same images available for multiple deployments, such as development or test environments and production environments
For more information see:
Installing Cloud Pak for Data on air-gapped clusters

The Cloud Pak for Data command-line interface (cpd-cli) enables you to install the Cloud Pak for Data software even when your cluster and your private container registry are air-gapped.

Before you move the client workstation behind your firewall, you can mirror the images from the IBM Entitled Registry to an intermediary container registry on the client workstation. After you mirror the images to the intermediary container registry, you can move the intermediary container registry behind the firewall so that you can mirror the images to your private container registry. Then, you can configure your cluster to pull the Cloud Pak for Data software images from the private container registry. For more information, see Preparing to run IBM Cloud Pak for Data installs from a private container registry.

Operator privileges
Cloud Pak for Data uses the operator pattern to manage its workloads, which allows for a separation of concerns. Each instance of Cloud Pak for Data has its own operators that are installed in the operators project for the instance. The operators are explicitly granted access to control the Cloud Pak for Data workloads in the operands project and any tethered projects for the instance. The operators too are scoped to operate only within the set of projects associated with an instance and are not permitted to manage non-Cloud Pak for Data projects in the cluster.

The exceptions to this are the operators for the IBM Certificate manager, License Service, and scheduling service, which are cluster-scoped operators.

Installation roles and personas describes the minimum permissions needed to complete various installation tasks.