securing KubeArmor pods and policies

[nyrahul]

KubeArmor is a security engine and thus it is imperative that it follows all the security best practices. The aim is to ensure security of the KubeArmor itself. Much of the work towards following best security practices (such as not using privileged flag) is already followed. It is now time to notch up the security practices to next level. The proposition is as follows:

• Use baseline level in enforce mode Pod Security Admission for KubeArmor namespace
• Dogfooding
  • Protect AppArmor policies mount point to be accessible only by KubeArmor binary. Enforce a KubeArmor policy to ensure this.
  • Only allow access of service account token for kubearmor binary in the KubeArmor pod.
  • Use hardening policies for KubeArmor pod.
• Remove use of cluster-admin role
• Satisfy SLSA 3 requirements SLSA 3 compliance #1164
• Ability to use signed policy YAMLs only
• seccomp profile for kubearmor
• selinux/apparmor ootb profile
• Fix all critical vulnerabilities across all kubearmor-images.
• TLS for all intra-kubearmor communication feat(gRPC): Implement m-TLS Support using self-signed certificate #1526
• Reducing the kubearmor base image (can we try distroless kubearmor image?) [moved to UBI]
• Remove unnecessary hostPaths from the manifests
• Remove unnecessary capabilities from the manifests
• attacker can disable kprobes, thus we won't get any future events
  Predefined hardening policy for checking any changes to /sys/kernel/debug/kprobes/enabled

[Ankurk99]

karmor recommend for KubeArmor Daemonset

[daemon1024]

• How would KubeArmor daemonset attach a profile to itself?
  • Failed admission if annotation added and no profile found

Potential Solution

• Snitch has the intelligence to load the default apparmor profile.

[DelusionalOptimist]

For protecting KubeArmor with KubeArmor in BPF LSM, we need to:

• How to differentiate between host process and containers with hostPid.

[daemon1024]

• Seccomp Loading
• Try running all other KA Components with Seccomp RuntimeDefault

[daemon1024]

• Remove skipping kubearmor-app logic from KubeArmor.
• Have snitch generate apparmor profile just for kubearmor daemonset with a privileged default profile
• annotate kubearmor daemonset if snitch successful
• verify if matchlabels works as expected with kubearmor pods as well

Edge Case

• kubearmore-controller should not block daemonset deployment or try to admission control daemonset (it can do it for other kubearmor pods except snitch)
• if operator does not exist, verify what happens when kubearmor tries to patch it's own daemonset
  • validate if kubearmor loads apparmor profile before patching

[dirsigler]

Regarding "Use baseline level in enforce mode Pod Security Admission for KubeArmor namespace", how about providing a Namespace manifest within the Helm chart which already provide the specific labels to set the Pod Security Standards on it.

This way users could for example deploy the Chart via Helm and use their own Namespace via --namespace --create-namespace or implement the provided namespace with all the features out of the box.