In this tutorial we will learn about Process Whitelisting, which is part of Alcide Runtime Security (ART). We will see how DevOps and/or SecOps teams can enable the detection of unauthorized or compromised processes running on pods in their kubernetes clusters.

Alcide Runtime (ART)

For this tutorial you will need a Kubernetes cluster with enough permissions to deploy resources into it.

Alcide Code-to-production security

In order to implement Alcide Runtime Security features, we will need to onboard your Kubernetes cluster into your Alcide Cloud Account

  1. Login to your account:
  2. On the left hand side menu, click on Create Data Center/Cluster
  3. Follow the steps in the UI wizard.

At this point you should be able to see your cluster, worker nodes, and workloads, in the Infrastructure View and the application components in your Application View

Alcide Code-to-production security

For this tutorial, we will leverage GitHub Actions to do our build actions generating the process whitelist checksum.

Since GitHub Actions run automatically when you push to a repository, you'll have to create a new repository to add the action to. Please refer to the instructions here.

Of course, if you prefer to use an existing repository that is possible as well.

Create the following file named in the myapp folder:

from flask import Flask
app = Flask(__name__)

def hello_world():
    return 'Hello, World!'

if __name__ == '__main__':, host='')

This is a simple Python web server that returns Hello World when opened.

Create the following file named Dockerfile in the root of the new repository:

FROM ubuntu:xenial

LABEL maintainer=""

RUN apt-get update -y && \
    apt-get install -y python-pip python-dev


COPY my-app/ /

RUN pip install Flask

### This is the Alcide whitelist generator integration ###

ADD /generator

RUN chmod +x /generator &&\
    /generator -k ${ALCIDE_PROCESS_WHITELIST_HASH_KEY} -i /usr/bin/python &&\
    rm -f generator
### End of integration section ###

ENTRYPOINT [ "python" ]

CMD [ "/" ]

This Dockerfile sets up the image for running the Python Flask application and generates a white list entry for the process we want to allow this container to run. In this case, we create a hash for /usr/bin/python because this image will run a python web server.

Create the following file named main.yml file in the .github/workflows directory in your repository:

name: CI

# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the master branch
    branches: [ master ]

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
  # This workflow contains a single job called "build"
    # The type of runner that the job will run on
    runs-on: ubuntu-latest

    # Steps represent a sequence of tasks that will be executed as part of the job
    # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
    - uses: actions/checkout@v2

    # Runs a set of commands using the runners shell
    - name: Run a multi-line script
      run: |
        docker login --username ${GITHUB_ACTOR} --password ${{ secrets.DOCKER_PASSWORD }}
        docker build -t ${GITHUB_ACTOR}/my-app:latest .
        docker push ${GITHUB_ACTOR}/my-app:latest

Add two secrets DOCKER_PASSWORD and ALCIDE_PROCESS_WHITELIST_HASH_KEY to the GitHub secrets.

  1. The DOCKER_PASSWORD is the password of to your docker account (we recommend you use an access token instead of your main password) so the image can be uploaded to the public Docker hub.
  2. As ALCIDE_PROCESS_WHITELIST_HASH_KEY we will start with an invalid key so the workload will get flagged as unauthorized - enter 123abc.

By saving the workflow yaml, GitHub will automatically start running your workflow. Navigate to the output by clicking on the > Actions header item on your main repository page.

Overview of running workflow

Now that we have a Docker image built and uploaded to DockerHub, we can run a kubernetes workload on the cluster you have connected to your Alcide Cloud environment.

# create an environment variable with your username so you can copy and paste the kubectl commands
export USERNAME=<yourusername>
# spin up our unauthorized workload
kubectl run --generator=run-pod/v1 process-whitelist-workload --image=${USERNAME}/my-app:latest

When we go to the Infrastructure overview in Alcide Cloud, we will see the following alert (may take 5 to 10 minutes).

Unauth workflow error

Let's delete the workload and re-build the Docker image with the correct key.

kubectl delete process-whitelist-workload

The correct key for your organization can be found within the Alcide Cloud platform at Settings/Keys/Process whitelist under hash keyShow key (direct url: We will use this key to generate the whitelist and later validate its authenticity in runtime.

Update the existing GitHub secret named ALCIDE_PROCESS_WHITELIST_HASH_KEY with the new value.

To kick off the build process, make an arbitrary change (like creating a and push it to the repository. Under > Actions we will see a new build job starting.

Overview of running workflow

Execute the following command again:

kubectl run --generator=run-pod/v1 --image=${USERNAME}/my-app:latest

We will see the pod workload reappearing in Alcide Cloud without any alert, like so:

Auth workflow

Let's wreak some havoc and simulate an attack on the running pod and a hacker getting shell access to the pod. We won't actually trigger a Flask vulnerability - although you could - but rather use kubectl exec to spawn a bash terminal in the container.

kubectl exec -ti process-whitelist-workload bash

Since we didn't generate a whitelist entry for bash, once we do this, the workload should get flagged in Alcide Cloud. Again, this may take several moments to show up.

Another unauth workflow error

You see that Process Whitelisting is useful both for detecting both unauthorized/compromised Docker container images as well as hackers compromising the running pod.

That's all folks! Get rid of the pod by running the following command:

kubectl delete process-whitelist-workload

In this codelab we covered:

Alcide Code-to-production security