Update Containers to Run as Non-root · CloudOps for Kubernetes

note

These steps can be done at any point after updating to CloudOps for Kubernetes v2.11.x.

CloudOps for Kubernetes release 2.11 introduces the option to run MySQL, ActiveMQ, and Self Managed Commerce containers with a non-root user. The benefit of using containers that run as non-root is improved security. This option is only available with container images built with Elastic Path Docker repository release 4.2.x or newer. To continue to run containers as root, you must use images built with Elastic Path Docker release 4.1.x or earlier.

Prerequisite

The steps in this document only apply and can only be performed after you have upgraded to CloudOps for Kubernetes release 2.11.x or higher. For information about upgrading from release 2.10.x to release 2.11.x see Update from version 2.10.0.

Checking The Current User

Below are two ways to check which user your containers currently run as.

Check the container image

If you are not sure if your images were built to use the non-root user you can check the image build logs for any mentions of the non-root user, app_runner, or you can run the image with the docker command below, replacing IMAGE_ID with the ID of the image you want to check.

docker run -it <IMAGE_ID> /bin/bash

Then print the current user account from inside the container with the command.

whoami

Check the Kubernetes Security Context

To see if an existing Kubernetes Deployment has a non-root security context applied, run the following command, replacing DEPLOMENT_NAMESPACE and DEPLOYMENT_NAME with the appropriate values.

kubectl -n <DEPLOMENT_NAMESPACE> get deployment <DEPLOYMENT_NAME> -o json | jq '.spec.template.spec.securityContext'

This should print out the portion of the deployment that defines the security context.

If the output is

`{}`

The security context was not defined and the deployment is run as root by default.

If the output is

{
  "fsGroup": 10001,
  "runAsGroup": 10001,
  "runAsNonRoot": true,
  "runAsUser": 10001
}`

The security context is set to run as the non-root user.

If the output is

{
  "fsGroup": 0,
  "runAsGroup": 0,
  "runAsNonRoot": false,
  "runAsUser": 0
}`

The security context is set to run as root.

Any other output indicates an error and requires further investigation.

Updating Existing Deployments

The following steps describe how to update existing Self Managed Commerce deployments to use containers that run as non-root. To make this change you must have completed the upgrade to CloudOps for Kubernetes release 2.11.x or higher, and you must use the Elastic Path Docker release 4.2.x or higher.

An Self Managed Commerce environment is composed of the following:

An ActiveMQ deployment.
(Optional) A MySQL deployment.
A data-pop-tool job that creates and populates the Self Managed Commerce database.
The Self Managed Commerce application stack.

These deployments are independent of each other and do not have to be updated all at once (ie. if your Self Managed Commerce deployment was updated to run as non-root you do not have to immediately update the corresponding ActiveMQ and MySQL deployments).

For instructions on updating from 2.10.x, follow the general instructions on updating the cluster in the Upgrading CloudOps for Kubernetes documentation.

Rebuild All Docker Images

To use the non-root Self Managed Commerce containers, rebuild all Elastic Path container images using the Elastic Path Docker release 4.2.x or higher.

tip

Use a unique and relevant value in the imageTag parameter.

The build-selected-docker-images Jenkins job provides a convenient way to rebuild all of the images. The following parameters must be set to true to rebuild all the images to run as non-root:

buildActivemq
buildMysql
buildBase
buildCortex
buildSearch
buildBatch
buildIntegration
buildCm
buildDatasync
buildDatapop
buildMock
infoPage

Updating the ActiveMQ container deployments

warning

You must update the ActiveMQ deployment architecture before migrating ActiveMQ to use non-root containers. If you do not update the ActiveMQ deployment architecture before switching to the non-root user, then the process to switch to the non-root user and the ActiveMQ deployments will fail. For more information on updating the ActiveMQ deployment architecture see the Update the ActiveMQ Deployments documentation.

Repeat the following steps for each of your ActiveMQ deployments. These steps are required to complete your previous ActiveMQ migrations that are currently using the root user in their containers to using the non-root user in their containers.

Create a shell session inside your ActiveMQ deployment. Replace the <activemq_namespace> value with the namespace that your ActiveMQ deployment is in.

activemq_pod=$(kubectl get pods -n <activemq_namespace> -l app="ep-activemq" -o json | jq -r '.items[].metadata.name')
kubectl exec -it ${activemq_pod} -n <activemq_namespace> /bin/bash

Modify the KahaDB folder so that the new non-root user is the owner and exit the session.
```
chown -R 10001:10001 /ep/efs/activemq/kahadb/
exit
```
Build the create-or-delete-activemq-container Jenkins job.

Use the kubernetesNickname parameter set to the namespace of the previously deployed ActiveMQ deployment and the parameters that you previously used to run the create-or-delete-activemq-container Jenkins job. Ensure that:
- The cloudOpsForKubernetesBranch parameter is set to the new release branch.
- The dockerImageTag is set to the same value as the imageTag parameter from the Jenkins job build-selected-docker-images with release 4.2.x or newer of the Elastic Path Docker repository.
- The containerUser parameter is set to non-root.

Updating the MySQL container deployments

Repeat the following steps for each of your MySQL container deployments to use the new non-root images in the existing MySQL container deployments.

Build the create-or-delete-mysql-container Jenkins job.

Use the kubernetesNickname parameter set to the namespace of the previously deployed MySQL container deployment and the parameters that you previously used to run the create-or-delete-mysql-container Jenkins job. Ensure that:
- The cloudOpsForKubernetesBranch parameter is set to the new release branch.
- The imageTag is set to the same value as the imageTag parameter from the Jenkins job build-selected-docker-images.
- The containerUser parameter is set to non-root.
The service uses the updated non-root image once the create-or-delete-mysql-container Jenkins job is successfully finished.

Running the Data-pop-tool

When running the Jenkins job run-data-pop-tool to populate a Self Managed Commerce database, make sure to set the containerUser parameter to the appropriate value.

Set the containerUser parameter to root if the data-pop tool was built with release 4.1.x or earlier of the Elastic Path Docker repository.
Set the containerUser parameter to non-root if the data-pop tool was built with Release 4.2.x or newer of the Elastic Path Docker repository.

Updating the Self Managed Commerce Stack

Repeat the following steps for each of your Self Managed Commerce stacks. These steps are required for the new non-root images to be used by existing Self Managed Commerce stacks.

Build the deploy-or-delete-commerce-stack Jenkins job.

Use the kubernetesNickname parameter set to the namespace of the previously deployed Self Managed Commerce stack and the parameters that you previously used to run the deploy-or-delete-commerce-stack Jenkins job. Ensure that:
- The cloudOpsForKubernetesBranch parameter is set to the new release branch.
- The dockerImageTag is set to the same value as the imageTag parameter from the Jenkins job build-selected-docker-images.
- The containerUser parameter is set to non-root.
The services use the updated non-root image once the deploy-or-delete-commerce-stack Jenkins job is successfully finished.

Running Deployments as Root

If you are not prepared to start running containers with the non-root user, it is still possible to run deployments as root even after updating to CloudOps for Kubernetes release 2.11.x.

To use the root Self Managed Commerce containers, continue to build all Elastic Path container images using the Elastic Path Docker release 4.1.x.
Make sure to set the containerUser parameter to root for all deployments.