KubeArmor is a cloud-native runtime security enforcement system that restricts the behavior (such as process execution, file access, and networking operations) of pods, containers, and nodes (VMs) at the system level.

KubeArmor leverages Linux security modules (LSMs) such as AppArmor, SELinux, or BPF-LSM to enforce the user-specified policies. KubeArmor generates rich alerts/telemetry events with container/pod/namespace identities by leveraging eBPF.

Architecture Overview

Documentation 📓

• 👉 Getting Started

• 🎯 Use Cases

• ✔️ KubeArmor Support Matrix

• ♟️ How is KubeArmor different?

• 📜 Security Policy for Pods/Containers [Spec] [Examples]

• 📜 Cluster level security Policy for Pods/Containers [Spec] [Examples]

• 📜 Security Policy for Hosts/Nodes [Spec] [Examples] ... detailed documentation

Contributors 👥

• 📘 Contribution Guide

• 🧑‍💻 Development Guide, Testing Guide

• ✋ Join KubeArmor Slack

• ❓ FAQs

Biweekly Meeting

• 🗣️ Zoom Link

• 📄 Minutes: Document

• 📆 Calendar invite: Google Calendar, ICS file

Notice/Credits 🤝

• KubeArmor uses Tracee's system call utility functions.

CNCF

KubeArmor is Sandbox Project of the Cloud Native Computing Foundation.

ROADMAP

KubeArmor roadmap is tracked via KubeArmor Projects

KubeArmor is a runtime security enforcement system for containers and nodes. It uses security policies (defined as Kubernetes Custom Resources like KSP, HSP, and CSP) to define allowed, audited, or blocked actions for workloads. The system monitors system activity using kernel technologies such as eBPF and enforces the defined policies by integrating with the underlying operating system's security modules like AppArmor, SELinux, or BPF-LSM, sending security alerts and telemetry through a log feeder.

Visual Overview

karmor profile provides a real-time terminal UI that visualizes security-relevant activity observed by KubeArmor, including Process, File, and Network events. It fetches live data from the KubeArmor logs API, displays counters and key details for each event type, and supports easy navigation and filtering.

🔍 Filtering Logs with karmor profile

The karmor profile command allows you to filter logs or alerts using a set of useful flags. These filters help narrow down the output to specific Kubernetes objects like containers, pods, and namespaces.

🧰 Available Filters

📌 Usage Examples

✅ Filter by Container Name

karmor profile -c nginx

Outputs logs only from the container named nginx.

✅ Filter by Namespace

karmor profile -n nginx1

Outputs logs only from the namespace nginx1.

✅ Filter by Pod

karmor profile --pod nginx-pod-1

Outputs logs only from the pod named nginx-pod-1.

🔗 Combine Multiple Filters

You can combine filters to narrow down the logs even further.

karmor profile -n nginx1 -c nginx

Outputs logs only from the nginx container in the nginx1 namespace.

💡 Tip

Use these filters during profiling sessions to quickly isolate behavior or security events related to a specific pod, container, or namespace.

KubeArmor helps organizations enforce a zero trust posture within their Kubernetes clusters. It allows users to define an allow-based policy that allows specific operations, and denies or audits all other operations. This helps to ensure that only authorized activities are allowed within the cluster, and that any deviations from the expected behavior are denied and flagged for further investigation.

By implementing a zero trust posture with KubeArmor, organizations can increase their security posture and reduce the risk of unauthorized access or activity within their Kubernetes clusters. This can help to protect sensitive data, prevent system breaches, and maintain the integrity of the cluster.

KubeArmor supports allow-based policies which results in specific actions to be allowed and denying/auditing everything else. For example, a specific pod/container might only invoke a set of binaries at runtime. As part of allow-based rules you can specify the set of processes that are allowed and everything else is either audited or denied based on the .

Allow execution of only specific processes within the pod

1. Install the nginx deployment using

   • kubectl create deployment nginx --image=nginx.

2. Set the default security posture to default-deny.

   • kubectl annotate ns default kubearmor-file-posture=block --overwrite

3. Apply the following policy:

Observe that the policy contains Allow action. Once there is any KubeArmor policy having Allow action then the pods enter least permissive mode, allowing only explicitly allowed operations.

Note: Use kubectl port-forward $POD --address 0.0.0.0 8080:80 to access nginx and you can see that the nginx web access still works normally.

Lets try to execute some other processes:

This would be permission denied.

Challenges with maintaining Zero Trust Security Posture

Achieving Zero Trust Security Posture is difficult. However, the more difficult part is to maintain the Zero Trust posture across application updates. There is also a risk of application downtime if the security posture is not correctly identified. While KubeArmor provides a way to enforce Zero Trust Security Posture, identifying the policies/rules for achieving this is non-trivial and requires that you keep the policies in dry-run mode (or default audit mode) before using the default-deny mode.

KubeArmor provides framework so as to smoothen the journey to Zero Trust posture. For e.g., it is possible to set dry-run/audit mode at the namespace level by . Thus, you can have different namespaces in different default security posture modes (default-deny vs default-audit). Users can switch to default-deny mode once they are comfortable (i.e., they do not see any alerts) with the settings.

This recipe explains how to use KubeArmor directly on a VM/Bare-Metal machine, and we tested the following steps on Ubuntu hosts.

The recipe installs kubearmor as systemd process and karmor cli tool to manage policies and show alerts/telemetry.

Download and Install KubeArmor

1. Download the latest release or KubeArmor.

2. Install KubeArmor (VER is the kubearmor release version)

sudo apt --no-install-recommends install ./kubearmor_${VER}_linux-amd64.deb

Note that the above command doesn't installs the recommended packages, as we ship object files along with the package file. In case you don't have BTF, consider removing --no-install-recommends flag.

wget https://github.com/KubeArmor/KubeArmor/releases/download/v${VER}/kubearmor_${VER}_linux-amd64.tar.gz

sudo tar --no-overwrite-dir -C / -xzf kubearmor_${VER}_linux-amd64.tar.gz
sudo systemctl daemon-reload

Start KubeArmor

sudo systemctl start kubearmor

Check the status of KubeArmor using sudo systemctl status kubearmor or use sudo journalctl -u kubearmor -f to continuously monitor kubearmor logs.

Apply sample policy

Following policy is to deny execution of sleep binary on the host:

apiVersion: security.kubearmor.com/v1
kind: KubeArmorHostPolicy
metadata:
  name: hsp-kubearmor-dev-proc-path-block
spec:
  nodeSelector:
    matchLabels:
      kubearmor.io/hostname: "*" # Apply to all hosts
  process:
    matchPaths:
    - path: /usr/bin/sleep # try sleep 1
  action:
    Block

Save the above policy to hostpolicy.yaml and apply:

karmor vm policy add hostpolicy.yaml

Now if you run sleep command, the process would be denied execution.

Note that sleep may not be blocked if you run it in the same terminal where you apply the above policy. In that case, please open a new terminal and run sleep again to see if the command is blocked.

Get Alerts for policies and telemetry

karmor logs --gRPC=:32767 --json

{
"Timestamp":1717259989,
"UpdatedTime":"2024-06-01T16:39:49.360067Z",
"HostName":"kubearmor-dev",
"HostPPID":1582,
"HostPID":2420,
"PPID":1582,
"PID":2420,
"UID":1000,
"ParentProcessName":"/usr/bin/bash",
"ProcessName":"/usr/bin/sleep",
"PolicyName":"hsp-kubearmor-dev-proc-path-block",
"Severity":"1",
"Type":"MatchedHostPolicy",
"Source":"/usr/bin/bash",
"Operation":"Process",
"Resource":"/usr/bin/sleep",
"Data":"lsm=SECURITY_BPRM_CHECK",
"Enforcer":"BPFLSM",
"Action":"Block",
"Result":"Permission denied",
"Cwd":"/"
}

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:

1. It is often difficult to predict which LSM (AppArmor or SELinux) would be available on the target node.

2. BPF-LSM is not supported by Pod Security Context.

3. 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:

• Armoring Cloud Native Workloads with BPF-LSM

• Securing Bottlerocket deployments on Amazon EKS with KubeArmor

Adversarial attacks exploit vulnerabilities in AI systems by subtly altering input data to mislead the model into incorrect predictions or decisions. These perturbations are often imperceptible to humans but can significantly degrade the system's performance.

Types of Adversarial Attacks

1. By Model Access:

   • White-box Attacks: Complete knowledge of the model, including architecture and training data.

   • Black-box Attacks: No information about the model; the attacker probes responses to craft inputs.

2. By Target Objective:

   • Non-targeted Attacks: Push input to any incorrect class.

   • Targeted Attacks: Force input into a specific class.

Attack Phases

1. Training Phase Attacks:

   • Data Poisoning: Injects malicious data into the training set, altering model behavior.

   • Backdoor Attacks: Embeds triggers in training data that activate specific responses during inference.

2. Inference Phase Attacks:

   • Model Evasion: Gradually perturbs input to skew predictions (e.g., targeted misclassification).

   • Membership Inference: Exploits model outputs to infer sensitive training data (e.g., credit card numbers).

Observations on Model Robustness

Highly accurate models often exhibit reduced robustness against adversarial perturbations, creating a tradeoff between accuracy and security. For instance, Chen et al. found that better-performing models tend to be more sensitive to adversarial inputs.

Defense Strategies

1. Pre-analysis: Test models for prompt injection vulnerabilities using techniques like fuzzing.

2. Input Sanitation:

   • Validation: Enforce strict input rules (e.g., character and data type checks).

   • Filtering: Strip malicious scripts or fragments.

   • Encoding: Convert special characters to safe representations.

3. Secure Practices for Model Deployment:

   • Restrict model permissions.

   • Regularly update libraries to patch vulnerabilities.

   • Detect injection attempts with specialized tooling.

Case Study: Pickle Injection Vulnerability

Python's pickle module allows serialization and deserialization but lacks security checks. Attackers can exploit this to execute arbitrary code using crafted payloads. The module’s inherent insecurity makes it risky to use with untrusted inputs.

Mitigation:

• Avoid using pickle with untrusted sources.

• Use secure serialization libraries like json or protobuf.

Relevant Resources

• Adversarial Attacks on Deep Learning Models

• How to Protect ML Models Against Adversarial Attacks

• Weaponizing ML Models with Ransomware

This guide assumes you have access to a . If you want to try non-k8s mode, for instance systemd mode to protect/audit containers or processes on VMs/bare-metal, check .

Check the to verify if your platform is supported.

Install KubeArmor

You can find more details about helm related values and configurations .

Install kArmor CLI (Optional)

[!NOTE] kArmor CLI provides a Developer Friendly way to interact with KubeArmor Telemetry. You can stream KubeArmor telemetry independently of kArmor CLI tool and integrate it with your chosen SIEM (Security Information and Event Management) solutions. on how to achieve this integration. This guide assumes you have kArmor CLI to access KubeArmor Telemetry but you can view it on your SIEM tool once integrated.

Deploy test nginx app

[!NOTE]$POD is used to refer to the target nginx pod in many cases below.

Sample policies

Here, we demonstrate how to define a cluster security policies.

• Process Execution Restriction

  • Block a specific executable - In operator ()

    • Explanation: The purpose of this policy is to block the execution of '/usr/bin/apt' in the containers present in the namespace nginx1. For this, we define the 'nginx1' value and operator as 'In' in selector -> matchExpressions and the specific path ('/usr/bin/apt') in process -> matchPaths. Also, we put 'Block' as the action of this policy.

    • Verification: After applying this policy, please get into one of the containers in the namespace 'nginx1' (using "kubectl -n nginx1 exec -it nginx-X-... -- bash") and run '/usr/bin/apt'. You will see that /usr/bin/apt is blocked.

  • Block a specific executable - NotIn operator()

    • Explanation: The purpose of this policy is to block the execution of '/usr/bin/apt' in all containers present in the cluster except that are in the namespace nginx1. For this, we define the 'nginx1' value and operator as 'NotIn' in selector -> matchExpressions and the specific path ('/usr/bin/apt') in process -> matchPaths. Also, we put 'Block' as the action of this policy.

    • Verification: After applying this policy, please get into one of the containers in the namespace 'nginx1' (using "kubectl -n nginx1 exec -it nginx-X-... -- bash") and run '/usr/bin/apt'. You will see that /usr/bin/apt is not blocked. Now try running same command in container inside 'nginx2' namespace and it should not be blocked.

  • Block a specific executable matching labels, In operator- In operator ()

    • Explanation: The purpose of this policy is to block the execution of '/usr/bin/apt' in the workloads who match the labels app=nginx OR app=nginx-dev present in the namespace nginx1 . For this, we define the 'nginx1' as value and operator as 'In' for key namespace AND app=nginx & app=nginx-dev value and operator as 'In' for key label in selector -> matchExpressions and the specific path ('/usr/bin/apt') in process -> matchPaths. Also, we put 'Block' as the action of this policy.

    • Verification: After applying this policy, please get into one of the containers in the namespace 'nginx1' (using "kubectl -n nginx1 exec -it nginx-X-... -- bash") and run '/usr/bin/apt'. You will see that /usr/bin/apt is blocked. apt won't be blocked in a workload that doesn't have labels app=nginx OR app=nginx-dev in namespace nginx1 and all the workloads across other namespaces.

  • Block accessing specific executable matching labels, NotIn operator ()

    • Explanation: The purpose of this policy is to block the execution of '/usr/bin/apt' in all the workloads who doesn't match the labels app=nginx AND not present in the namespace nginx2 . For this, we define the 'nginx2' as value and operator as 'NotIn' for key namespace AND app=nginx value and operator as 'NotIn' for key label in selector -> matchExpressions and the specific path ('/usr/bin/apt') in process -> matchPaths. Also, we put 'Block' as the action of this policy.

    • Verification: After applying this policy, please exec into any container within the namespace 'nginx2' and run '/usr/bin/apt'. You can see the operation is blocked. Then try to do same in other workloads present in different namespace and if they don't have label app=nginx, the operation will be blocked, in case container have label app=nginx, operation won't be blocked.

• File Access Restriction

  • Block accessing specific file ()

    • Explanation: The purpose of this policy is to block read access for '/etc/host.conf' in all the containers except the namespace 'bginx2'.

    • Verification: After applying this policy, please get into the container within the namespace 'nginx2' and run 'cat /etc/host.conf'. You can see the operation is not blocked and can see the content of the file. Now try to run 'cat /etc/host.conf' in container of 'nginx1' namespace, this operation should be blocked.

Note Other operations like Network, Capabilities, Syscalls also behave in same way as in security policy. The difference only lies in how we match the cluster policy with the namespaces.

ModelArmor is a Zero Trust security solution purpose-built to protect AI/ML/LLM workloads from runtime threats. It safeguards against the unique risks of agentic AI systems and untrusted models by sandboxing deployments and enforcing granular runtime policies.

ModelArmor uses KubeArmor as a sandboxing engine to ensure that the untrusted models execution is constrained and within required checks. AI/ML Models are essentially processes and allowing untrusted models to execute in AI environments have significant risks such as possibility of cryptomining attacks leveraging GPUs, remote command injections, etc. KubeArmor's preemptive mitigation mechanism provides a suitable framework for constraining the execution environment of models.

ModelArmor can be used to enforce security policies on the model execution environment.

Why ModelArmor?

ModelArmor enables secure deployment of agentic AI applications and ML models, addressing critical security gaps that traditional guardrails and static scanning cannot solve.

It is designed for:

• Agentic AI workloads using autonomous, tool-using agents.

• ML pipelines importing untrusted models from public repositories.

• Environments where guardrails alone are not sufficient.

ModelArmor protects the entire AI lifecycle, from development to deployment, using sandboxing and policy enforcement to neutralize malicious behavior at runtime.

The Problem: Security Risks in Agentic AI

1. Arbitrary Code Execution

Agentic AI systems can execute arbitrary system commands due to their autonomy and access to tools.

• Prompt engineering can bypass LLM guardrails.

• Attackers can instruct agents to run harmful commands, download malware, or scan networks.

2. Model Supply Chain Attacks

Malicious models uploaded to public repositories (e.g., Hugging Face) can contain embedded payloads.

• Loading such models allows hidden code execution, leading to system compromise and C&C communication.

3. Prompt Injection Attacks

Crafted prompts can manipulate the agent into performing unauthorized actions:

• Reading sensitive files (e.g., /root/.aws/credentials).

• Installing tools (apk add nmap) or scanning networks.

• Fetching and executing external scripts.

Traditional container security cannot detect these because they exploit application behavior, not the container itself.

The Solution

Sandboxing Agentic AI

ModelArmor isolates agentic AI apps and ML workloads at runtime, blocking unauthorized actions even if guardrails or code reviews are bypassed.

Zero Trust Policy Enforcement

Define fine-grained security policies to:

• Restrict file system access (e.g., block /root/.aws/credentials).

• Control process execution (allow only trusted binaries).

• Limit network activity (disable raw sockets, ICMP, or outbound traffic).

Automated Red Teaming

Simulate adversarial scenarios like malicious model imports and prompt injections to identify vulnerabilities pre-deployment.

Protection Across the Stack

ModelArmor works across frameworks and environments:

• Supports any language runtime or AI framework.

• Requires no code changes to your application.

• Lightweight and cost-efficient, avoiding the overhead of MicroVMs or full isolation environments.

TensorFlow Based Use Cases

FGSM Adversarial Input Attack

An FGSM attack manipulates input data by adding imperceptible noise, creating adversarial examples that force the TensorFlow model to misclassify (e.g., predicting “5” for an image of “2”).

Traditional container security fails here because the model and container remain unchanged; the attack happens through crafted input.

ModelArmor Protection:

• Proactively simulates adversarial attacks using Automated Red Teaming.

• Secures model behavior with input validation and anomaly detection, akin to an LLM Prompt Firewall for ML workloads.

• Protects against sophisticated input-level manipulations.

Keras Model Injection Attack

A deployed TensorFlow model in a Docker container is vulnerable to compromise via a malicious Keras Lambda layer. This attack involves:

• Installing Python inside the container or

• Copying malicious scripts (e.g., into /tmp) to execute unauthorized system commands.

ModelArmor Protection:

• Blocks unauthorized installations (e.g., Python) and filesystem modifications (e.g., writing to /tmp).

• Uses Automated Red Teaming to detect such vulnerabilities pre-deployment.

• Isolates workloads (like TensorFlow) with Sandboxing Agentic AI to prevent code injection.

Securing NVIDIA NIM

📄

KubeArmor v1.5 delivers significant advancements in runtime security for Kubernetes environments. This release introduces enhanced policy enforcement, streamlined management, and improved observability, making it easier to secure workloads effectively.

This version expands platform support, optimizes performance, and introduces new features like network policy enforcement and host security hardening, along with integrations for a seamless security experience.

📺 Watch the v1.5 Feature Showcase Livestream:

🔑 Key Highlights

• Runtime Protection for Kubernetes Clusters Secure clusters at runtime with fine-grained policies to prevent unauthorized access and block malicious activity.

• Cluster-wide Security Policies Support for cluster-level policies enables security enforcement beyond namespaces for organization-wide protection. KubeArmor enforces Cluster Security Policies (CSPs) that allow you to define security controls across the entire cluster. CSPs provide a unified way to manage container workloads at scale, enabling global policy enforcement across namespaces.

  📄 📝

• KubeArmor Presets Simplify security policy deployment with predefined policy templates for common use cases like:

  • Blocking fileless execution

  • Protecting environment variables

  • Auditing and blocking kubectl exec commands To use presets, specify the preset-rule field in your KubeArmorPolicy.

• Minikube and Killercoda Playground Support Set up quick test environments for demos and PoCs effortlessly.

• Support for SCTP and All Protocols Added the ability to handle SCTP protocol and all protocols with raw socket, including protocol: all network rule. (Contributed by in )

• OpenSSF Scorecard Improvements Reduced attack surfaces and enhanced compliance by optimizing SecComp profiles and minimizing host exposure.

• NRI Handler Support Implemented NRI (Network Resource Interface) handler to extend runtime integrations. (Contributed by in )

🛠 Improvements

• Cluster Name Detection Auto-fetch cluster names for easier multi-cluster management.

• Docker ImagePull Secrets Improved management of Docker credentials for smoother deployments.

• Fileless Execution Handling Added special presets to manage and prevent fileless attacks.

• Containerd API Refactor Upgraded to v2 API for better performance and stability.

• RBAC Enhancements Introduced flag-based RBAC rules and refined operator configurations.

• Deprecation of kube-rbac-proxy Replaced with built-in controller authentication for streamlined security configuration.

• Improved Controller Annotation Logic Enhanced handling of pod deletions in the KubeArmor controller for better reliability. (Contributed by in )

• Optimized Memory Usage Reduced memory overhead in os.readlink operations to improve efficiency. (Contributed by in )

• Exclude Labels in Endpoint Matching Added support for excluding labels in CSP and KSP endpoint matching for flexible policy scoping. (Contributed by in )

🐞 Bug Fixes

• Fixed conditional mount issues for operator consistency.

• Enhanced log handling for cases where process names were missing.

• Improved build system by injecting version info into systemd packages.

• Added go-get-tool function to operator Makefile for more stable builds.

• Fixed network event returned values for more accurate monitoring. (Contributed by in )

📖 Documentation Updates

• Talos Support Updated FAQ and guides for Talos environments, ensuring all platforms are well-documented.

📄

KubeArmor continues to harden cloud-native environments, enforcing least-permissive access and monitoring critical paths for Kubernetes, containerized, and bare-metal workloads.

👉 Join the Community:

KubeArmor has visibility into systems and application behavior. KubeArmor summarizes/aggregates the information and provides a user-friendly view to figure out the application behavior.

What application behavior is shown?

• Process data:

  • What are the processes executing in the pods?

  • What processes are executing through which parent processes?

• File data:

  • What are the file system accesses made by different processes?

• Network Accesses:

  • What are the Ingress/Egress connections from the pod?

  • What server binds are done in the pod?

How to get the application behavior?

Get visibility into process executions in default namespace.

The Pickle Code Injection Proof of Concept (PoC) demonstrates the security vulnerabilities in Python's pickle module, which can be exploited to execute arbitrary code during deserialization. This method is inherently insecure because it allows execution of arbitrary functions without restrictions or security checks.

Core Code Overview

Custom Pickle Injector:

Example Exploits

1. Print Injection:

2. Install Packages:

3. Adversarial Command Execution: Upon loading the tampered model:

   Output:

   • Installs the package or executes the payload.

   • Alters model behavior: changes predictions, losses, etc.

Attacker Use Cases

1. Spreading Malware: The injected code can download and install malware on the target machine, which can then be used to infect other systems in the network or create a botnet.

2. Backdoor Installation: An attacker can use pickle injection to install a backdoor that allows persistent access to the system, even if the original vulnerability is patched.

3. Data Exfiltration: An attacker can use pickle injection to read sensitive files or data from the system and send it to a remote server. This can include configuration files, database credentials, or any other sensitive information stored on the machine.

Key Risks

The pickle module is inherently insecure for handling untrusted input due to its ability to execute arbitrary code.

Ref:

KubeArmor maintainers welcome individuals and organizations from across the cloud security landscape (creators and implementers alike) to make contributions to the project. We equally value the addition of technical contributions and enhancements of documentation that helps us grow the community and strengthen the value of KubeArmor. We invite members of the community to contribute to the project!

To make a contribution, please follow the steps below.

1. Fork this repository (KubeArmor)

   First, fork this repository by clicking on the Fork button (top right).

   Then, click your ID on the pop-up screen.

   This will create a copy of KubeArmor in your account.
2. Clone the repository

   Now clone Kubearmor locally into your dev environment.

   This will clone a copy of Kubearmor installed in your dev environment.

3. Make changes

   First, go into the repository directory and make some changes.

   Please refer to to set up your environment for KubeArmor contribution.

4. Check the changes

   If you have changed the core code of KubeArmor then please run tests before committing the changes

   If you see any warnings or errors, please fix them first.

   If some tests are failing, then fix them by following

   If you have made changes in Operator or Controller, then follow

5. Commit changes

   Please see your changes using "git status" and add them to the branch using "git add".

   Then, commit the changes using the "git commit" command.

   Please make sure that your changes are properly tested on your machine.

6. Push changes to your forked repository

   Push your changes using the "git push" command.

7. Create a pull request with your changes with the following steps

   First, go to your repository on GitHub.

   Then, click "Pull request" button.

   After checking your changes, click 'Create pull request'.

   A pull request should contain the details of all commits as specific as possible, including "Fixes: #(issue number)".

   Finally, click the "Create pull request" button.

   The changes would be merged post a review by the respective module owners. Once the changes are merged, you will get a notification, and the corresponding issue will be closed.

8. DCO Signoffs

   To ensure that contributors are only submitting work that they have rights to, we are requiring everyone to acknowledge this by signing their work. Any copyright notices in this repo should specify the authors as "KubeArmor authors".

   To sign your work, just add a line like this at the end of your commit message:

   This can easily be done with the -s or --signoff option to git commit.

   By doing this, you state that the source code being submitted originated from you (see https://developercertificate.org).

Testing Guide

There are two ways to check the functionalities of KubeArmor: 1) testing KubeArmor manually and 2) using the testing framework.

0. Make sure Kubernetes cluster is running

Although there are many ways to run a Kubernetes cluster (like minikube or kind), it will not work with locally developed KubeArmor. KubeArmor needs to be on the same node as where the Kubernetes nodes exist. If you try to do this it will not identify your node since minikube and kind use virtualized nodes. You would either need to build your images and deploy them into these clusters or you can simply use k3s or kubeadm for development purposes. If you are new to these terms then the easiest way to do this is by following this guide:

0.1. Firstly Run 'kubectl proxy' in background

0.2. Now run KubeArmor

1. Test KubeArmor manually

1.1. Run 'kubectl proxy' in background

1.2. Compile KubeArmor

1.3. Run KubeArmor

1.4. Apply security policies into Kubernetes

Beforehand, check if the KubeArmorPolicy and KubeArmorHostPolicy CRDs are already applied.

If they are still not applied, do so.

Now you can apply specific policies.

You can refer to security policies defined for example microservices in .

1.5. Trigger policy violations to generate alerts

1.6. Check generated alerts

• Watch alerts using cli tool

  flags:

  Note that you will see alerts and logs generated right after karmor runs logs; thus, we recommend to run the above command in other terminal to see logs live.

2. Test KubeArmor using the auto-testing framework

• The case that KubeArmor is directly running in a host

  Compile KubeArmor

  Run the auto-testing framework

  Check the test report

• The case that KubeArmor is running as a daemonset in Kubernetes

  Run the testing framework

  Check the test report

• To run a specific suit of tests move to the directory of test and run

KubeArmor adds a number of new capabilities in this 0.3 release, including:

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)

KubeArmor now supports policy enforcement directly on the workloads installed on the hosts (either in virtual machine or on bare-metals). There were several fixes (#658, #631) to Kubearmor especially to handle restart conditions.

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 & 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.

New Managed Kubernetes platforms supported

KubeArmor v0.9 added support for new managed kubernetes platforms such as Oracle Container Engine for Kubernetes (OKE), IBM Cloud Kubernetes Service, and AWS Amazon Linux 2.

Support for ARM based k8s platforms

Support for ARM based cloud platforms such as AWS Graviton, and Oracle Ampere are added in v0.9.

Check out full KubeArmor support matrix here.

Performance Improvements

KubeArmor in-kernel event filtering changes were added in v0.9. The intention was to filter the events early in its cycle i.e., in the kernel space itself such that performance penalty of user space context switch is not incurred. Note that KubeArmor uses existing LSM (Linux Security Modules) hooks for policy enforcement. The LSM hooks are already enabled by default in all the Linux kernel images. Overall based on the benchmarking data taken on the docker sock-shop example, we found that the impact of KubeArmor is <3% on the overall requests per second performance of the sock-shop example.

Visibility/Telemetry configuration per namespace

Before v0.9, KubeArmor enabled telemetry across all the namespaces, deployments within the cluster. This caused significant telemetry events generated across non-user workload namespaces (such as kube-system). With v0.9, one can selectively enable process, file, network related telemetry across different namespaces.

K8s Operator-based install for KubeArmor

KubeArmor supports multiple modes of deployment today, including using manifests files, helm, and using karmor cli tool.

However, operator-based installation was desired for KubeArmor for the following reasons:

1. To handle the scenario where the cluster contains multiple nodes supporting different LSM (Linux Security Modules). KubeArmor cannot set the AppArmor annotation in context to the workload deployed on the node not supporting AppArmor.

2. There are certain services such as Kubearmor relay whose resource utilization depends on the number of nodes operating within the cluster.

Operator-based installation and subsequent monitoring simplify the handling of such scenarios.

With this release, the karmor cli tool or the helm/manifests will install the operator and then the operator will install the relevant Daemonset and services needed.

Consolidation of controllers

KubeArmor installed different controllers each for KubearmorPolicy, KubearmorHostPolicy in different pods namely policy-controller and host-policy-controller respectively. The new release consolidates multiple controllers into a single pod reducing the overall number of kubearmor pods deployed in the cluster and that single pod will reconcile all the kubernetes resources managed by KubeArmor.

Support for Unbreakable Enterprise Linux (UEK) used in Oracle Kubernetes Engine (OKE)

KubeArmor BPFLSM enforcer is used to support OKE with UEK7 and above. KubeArmor BPFLSM didn't support containerd which was a prerequisite for OKE platform. v0.9 added support for containerd to be used with BPFLSM enforcer, thus making OKE work.

Support for AWS Amazon Linux 2

AWS Amazon Linux 2 kernel version >=5.8 supported BPFLSM, however, it was found that the bpf filesystem was not mounted by default in the worker nodes. KubeArmor added the logic to check if the bpf filesystem is mounted and if not, mount the bpf filesystem on a custom path within the KubeArmor pod itself.

Support for IBM Cloud Kubernetes Service

IBM Cloud Kubernetes Service by default using Ubuntu 18.04 and AppArmor was by default supported on that platform. Thus KubeArmor didn't had to make any changes to support IBM Cloud Kubernetes Service.

ARM Servers: Support for AWS Graviton

AWS Graviton processors are designed by AWS to deliver the best price performance for the cloud workloads running in Amazon EC2. EKS also supports using EC2 instances running on AWS Graviton. AWS Graviton can use any Linux distributions. KubeArmor was tested on Ubuntu and Amazon Linux 2 distributions on AWS Graviton. KubeArmor now support AWS Graviton platform for application behavior analysis, network-segmentation, and audit based policies.

ARM Servers: Support for Oracle Ampere

The Oracle Cloud Infrastructure Ampere Altra A1 compute platform provides deterministic performance, linear scalability, and a secure architecture with the best price-performance in the market. Users can leverage the industry’s first 160-core Arm server at only $0.01 per core hour and flexible virtual machines with 1-80 cores and 1-64 GB of memory per core. KubeArmor now support Oracle Ampere platform for application behavior analysis, network-segmentation, and audit based policies.

Miscellaneous

• Full Enforcement on BPF LSM with Path based hooks. BPF-LSM based enforcement lacked certain enforcement support previously wherein file open related events were handled but a simple inode creation events were not handled. This resulted in certain operations (such as touch) to succeed even if the path is marked as blocked.

• Support for mount/umount system calls: To achieve CIS compliance 4.1.14 Ensure successful file system mounts are collected we need to audit the mount and umount events happening. Currently we are making use of mount and umount binaries for generating KubeArmor policies. This method will be not effective if the attacker is trying mount or unmount using system calls. KubeArmor now supports the mount/umount syscalls to make sure that issue mentioned is solved.

• App Behavior fixes: Bind port data is now showing meaningful data. Removed unnecessary netlink and unix domain sockets handling in the context.

• Use of k8s configmap: KubeArmor configuration previously was kept as environment variables. The new release ensures that KubeArmor uses k8s native approach of handling configuration and the changes to the configuration can now be handled dynamically i.e., without restarting the KubeArmor.

KubeArmor Operator as the Default Installation Method

Capabilities Enforcement with BPF LSM

Execname Matching in KubeArmor Policies

Securing KubeArmor

Additional Columns for KubeArmor Policies

Support for Alibaba Cloud

Performance Improvements

Key Takeaways

• KubeArmor Operator is now the default installation method for KubeArmor, providing a more streamlined installation process.

• New features include support for capabilities enforcement using BPF LSM, execname matching in policies, and additional columns in KubeArmor Security Policies (KSPs) and Host Security Policies (HSPs).

• Security enhancements include securing KubeArmor itself with Seccomp profiles and implementing mutual TLS (mTLS) for secure gRPC communication

• Support for Alibaba Cloud deployments has been added.

• Performance improvements include filtering watched nodes and pods server-side to reduce overhead in large clusters.

KubeArmor Operator as the Default Installation Method

Earlier we used to install KubeArmor through plain Kubernetes manfiests. In kubearmor-client a.k.a karmor, we had a heurisitics based mechanism for detecting the target environment and create KubeArmor manifests accordingly. In recent releases we've developed the KubeArmor Operator - a Kubernetes operator which gets the granular per-node configuration of target environments and accordingly creates KubeArmor manifests. We have been pushing on operator based installation, make it more stable and slowly migrating our docs and references to point towards it instead of the old method. Finally, with this release - we now have karmor using the operator based installation too.

Issues: https://github.com/kubearmor/KubeArmor/issues/1256

PRs: https://github.com/kubearmor/kubearmor-client/pull/402

Capabilities Enforcement with BPF LSM

In Kubernetes environments, certain workloads may require specific Linux capabilities to function correctly. However, granting unnecessary capabilities can introduce security risks. Previously, KubeArmor had the ability to enforce policies on Linux capabiliites only when using the AppArmor enforcer, recently we've introduced the same in our distinguishing BPF LSM enforcer as well. This improves the feature parity between AppArmor and BPF-LSM and allows you to define policies that restrict or allow specific capabilities for your workloads, enhancing the overall security posture of your Kubernetes cluster.

References: Restrict Capabilities Usecase

Issues:

• https://github.com/kubearmor/KubeArmor/issues/795

• https://github.com/kubearmor/KubeArmor/issues/1538

PRs:

• https://github.com/kubearmor/KubeArmor/pull/1543

Execname Matching in KubeArmor Policies

Identifying and blocking malicious or unauthorized applications running in your Kubernetes cluster can be a challenging task, especially when dealing with dynamic or obfuscated binaries. Previously, KubeArmor relied solely on file paths or other attributes to define policies, limiting its ability to detect and prevent the execution of specific binaries. To address this limitation, KubeArmor now supports matching executable names in its policies. This new feature enables you to create rules based on the name of the executable binary, allowing for more granular control over the applications running in your Kubernetes cluster. For example, you can now block or allow specific crypto-mining binaries like xmrig by matching their executable names. By introducing execname matching, KubeArmor provides an additional layer of security and control, enabling you to proactively detect and prevent the execution of known malicious or unauthorized binaries within your Kubernetes environment.

References: Example Policy

Discussion: https://kubearmor.slack.com/archives/C01F9V3SEHY/p1709480346589829

PRs: https://github.com/kubearmor/KubeArmor/pull/1664

Securing KubeArmor

As a security project, it's crucial for KubeArmor itself to adhere to security best practices and minimize its attack surface. For this, we've been constantly making improvements through past releases. In this release

Seccomp

KubeArmor will now ship with a default seccomp profile of it's own to restrict the system calls it can make. The profile won't be activated by default as of now but in future releases we'll make it enabled by default.

Secure gRPC Communication with Mutual TLS

In previous versions of KubeArmor, communication between the KubeArmor server and clients (e.g., kubearmor-relay, kubearmor-client) was unencrypted, potentially exposing sensitive information or allowing unauthorized access to the communication channel. To address this security concern, KubeArmor now supports secure gRPC communication between the KubeArmor server and clients using mutual TLS (mTLS). This enhancement ensures that all communication between KubeArmor components is encrypted and only trusted parties can connect with KubeArmor.

Vulnerabilities

Many critical vulnerabilities across KubeArmor images have been addressed, ensuring the overall security of the KubeArmor deployment and protecting against potential exploits or vulnerabilities.

References: KubeArmor Security Enhancements

Issues: https://github.com/kubearmor/KubeArmor/issues/1186

PRs:

• https://github.com/kubearmor/KubeArmor/pull/1526

• https://github.com/kubearmor/KubeArmor/pull/1661

Additional Columns for KubeArmor Policies

Previously, when listing KubeArmor Security Policies (KSPs) and Host Security Policies (HSPs) using kubectl get, users only had access to limited information about each policy, making it challenging to quickly assess the purpose and impact of each policy. To improve visibility and usability, policy status now includes additional columns. These columns display the action (Allow/Audit/Block) and severity level for each policy. This enhancement allows users to quickly identify the intended behavior and potential impact of each policy, facilitating easier policy management and enabling more informed decision-making when deploying or updating security policies within their Kubernetes environment.

References:

Issues: https://github.com/kubearmor/KubeArmor/issues/1326https://github.com/dqsully

PRs: https://github.com/kubearmor/KubeArmor/pull/1683

Support for Alibaba Cloud

As Kubernetes adoption continues to grow, organizations are increasingly leveraging various cloud providers to host their deployments. Previously, KubeArmor lacked official support for Alibaba Cloud deployments, which could pose challenges for users seeking to secure their Kubernetes workloads running on Alibaba Cloud's infrastructure. To address this gap, KubeArmor now officially supports Alibaba Cloud deployments, including Alibaba Cloud Kubernetes (ACK) and Elastic Compute Services (Virtual Machines). This support ensures that KubeArmor can be seamlessly deployed and integrated with Alibaba Cloud environments, providing robust security for your Kubernetes workloads running on Alibaba Cloud. With this addition, KubeArmor expands its reach and enables organizations leveraging Alibaba Cloud to benefit from its advanced security capabilities, ensuring consistent protection across various cloud platforms. The latest image of Alibaba Cloud Linux 3 contains BPF-LSM enabled by default as part of the kernel config but not enabled by default as part of the boot parameter. Thus the user has to enable BPF-LSM boot for all the nodes for which they desire to secure with KubeArmor. Checkout the FAQ for Checking And Enabling Support For BPF LSM.

Performance Improvements

In large-scale Kubernetes deployments with numerous nodes and pods, the overhead associated with listing and watching all resources can significantly impact performance and scalability. Previously, each KubeArmor DaemonSet pod listed and watched every node and pod in the cluster, leading to potential performance bottlenecks and resource constraints as the cluster grew larger. To address this performance concern, KubeArmor now filters watched nodes and pods server-side, reducing overhead significantly in large clusters. Instead of each KubeArmor DaemonSet pod listing and watching every node and pod in the cluster, KubeArmor now specifies the nodes and pods of interest for each DaemonSet. This optimization enhances the overall performance and scalability of KubeArmor in large-scale Kubernetes deployments, ensuring efficient resource utilization and enabling smoother operations in resource-constrained environments. Special thanks to dqsully for recognizing and fixing this!

PRs: https://github.com/kubearmor/KubeArmor/pull/1676

v1.3.0 release includes new improvements to enhance the security, usability, and performance of KubeArmor along with some bug fixes. We list major changes below.

KubeArmor Operator as the Default Installation Method

Capabilities Enforcement with BPF LSM

Execname Matching in KubeArmor Policies

Securing KubeArmor

Additional Columns for KubeArmor Policies

Support for Alibaba Cloud

Performance Improvements

Key Takeaways

• KubeArmor Operator is now the default installation method for KubeArmor, providing a more streamlined installation process.

• New features include support for capabilities enforcement using BPF LSM, execname matching in policies, and additional columns in KubeArmor Security Policies (KSPs) and Host Security Policies (HSPs).

• Security enhancements include securing KubeArmor itself with Seccomp profiles and implementing mutual TLS (mTLS) for secure gRPC communication

• Support for Alibaba Cloud deployments has been added.

• Performance improvements include filtering watched nodes and pods server-side to reduce overhead in large clusters.

KubeArmor Operator as the Default Installation Method

Earlier we used to install KubeArmor through plain Kubernetes manfiests. In kubearmor-client a.k.a karmor, we had a heurisitics based mechanism for detecting the target environment and create KubeArmor manifests accordingly. In recent releases we've developed the KubeArmor Operator - a Kubernetes operator which gets the granular per-node configuration of target environments and accordingly creates KubeArmor manifests. We have been pushing on operator based installation, make it more stable and slowly migrating our docs and references to point towards it instead of the old method. Finally, with this release - we now have karmor using the operator based installation too.

Issues: https://github.com/kubearmor/KubeArmor/issues/1256

PRs: https://github.com/kubearmor/kubearmor-client/pull/402

Capabilities Enforcement with BPF LSM

In Kubernetes environments, certain workloads may require specific Linux capabilities to function correctly. However, granting unnecessary capabilities can introduce security risks. Previously, KubeArmor had the ability to enforce policies on Linux capabiliites only when using the AppArmor enforcer, recently we've introduced the same in our distinguishing BPF LSM enforcer as well. This improves the feature parity between AppArmor and BPF-LSM and allows you to define policies that restrict or allow specific capabilities for your workloads, enhancing the overall security posture of your Kubernetes cluster.

References: Restrict Capabilities Usecase

Issues:

• https://github.com/kubearmor/KubeArmor/issues/795

• https://github.com/kubearmor/KubeArmor/issues/1538

PRs:

• https://github.com/kubearmor/KubeArmor/pull/1543

Execname Matching in KubeArmor Policies

Identifying and blocking malicious or unauthorized applications running in your Kubernetes cluster can be a challenging task, especially when dealing with dynamic or obfuscated binaries. Previously, KubeArmor relied solely on file paths or other attributes to define policies, limiting its ability to detect and prevent the execution of specific binaries. To address this limitation, KubeArmor now supports matching executable names in its policies. This new feature enables you to create rules based on the name of the executable binary, allowing for more granular control over the applications running in your Kubernetes cluster. For example, you can now block or allow specific crypto-mining binaries like xmrig by matching their executable names. By introducing execname matching, KubeArmor provides an additional layer of security and control, enabling you to proactively detect and prevent the execution of known malicious or unauthorized binaries within your Kubernetes environment.

References: Example Policy

Discussion: https://kubearmor.slack.com/archives/C01F9V3SEHY/p1709480346589829

PRs: https://github.com/kubearmor/KubeArmor/pull/1664

Securing KubeArmor

As a security project, it's crucial for KubeArmor itself to adhere to security best practices and minimize its attack surface. For this, we've been constantly making improvements through past releases. In this release

Seccomp

KubeArmor will now ship with a default seccomp profile of it's own to restrict the system calls it can make. The profile won't be activated by default as of now but in future releases we'll make it enabled by default.

Secure gRPC Communication with Mutual TLS

In previous versions of KubeArmor, communication between the KubeArmor server and clients (e.g., kubearmor-relay, kubearmor-client) was unencrypted, potentially exposing sensitive information or allowing unauthorized access to the communication channel. To address this security concern, KubeArmor now supports secure gRPC communication between the KubeArmor server and clients using mutual TLS (mTLS). This enhancement ensures that all communication between KubeArmor components is encrypted and only trusted parties can connect with KubeArmor.

Vulnerabilities

Many critical vulnerabilities across KubeArmor images have been addressed, ensuring the overall security of the KubeArmor deployment and protecting against potential exploits or vulnerabilities.

References: KubeArmor Security Enhancements

Issues: https://github.com/kubearmor/KubeArmor/issues/1186

PRs:

• https://github.com/kubearmor/KubeArmor/pull/1526

• https://github.com/kubearmor/KubeArmor/pull/1661

Additional Columns for KubeArmor Policies

Previously, when listing KubeArmor Security Policies (KSPs) and Host Security Policies (HSPs) using kubectl get, users only had access to limited information about each policy, making it challenging to quickly assess the purpose and impact of each policy. To improve visibility and usability, policy status now includes additional columns. These columns display the action (Allow/Audit/Block) and severity level for each policy. This enhancement allows users to quickly identify the intended behavior and potential impact of each policy, facilitating easier policy management and enabling more informed decision-making when deploying or updating security policies within their Kubernetes environment.

References:

Issues: https://github.com/kubearmor/KubeArmor/issues/1326https://github.com/dqsully

PRs: https://github.com/kubearmor/KubeArmor/pull/1683

Support for Alibaba Cloud

As Kubernetes adoption continues to grow, organizations are increasingly leveraging various cloud providers to host their deployments. Previously, KubeArmor lacked official support for Alibaba Cloud deployments, which could pose challenges for users seeking to secure their Kubernetes workloads running on Alibaba Cloud's infrastructure. To address this gap, KubeArmor now officially supports Alibaba Cloud deployments, including Alibaba Cloud Kubernetes (ACK) and Elastic Compute Services (Virtual Machines). This support ensures that KubeArmor can be seamlessly deployed and integrated with Alibaba Cloud environments, providing robust security for your Kubernetes workloads running on Alibaba Cloud. With this addition, KubeArmor expands its reach and enables organizations leveraging Alibaba Cloud to benefit from its advanced security capabilities, ensuring consistent protection across various cloud platforms. The latest image of Alibaba Cloud Linux 3 contains BPF-LSM enabled by default as part of the kernel config but not enabled by default as part of the boot parameter. Thus the user has to enable BPF-LSM boot for all the nodes for which they desire to secure with KubeArmor. Checkout the FAQ for Checking And Enabling Support For BPF LSM.

Performance Improvements

In large-scale Kubernetes deployments with numerous nodes and pods, the overhead associated with listing and watching all resources can significantly impact performance and scalability. Previously, each KubeArmor DaemonSet pod listed and watched every node and pod in the cluster, leading to potential performance bottlenecks and resource constraints as the cluster grew larger. To address this performance concern, KubeArmor now filters watched nodes and pods server-side, reducing overhead significantly in large clusters. Instead of each KubeArmor DaemonSet pod listing and watching every node and pod in the cluster, KubeArmor now specifies the nodes and pods of interest for each DaemonSet. This optimization enhances the overall performance and scalability of KubeArmor in large-scale Kubernetes deployments, ensuring efficient resource utilization and enabling smoother operations in resource-constrained environments. Special thanks to dqsully for recognizing and fixing this!

PRs: https://github.com/kubearmor/KubeArmor/pull/1676

Security update! Announcing the release of KubeArmor v0.10, packed with exciting new features, enhancements, and fixes. This release brings improved default visibility settings, enriched telemetry, and alert data, support for new platforms, and various installation fixes. The community has collaboratively worked to deliver a solid new release. Let’s get into the details of what's new in KubeArmor v0.10:

Enrichment of Telemetry and Alerts Data

For better visibility, alerts, and telemetry, KubeArmor now includes Deployment Name, Pod Name, Namespace, and Cluster Name. This strategy improves analysis and monitoring, allowing for comprehensive deployments and effective troubleshooting. Added support for deployment scenarios (replicasets, statefulsets, daemonset). This makes it easier for you to base decisions on accurate metadata. You can now expect even more detailed and insightful information, empowering you to monitor and analyze your workloads with greater precision.

{
  "Timestamp": 1679588263,
  "UpdatedTime": "2023-03-23T16:17:43.146109Z",
  "ClusterName": "default",
  "HostName": "prateek-lenovo-ideapad-310-15isk",
  "NamespaceName": "default",
  "Owner": {
    "Ref": "DaemonSet",
    "Name": "my-daemonset",
    "Namespace": "default"
  },
  "PodName": "my-daemonset-xhrr9",
  "Labels": "app=my-app",
  "ContainerID": "0e6a98ec00521ed92fd29664ae238f60463a93b819e6c54a4494cf371e63e86a",
  "ContainerName": "my-container",
  "ContainerImage": "docker.io/library/nginx:latest@sha256:1ed4dff2b99011798f2c228667d7cb4f4e2bd76b2adc78fd881d39f923e78c9d",
  "HostPPID": 671928,
  "HostPID": 672009,
  "PPID": 41,
  "PID": 46,
  "ParentProcessName": "/bin/bash",
  "ProcessName": "/bin/sleep",
  "PolicyName": "new",
  "Severity": "5",
  "Message": "block /bin/sleep",
  "Type": "MatchedPolicy",
  "Source": "/bin/bash",
  "Operation": "Process",
  "Resource": "/bin/sleep",
  "Data": "syscall=SYS_EXECVE",
  "Enforcer": "AppArmor",
  "Action": "Block",
  "Result": "Permission denied"
}

Note the availability of owner nested json in the above telemetry event that provides details about the owner references that generated this telemetry event.

Support for BPF-LSM in Non-Orchestrated Containerized Workloads

In the previous versions, enforcement in containerized workloads was limited to AppArmor. We are delighted to introduce support for BPF-LSM (Linux Security Modules) in non-orchestrated containerized workloads. This new capability allows you to leverage the benefits of BPF-based security policies even outside of orchestrated environments. You can now avail the benefits of BPF LSM for enhanced security and fine-grained control over containerized workloads.

By incorporating BPF LSM enforcement, KubeArmor enables users to define and enforce security policies at the kernel level, providing an additional layer of protection for their containerized environments. Advanced capabilities offered by BPF LSM, including powerful eBPF (extended Berkeley Packet Filter) programs and flexible security rules, are now unlocked!

Helm Installation Fixes

For smoother deployments using Helm, we have addressed several issues and made necessary fixes. To benefit from these improvements, please refer to our updated Helm installation guide. If you are still facing any issues, please put it up in the discussions.

Auto-Updating Dependencies

To ensure you always have the latest dependencies, KubeArmor now utilizes Renovate, an automated dependency update tool. With Renovate, you can expect a seamless experience, as KubeArmor keeps your dependencies up to date automatically. Everything synced!

Support for New Platforms

With this release, we have expanded our platform support to include:

1. DigitalOcean Kubernetes (DOKs)

2. Mirantis MKE.

3. Amazon Linux 2023.

This means you can now confidently run KubeArmor on these platforms, benefiting from enhanced security and protection.

Default Visibility Changes

In previous versions, KubeArmor enabled full telemetry by default for all workloads. With v0.10, we have made a significant change. By default, telemetry for workloads is now disabled, offering more flexibility in managing telemetry settings. If you want to enable telemetry for specific workloads or namespaces, you can easily do so using annotations.

Miscellaneous

We are grateful to our dedicated community for their continuous support and valuable contributions that have made this release possible. Your feedback and suggestions drive us to improve KubeArmor with every release.

To explore the complete list of changes, bug fixes, and enhancements in KubeArmor v0.10, please refer to our release notes.

Upgrade to KubeArmor v0.10 today and experience the latest features and fixes firsthand. We look forward to hearing your thoughts and helping you strengthen the security of your Kubernetes deployments.

Got any questions? Check out the FAQ page or join the KubeArmor Slack for support.

Stay tuned for more updates and exciting features on our roadmap. Together, let's build a more secure and resilient Kubernetes ecosystem!

We are excited to announce the release of KubeArmor v1.6, packed with powerful new features, significant enhancements, and critical bug fixes that make workload protection and observability even more robust for cloud-native environments.

This release reflects major advancements in policy enforcement, system monitoring, and ecosystem integrations while addressing important stability and performance improvements.

Watch the KubeArmor v1.6 Release Overview

Key Features & Enhancements

🔐 Advanced Process Arguments Matching

• Introduced argument-based matching for processes in policies.

• Allows precise control over command-line arguments, enabling granular process enforcement.

• This feature is currently limited to BPFLSM.

• Example policy:

  Copy

  apiVersion: security.kubearmor.com/v1
  kind: KubeArmorPolicy
  metadata:
    name: allow-steampipe-args
  spec:
    selector:
      matchLabels:
        app: steampipe
    process:
      matchPaths:
      - path: /usr/bin/python3.6
        allowedArgs:
          - -m
          - modules.steampipe_aws
    action: Block

➕ Add support for non-Kubernetes installation through the KubeArmor client

📡 DNS Visibility at Pod-Level

• Added DNS query tracing on UDP to provide insights into domain lookups from workloads.

• Helps detect malicious behaviors like DGA (Domain Generation Algorithms) or unauthorized C2 communications.

🛡️ New Policy Presets

• ProtectProc: Blocks unauthorized access to the /proc directory by non-owner processes.

• ProtectEnv: Prevents unauthorized access to sensitive environment variables in /proc/[pid]/environ.

• ExecPreset: Enforces restrictions on external process executions (e.g., via kubectl exec).

🔌 Container Runtime Enhancements

• OCI Hooks Support:

  • Added support for containerd and CRI-O hooks, eliminating the need for exposing runtime UNIX sockets for container events.

📈 Improved Telemetry and Observability

• Added TTY information in BPF-LSM generated telemetry.

• Enhanced telemetry with network metadata using Kubernetes informers.

• Extended alert resources to include full command arguments.

🌐 Ecosystem and Integrations

• OpenSearch Support: Added OpenSearch as a datasource for process graphs in Grafana dashboards.

• Integrated image vulnerability scanning workflows (via Trivy) in release pipelines.

🛠️ Bug Fixes and Stability Improvements

• Resolved memory leaks in AppArmor DaemonSet (observed in AKS clusters).

• Fixed policy deletion logic for recommended policies in the operator.

• Addressed KubeArmorClusterPolicy enforcement issue for pods created post-policy application.

• Fixed panic errors with uninitialized Docker daemons.

• Resolved tolerations propagation issues in Helm chart deployments.

• Improved filtering logic in karmor profile commands to respect namespace, pod, and container filters.

• Fixed PID/HostPID and PPID/HostPPID display anomalies (e-notation issues).

⚙️ Additional Improvements

• Helm charts updated to handle tolerations properly.

• Introduced conditional deployment of pod refresh controllers.

• Updated CI pipelines to use Ubuntu 22.04 runners and separated network tests for newer kernels.

• Deprecated legacy Config Watcher in favor of karmor.yaml configuration.

🚨 Breaking Changes

• Preset API Specification Updated:

  • Action is now defined per-preset level:

    Copy

    presets:
      - name: protectEnv
        action: Block

• Configuration changes via karmor.yaml will eventually replace existing ConfigMap fields.

📖 Documentation Updates

• Revised hardening policies and presets documentation.

• Updated multi-OS deployment instructions and CLI long descriptions.

• Added ModelArmor use-cases and a better getting started guide

✅ Upgrade Notes

• Users are advised to review preset configurations and update CRDs accordingly.

• When upgrading from v1.5, ensure Helm charts are updated to leverage new toleration handling and configuration management features.

📌 Contributors

This release wouldn’t have been possible without the incredible contributions from the community. Special thanks to all contributors for feature development, bug fixes, and reviews. 🙌

🔗 Resources

• 📚 KubeArmor Documentation

• 🛠️ GitHub Repository

• 📝 Changelog

KubeArmor currently supports enabling visibility for containers and hosts.

Visibility for hosts is not enabled by default, however it is enabled by default for containers .

The karmor tool provides access to both using karmor logs.

Prerequisites

• If you don't have access to a K8s cluster, please follow this to set one up.

• karmor CLI tool: Download and install karmor-cli

Example: wordpress-mysql

• To deploy wordpress-mysql app follow this

• Now we need to deploy some sample policies

kubectl apply -f https://raw.githubusercontent.com/kubearmor/KubeArmor/main/examples/wordpress-mysql/security-policies/ksp-wordpress-block-process.yaml

This sample policy blocks execution of the apt and apt-get commands in wordpress pods with label selector app: wordpress.

Getting Container Visibility

• Checking default visibility

  • Container visibility is enabled by default. We can check it using kubectl describe and grep kubearmor-visibility

  Copy

  POD_NAME=$(kubectl get pods -n wordpress-mysql -l app=wordpress -o jsonpath='{.items[0].metadata.name}') && kubectl describe -n wordpress-mysql pod $POD_NAME | grep kubearmor-visibility
  
  kubearmor-visibility: process, file, network, capabilities

  • For pre-existing workloads : Enable visibility using kubectl annotate. Currently KubeArmor supports process, file, network, capabilities

  Copy

  kubectl annotate pods <pod-name> -n wordpress-mysql "kubearmor-visibility=process,file,network,capabilities"

• Open up a terminal, and watch logs using the karmor cli

  Copy

  karmor logs

• In another terminal, simulate a policy violation . Try sleep inside a pod

  Copy

  POD_NAME=$(kubectl get pods -n wordpress-mysql -l app=wordpress -o jsonpath='{.items[0].metadata.name}') && kubectl -n wordpress-mysql exec -it $POD_NAME -- bash
  # apt update

• In the terminal running karmor logs, the policy violation along with container visibility is shown, in this case for example

• The logs can also be generated in JSON format using karmor logs --json

Getting Host Visibility

• Host Visibility is not enabled by default . To enable Host Visibility we need to annotate the node using kubectl annotate node

  kubectl annotate node <node-name> "kubearmor-visibility=process,file,network,capabilities" 

• To confirm it use kubectl describe and grep kubearmor-visibility

kubectl describe node <node-name> | grep kubearmor-visibility

• Now we can get general telemetry events in the context of the host using karmor logs .The logs related to Host Visibility will have type Type: HostLogand Operation: File | Process | Network

karmor logs --logFilter=all

== Alert / 2023-01-04 04:58:37.689182 ==
== Log / 2023-01-27 14:41:49.017709 ==
ClusterName: default
HostName: kubearmor-dev2
Type: HostLog
Source: /usr/bin/dockerd
Resource: /usr/bin/runc --version
Operation: Process
Data: syscall=SYS_EXECVE
Result: Passed
HostPID: 193088
HostPPID: 914
PID: 193088
PPID: 914
ParentProcessName: /usr/bin/dockerd
ProcessName: /usr/bin/runc
== Log / 2023-01-27 14:41:49.018951 ==
ClusterName: default
HostName: kubearmor-dev2
Type: HostLog
Source: /usr/bin/runc --version
Resource: /lib/x86_64-linux-gnu/libc.so.6
Operation: File
Data: syscall=SYS_OPENAT fd=-100 flags=O_RDONLY|O_CLOEXEC
Result: Passed
HostPID: 193088
HostPPID: 914
PID: 193088
PPID: 914
ParentProcessName: /usr/bin/dockerd
ProcessName: /usr/bin/runc
== Log / 2023-01-27 14:41:49.018883 ==
ClusterName: default
HostName: kubearmor-dev2
Type: HostLog
Source: /usr/bin/runc --version
Resource: /etc/ld.so.cache
Operation: File
Data: syscall=SYS_OPENAT fd=-100 flags=O_RDONLY|O_CLOEXEC
Result: Passed
HostPID: 193088
HostPPID: 914
PID: 193088
PPID: 914
ParentProcessName: /usr/bin/dockerd
ProcessName: /usr/bin/runc
== Log / 2023-01-27 14:41:49.020905 ==
ClusterName: default
HostName: kubearmor-dev2
Type: HostLog
Source: /var/lib/rancher/k3s/data/2949af7261ce923f6a5091396d266a0e9d9436dcee976fcd548edc324eb277bb/bin/k3s
Resource: /var/lib/rancher/k3s/data/2949af7261ce923f6a5091396d266a0e9d9436dcee976fcd548edc324eb277bb/bin/portmap
Operation: Process
Data: syscall=SYS_EXECVE
Result: Passed
HostPID: 193090
HostPPID: 5627
PID: 193090
PPID: 5627
ParentProcessName: /var/lib/rancher/k3s/data/2949af7261ce923f6a5091396d266a0e9d9436dcee976fcd548edc324eb277bb/bin/k3s
ProcessName: /var/lib/rancher/k3s/data/2949af7261ce923f6a5091396d266a0e9d9436dcee976fcd548edc324eb277bb/bin/portmap

Updating Namespace Visibility

KubeArmor has the ability to let the user select what kind of events have to be traced by changing the annotation kubearmor-visibility at the namespace.

• Checking Namespace visibility

  • Namespace visibility can be checked using kubectl describe.

  Copy

  kubectl describe ns wordpress-mysql | grep kubearmor-visibility
  
  kubearmor-visibility: process, file, network, capabilities

  • To update the visibility of namespace : Now let's update Kubearmor visibility using kubectl annotate. Currently KubeArmor supports process, file, network, capabilities. Lets try to update visibility for the namespace wordpress-mysql

  Copy

   kubectl annotate ns wordpress-mysql kubearmor-visibility=network --overwrite
   "namespace/wordpress-mysql annotated"
  

  Note: To turn off the visibility across all aspects, use kubearmor-visibility=none. Note that any policy violations or events that results in non-success returns would still be reported in the logs.

• Open up a terminal, and watch logs using the karmor cli

  Copy

  karmor logs --logFilter=all -n wordpress-mysql
  

• In another terminal, let's exec into the pod and run some process commands . Try ls inside the pod

  Copy

    POD_NAME=$(kubectl get pods -n wordpress-mysql -l app=wordpress -o jsonpath='{.items[0].metadata.name}') && kubectl -n wordpress-mysql exec -it $POD_NAME -- bash
  # ls

  Now, we can notice that no logs have been generated for the above command and logs with only Operation: Network are shown.

  Note If telemetry is disabled, the user wont get audit event even if there is an audit rule.

  Note Only the logs are affected by changing the visibility, we still get all the alerts that are generated.

• Let's simulate a sample policy violation, and see whether we still get alerts or not.

  • Policy violation :

  Copy

  POD_NAME=$(kubectl get pods -n wordpress-mysql -l app=wordpress -o jsonpath='{.items[0].metadata.name}') && kubectl -n wordpress-mysql exec -it $POD_NAME -- bash
  #apt 

  Here, note that the alert with Operation: Process is reported.

We're thrilled to introduce the latest release of KubeArmor, version v0.11! This significant update reinforces our commitment to providing top-tier container-level security for Kubernetes deployments. With an array of new features, integrations, and improvements, KubeArmor v0.11 empowers you to achieve even greater security and control over your containerized workloads. Let's delve into the key highlights of this release:

Operator support: Simplifying Management and Deployment

KubeArmor v0.11 comes with robust operator support, making the installation, configuration, and management of KubeArmor instances a breeze. The KubeArmor Operator streamlines the deployment process, enabling you to efficiently set up and maintain KubeArmor across your Kubernetes clusters. Embrace simplicity and consistency in managing your security policies.

Elements of KubeArmor Operator design:

• Operator: Operator is the initial component that gets deployed as part of helm based installation. The job of the operator is to reconcile the current state of KubeArmor to its intended state.

• Snitch: Snitch is a job deployed by operator to check what is the prevalent LSM (Linux Security Modules) and the container runtime on each of the node. Snitch then directs the KubeArmor daemonset to use these parameters to accordingly use the appropriate enforcer and container runtime primitives.

• bpf-containerd: This is essentially the KubeArmor daemonset that does most of the work from observability to policy enforcement. Note that the name of the daemonset is dependent on the underlying enforcer (bpf, apparmor) that is used and the container runtime that is detected.

• Relay: KubeArmor Relay connects to each of the daemonset and collects the alerts/telemetry/log and makes it available at single GRPC endpoint. External services can connect to KubeArmor Relay to gets the alerts/telemetry from a single point. Relay is available as a k8s deployment/service.

• Controller: KubeArmor controller reconciles the KubeArmor policies. One of the biggest advantage of KubeArmor is its use of k8s-native design for policy management. Users can enable disable policies at will by applying/deleting the policies at runtime. This enables a wide range of possibilities such as time-based policy activation.

OpenTelemetry

The OpenTelemetry KubeArmor adapter converts KubeArmor telemetry data (logs, visibilty events, policy violations) to the openTelemetry format. This adds opentelemetry support to KubeArmor providing a vendor agnostic means of exporting KubeArmor's telemetry data to various observability backend such as elastic search, grafana, signoz and a bunch of other opentelemetry adopters!

To enhance your observability capabilities, KubeArmor now seamlessly integrates with Open Telemetry. Gain unparalleled insights into container behavior and workload interactions through comprehensive telemetry data collection. With this integration, you'll be equipped to make informed decisions, swiftly identify anomalies, and proactively address potential security threats.

Credits: Amazing work by Maureen Ononiwu for handling KubeArmor's OpenTelemetry integration as part of LFX Mentorship. 🚀

Announcing k8tls (pronounced cattles): k8s service endpoints TLS best practices assessment

Security extends beyond containers. KubeArmor v0.11 introduces k8tls to bolster transport layer security within Kubernetes clusters. Safeguard your communications with enhanced encryption, safeguarding your data and ensuring the confidentiality of sensitive information.

K8tls is a k8s-native service endpoint scanning engine that verifies whether the endpoint is using secure communication and is using right security configuration. K8tls deploys itself as a k8s job that scans/fingerprints k8s service endpoints to identify if TLS best practices are followed. Primary features include:

• 🔒 Check if the server port is TLS enabled or not.

• 📃 Check TLS version, Ciphersuite, Hash, and Signature for the connection. Are these TLS parameters per the TLS best practices guide?

• Certificate Verification

  • 💥 Is the certificate expired or revoked?

  • ✍️ Is it a self-signed certificate?

  • ⛓️ Is there a self-signed certificate in the full certificate chain?

KubeArmor as Canonical Microk8s Addon

Microk8s is a full embedded Kubernetes platform that is lightweight yet robust and scalable and is a perfect fit for edge, embedded scenarios. KubeArmor support for Canonical MicroK8s as a community addon is merged making microk8s more secure. Microk8s with KubeArmor brings enterprise grade security to lightweight edge kubernetes environments.

Kind and Minikube Compatibility

With this release, KubeArmor extends its compatibility to Kind and Minikube clusters, enabling you to effortlessly apply KubeArmor's security policies to your local testing and development environments. Maintain consistency between testing and production while fortifying your workloads.

karmor profile

karmor logs tool provides raw telemetry out of the box. However, you may want to summarize the process, file, network, syscall events over a period of time. karmor profile introduces a way to handle the summarization. KubeArmor community followers might realize that the base profile feature was added in v0.8 release. v0.11 vastly improves the usability of the features, for e.g, by sorting the data based on process name, summarizing/aggregating well, adding syscall related event summarization etc.

EKS Addon published: Simplifing EKS deployment

Amazon EKS Anywhere allows installing and managing Kubernetes clusters on your own infrastructure, with optional support from AWS. EKS Anywhere supports full lifecycle management of multiple Kubernetes clusters that can operate completely independently of any AWS services. It provides open-source software that’s up to date and patched so you can have an on-premises Kubernetes environment that’s more reliable than a self-managed Kubernetes offering. EKS Anywhere is compatible with Bare Metal, CloudStack, and VMware vSphere as deployment targets.

Although EKS Anywhere can make cluster administration easier, the issue of protecting how Kubernetes namespaces, pods, workloads, and clusters interaction and access of shared resources remains an unsolved problem. It is imperative that workloads are protected at runtime since most of the attacks such as cryptomining, ransomware, data exfiltration, denial of service are manifest once the workloads are deployed in target k8s environment.

In line with the recommended safety guidelines for EKS, KubeArmor comprehensively fulfills these requirements. Getting up to speed on the Kubernetes threat environment proves to be difficult for security teams. New responsibilities for Kubernetes infrastructure and workloads lead to high overhead. Furthermore, ensuring that platform and application teams have consistency and complete visibility across environments for configurations and settings to fulfill AWS EKS security best practices can be difficult. KubeArmor helps you take care of most of these for you.

Streamlined Deployment: Updated Helm Chart

Deploying KubeArmor has never been smoother. The updated Helm chart simplifies the installation process, ensuring that you can effortlessly manage KubeArmor's security policies across your Kubernetes clusters. Spend less time configuring and more time securing. Use of KubeArmor Operator greatly simplifies the auto detection of cluster components and deploying the kubearmor accordingly. For example, no more mounting of unwanted host mount points to just detect the container runtime in use.

Staying in Sync with Infrastructure: Terraform Updates

For those who embrace infrastructure-as-code, KubeArmor v0.11 offers updated Terraform integration. Seamlessly incorporate KubeArmor into your Terraform workflows, ensuring consistent security provisioning throughout your infrastructure.

Open source KubeArmor terraform provider from AccuKnox helps provision KubeArmor deployments, policies, and configuration at scale using Hashicorp Terraform.

Pushing Boundaries: Scale Testing with KubeArmor-Relay

Scalability is of paramount importance. One of primary hurdle to observability/monitoring solutions is its impact on runtime performance. With v0.11, we tested logging/telemetry components such as KubeArmor-Relay for scale of 100s of nodes. Through rigorous testing under varying workloads, KubeArmor v0.11 ensures unwavering performance even in the most dynamic Kubernetes environments.

Flourishing Ecosystem: Adopters Update

Our community of adopters continues to grow, and we're immensely grateful for your support. Join a vibrant community of users and contributors who are shaping the future of container security. Together, we're elevating Kubernetes security to new heights.

Thanks/Credits

We extend our gratitude to our dedicated community, whose feedback and contributions drive the evolution of KubeArmor. Dive into the cutting-edge security enhancements of KubeArmor v0.11 and fortify your Kubernetes environment with confidence.

To explore the latest features and embark on your journey with KubeArmor v0.11, visit our official GitHub repository and comprehensive documentation.

Secure your containers, fortify your Kubernetes clusters — experience KubeArmor v0.11 today.

Stay secure, The KubeArmor Team

KubeArmor v0.5 Release Notes

KubeArmor adds a number of new capabilities in this 0.5 release, including:

• support for BPF-LSM policy enforcement,

• integration with the Kubernetes admission controller, and

• support for the CRI-O container runtime engine.

We’ve expanded platform support to include AWS Bottlerocket and Linux 2 and Microsoft AKS. We’ve also added support for network rules in SELinux, made improvements to the CLI, along with other enhancements and fixes.

Support for BPF-LSM for policy enforcement

KubeArmor today leverages LSMs such as AppArmor, SELinux for policy enforcement. With v0.5, Kubearmor now integrates with BPF-LSM for pod/container based policy enforcement as well. BPF-LSM is a new LSM (Linux Security Modules) that is introduced in the newer kernels (version > 5.7). BPF-LSM allows Kubearmor to attach bpf-bytecode at LSM hooks. This changes everything, since now with bpf-bytecode kubearmor has access to much richer information/kernel context and it does not have to work within the constraints of SELinux and AppArmor policy language.

What platforms support BPF-LSM?

• Latest images of GKE COS (> 1.22.6-gke.1000 ref)

• AWS Bottlerocket

• Latest images of Amazon Linux 2. Note: The default Amazon Linux 2 is still at kernel version 5.4 and hence bpf-lsm cannot be used with it.

• Most of the managed cloud platforms are already leveraging latest kernel images in their latest OS images. Detailed information could be found here.

In fact in most of the latest kernels, the bpf-lsm config is enabled by default.

Relevant Issues/PRs: #484, #741

What happens if the OS image supports both AppArmor and BPF-LSM? What will be used for policy enforcement?

If BPF-LSM is available, that takes priority by default. Note that BPF-LSM is a stackable LSM (unlike AppArmor, SELinux) which means it can be enabled with existing non-stackable LSMs such as AppArmor/SELinux. Thus if for some reason the bpf-lsm enforcer fails, the AppArmor enforcer will be automatically used underneath the hood.

Is their any change in the KubeArmorPolicy construct for BPF-LSM?

No. The existing constructs work as it is. This means for the user, there is no change in the way policies have to be specified.

Support for AWS Bottlerocket 🚀 and Amazon Linux 2 (latest image)

What security does Bottlerocket offer?

Bottlerocket is a security focussed Linux based Open Source OS from Amazon that is purpose built for container based workloads. The intention with Bottlerocket is to avoid installation of maintenance packages directly as part of host OS and install only bare-minimum host packages that are required to run the containers. Maintenance tools could in turn be installed as containers if necessary.

How Kubearmor improves on Bottlerocket security?

Bottlerocket uses SELinux to lock down the host and provides some limited inter-container isolation.

KubeArmor provides enhanced security by using BPF-LSM to protect Bottlerocket containers from within by limiting system behavior with respect to processes, files, etc. For e.g., a k8s security access token that is mounted within the pod is accessible by default across all the containers. KubeArmor can restrict access to such tokens only for certain processes. Similarly KubeArmor can be used to protect other sensitive information e.g., k8s secrets, x509 certs, within the container. Moreover, KubeArmor can restrict execution of certain binaries within the containers.

Want to try out AWS Bottlerocket with KubeArmor?

Here is the quick start guide.

KubeArmor now uses k8s admission controller to inject security annotations

KubeArmor depends upon AppArmor, SELinux and the underlying LSMs for security policy enforcement. In the context of k8s, such policies need to be specified as annotations. Before v0.5, Kubearmor used to apply deployment patch to inject such annotations. This resulted in the deployment to be restarted. Furthermore, one cannot apply annotations to pods that are not started as part of deployments.

In v0.5, Kubearmor has started making use of k8s admission controller feature to inject annotations in the pod. This resolves the deployment restart issue as well as the annotations can now be applied to pods as well.

The detailed design document can be found here.

Relevant issues/PRs: #360, #687, #655

Support for CRI-O

KubeArmor directly interfaces with container runtimes to get metadata like container’s namespaces, image and so on. This metadata is then used for generating rich telemetry data and policy enforcement.

In the past, KubeArmor has supported Containerd and Docker and now with v0.5, KubeArmor will also support the CRI-O runtime. This has been made possible by leveraging the CRI-API. Also, if you have multiple container runtimes, you can now use the CRI_SOCKET environment var or the -criSocket flag with kubearmor for specifying one to use.

Relevant Issues/PRs: #697

Support for Microsoft AKS

KubeArmor now supports Microsoft AKS and has been validated with the default OS images used on AKS.

Relevant PRs: #721

Network rules support for SELinux

Kubearmor process-bound network rules allows one to limit network communication to only certain processes. It is possible to enable/disable TCP/UDP/ICMP communication for certain processes only.

apiVersion: security.kubearmor.com/v1
kind: KubeArmorHostPolicy
metadata:
  name: ksp-block-curl-tcp
spec:
  severity: 8
  selector:
    matchLabels:
      kubernetes.io/hostname: gcp-host-tunnel
  network:
    matchProtocols:
    - protocol: tcp
      fromSource:
        - path: /usr/bin/curl
  action:
    Block

The above policy prevents /usr/bin/curl from initiating tcp connection.

SELinux support was added as part of v0.4.4 but could not handle the [network based rules]. v0.5 adds support for network based rules.

Improvements to kubearmor cli tool

Kubearmor client tool can be used to install, uninstall, watch alerts/telemetry, observe and discover kubearmor security policies. The client tool automatically identifies the underlying k8s/container platform and appropriates handles the deployment. The same client tool can be used across any deployment mode (viz, k8s, pure-containerized and VM/Bare-metal).

Kubearmor client tool was extended to support different filtering options based on process name, resource type, namespace, labels etc. This filtering implementation was handled by a LFX mentee and is documented here.

KubeArmor supports configurable default security posture. The security posture could be allow/audit/deny. Default Posture is used when there's atleast one Allow policy for the given deployment i.e. KubeArmor is handling policies in whitelisting manner (more about this in ).

There are two default mode of operations available block and audit. block mode blocks all the operations that are not allowed in the policy. audit generates telemetry events for operations that would have been blocked otherwise.

KubeArmor has 4 types of resources: Process, File, Network and Capabilities. Default Posture is configurable for each of the resources seperately except Process. Process based operations are treated under File resource only.

Configuring Default Posture

Global Default Posture

Note By default, KubeArmor set the Global default posture to audit

Global default posture is configured using configuration options passed to KubeArmor using configuration file

Or using command line flags with the KubeArmor binary

Namespace Default Posture

We use namespace annotations to configure default posture per namespace. Supported annotations keys are kubearmor-file-posture,kubearmor-network-posture and kubearmor-capabilities-posture with values block or audit. If a namespace is annotated with a supported key and an invalid value ( like kubearmor-file-posture=invalid), KubeArmor will update the value with the global default posture ( i.e. to kubearmor-file-posture=block).

Example

Let's start KubeArmor with configuring default network posture to audit in the following YAML.

Contents of kubearmor.yaml

Here's a sample policy to allow tcp connections from curl binary.

Note: This example is in the environment.

Inside the ubuntu-5-deployment, if we try to access tcp using curl. It works as expected with no telemetry generated.

If we try to access udp using curl, a bunch of telemetry is generated for the udp access.

curl google.com requires UDP for DNS resolution.

Generated alert has Policy Name DefaultPosture and Action as Audit

Now let's update the default network posture to block for multiubuntu namespace.

Now if we try to access udp using curl, the action is blocked and related alerts are generated.

Here curl couldn't resolve google.com due to blocked access to UDP.

Generated alert has Policy Name DefaultPosture and Action as Block

Let's try to set the annotation value to something invalid.

We can see that, annotation value was automatically updated to audit since that was global mode of operation for network in the KubeArmor configuration.

Welcome back to the KubeArmor tutorial! In the previous chapter, we learned about KubeArmor's Security Policies (KSP, HSP, CSP) and how they define rules for what applications and processes are allowed or forbidden to do. We saw that these policies use selectors (like labels and namespaces) to tell KubeArmor which containers, pods, or nodes they should apply to.

But how does KubeArmor know which policy to apply when something actually happens, like a process trying to access a file? When an event occurs deep within the operating system (like a process accessing /etc/shadow), the system doesn't just say "a pod with label app=my-web-app did this". It provides low-level details like Process IDs (PID), Parent Process IDs (PPID), and Namespace IDs (like PID Namespace and Mount Namespace).

This is where the concept of Container/Node Identity comes in.

What is Container/Node Identity?

Think of Container/Node Identity as KubeArmor's way of answering the question: "Who is doing this?".

When a system event happens on a node – maybe a process starts, a file is opened, or a network connection is attempted – KubeArmor intercepts this event. The event data includes technical details about the process that triggered it. KubeArmor needs to take these technical details and figure out if the process belongs to:

1. A specific Container (which might be part of a Kubernetes Pod or a standalone Docker container).

2. Or, the Node itself (the underlying Linux operating system, potentially running processes outside of containers).

Once KubeArmor knows who is performing the action (the specific container or node), it can then look up the relevant security policies that apply to that identity and decide whether to allow, audit, or block the action.

Why is Identity Important? A Simple Use Case

Imagine you have a KubeArmorPolicy (KSP) that says: "Block any attempt by containers with the label app: sensitive-data to read the file /sensitive/config.":

Now, suppose a process inside one of your containers tries to open /sensitive/config.

• Without Identity: KubeArmor might see an event like "Process with PID 1234 and Mount Namespace ID 5678 tried to read /sensitive/config". Without knowing which container PID 1234 and MNT NS 5678 belong to, KubeArmor can't tell if this process is running in a container labeled app: sensitive-data. It wouldn't know which policy applies!

• With Identity: KubeArmor sees the event, looks up PID 1234 and MNT NS 5678 in its internal identity map, and discovers "Ah, that PID and Namespace belong to Container ID abc123def456... which is part of Pod my-sensitive-pod-xyz in namespace default, and that pod has the label app: sensitive-data." Now it knows this event originated from a workload targeted by the block-sensitive-file-read policy. It can then apply the Block action.

So, identifying the workload responsible for a system event is fundamental to enforcing policies correctly.

How KubeArmor Identifies Workloads

KubeArmor runs as a DaemonSet on each node in your Kubernetes cluster (or directly on a standalone Linux server). This daemon is responsible for monitoring system activity on that specific node. To connect these low-level events to higher-level workload identities (like Pods or Nodes), KubeArmor does a few things:

1. Watching Kubernetes (for K8s environments): The KubeArmor daemon watches the Kubernetes API Server for events related to Pods and Nodes. When a new Pod starts, KubeArmor gets its details:

   • Pod Name

   • Namespace Name

   • Labels (this is key for policy selectors!)

   • Container details (Container IDs, Image names)

   • Node Name where the Pod is scheduled. KubeArmor stores this information.

2. Interacting with Container Runtimes: KubeArmor talks to the container runtime (like Docker or containerd) running on the node. It uses the Container ID (obtained from Kubernetes or by watching runtime events) to get more low-level details:

   • Container PID (the process ID of the main process inside the container as seen from the host OS).

   • Container Namespace IDs (specifically the PID Namespace ID and Mount Namespace ID). These IDs are crucial because system events are often reported with these namespace identifiers.

3. Monitoring Host Processes: KubeArmor also monitors processes running directly on the host node (outside of containers).

KubeArmor builds and maintains an internal map that links these low-level identifiers (like PID Namespace ID + Mount Namespace ID) to the corresponding higher-level identities (Container ID, Pod Name, Namespace, Node Name, Labels).

Let's visualize how this identity mapping happens and is used:

This diagram shows the two main phases:

1. Identity Discovery: KubeArmor actively gathers information from Kubernetes and the container runtime to build its understanding of which system identifiers belong to which workloads.

2. Event Correlation: When a system event occurs, KubeArmor uses the identifiers from the event (like Namespace IDs) to quickly look up the corresponding workload identity in its map.

Looking at the Code (Simplified)

The KubeArmor code interacts with Kubernetes and Docker/containerd to get this identity information.

For Kubernetes environments, KubeArmor's k8sHandler watches for Pod and Node events:

This snippet shows that KubeArmor isn't passively waiting; it actively watches the Kubernetes API for changes using standard Kubernetes watch mechanisms. When a Pod is added, updated, or deleted, KubeArmor receives an event and updates its internal state.

For Docker (and similar logic exists for containerd), KubeArmor's dockerHandler can inspect running containers to get detailed information:

This function is critical. It takes a containerID and retrieves its associated Namespace IDs (PidNS, MntNS) by reading special files in the /proc filesystem on the host, which link the host PID to the namespaces it belongs to. It also retrieves labels and other useful information directly from the container runtime's inspection data.

This collected identity information is stored internally. For example, the SystemMonitor component maintains a map (NsMap) to quickly look up a workload based on Namespace IDs:

These functions from processTree.go show how KubeArmor builds and uses the core identity mapping: it stores the relationship between Namespace IDs (found in system events) and the Container ID, allowing it to quickly identify which container generated an event.

Identity Types Summary

KubeArmor primarily identifies workloads using the following:

This allows KubeArmor to apply the correct security policies, whether they are KSPs (targeting Containers/Pods based on labels/namespaces) or HSPs (targeting Nodes based on node labels).

Conclusion

Understanding Container/Node Identity is key to grasping how KubeArmor works. It's the crucial step where KubeArmor translates low-level system events into the context of your application workloads (containers in pods) or your infrastructure (nodes). By maintaining a map of system identifiers to workload identities, KubeArmor can accurately determine which policies apply to a given event and enforce your desired security posture.

In the next chapter, we'll look at the component that takes this identified event and the relevant policy and makes the decision to allow, audit, or block the action.

Welcome to the KubeArmor tutorial! In this first chapter, we'll dive into one of the most fundamental concepts in KubeArmor: Security Policies. Think of these policies as the instruction manuals or rulebooks you give to KubeArmor, telling it exactly how applications and system processes should behave.

What are Security Policies?

In any secure system, you need rules that define what is allowed and what isn't. In Kubernetes and Linux, these rules can get complicated, dealing with things like which files a program can access, which network connections it can make, or which powerful system features (capabilities) it's allowed to use.

KubeArmor simplifies this by letting you define these rules using clear, easy-to-understand Security Policies. You write these policies in a standard format that Kubernetes understands (YAML files, using something called Custom Resource Definitions or CRDs), and KubeArmor takes care of translating them into the low-level security configurations needed by the underlying system.

These policies are powerful because they allow you to specify security rules for different parts of your system:

1. KubeArmorPolicy (KSP): For individual Containers or Pods running in your Kubernetes cluster.

2. KubeArmorHostPolicy (HSP): For the Nodes (the underlying Linux servers) where your containers are running. This is useful for protecting the host system itself, or even applications running directly on the node outside of Kubernetes.

3. KubeArmorClusterPolicy (CSP): For applying policies across multiple Containers/Pods based on namespaces or labels cluster-wide.

Why Do We Need Security Policies?

Imagine you have a web server application running in a container. This application should only serve web pages and access its configuration files. It shouldn't be trying to access sensitive system files like /etc/shadow or connecting to unusual network addresses.

Without security policies, if your web server container gets compromised, an attacker might use it to access or modify sensitive data, or even try to attack other parts of your cluster or network.

KubeArmor policies help prevent this by enforcing the principle of least privilege. This means you only grant your applications and host processes the minimum permissions they need to function correctly.

Use Case Example: Let's say you have a simple application container that should never be allowed to read the /etc/passwd file inside the container. We can use a KubeArmor Policy (KSP) to enforce this rule.

Anatomy of a KubeArmor Policy

KubeArmor policies are defined as YAML files that follow a specific structure. This structure includes:

1. Metadata: Basic information about the policy, like its name. For KSPs, you also specify the namespace it belongs to. HSPs and CSPs are cluster-scoped, meaning they don't belong to a specific namespace.

2. Selector: This is how you tell KubeArmor which containers, pods, or nodes the policy should apply to. You typically use Kubernetes labels for this.

3. Spec (Specification): This is the core of the policy where you define the actual security rules (what actions are restricted) and the desired outcome (Allow, Audit, or Block).

Let's look at a simplified structure:

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy # or KubeArmorHostPolicy, KubeArmorClusterPolicy
metadata:
  name: block-etc-passwd-read
  namespace: default # Only for KSP
spec:
  selector:
    # How to select the targets (pods for KSP, nodes for HSP, namespaces/labels for CSP)
    matchLabels:
      app: my-web-app # Apply this policy to pods with label app=my-web-app
  file: # Or 'process', 'network', 'capabilities', 'syscalls'
    matchPaths:
      - path: /etc/passwd
  action: Block # What to do if the rule is violated

Explanation:

• apiVersion and kind: Identify this document as a KubeArmor Policy object.

• metadata: Gives the policy a name (block-etc-passwd-read) and specifies the namespace (default) it lives in (for KSP).

• spec: Contains the security rules.

• selector: Uses matchLabels to say "apply this policy to any Pod in the default namespace that has the label app: my-web-app".

• file: This section defines rules related to file access.

• matchPaths: We want to match a specific file path.

• - path: /etc/passwd: The specific file we are interested in.

• action: Block: If any process inside the selected containers tries to access /etc/passwd, the action should be to Block that attempt.

This simple policy directly addresses our use case: preventing the web server (app: my-web-app) from reading /etc/passwd.

Policy Types in Detail

Let's break down the three types:

KubeArmorPolicy (KSP)

• Applies to pods within a specific Kubernetes namespace.

• Uses selector.matchLabels or selector.matchExpressions to pick which pods the policy applies to, based on their labels.

• Example: Block /bin/bash execution in all pods within the dev namespace labeled role=frontend.

KubeArmorHostPolicy (HSP)

• Applies to the host operating system of the nodes in your cluster.

• Uses nodeSelector.matchLabels to pick which nodes the policy applies to, based on node labels.

• Example: Prevent the /usr/bin/ssh process on nodes labeled node-role.kubernetes.io/worker from accessing /etc/shadow.

KubeArmorClusterPolicy (CSP)

• Applies to pods across multiple namespaces or even the entire cluster.

• Uses selector.matchExpressions which can target namespaces (key: namespace) or labels (key: label) cluster-wide.

• Example: Audit all network connections made by pods in the default or staging namespaces. Or, block /usr/bin/curl execution in all pods across the cluster except those labeled app=allowed-tools.

These policies become Kubernetes Custom Resources when KubeArmor is installed. You can see their definitions in the KubeArmor source code under the deployments/CRD directory:

• KubeArmorPolicy CRD (KSP)

• KubeArmorHostPolicy CRD (HSP)

• KubeArmorClusterPolicy CRD (CSP)

And their corresponding Go type definitions are in types/types.go. You don't need to understand Go or CRD internals right now, just know that these files formally define the structure and rules for creating KubeArmor policies that Kubernetes understands.

How KubeArmor Uses Policies (Under the Hood)

You've written a policy YAML file. What happens when you apply it to your Kubernetes cluster using kubectl apply -f your-policy.yaml?

1. Policy Creation: You create the policy object in the Kubernetes API Server.

2. KubeArmor Watches: The KubeArmor DaemonSet (a component running on each node) is constantly watching the Kubernetes API Server for KubeArmor policy objects (KSP, HSP, CSP).

3. Policy Discovery: KubeArmor finds your new policy.

4. Target Identification: KubeArmor evaluates the policy's selector (or nodeSelector) to figure out exactly which pods/containers or nodes this policy applies to.

5. Translation: For each targeted container or node, KubeArmor translates the high-level rules defined in the policy's spec (like "Block access to /etc/passwd") into configurations for the underlying security enforcer (which could be AppArmor, SELinux, or BPF, depending on your setup and KubeArmor's configuration - we'll talk more about these later).

6. Enforcement: The security enforcer on that specific node is updated with the new low-level rules. Now, if a targeted process tries to do something forbidden by the policy, the enforcer steps in to Allow, Audit, or Block the action as specified.

Here's a simplified sequence:

This flow shows how KubeArmor acts as the bridge between your easy-to-write YAML policies and the complex, low-level security mechanisms of the operating system.

Policy Actions: Allow, Audit, Block

Every rule in a KubeArmor policy (within the spec section) specifies an action. This tells KubeArmor what to do if the rule's condition is met.

• Allow: Explicitly permits the action. This is useful for creating "whitelist" policies where you only allow specific behaviors and implicitly block everything else.

• Audit: Does not prevent the action but generates a security alert or log message when it happens. This is great for testing policies before enforcing them or for monitoring potentially suspicious activity without disrupting applications.

• Block: Prevents the action from happening and generates a security alert. This is for enforcing strict "blacklist" rules where you explicitly forbid certain dangerous behaviors.

Remember the "Note" mentioned in the provided policy specifications: For system call monitoring (syscalls), KubeArmor currently only supports the Audit action, regardless of what is specified in the policy YAML.

Conclusion

In this chapter, you learned that KubeArmor Security Policies (KSP, HSP, CSP) are your rulebooks for defining security posture in your Kubernetes environment. You saw how they use Kubernetes concepts like labels and namespaces to target specific containers, pods, or nodes. You also got a peek at the basic structure of these policies, including the selector for targeting and the spec for defining rules and actions.

Understanding policies is the first step to using KubeArmor effectively to protect your workloads and infrastructure. In the next chapter, we'll explore how KubeArmor identifies the containers and nodes it is protecting, which is crucial for the policy engine to work correctly.

KubeArmor passes AWS Foundational Technical Review (FTR)

The Amazon Foundational Technical Review (FTR) is a framework that enables AWS Partners to detect and remediate issues in solutions and products. It focuses on quality, reliability, and safety and outlines the best practices to meet the set requirements.

KubeArmor applied for an AWS Foundational Technical Review and fulfilled all the set criteria. Changes had to be done in KubeArmor to fulfill the requirements, especially towards the security side of elements. FTR requires that the containers do not use privileged mode. KubeArmor had to be updated to fulfill this requirement.

One of the outcomes of this review was that KubeArmor is now listed as an official AWS Partner Solution.

Profiling KubeArmor logs using karmor

KubeArmor's CLI just received a new feature! karmor profile which in real-time shows a terminal user interface table of three different operations going on in KubeArmor: Process, File and Network. It maintains a counter of each operation that is happening within the cluster, along with other useful details. It directly fetches data from the karmor logs API and displays all the required information. The TUI includes simple navigation between operations and a user input based filter as well.

KubeArmor Image Signing using CoSign

Container Image provenance requires signing an image that provides cryptographic evidence indicating that the author is who they say they are. Software Supply Chain attacks are becoming increasingly common and the onus is on the developers and maintainers to ensure that the workload images are signed. The users of the images have the responsibility to verify the provenance of these images before deploying. Devs, maintainers, and users have to depend on a trusted entity for image provenance. One such framework is provided by the sigstore community. Sigstore provides primitives to sign the images/blobs, ensure certificate transparency, and subsequently provides tools that can be used to verify the images and get the activities records.

This release of KubeArmor introduces a way for KubeArmor to sign the images it pushes to the docker registry using sigstore/cosign such that any external user can verify the authenticity of the image and check the associated transparency logs using sigstore/rekor.

How does KubeArmor use sigstore primitives?

An image signed using KubeArmor pipelines indicates that the image was indeed produced by the appropriate KubeArmor ecosystem.

As a user, how can I verify whether the image is signed by the trusted entity?

One can use cosign verify to check whether the image is signed.

❯ COSIGN_EXPERIMENTAL=1 cosign verify kubearmor/kubearmor@sha256:3a1f3bf3bce191833176e7681b49ae4ae24edad19fa84941dcdda4382a3a44ee | jq

Verification for index.docker.io/kubearmor/kubearmor@sha256:3a1f3bf3bce191833176e7681b49ae4ae24edad19fa84941dcdda4382a3a44ee --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - The existence of the claims in the transparency log was verified offline
  - Any certificates were verified against the Fulcio roots.
[
  {
    "critical": {
      "identity": {
        "docker-reference": "index.docker.io/kubearmor/kubearmor"
      },
      "image": {
        "docker-manifest-digest": "sha256:3a1f3bf3bce191833176e7681b49ae4ae24edad19fa84941dcdda4382a3a44ee"
      },
      "type": "cosign container image signature"
    },
    "optional": {
      "1.3.6.1.4.1.57264.1.1": "https://token.actions.githubusercontent.com",
      "1.3.6.1.4.1.57264.1.2": "push",
      "1.3.6.1.4.1.57264.1.3": "445ee44df72f09f5b539cfdb7cac5b3d5e014e6a",
      "1.3.6.1.4.1.57264.1.4": "ci-latest-release",
      "1.3.6.1.4.1.57264.1.5": "kubearmor/KubeArmor",
      "1.3.6.1.4.1.57264.1.6": "refs/heads/main",
      "Bundle": {
        "SignedEntryTimestamp": "MEUCIQDxQ546JPKpzYj34zmTnaDNEKq2iKpE9eNyO+uh32YSdgIgOAIkgjQ5A7XS24bKZNp/f1RT/TzcZLfrzsHRnruqtbI=",
        "Payload": {
          "body": "eyJhcGlWZXJzaW9uIjoiMC4wLjEiLCJraW5kIjoiaGFzaGVkcmVrb3JkIiwic3BlYyI6eyJkYXRhIjp7Imhhc2giOnsiYWxnb3JpdGhtIjoic2hhMjU2IiwidmFsdWUiOiI2MWYxNjZkYzkzMjNkZTYxZjY1MDVhZTVlNmQ1MDk5ZWI4YjEwZWNiYWExZDhlM2Q2NzdkOTAyMTUzNTlkZWIzIn19LCJzaWduYXR1cmUiOnsiY29udGVudCI6Ik1FVUNJQ2JZNm41ZSsrbzlWOTczS3BFd0lMcXRIQkpkTXRBZHFja2U3SkdXdHM4ZUFpRUF1K05TSVExL2tiR0VSMGVVY3NqR1VqMmdsamwyQmFXSWxUMWt6QnZBQjZRPSIsInB1YmxpY0tleSI6eyJjb250ZW50IjoiTFMwdExTMUNSVWRKVGlCRFJWSlVTVVpKUTBGVVJTMHRMUzB0Q2sxSlNVUnhWRU5EUVhrclowRjNTVUpCWjBsVldtVXZlVzVKZWtwc00ySlhkakJuZWtsaFFrRXlXblpZVmtORmQwTm5XVWxMYjFwSmVtb3dSVUYzVFhjS1RucEZWazFDVFVkQk1WVkZRMmhOVFdNeWJHNWpNMUoyWTIxVmRWcEhWakpOVWpSM1NFRlpSRlpSVVVSRmVGWjZZVmRrZW1SSE9YbGFVekZ3WW01U2JBcGpiVEZzV2tkc2FHUkhWWGRJYUdOT1RXcE5kMDFVUVhsTlJGRXdUMVJGZUZkb1kwNU5hazEzVFZSQmVVMUVVVEZQVkVWNFYycEJRVTFHYTNkRmQxbElDa3R2V2tsNmFqQkRRVkZaU1V0dldrbDZhakJFUVZGalJGRm5RVVZxYVRKMWFrVlZSVEpXT0hwbmVHVTBZMFZQVDI1UFFuTldXSGhyY0ZKalpUQlpkMFlLVm5wT01rUnBiWEpXUm1ST1ZFMHlhR1EyWVhjNGRtdElkamhvT1doU1IzQkVOelE0VkRKQmNGWjZhMlZ5YVdsUWNFdFBRMEZyTkhkblowcExUVUUwUndwQk1WVmtSSGRGUWk5M1VVVkJkMGxJWjBSQlZFSm5UbFpJVTFWRlJFUkJTMEpuWjNKQ1owVkdRbEZqUkVGNlFXUkNaMDVXU0ZFMFJVWm5VVlZzY2paUUNqQTFjRUZhVTBReE0xZEpibEZ4WlhSb1VVNVZWMEYzZDBoM1dVUldVakJxUWtKbmQwWnZRVlV6T1ZCd2VqRlphMFZhWWpWeFRtcHdTMFpYYVhocE5Ga0tXa1E0ZDJKQldVUldVakJTUVZGSUwwSkhTWGRaU1ZwbFlVaFNNR05JVFRaTWVUbHVZVmhTYjJSWFNYVlpNamwwVERKME1WbHRWbWhqYlRGMlkyazVUQXBrVjBwc1VWaEtkR0l6U1haTWJXUndaRWRvTVZscE9UTmlNMHB5V20xNGRtUXpUWFpaTW10MFlrZEdNRnBZVGpCTVdFcHNZa2RXYUdNeVZYVmxWekZ6Q2xGSVNteGFiazEyWVVkV2FGcElUWFppVjBad1ltcEJOVUpuYjNKQ1owVkZRVmxQTDAxQlJVSkNRM1J2WkVoU2QyTjZiM1pNTTFKMllUSldkVXh0Um1vS1pFZHNkbUp1VFhWYU1td3dZVWhXYVdSWVRteGpiVTUyWW01U2JHSnVVWFZaTWpsMFRVSkpSME5wYzBkQlVWRkNaemM0ZDBGUlNVVkNTRUl4WXpKbmR3cE9aMWxMUzNkWlFrSkJSMFIyZWtGQ1FYZFJiMDVFVVRGYVYxVXdUa2RTYlU1NlNtMU5SR3h0VGxkSk1VMTZiR3BhYlZKcFRqSk9hRmw2Vm1sTk1sRXhDbHBVUVhoT1IxVXlXVlJCWmtKbmIzSkNaMFZGUVZsUEwwMUJSVVZDUWtacVlWTXhjMWxZVW14ak0xRjBZMjFXYzFwWFJucGFWRUZvUW1kdmNrSm5SVVVLUVZsUEwwMUJSVVpDUWs1eVpGZEtiRmxZU25SaU0wbDJVek5XYVZwVlJubGlWemw1VFVJd1IwTnBjMGRCVVZGQ1p6YzRkMEZSV1VWRU0wcHNXbTVOZGdwaFIxWm9Xa2hOZG1KWFJuQmlha05DYVdkWlMwdDNXVUpDUVVoWFpWRkpSVUZuVWpoQ1NHOUJaVUZDTWtGT01EbE5SM0pIZUhoRmVWbDRhMlZJU214dUNrNTNTMmxUYkRZME0ycDVkQzgwWlV0amIwRjJTMlUyVDBGQlFVSm9XRVJRTlhNNFFVRkJVVVJCUldOM1VsRkpaMVZDVFdscWMwb3JNbVJPVWxCVU9FVUtlRFYyVEZBNWFtNVVlREZKTW5aaFQycGxaelZOYUhBd2NFaDNRMGxSUkc1TldFdFdlbVZUWXpSakwycElTRGhyVWtwSFpHYzNabEZzVjFCM1JHWm1jd3BuZGxGdmFEQk5ZaTlxUVV0Q1oyZHhhR3RxVDFCUlVVUkJkMDV2UVVSQ2JFRnFSVUV4WlRoaWFVRnFiRkJDZFRjM2FrVXJaM1p3VWtSQmJGcHVTbVZ4Q21FNE5VOHpjWHBvVHpZdk4yTkdkVWhYT0ZSR1dsRnlMMk4yUjBOMVZXWlJPRXhCVlVGcVFVRnhXVEU1YkZJMWF6VkJXWE4zUVhaT2RUaFNSMG92Ym1jS1RHdHNZM3BaU0V4aFpGWTVURmhPUW5vMlZEQmFhM0ZpTWxWdVdHOHJia3QzVUM5TE1qSlpQUW90TFMwdExVVk9SQ0JEUlZKVVNVWkpRMEZVUlMwdExTMHRDZz09In19fX0=",
          "integratedTime": 1672634952,
          "logIndex": 10298691,
          "logID": "c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801d"
        }
      },
      "Issuer": "https://token.actions.githubusercontent.com",
      "Subject": "https://github.com/kubearmor/KubeArmor/.github/workflows/ci-latest-release.yml@refs/heads/main",
      "githubWorkflowName": "ci-latest-release",
      "githubWorkflowRef": "refs/heads/main",
      "githubWorkflowRepository": "kubearmor/KubeArmor",
      "githubWorkflowSha": "445ee44df72f09f5b539cfdb7cac5b3d5e014e6a",
      "githubWorkflowTrigger": "push"
    }
  }
]

As a user, one can check the transparency records from Rekor logs. Example Rekor logs for KubeArmor can be seen here.

Get visibility into the use of server ports

karmor summary of bind/syscalls

Ingress connections
+----------+------------------+-------------------------------+------+-----------+----------------------------+-------+------------------------------+
| PROTOCOL |     COMMAND      |          POD/SVC/IP           | PORT | NAMESPACE |           LABELS           | COUNT |      LAST UPDATED TIME       |
+----------+------------------+-------------------------------+------+-----------+----------------------------+-------+------------------------------+
| TCPv6    | /usr/sbin/mysqld | pod/dvwa-web-59b677c755-xdbsq | 3306 | dvwa      | app=dvwa-web,tier=frontend | 20    | Mon Jan  2 13:52:55 UTC 2023 |
+----------+------------------+-------------------------------+------+-----------+----------------------------+-------+------------------------------+


Egress connections
+----------+---------------------+-----------------------------+------+-----------+--------+-------+------------------------------+
| PROTOCOL |       COMMAND       |         POD/SVC/IP          | PORT | NAMESPACE | LABELS | COUNT |      LAST UPDATED TIME       |
+----------+---------------------+-----------------------------+------+-----------+--------+-------+------------------------------+
| AF_UNIX  | /usr/bin/mysql      | /var/run/mysqld/mysqld.sock | 0    |           |        | 2     | Fri Dec 23 04:49:32 UTC 2022 |
| AF_UNIX  | /usr/bin/mysqladmin | /var/run/mysqld/mysqld.sock | 0    |           |        | 1     | Fri Dec 23 04:49:32 UTC 2022 |
+----------+---------------------+-----------------------------+------+-----------+--------+-------+------------------------------+


Bind Points
+------------+------------------+-----------+--------------+-------+------------------------------+
|  PROTOCOL  |     COMMAND      | BIND PORT | BIND ADDRESS | COUNT |      LAST UPDATED TIME       |
+------------+------------------+-----------+--------------+-------+------------------------------+
| AF_NETLINK | /usr/sbin/mysqld |           |              | 1     | Fri Dec 23 04:49:36 UTC 2022 |
| AF_INET6   | /usr/sbin/mysqld | 3306      | ::           | 1     | Fri Dec 23 04:49:36 UTC 2022 |
+------------+------------------+-----------+--------------+-------+------------------------------+

##Learnings For this release, we tried to use kernel audit for observing policy violations. We faced some issues with it and thus have to revert the changes. Here is a summary of what was expected, what happened, and the learnings from this interesting experiment.

The expectations:

Kernel Audit for fetching policy violations

KubeArmor uses eBPF for two purposes:

1. Get visibility/observability events into the workloads.

2. To get alerts in the context of the policies

The operations involved in point 1 are straightforward i.e, KubeArmor gets an event, matches/annotate the events with the process, container, pod, and namespace information, and sends the event out to the clients waiting on the stream. The operations involved in point 2 are tricky. When KubeArmor gets an event, it needs to check whether the event parameters match any of the policy specifications/rules, and if it does, generate an alert accordingly. The challenge is that the matching operation is a non-trivial operation. Assume that the user has set the policy to block execution of /usr/bin/sleep binary. Now when the event is generated, the kretprobe of the sys_execve syscall is going to return "Permission Denied" since the LSM will block the event. Currently, KubeArmor matches the binary name and other contextual information with the policy rules that it has internally stored and checks whether the event was triggered due to a policy violation. This matching operation is non-trivial. Note that the access could be permission denied for reasons outside the scope of KubeArmor i.e, due to capability LSM or due to other access control settings. Thus it should not be inferred that a "Permission Denied" event will always be triggered due to KubeArmor-enforced policy rules only.

Performance implications

We also expected it to have a drastic (positive) impact on KubeArmor performance since there is no policy-matching code involved in every system call hook.

What was changed?

Traditional LSMs such as AppArmor, and SELinux, use the Kernel Audit mechanism to send the policy violation events. Kernel Audit is supported across most of the kernels. Note that this change does not depend on userspace components such as auditd.

Issues:

• First, we didn't see any noticeable change in the overall performance of KubeArmor, which we measured by looking at the number of alerts being dropped/lost.

• Second and more important, we came up with an issue in AppArmor (or a feature if you want to call it). For Allow-based policies (default posture being Audit), we were getting alerts even in the case of resources that were allowed in the policy. For eg: We cannot create a profile that says, allow access to /root and audit every other access. AppArmor doesn't support this kind of action.

Learnings and future plan:

With the above experiment we realized that kernel-audit is not suitable for all our needs and eBPF mode of observability has the future. We plan on to improve the current performance issues with the eBPF mode of policy violation alerts.

• KubeArmor on RedHat Ecosystem #1294 ✅

• list the applied policies for unorchestrated workloads #1311 ✅

• Use Enforcer as a source of Alerts #1277 ✅

• Disable file visibility by default #1442 ✅

• KubeArmor on Flatcar feedback #1265 ✅

• Create PolicyReports for security events to use with Policy Reporter #1337 ✅ #1328

• CEF format support #1371 ✅ #1328

• handle policy addition and deletion in systemd mode. #1312 ✅

• kubearmor packer provisioner #3 ✅

• K0s Support for KubeArmor #1318 ✅

• Install KubeArmor in the "kubearmor" namespace by default #1167 ✅

• adding cwd in alerts/telemetry #1453 ✅

• Nephio Integration

• MicroShift Support #1325

• Prebuilt 5G Security controls from MITRE FiGHT and ENISA

• Modify Sidekick to export KubeArmor events #1328 ✅

• Performance Improvement

Boost Confidence with Red Hat OpenShift Certified KubeArmor Operator @rksharma95

Ensuring compatibility, security, and trustworthiness is crucial in today's containerised world. That's where Red Hat OpenShift Product Certification for the KubeArmor Operator comes in. This certification provides approval, signifying that KubeArmor is rigorously tested and verified to work seamlessly with OpenShift in production environments.

Improved support for Kubearmor-client in Systemd Mode @Aryan-sharma11

Applying policies via kubearmor-client

In systemd mode, karmor is getting an upgrade to handle policy addition and deletion better. The current behaviour can be confusing, as it always returns a "SUCCESS" message, even when adding a policy already applied or deleting a policy that doesn't exist.

1. Policy Addition: If you try to apply a policy already in effect, karmor will tell you, "Policy is already applied."

2. Policy Deletion: If you attempt to delete a policy that doesn't exist, the response will indicate that the "Policy doesn't exist."

These enhancements include a new check to ensure that policies are received by the gRPC client and successfully applied by the ParseAndUpdate functions. This makes karmor more reliable and user-friendly when managing policies in systemd mode. In the containerization landscape, orchestrated workloads receive much attention, but unorchestrated workloads are equally important. Often running in Systemd mode, unmanaged containers can benefit from a policy management approach. One effective tool is the Karmor Probe, which helps ensure security and compliance.

Karmor Probe for Unorchestrated Workloads

1. Using a gRPC Endpoint

• Set up a gRPC endpoint within your unorchestrated environment to query and list policies applied to workloads.

• This allows you to integrate Karmor Probe seamlessly and maintain the same standards for unorchestrated and orchestrated workloads.

1. Systemd Mode Workloads

• Unorchestrated workloads in Systemd mode can be managed by leveraging Systemd commands and unit files.

• Use Systemd-specific tools to inspect policies and maintain clear documentation for each service.

In conclusion, maintaining policies for unorchestrated workloads is essential for a comprehensive container environment. Karmor Probe and a strategic approach help ensure security and compliance for all your containers, regardless of orchestration.

Streamlining Kubernetes Security with KubeArmor Enforcer Alerts @daemon1024 @Aryan-sharma11

KubeArmor's latest feature request aims to reduce confusion by using alerts sent by the KubeArmor enforcer, rather than triggering Default Posture alerts when no permissions are denied. This enhancement simplifies Kubernetes security and provides more accurate information to users.

In the world of Kubernetes security, minimizing confusion is a priority. KubeArmor's proposed solution involves setting up a Ring Buffer Infrastructure in the BPF LSM Enforcer to manage alerts more effectively. Here's how it works:

The Solution:

1. Ring Buffer Infrastructure: KubeArmor creates a ring buffer in the kernel space to store and manage alerts.

2. Alert Handling: Alerts are generated when permissions are denied, containing crucial information about the denial.

3. User-Friendly Alerts: Only genuine security alerts are triggered, reducing unnecessary Default Posture alerts.

Benefits:

• Reduced Confusion: Users won't be bombarded with false alarms.

• Enhanced Usability: Security monitoring becomes more straightforward.

• Improved Resource Utilization: Fewer alerts mean more efficient resource usage.

Conclusion: KubeArmor's feature request promises a simpler and more user-friendly Kubernetes security experience by focusing on real security events and minimizing noise. This development contributes to a robust and effective Kubernetes security solution.

Enhanced Security with Disabled File-Based Telemetry by Default @Ankurk99

KubeArmor has significantly updated by disabling file-based telemetry by default. This modification substantially decreases telemetry data generated by file events, lowering overall resource consumption. Users have the flexibility to configure these changes and can effortlessly enable visibility as needed.

Enhancing KubeArmor on Flatcar OS @daemon1024

KubeArmor recently underwent testing on Flatcar OS, leading to valuable feedback and feature requests. Key details include a missing /usr/src directory on Flatcar OS, which prompted the suggestion to make its location optional. Additionally, enabling BPF-LSM was found to be crucial and is now clarified in the documentation.

KubeArmor has responded with enhancements, including the KubeArmor Operator for smoother deployments and a new FAQ section on enabling BPF-LSM. These updates reflect the project's commitment to improving container security and user experience.

Improved Policy Handling in Systemd Mode @Aryan-sharma11

Simplify Kubernetes Security with KubeArmor Packer Provisioner @Prateeknandle

In the world of Kubernetes security, KubeArmor is a game-changer. But installing it can be complex. That's where the Kubearmor Packer Provisioner comes in. It offers:

1. Ansible Playbook: An automated way to install KubeArmor, Karmor, and dependencies, ensuring consistency.

2. Packer Integration: Seamlessly integrates with Packer for image creation, so your Kubernetes cluster comes pre-configured with Kubearmor and Karmor.

With this provisioner, you can fortify your Kubernetes security effortlessly and efficiently, saving time and reducing the risk of misconfigurations.

KubeArmor Adds Support for K0s: Boosting Kubernetes Security @anurag-rajawat

K0s is known for its simplicity and efficiency, making it a preferred choice for some Kubernetes users. With KubeArmor's support, K0s users can now benefit from advanced security features while keeping their clusters lightweight.

Key Benefits:

1. Enhanced Security: K0s users can apply fine-grained security policies to container workloads, improving protection against threats.

2. Increased Flexibility: Integrating K0s support expands choices for securing Kubernetes environments.

3. Growing Ecosystem: It contributes to the diversity and adaptability of the Kubernetes ecosystem.

KubeArmor's support for K0s is a valuable addition that enhances Kubernetes security options. Whether you're already using K0s or considering it, explore the benefits of KubeArmor's security solutions for your containerized workloads.

Enhancing Container Security with BPF LSM and KubeArmor @daemon1024

Containerization and Kubernetes have transformed application deployment, but security remains a concern. KubeArmor, an open-source project, leverages BPF LSM (Linux Security Modules) to enforce host policies for stronger Kubernetes security.

Containers share the host kernel, making them vulnerable. KubeArmor addresses this by enforcing fine-grained host policies that boost security.

BPF LSM combines BPF's power with LSM's security framework to make real-time policy decisions and enforcement possible—enhanced Security with KubeArmor. KubeArmor delivers real-time policy enforcement, host-level policies, fine-grained control, auditing, and seamless Kubernetes integration. KubeArmor's innovative use of BPF LSM enhances security in Kubernetes environments, protecting containerized applications and ensuring compliance.

Installing KubeArmor in the "kubearmor" Namespace @Ankurk99

The kube-system namespace is used for objects created by the Kubernetes system. It is reserved for system-level resources and components critical to the cluster's functioning. Installing any external deployments with the system's essential resources is not recommended. In this release, we have modified the default namespace for KubeArmor to utilize kubearmor.

Streamlining Kubearmor Event Export with Sidekick Integration @Shreyas220

Exporting Kubearmor security events to various outputs is essential for effective Kubernetes security management. Discover how integrating Falcosidekick can simplify this process. It's a vital tool for securing Kubernetes clusters, but handling the export of security events can be challenging. We have integrated Falcosidekick to seamlessly export Kubearmor events to multiple outputs like email, Slack, Redis, RabbitMQ, Kafka, and more. Falcosidekick acts as a bridge, receiving events from Kubearmor and forwarding them to your chosen destinations. This integration allows you to customize event routing, receive real-time alerts, and ensure scalability and reliability.

The Kubearmor and Falcosidekick integration simplifies exporting security events, enhancing your ability to manage and respond to Kubernetes security incidents effectively.

Leveraging eBPF for Current Working Directory (CWD) in Alerts @Prateeknandle

Introduction

In this blog, we'll explore using eBPF to capture a process's Current Working Directory (CWD) and include this information in your system alerts and telemetry. CWD is valuable for debugging, troubleshooting, security, and compliance.

Why CWD Matters

• Debugging: Helps identify file access, permissions, and dependencies issues.

• Troubleshooting: Contextual information for efficient issue diagnosis.

• Security: Detects suspicious activities related to directory access.

• Compliance: Provides context for auditing and compliance requirements.

Adding CWD to Alerts and Telemetry

1. Write an eBPF program to capture CWD.

2. Extract CWD information from process data structures.

3. Send CWD data to your logging or alerting system.

4. Correlate CWD data with other observability metrics.

Benefits

• Faster Issue Resolution: Speed up troubleshooting.

• Enhanced Security: Detect unauthorized activities.

• Compliance: Meet regulatory requirements.

• Improved Resource Utilization: Optimize system resources.

Incorporating CWD data through eBPF empowers better system observability and performance analysis.

Development

1. Vagrant Environment (Recommended)

Note Skip the steps for the vagrant setup if you're directly compiling KubeArmor on the Linux host. Proceed to setup K8s on the same host by resolving any dependencies.

• Requirements

  Here is the list of requirements for a Vagrant environment

  Clone the KubeArmor github repository in your system

  Install Vagrant and VirtualBox in your environment, go to the vagrant path and run the setup.sh file

• VM Setup using Vagrant

  Now, it is time to prepare a VM for development.

  To create a vagrant VM

  Output will show up as ...

  To get into the vagrant VM

  Output will show up as ...

  To destroy the vagrant VM

  • VM Setup using Vagrant with Ubuntu 21.10 (v5.13)

    To use the recent Linux kernel v5.13 for dev env, you can run make with the NETNEXT flag set to 1 for the respective make option.

    You can also make the setting static by changing NETNEXT=0 to NETNEXT=1 in the Makefile.

2. Self-managed Kubernetes

• Requirements

  Here is the list of minimum requirements for self-managed Kubernetes.

  KubeArmor is designed for Kubernetes environment. If Kubernetes is not setup yet, please refer to . KubeArmor leverages CRI (Container Runtime Interfaces) APIs and works with Docker or Containerd or CRIO based container runtimes. KubeArmor uses LSMs for policy enforcement; thus, please make sure that your environment supports LSMs (either AppArmor or bpf-lsm). Otherwise, KubeArmor will operate in Audit-Mode with no policy "enforcement" support.

  Alternative Setup

  You can try the following alternative if you face any difficulty in the above Kubernetes (kubeadm) setup.

  Note Please make sure to set up the alternative k8s environment on the same host where the KubeArmor development environment is running.

  • K3s

    You can also develop and test KubeArmor on K3s instead of the self-managed Kubernetes. Please follow the instructions in .

  • MicroK8s

    You can also develop and test KubeArmor on MicroK8s instead of the self-managed Kubernetes. Please follow the instructions in .

  • No Support - Docker Desktops

    KubeArmor does not work with Docker Desktops on Windows and macOS because KubeArmor integrates with Linux-kernel native primitives (including LSMs).

• Development Setup

  In order to install all dependencies, please run the following command.

  will automatically install , , , and some other dependencies.

  Now, you are ready to develop any code for KubeArmor. Enjoy your journey with KubeArmor.

3. Environment Check

• Compilation

  Check if KubeArmor can be compiled on your environment without any problems.

  If you see any error messages, please let us know the issue with the full error messages through #kubearmor-development channel on CNCF slack.

• Execution

  In order to directly run KubeArmor in a host (not as a container), you need to run a local proxy in advance.

  Then, run KubeArmor on your environment.

  Note If you have followed all the above steps and still getting the warning The node information is not available, then this could be due to the case-sensitivity discrepancy in the actual hostname (obtained by running hostname) and the hostname used by Kubernetes (under kubectl get nodes -o wide). K8s converts the hostname to lowercase, which results in a mismatch with the actual hostname. To resolve this, change the hostname to lowercase using the command hostnamectl set-hostname <lowercase-hostname>.

• KubeArmor Controller

  Starting from KubeArmor v0.11 - annotations, container policies, and host policies are handled via kubearmor controller, the controller code can be found under pkg/KubeArmorController.

  To install the controller from KubeArmor docker repository run

  To install the controller (local version) to your cluster run

  if you need to setup a local registry to push you image, use docker-registry.sh script under ~/KubeArmor/contribution/local-registry directory

Code Directories

Here, we briefly give you an overview of KubeArmor's directories.

• Source code for KubeArmor (/KubeArmor)

• Source code for KubeArmor Controller (CRD)

• Deployment tools and files for KubeArmor

• Files for testing

Cluster Policy Specification

Here is the specification of a Cluster security policy.

Note Please note that for system calls monitoring we only support audit action no matter what the value of action is

Policy Spec Description

Now, we will briefly explain how to define a cluster security policy.

Common