68281d00e9
- add a link to SELinux k8s docs
- style improvements:
- capitalize proper nouns consistently
- DaemonSet, per [k8s style guide](https://kubernetes.io/docs/contribute/style/style-guide/#use-upper-camel-case-for-api-objects)
- consistently use capital "AppArmor", capital "SELinux", and capital "Pod Security Context"
- these were sometimes lower-cased or just inconsistently capitalized
- consistently use "multi-cloud" (instead of "multicloud" or "multi cloud")
- consistently have a newline before and after lists, per `markdownlint`
- consistently have 1 sentence per line in prose
- instead of some very long lines
- remove duplicate post-attack mitigation link
- links should also have context and not use "here", per [k8s style guide](https://kubernetes.io/docs/contribute/style/style-guide/#links)
- use simpler and more direct language, per [k8s style guide](https://kubernetes.io/docs/contribute/style/style-guide/#use-simple-and-direct-language)
- shortens a few sentences, removes unnecessary phrases, makes it clearer and more concise
- use present tense where possible, per [k8s style guide](https://kubernetes.io/docs/contribute/style/style-guide/#use-present-tense)
- "it becomes" -> "it is"
- avoid Latin phrases, per [k8s style guide](https://kubernetes.io/docs/contribute/style/style-guide/#avoid-latin-phrases)
- heavily simplify the one sentence that used two Latin phrases almost immediately after each other
- grammar fixes:
- fix tense issues:
- "capabilities [...] allows it" -> "[...] allow it"
- "easy way for policy enforcement" -> "easy way to enforce policies" -- missing verb entirely
- "allowed to executes" -> "allowed to execute"
- fix various issues with articles and plurality:
- consistently use "the host" -- there is only one host in context (a process only has one host)
- consistently use "a process", "a pod", "a rule", etc -- it can be any process and is not a specific process
- consistently use "LSMs" with no article
- consistently don't use articles in "Attacker" line (as this is a brief hypothetical)
- "its binary" -> "a binary" -- binary is necessarily possesed by the attacker
- "the sensitive contents" -> "sensitive contents" -- we're not referring to a specific set of contents, just any set
- no comma after "By the time" as the pause is later after the verb
- typos:
- "and changes" -> "any changes"
- "can multiple" -> "can have multiple"
- "it flaws" -> "its flaws"
Signed-off-by: Anton Gilgur <agilgur5@gmail.com>
3.9 KiB
KubeArmor Differentiation
Significance of Inline Mitigation
KubeArmor supports attack prevention, not just observability and monitoring. More importantly, the prevention is handled inline: even before a process is spawned, a rule can deny execution of a process. Most other systems typically employ "post-attack mitigation" that kills a process/pod after malicious intent is observed, allowing an attacker to execute code on the target environment. Essentially KubeArmor uses inline mitigation to reduce the attack surface of a pod/container/VM. KubeArmor leverages best of breed Linux Security Modules (LSMs) such as AppArmor, BPF-LSM, and SELinux (only for host protection) for inline mitigation. LSMs have several advantages over other techniques:
- KubeArmor does not change anything with the pod/container.
- KubeArmor does not require any changes at the host level or at the CRI (Container Runtime Interface) level to enforce blocking rules. KubeArmor deploys as a non-privileged DaemonSet with certain capabilities that allows it to monitor other pods/containers and the host.
- A given cluster can have multiple nodes utilizing different LSMs. KubeArmor abstracts away complexities of LSMs and provides an easy way to enforce policies. KubeArmor manages complexity of LSMs under-the-hood.
Post-Attack Mitigation and its flaws
- Post-exploit Mitigation works by killing a suspicious process in response to an alert indicating malicious intent.
- Attacker is allowed to execute a binary. Attacker could disable security controls, access logs, etc to circumvent attack detection.
- By the time a malicious process is killed, sensitive contents could have already been deleted, encrypted, or transmitted.
- Quoting Grsecurity, “post-exploitation detection/mitigation is at the mercy of an exploit writer putting little to no effort into avoiding tripping these detection mechanisms.”
Problems with k8s native Pod Security Context
Pod Security Context allows one to specify native AppArmor or native SELinux policies.
This approach has multiple problems:
- It is often difficult to predict which LSM (AppArmor or SELinux) would be available on the target node.
- BPF-LSM is not supported by Pod Security Context.
- It is difficult to manually specify an AppArmor or SELinux policy. Changing default AppArmor or SELinux policies might result in more security holes since it is difficult to decipher the implications of the changes and can be counter-productive.
Problems with multi-cloud deployment
Different managed cloud providers use different default distributions. Google GKE COS uses AppArmor by default, AWS Bottlerocket uses BPF-LSM and SELinux, and AWS Amazon Linux 2 uses only SELinux by default. Thus it is challenging to use Pod Security Context in multi-cloud deployments.
Use of BPF-LSM
References: