Default Security Posture
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
ProcessName, ParentProcessName fields in all telemetry events
KubeArmor PR#632 now generates an appropriate
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.
ParentProcessName fields in the json fields.
Branching and Release Strategy
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:
mainas our bleeding edge branch where things might be unstable.
- 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
- Every version (including release candidates) will have a tag created.
- Every version (not including release candidates) will have a branch name corresponding to the version name (for e.g., v0.2).
- KubeArmor dockerhub image will have following: a.
kubearmor/kubearmor:latestpointing 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
- 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 & Stable channels
Google’s GKE supports multiple release channels and KubeArmor has now been tested across the latest release across all these release channels. Earlier, we found (issue#579) that GKE has further constrained access to the system folder on images of Rapid/Regular release channels. Fixed through PR#648.