Security risk analysis for Kubernetes resources

Kubesec is an open-source tool to perform security analysis of the Kubernetes resources(pods, deployments, etc.). Kubesec read the manifest resource file and conducted grading in terms of security aspects. The better security practices in the manifest file would result in higher grading by Kubesec and vice versa.
Developers can manually execute this lightweight tool to grade the security aspect of the resource. However, many organizations have this tool as a part of their CI/CD pipeline. Having this tool grade the Kubernetes resources during the CI/CD, the DevOps team prevents the vulnerable code from production.

Installation:

Kubesec is available in the following form:

  • Binary: Download binary from the official Github page.
  • Kubectl plugin
  • Kubesec as service
  • Container image
 

Usage as Binary:

If you use Kubesec as binary, then the command with the following syntax would read the YAML file and grade it.

Download and untar the binary file from the official Github page:

wget https://github.com/controlplaneio/kubesec/releases/download/v2.11.4/kubesec_linux_amd64.tar.gz
tar zxf kubesec_linux_amd64.tar.gz

Run static analysis on any manifest file.  Here I am using a YAML file called  pod-manifest-to-test.yml .

./kubesec scan pod-manifest-to-test.yml 

You can also run Kubesec on the running resources by running the Kubesec command as follow. Here I am running static analysis on a pod called pod-to-debug.

kubectl get pod -o yaml pod-to-debug |./kubesec scan –

 

Usage as Kubectl plugin:

For installation of Kubesec-scan follow the steps provided here.  Notice the result,  Score in GREEN, it provides the score and steps to improve the score. 

kubectl kubesec-scan pod pod-to-debug
scanning pod pod-to-debug in namespace default
kubesec.io score: 3
-----------------
Advise1. containers[] .securityContext .runAsNonRoot == true
Force the running image to run as a non-root user to ensure least privilege
2. containers[] .securityContext .capabilities .drop
Reducing kernel capabilities available to a container limits its attack surface
3. containers[] .securityContext .readOnlyRootFilesystem == true
An immutable root filesystem can prevent malicious binaries being added to PATH and increase attack cost
4. containers[] .securityContext .runAsUser > 10000
Run as a high-UID user to avoid conflicts with the host's user table
5. containers[] .securityContext .capabilities .drop | index("ALL")
Drop all capabilities and add only those required to reduce syscall attack surface

Using Kubesec as service:

You can curl to the Kubesec server to get your manifest file validated.  However, not everyone wants their code to go out of their network. To avoid this, Kubesec provides an alternative way of self-hosting Kubesec in its cluster. You may not prefer this if you consider your resource files confidential. 

curl -sSX POST --data-binary @<(kubectl get pod pod-to-debug -o yaml) https://v2.kubesec.io/scan
curl -sSX POST --data-binary @p.yml https://v2.kubesec.io/scan

Self-hosting the kubesec server within the cluster:

You can self-host the kubesec server if you do not want your files to leave the cluster. This can be done by creating the kubesec pod and exposing it within the cluster with cluster IP. This option is used by many as a part of their CI/CD pipeline. 

ps@kube-master:~$ k run kubescan --image=docker.io/kubesec/kubesec:v2 --expose --port 8080
service/kubescan created
pod/kubescan created

Performing requests to the service created within the service to validate our resource file(p.yml).

ps@kube-master:~$ curl -sSX POST --data-binary @p.yml http://kubescan:8080

Improving the score:

Here is a sample snippet from the result of the Kubesec scan command. This command performed a static analysis of the manifest file and highlighted the scope of improving the security. You may notice the following advice under the advice section of the result. 

 

kubesec results

 

  1. The first error is advising to make the root filesystem read-only by setting readOnlyRootFileSystem to True. 
  2. The second error is advising to enforce the container user as a non-root user. This is done by setting runAsNonRoot to True.
  3. The tried error advises running the container with user ID > 10000. This is done by setting runAsUser > 10000.

Here is the changed file look like, 

kubesec

 

After making these changes, the previous advice would move to the passed section. Similarly other advice can be applied to improve the score. Note that, it is not always possible to pass all the tests due to organizational policies. 

0 0 votes
Please, Rate this post
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x
Scroll to Top