Basic security features on Red Hat OpenShift Container 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.

• Uses Red Hat CoreOS as the immutable host operating system.
• Draft comment: omima.hassan@ibm.com
  Only applicable in 3.3
  Provides stronger platform security with FIPS (Federal Information Processing Standard) compliant encryption (FIPS 140-2 Level 1). For more information, see https://www.ibm.com/docs/en/cloud-paks/cp-data/4.6.x?topic=considerations-services-that-support-fips
• Uses the Node Tuning Operator, which provides opportunities to further reduce privilege requirements in the security context constraints (SCC). For more information, see Using the Node Tuning Operator.
• Supports encrypting data that is stored in etcd, which provides extra protection for secrets that are stored in the etcd database. For more information, see Encrypting etcd data.
• 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.
• Enables SELinux as mandatory on Red Hat OpenShift Container Platform.

Service accounts and roles

Guardium Insights runs in a separate namespace or project on the OpenShift cluster. In the OpenShift project, Guardium Insights creates service accounts and RBAC role bindings for pods to use within that namespace.

• No cluster level access is permitted. All roles impose a restriction to work within that namespace only.
• Two roles are created: cpd-admin-role and cpd-viewer-role. These roles allow Guardium Insights to ensure that the principle of least privilege can be applied even within the same namespace.
• Twenty service accounts are created. anyuid SCC is bound with the following service accounts: *"mongodb-kubernetes-operator"* , *"mongodb-database"* privileged SCC is bound with "account-staging-staging-db2" service account.
• The default service account that is automatically created in every OpenShift project is not granted any RBAC privileges; that is, no roles are bound.
• The expectation is that the default service account is used for user workloads such as Notebooks and Python jobs. It will not be allowed to perform any kind of actions inside the namespace.
• The default service account is associated with the restricted security context constraints (SCCs). However, some add-on services might still need custom SCCs, for example to support IPCs. For more information, see Security context constraints in the IBM® Cloud Platform Common Services documentation.

Service UIDs

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 Guardium Insights is installed.

• The Db2 as a service restricted SCC reserves UID 500.
• The IBM Db2 SCC reserves the following UIDs: 500, 501, 505, 600, 700, and 1001.
• The Watson Knowledge Catalog SCC reserves UID 10032.

• 999 and 2000

For details on which services use these SCCs, see https://ibmdocs-test.dcs.ibm.com/docs/en/SSWSZ5_3.2.x_test?topic=features-custom-security-context-constraints-services.

Security hardening

Security hardening is enforced on Guardium Insights on Red Hat OpenShift. The following security hardening actions are taken:

• Only nonroot processes are run in containers. The UIDs of the processes are in the OpenShift Project's pre-defined range only, enforced by the use of the restricted SCCs. The restricted SCC does not allow running containers as root.
  Attention: Some services still do require a fixed UID. Such services use a custom SCC for that purpose.
• Cluster Admin privileges are not required for Guardium Insights workloads at runtime. Cluster Admin authority is needed only to set up projects and custom SCCs (and only for the services that do need them). Service accounts in each Guardium Insights instance are granted privileges that are only scoped within their OpenShift project.
• Guardium Insights users are typically not granted OpenShift Kubernetes access, and even if they are, it would be only for the express purpose of installing or upgrading services inside their assigned OpenShift project.
• Strict use of service accounts with RBAC privileges is enforced, and the least privilege principle is applied. Guardium Insights ensures that any pod that is running user code (such as scripts or analytics environments) is not granted any RBAC privileges.
• No host access is necessary for Guardium Insights workloads at runtime. This restriction is enforced by the SCCs. There is no access to host paths or networks.
• All pods have restricted resource consumption. Pod resource requests and limits are set for each pod, which restricts the consumption. This approach helps protect against noisy neighbors that cause resource contention.
• Reliability gauges (liveness and readiness probes) are present for each pod to ensure that the pods are working correctly.
• For consumption monitoring, each of the pods on Guardium Insights is annotated with metering annotations to uniquely identify add-on service workloads on the cluster.

Prescriptive security practices during installation

You don't need to SSH to an Openshift cluster's node. The OpenShift oc command-line interface and the cloudctl command-line interface are used to deploy and manage the Guardium Insights operator and and its services.

You can install the software on a cluster that is connected to the internet or a cluster that is air-gapped.

Installing Guardium Insights on clusters that are connected to the internet

It is highly recommended that you use the cloudctl utility from a client workstation to download the CASE packages and mirror images from the IBM Entitled Registry and other public container registries into your private container registry.

Installing Guardium Insights on air-gapped clusters

Guardium Insights supports mirroring of images to your private container registry. This procedure does not require that your private container registry and Red Hat OpenShift Container Platform cluster are able to access the internet. You are able to download the CASE packages and mirror images by using the cloudctl utility from a bastion node. If the bastion node does not have a direct access to the private container registry, then an intermediary container registry can be used. By using the intermediary container registry, you are able to mirror the images first on the bastion node. You need to make sure that your private container registry is accessible from your internal network, but not from public internet. Therefore, your Red Hat OpenShift Container Platform cluster would need to be configured to pull from the private container registry. That way you are able to install the Guardium Insights operators and services without access to the internet.

Namespace scope and Operator privileges

Guardium Insights uses the Operator pattern to manage its workloads, which allows for a separation of concerns. That way Operators that are resident in one central namespace are granted access to manage the Guardium Insights Service workloads in multiple different "instance" namespaces. Users in those instance namespaces can thus be granted far lesser privileges, scoped within that namespace. Operators too are scoped to operate only within these specific namespaces and are, by design, not permitted to manage non-Guardium Insights namespaces in the cluster.

You need the following scope and user privileges.

• To install the Operator Catalog Source, you need a Red Hat OpenShift Container Platform user, with privileges in the openshift-marketplace namespace.
• To create an "own Namespace" mode for the OperatorGroup and any Subscriptions for the needed Operators, you need users with privileges in ibm-common-services.
  Note: For security reasons, the "All Namespaces" mode for the OperatorGroup is not recommended.
• To restrict the namespaces that the Guardium Insights Operator has authority over, use the IBM Cloud Pak® foundational services Namespace-scope Operator. For more information, see Authorizing foundational services to perform operations on workloads in a namespace.
• To create custom resources to deploy the individual Guardium Insights services or to upgrade or scale them postinstallation, you need users with Project admin privileges in the "instance" namespaces.

Cluster admin responsibility

Cluster Admins are expected to manage the OpenShift cluster and prepare it for use by the Guardium Insights Services. Such tasks include:

Node tuning and machine pool configurations for kernel settings and cri-o settings (such as pids-limit, ulimit).

Only for services that need them.

Set up the image content source policy and any secrets.

The setup is done to pull images from the private container registry.

Create OpenShift Projects.

For the IBM® Guardium Insights foundational services and Operators.

For the instances of Guardium Insights.

Configure the namespaces.

Define namespace quotas and Limit Ranges.

Grant access of the Guardium Insights Admins to specific instance namespaces.

Create custom SCCs.

Only for services that need them.

Storage installation and configuration.

Storage that is used by the workloads.

Securely manage OpenShift.

Handle encryption and auditing as well as other operations such as adding nodes, replacing nodes and others.