add support for crown jewel policies

[Ankurk99]

Description

Add support for generating lenient policies protecting sensitive assets (mount points here)

Problem
Currently we were discovering least-permissive security policies using Discovery Engine. Ideally these policies were designed to get us a Zero-trust security posture by only allowing the binaries which are essential for running any particular application. But the issue with these types of policies is that it's very difficult to actually create an exhaustive policy which contains all the necessary binaries allowed. If we miss even a single important binary, that would have caused the whole application to crash in worst case.

Solution
The aim of this PR is to identify the crown-jewels or the list of important assets which when protected can give us a fairly good security posture for the whole application.

PR changes
This PR identifies the paths mounted by any application and check if they are actually being used. We then create a "Crown-jewel" lenient policy which only allows the access of the particular mount paths by a particular binary based on the actual usage and deny access from others.

Example of a Crown jewel policy:

 - apiVersion: v1
  kind: KubeArmorPolicy
  metadata:
    name: autopol-assets-vault
    namespace: default
  spec:
    action: Allow
    file:
      matchDirectories:
      - action: Block
        dir: /vault/data/
        recursive: true
      - dir: /vault/data/
        fromSource:
        - path: /bin/vault
        recursive: true
      - dir: /
        recursive: true
      - dir: /vault/config/
        recursive: true
      - action: Block
        dir: /home/vault/
        recursive: true
      - dir: /home/vault/
        fromSource:
        - path: /bin/sh
        recursive: true
    message: Sensitive assets and process control policy
    network: {}
    process:
      matchPaths:
      - path: /bin/sh
      - path: /bin/vault
      - path: /bin/busybox
    selector:
      matchLabels:
        app.kubernetes.io/instance: vault
        app.kubernetes.io/name: vault
        component: server
        helm.sh/chart: vault-0.24.1
    severity: 7

Here in the above policy, access to the dir: /home/vault/ is only allowed by /bin/sh and /vault/data/ by /bin/vault. The other mount path /vault/config/ is not being used, so it's set to Block. As Vault is using Alpine image, that's why we see the process /bin/busybox being used (will be a symlink to system packages).

ref: #715

[rajaSahil]

I can see this channel also getting initialized through init, can you explain the flow here?

[rajaSahil]

Why are we using pod name?
And how mount paths from observability data is utilized?

[Ankurk99]

Why are we using pod name?

We are checking the resource to be pods (instead of deployment/statefulset etc.) because pod labels contains all the labels for that resource which might be missing in other workload (say statefulset for eg.).
Here below is an example of a vault statefulset:

Pod Labels:

Labels:     app.kubernetes.io/instance=vault
                  app.kubernetes.io/name=vault
                  component=server
                  controller-revision-hash=vault-5f4c59685d
                  helm.sh/chart=vault-0.24.1
                  statefulset.kubernetes.io/pod-name=vault-0

Statefulset labels:

  Labels:           app.kubernetes.io/instance=vault
                    app.kubernetes.io/name=vault
                    component=server
                    helm.sh/chart=vault-0.24.1```

[Ankurk99]

And how mount paths from observability data is utilized?

PTAL at #739 (comment), if anything is unclear please comment.

[Ankurk99]

The code implementation can be summarized as below:

• func getProcessList() : Get the list of running processes from observability data and store it in an array processList[]
• func getVolumeMountPaths(): Get all the volume path from the k8s cluster (looking for pods matching the labels) and store it in array mountPaths[]
• func usedMountPath(): Get the list of used mount paths from observability data and store the info together in sumResponses[] string with fromSource make(map[string]string)
• func accessedMountPaths(): Match used mounts paths with actually accessed mount paths. Here we compare the mount points found in getVolumeMountPaths and usedMountPaths, if they match then keep them otherwise ignore those mount paths.

All the required info about the mount points which are mounted and actually being used are used to create a crown jewel policy using getCrownjewelPolicy() func.

• func getCrownjewelPolicy() calls createCrownjewelPolicy()

• func createCrownjewelPolicy(): Assigns Actions (for eg: block Allow for matching mount paths and Block by default) and ignores duplicate fromSource values. It then calls buildSystemPolicy() func to generate the crown jewel policy.

• func buildSystemPolicy(): has the template to create the policy. Currently, severity and message are set by default but they can be assigned from the func arguments.

• func getFilteredPolicy(): filters to check the namespaces to be ignored and calls systempolicy.UpdateSysPolicies(policies)

• func systempolicy.UpdateSysPolicies(): Inserts the system policies to DB (sqlite or MYSQL)

• func WriteSystemPoliciesToFile(): all the crown jewel policies are saved to a file named "kubearmor_policies_sensitive"

The logic for updating the crown jewel policies to the DB is the same as was for other system policies.