What you'll learn:

  • Deploy KubeArmor on Google Kubernetes Engine (GKE)
  • Create a MultiUbuntu Microservice Deployment
  • Apply KubeArmor Policy (ksp) to block the malicious app behavior
  • Create a YAML policy to block (or use an existing one to apply) the action
  • Check the logs for applied KubeArmor System Policy

What you'll need:

A Google Cloud Platform project to create GKE Cluster

Setup and Requirements

If you’ve not deployed KubeArmor in your GKE already then worry not, just enter the following one command and it should be running well.

kubectl apply -f https://raw.githubusercontent.com/kubearmor/KubeArmor/master/deployments/GKE/kubearmor.yaml


Once deployed you can check the status of pods using the below command:

kubectl -n kube-system get pods -l kubearmor-app=kubearmor

Create MultiUbuntu Microservice Deployment:

To deploy the sample microservice application we’ve combined all the deployment into a single YAML so all you need is to just apply the below command:

kubectl apply -f https://raw.githubusercontent.com/kubearmor/KubeArmor/master/examples/multiubuntu/multiubuntu-deployment.yaml


You can see the deployment running successfully in multiubuntu namespace and can verify on your own cluster using the same command:

kubectl get pod -n multiubuntu

Example #01: Block process execution:

Let’s take the first example to block process execution in this case we’re trying to block sleep command. Below you can see the policy.

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: ksp-group-1-proc-path-block
  namespace: multiubuntu
spec:
  severity: 5
  message: "block the sleep command"
  selector:
    matchLabels:
      group: group-1
  process:
    matchPaths:
    - path: /bin/sleep # try sleep 1 (permission denied)
  action:
    Block

Before going into that let’s compare the 2 given scenario and try to figure out the difference. Don’t worry we’ll also describe the difference in the last.

Scenario #01: Executing sleep 3 command without applying the above policy

We need to execute inside the pod into consideration which is ubuntu-1-deployment-random-string

kubectl exec -it --namespace multiubuntu ubuntu-1-deployment-6d897796-pjv44 -- bash
[email protected]:/# sleep 3

Scenario #02: Now let’s apply the policy and see the difference in execution

kubectl apply -f https://raw.githubusercontent.com/accuknox/KubeArmor/master/examples/multiubuntu/security-policies/ksp-group-1-proc-path-block.yaml
kubectl exec -it --namespace multiubuntu ubuntu-1-deployment-6d897796-pjv44 -- bash                                                                 
[email protected]:/# sleep 3

Analysis: Comparing two scenarios we came to the conclusion that the above policy was able to block sleep command on ubuntu-1-deployment successfully.

Now the question is how I can get the logs, the source of truth if it was blocked or not?

But before that let’s look into one more example to understand more clearly.

Example #01: Block file access:

Another example is to block a specific directory and the subdirectories which contain sensitive information and we wanted to protect it. So let’s see how it can be achieved.
In this example, we’ll leverage the below policy to demonstrate file access restriction

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata: 
  name: ksp-ubuntu-5-file-dir-recursive-block
  namespace: multiubuntu
spec: 
  severity: 9
  selector: 
    matchLabels: 
      container: ubuntu-5
  file: 
    matchDirectories: 
    - dir: /credentials/ # try 'cat /credentials/password' (permission denied)
      recursive: true
  action: 
    Block

Let’s repeat the above scenario in ubuntu-5-deployment

kubectl get pod -n multiubuntu
kubectl exec -it --namespace multiubuntu ubuntu-5-deployment-77f48cfcc7-f78dt -- bash
[email protected]:/# cat /credentials/password

You should be able to see the sensitive file

Now let’s repeat the same step but after applying the above policy.

kubectl apply -f https://raw.githubusercontent.com/kubearmor/KubeArmor/master/examples/multiubuntu/security-policies/ksp-ubuntu-5-file-dir-recursive-block.yaml
kubectl exec -it --namespace multiubuntu ubuntu-5-deployment-77f48cfcc7-f78dt -- bash
[email protected]:/# cat /credentials/password

You can see Permission denied

Checking Audit Logs:

Now let’s get back to the point where we wanted to know how I can get into the logs what policies have been denied. Not only deny we can use other actions as well

Don’t forget to look into Security Policy Specification for Containers for KubeArmor Policy Specification

To check for audit logs, we need to find the common node where KubeArmor pod and our sample deployment pod is running

To do it first we need to find the node where MultiUbuntu pods are running

kubectl get pod -n multiubuntu -o wide

Take a note of node, it may vary in your scenario. We’ve highlighted it in red

Now describe the node and make note of KubeArmor pod there, to make things clear I’m doing a grep on top of the command

kubectl describe node gke-accuknox-qa-e2e-accuknox-qa-e2e-p-8889bb4d-qmcn | grep kubearmor-

kubectl describe node gke-accuknox-qa-e2e-accuknox-qa-e2e-p-8889bb4d-qmcn | grep kubearmor-

kubectl exec -it -n kube-system kubearmor-6nh7j -- cat /tmp/kubearmor.log


This is the sample KubeArmor log you will get:

{
  "timestamp": 1635327224,
  "updatedTime": "2021-10-27T09:33:44.824028Z",
  "hostName": "gke-accuknox-qa-e2e-accuknox-qa-e2e-p-8889bb4d-qmcn",
  "namespaceName": "multiubuntu",
  "podName": "ubuntu-1-deployment-6d897796-pjv44",
  "containerID": "79a0664f6faba7875133c5b2221465447396627c50d7baf6422f8922241f7783",
  "containerName": "ubuntu-1-container",
  "hostPid": 3480296,
  "ppid": 220,
  "pid": 231,
  "uid": 0,
  "policyName": "ksp-group-1-proc-path-block",
  "severity": "5",
  "message": "block the sleep command",
  "type": "MatchedPolicy",
  "source": "/bin/bash",
  "operation": "Process",
  "resource": "/bin/sleep 3",
  "data": "syscall=SYS_EXECVE",
  "action": "Block",
  "result": "Permission denied"
}

Finally, Now I don’t need to worry about someone trying to access my password since I can use KubeArmor to do all the works.

Conclusion: