Update Containers to Run as Non-root

Previous releases of CloudOps for Kubernetes allowed users to run MySQL, ActiveMQ, and Self Managed Commerce containers as the root user. Since CloudOps for Kubernetes release 2.11.x support was added for running the containers as a non-root user.

The benefit of using containers that run as non-root is improved security.

important

Starting with CloudOps for Kubernetes release 3.1.x, only non-root containers are supported, and Elastic Path docker Git repository release 4.2.x or higher is required. For release compatibility information, see Compatibility of CloudOps for Kubernetes.

The Elastic Path docker Git repository is available to Self Managed Commerce licensed users at code.elasticpath.com.

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 see Upgrade Overview.

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 one of the below

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

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

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.

important

Starting with CloudOps for Kubernetes release 3.1.x, only non-root containers are supported, and Elastic Path docker Git repository release 4.2.x or higher is required. For release compatibility information, see Compatibility of CloudOps for Kubernetes.

An Self Managed Commerce environment is composed of the following:

• An ActiveMQ deployment.
• (Optional) A containerized 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).

Merge the newer docker code

Obtain release 4.2.x or newer from the Elastic Path docker Git repository and merge that into your hosted copy of that repository. The Elastic Path docker Git repository is available to Self Managed Commerce licensed users at code.elasticpath.com.

Rebuild All Container 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

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.

1. 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

2. 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

3. 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.

1. 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.
   • In CloudOps for Kubernetes releases prior to 3.1.x set the containerUser parameter is set to non-root. This parameter is removed in CloudOps for Kubernetes releases 3.1.x, when support for root containers was removed.

2. 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.

1. 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.

2. The services use the updated non-root image once the deploy-or-delete-commerce-stack Jenkins job is successfully finished.