Restricting User-Controlled Kubernetes Pods

Required Role: Site Administrator

Cloudera Data Science Workbench 1.6.0 (and higher) includes three properties that allow you to control the permissions granted to user-controlled Kubernetes pods. An example of a user-controlled pod is the engine pod, which provides the environment for sessions, jobs, etc. These pods are launched in a per-user Kubernetes namespace. Since the user has the ability to launch arbitrary pods, these settings restrict what those pods can do.

They are available under the site administrator panel at Admin > Security under the Control of User-Created Kubernetes Pods section.

Do not modify these settings unless you need to run pods that require special privileges. Enabling any of these properties puts CDSW user data at risk.

Allow containers to run as root

Security best practices dictate that engine containers should not run as the root user. Previously, engines (v7 and lower) would briefly initialize as the root user and then run as the cdsw user. With engine v8 (and higher), engines now follow the best practice and run only as the cdsw user.

Use the following sections to determine whether you need to perform any steps to take advantage of this feature.

New Deployments - Version 1.6.0 (or higher)

Cloudera Data Science Workbench 1.6 (and higher) ships with engine v8 (and higher). On such deployments, all projects should already be using the latest engine versions. Therefore, this property should be left disabled.

Upgrades from Version 1.5.x (and lower) to 1.6.0 (or higher)

For deployments that have upgraded from Cloudera Data Science Workbench 1.5 (or lower), it is likely that projects on your deployment are still using base engine v7 (or lower). On such deployments, this property will be enabled by default.

Perform the following steps so that you can disable this property to take advantage of the security fix:
  1. Upgrade to Cloudera Data Science Workbench 1.6 (or higher).
  2. Test and upgrade all projects to engine v8 (or higher). If you are using custom engines, you will need to rebuild these engines using engine v8 or higher as the base image.
  3. Go to Admin > Security. Under the Control of User-Created Kubernetes Pods section, disable the Allow containers to run as root checkbox.

Allow "privileged" pod containers

Pod containers that are "privileged" are extraordinarily powerful. Processes within such containers get almost the same privileges that are available to processes outside the container. If this property is enabled, a privileged container could potentially access all data on the host.

This property is disabled by default.

Allow pod containers to mount unsupported volume types

The volumes that can be mounted inside a container in a Kubernetes pod are already heavily restricted. Access is normally denied to volume types that are unfamiliar, such as GlusterFS, Cinder, Fibre Channel, etc. If this property is enabled, pods will be able to mount all unsupported volume types.

This property is disabled by default.