RodrigTech

CKS Verifying platform binaries/K8s Security

—

by

rodrigtech
in

Today I felt like we should take a more tailored approach to some security features in general that also tie into kubernetes security specialist exam.

Verifying platform binaries

  • Any download that you are performing likely will include hash list such as md5/sha256 and those keys ensure the integrity of the software you are downloading has not been altered
  • This is in general good security practice at home and at work due to the ability to change or create a cloned site or the threat of interception of the file

So for today I wanted to take a dive into the tool Kube-Score this will be running on my local microk8s cluster and I had to actually verify the binary that was downloaded so as part of my own security of tools I’m running through this as well.

Navigate to https://github.com/zegl/kube-score if you’d like to follow this project and contribute

So going for the releases to the binaries that are publicly listed we see a file checksum.txt that will contain the binaries source of truth.

Navigate to your linux machine in my case if your running mac you can use brew

wget -O https://github.com/zegl/kube-score/releases/download/v1.16.1/kube-score_1.16.1_linuxarm64.tar.gz

So now the file will download to our local machine and then we want to run the following command

sha256sum kube-score_1.16.1_linuxarm64.tar.gz

As part of the check sum and version to verify this is authentic

Always verify what you are downloading this is one factor to verify authenticity luckily for us kube-score is available as web interface at www.kube-score.com.

You simply paste your YAML file and the output will give you findings on what can improve.

So let’s make it analyze our file below

apiVersion: v1
kind: Pod
metadata:
  namespace: microservice
  name: micro-front-end
spec:
  containers:
  - image: alpine:3.17
    name: micro-front-end
    securityContext:
       privileged: false
       readOnlyRootFileSystem: true

After running our scan our output looks like we will need some work

Only false positive at least taking a look at this is that ReadOnlyRootFileSystem to true and I did have this set as the YAML above perhaps I’ll have to take a look back at it.

Things that come to mind in the supply-chain at this point to what you’ll need to verify is the container image (should have a defined version) best practice is to not have a “latest” tag.

Consider when the container image is created was it our organization that did this? When was the container image scanned? Do we have policies in place such as deployment gates for criteria to be met prior to release?

The best part about shift left is your moving the control aspect of the code to production and the security that is involved with that.