KubeArmor version release v0.3

Default Security Posture (@daemon1024)

One of the tenets of achieving Zero Trust stature requires one to set the workloads in "least-permissive mode". Setting up least-permissive mode can be fraught with challenges and it is important that the tooling supports gradual upgrade to the least-permissive mode. One of the important tool is setting audit or dry-run mode for the policies before one can use the block/deny mode.

KubeArmor supports deny-by-default mode wherein one can specify what actions are allowed and everything else get denied. However, this mode can be a fatal for security ops folks since it has the possibility to bring down the application. While KubeArmor always supported an audit mode, version 0.3 release PR#630 & PR#595 brings in a more streamlined approach for handling this mode.

• It is now possible to set the global mode for default posture separartely for file/process, capabilities and network operations.
• Further, it is now possible to set the default posture at namespace level for file/process, capabilities and network operations.

An example of setting the default network posture to audit mode for namespace=multiubuntu.

~❯❯❯  kubectl annotate ns multiubuntu kubearmor-network-posture=audit --overwrite
namespace/multiubuntu annotated
~❯❯❯  kubectl describe ns multiubuntu
Name:         multiubuntu
Labels:       kubernetes.io/metadata.name=multiubuntu
Annotations:  kubearmor-network-posture: audit
Status:       Active

ProcessName, ParentProcessName fields in all telemetry events (@nam-jaehyun)

KubeArmor PR#632 now generates an appropriate processName and parentProcessName in the context of every event. Earlier Kubearmor had several issues especially in cases where the binaries could be symbolic links, relative paths used to invoke the binary. With version 0.3 kubearmor now leverages LSM hook kprobe security_bprm_check to get an absolute binary path for the executable.

{
  "Timestamp": 1648788707,
  "UpdatedTime": "2022-04-01T04:51:47.854366Z",
  "ClusterName": "default",
  "HostName": "ubuntu2004-vagrants",
  "NamespaceName": "explorer",
  "PodName": "knoxautopolicy-f69c455-9824f",
  "ContainerID": "60d9a043cdb09fc99d26bfe22d1d0961e981f407b5d747626f14ad01515a41e8",
  "ContainerName": "knoxautopolicy",
  "HostPID": 1379898,
  "PPID": 404,
  "PID": 414,
  "PolicyName": "autopol-system-4153385364",
  "Severity": "1",
  "Type": "MatchedPolicy",
  "Source": "/usr/bin/bash",
  "Operation": "Process",
  "Resource": "/usr/bin/chmod",
  "Data": "syscall=SYS_EXECVE",
  "Action": "Block",
  "Result": "Permission denied",
  "ContainerImage": "docker.io/nyrahul/knoxautopolicy:dev@sha256:3d696f1650ac8b9932cb975c98f69a406b12fc8514f0b0ad39b19c8dfd2add8f",
  "ParentProcessName": "/usr/bin/bash",
  "ProcessName": "/usr/bin/chmod"
}

Note the ProcessName and ParentProcessName fields in the json fields.

Support for Virtual Machines (@seswarrajan)

Branching and Release Strategy (@Ankurk99, @nyrahul)

KubeArmor is maturing both in terms of feature set and in terms of managing release procedures. With version 0.3 #590 we are now following a streamlined branching and release strategy. Some key highlights are:

1. Have main as our bleeding edge branch where things might be unstable.
2. Release kubearmor every month or two with a new release version and release logs ... the versioning will be v0.2, v0.3 and so on ... If there are any backports, those will be handled as part of release-candidates version .. for e.g. v0.2-rc1, v0.2-rc2 and so on
3. Every version (including release candidates) will have a tag created.
4. Every version (not including release candidates) will have a branch name corresponding to the version name (for e.g., v0.2).
5. KubeArmor dockerhub image will have following: a. kubearmor/kubearmor:latest pointing to main branch image b. kubearmor/kubearmor:v0.2 ... version specific image ... release candidates will update this image itself for the corresponding version c. kubearmor/kubearmor:stable ... a version will be upgraded to stable version only after enough due diligence (what this due diligence is would be considered in the future) .. for e.g., we might have v0.2, v0.3 as existing versions but stable might point to v0.2
6. karmor cli tool and helm charts will ensure that the right accessory tooling (for e.g., kubearmor-relay-server) is made use of for the appropriate kubearmor version.

Support for KubeArmor on GKE Rapid Release, Regular channels (@nyrahul)