Open nyrahul opened 1 year ago
Potential Solution
For protecting KubeArmor with KubeArmor in BPF LSM, we need to:
Edge Case
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.
Prioritize
Future
Remove:
/sys/fs/bpf
- not needed, KubeArmor can create and mount bpffs within the container, persistence of maps not an issue
/sys/kernel/debug
- was needed earlier for bpf_printk logs, not needed anymore
Init container mounts: if BTF present, compilation not needed - remove the init container entirely along with below volumes. Also document when would this be needed. (Checkout PR #1658)
/etc/os-release
/lib/modules
/usr/src
Document:
/etc/apparmor.d
(read/write) - needed for writing apparmor profiles. Only mounted if AppArmor enforcer is being used.Remove:
/
- snitch mounts entire root, though read-only but it is not good. Mount specific paths. Also, document each of the path that snitch mounts for detection of the env, if we cannot remove them.Document:
/var/lib/kubelet/seccomp
- (read/write) needed for storing seccomp profiles - if not desired inform about the option to disable seccomp./sys/kernel/security
- to check if AppArmor enforcer. Handle this through snitch and remove relevant code in controller. Label/annotate the deployment and accordingly skip adding this volume if it is not AppArmor. (Checkout PR: https://github.com/kubearmor/KubeArmor/pull/1497)Remove:
SYS_RESOURCE
- for managing memory. Needed only on kernel < 5.11 by cilium/ebpf (ref). Modify snitch to handle this.Check:
SYS_ADMIN
- Our usecases should ideally be satisfied with CAP_BPF
itself however SYS_ADMIN is still kept
SETUID
- trace and checkSETGID
- trace and checkIPC_LOCK
- for locking memory using mmap and other related syscalls as mentioned in man page. (Ref)Document:
SETPCAP
- For AppArmor subprofilesSYS_PTRACE
- for reading processes other than self from procfs (source: man capabilities)MAC_ADMIN
- for managing LSM rules (man capabilities and ref)CAP_DAC_OVERRIDE
, CAP_DAC_READ_SEARCH
- mainly needed by cilium/ebpf (ref). Also possible that these are needed for managing apparmor profiles at /etc/apparmor.dIPC_LOCK
SYS_ADMIN
SYS_RESOURCE
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.
Yep! This seems fairly straight and user friendly. Thanks for the suggestion @dirsigler. Also, no one is looking into this aspect right now so PRs welcome! : )
Signing container images SBOM PR - https://github.com/kubearmor/KubeArmor/pull/1735
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:
baseline
level inenforce
mode Pod Security Admission for KubeArmor namespace/sys/kernel/debug/kprobes/enabled