diff --git a/getting-started/deployment_guide.md b/getting-started/deployment_guide.md index 1a9a26b8fc..78dcf664cd 100644 --- a/getting-started/deployment_guide.md +++ b/getting-started/deployment_guide.md @@ -14,6 +14,18 @@ kubectl apply -f https://raw.githubusercontent.com/kubearmor/KubeArmor/main/pkg/ You can find more details about helm related values and configurations [here](https://github.com/kubearmor/KubeArmor/tree/main/deployments/helm/KubeArmorOperator). +### (Optional) Set the CRI socket explicitly + +KubeArmorOperator deploys a `kubearmor-snitch` Job to detect node information (including the container runtime). If CRI socket auto-detection does not work in an environment, provide the socket path explicitly via Helm. + +{% hint style="warning" %} +The `--socket-file` flag is consumed by the `kubearmor-snitch` Job. The exact Helm value key that feeds snitch arguments depends on the chart version. If this flag is not being applied to snitch, use the chart documentation in the KubeArmor repository to find the snitch argument wiring for the chart version in use. +{% endhint %} + +Related: + +* [KubeArmorOperator Helm chart (upstream)](https://github.com/kubearmor/KubeArmor/tree/main/deployments/helm/KubeArmorOperator) + ## Install kArmor CLI (Optional) ``` diff --git a/getting-started/kubearmor-events.md b/getting-started/kubearmor-events.md index fd5cb3ba01..3dd51f0f00 100644 --- a/getting-started/kubearmor-events.md +++ b/getting-started/kubearmor-events.md @@ -18,6 +18,7 @@ | ContainerImage | shows the image that was used to spin up the container | docker.io/accuknox/knoxautopolicy:v0.9@sha256:bb83b5c6d41e0d0aa3b5d6621188c284ea | | ContainerName | specifies the Container name where the log got generated | discovery-engine | | Data | shows the system call that was invoked for this operation | syscall=SYS_OPENAT fd=-100 flags=O_RDWR\|O_CREAT\|O_NOFOLLOW\|O_CLOEXEC | +| EventData | map of parsed key/value pairs derived from structured `Data` and (for `Operation=Network`) `Resource` | {"Fd":"10","Sa_family":"AF_INET","Sin_port":"53","Sin_addr":"10.0.0.10"} | | HostName | shows the node name where the log got generated | aks-agentpool-16128849-vmss000001 | | HostPID | gives the host Process ID | 967872 | | HostPPID | list the details of host Parent Process ID | 967496 | @@ -34,6 +35,20 @@ | Source | lists the source from where the operation request came | /knoxAutoPolicy | | Type | specifies it as container log | ContainerLog | +### About `EventData` + +`EventData` is a `map` field present in both **Container Telemetry** (logs) and **Container Alerts**. + +KubeArmor populates it by parsing: + +* `Data` (space-separated `key=value` pairs) +* `Resource` only when `Operation` is `Network` + +For example, a network telemetry event may include: + +* `Resource`: `sa_family=AF_INET sin_port=53 sin_addr=10.0.0.10` +* `EventData`: `{ "Sa_family": "AF_INET", "Sin_port": "53", "Sin_addr": "10.0.0.10" }` +

Process Log

 ```json @@ -136,6 +151,7 @@ The primary difference in the container alerts events vs the telemetry events (s | ContainerImage | shows the image that was used to spin up the container | docker.io/library/mysql:5.6@sha256:20575ecebe6216036d25dab5903808211f | | ContainerName | specifies the Container name where the alert got generated | mysql | | Data | shows the system call that was invoked for this operation | syscall=SYS_EXECVE | +| EventData | map of parsed key/value pairs derived from structured `Data` and (for `Operation=Network`) `Resource` | {"Syscall":"SYS_EXECVE"} | | Enforcer | it specifies the name of the LSM that has enforced the policy | AppArmor/BPFLSM | | HostName | shows the node name where the alert got generated | aks-agentpool-16128849-vmss000001 | | HostPID | gives the host Process ID | 3647533 | diff --git a/getting-started/release-notes/v1.6.md b/getting-started/release-notes/v1.6.md index 4dd4db43b8..5811a28585 100644 --- a/getting-started/release-notes/v1.6.md +++ b/getting-started/release-notes/v1.6.md @@ -1,5 +1,32 @@ # KubeArmor v1.6 Release Notes +## v1.6.8 + +- **Date:** 2026-02-25 +- **Version:** v1.6.8 + +### 🆕 New Features + +- Added usernames to host logs and security alerts for clearer identity context. +- Added a Helm option to select the container runtime socket file during deployment. +- Added default CPU and memory requests and limits for relay, the KubeArmor controller, the DaemonSet, and snitch. + +### 🐛 Bug Fixes + +- Fixed intermittent failures under high concurrency in endpoint and host security policy handling. +- Fixed data races in alert throttling during high alert volumes. +- Fixed container runtime detection with multiple sockets by deriving the runtime from the matched socket path. +- Fixed CRI socket flag injection so generated DaemonSets consistently use the intended socket argument. +- Fixed RHEL9 build gating so RHEL9-specific features are enabled only for builds >= 400. + +### 🎁 Misc + +- Updated CI workflows to use the correct Helm values key for the `kubearmor-operator` image tag. +- Improved tests by allowing LSM ordering to be passed through to match target environments. +- Improved host-only runs by adding timestamps to USB logs and explicitly setting `k8s=false`. +- Updated dependencies and release metadata, including Go 1.24.13, a Cilium dependency bump to v1.18.4, and the stable release version to v1.6.8. +- Reduced static analysis noise by refining security checks and suppressions in CI. + 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. diff --git a/wiki/log_feeder.md b/wiki/log_feeder.md index 014af38565..b771e69c02 100644 --- a/wiki/log_feeder.md +++ b/wiki/log_feeder.md @@ -100,6 +100,7 @@ message Alert { string Operation = 19; // e.g., Process, File, Network string Resource = 20; // e.g., /etc/passwd, tcp://1.2.3.4:80 string Data = 21; // Additional data if any + map EventData = 43; // Parsed key/value data from `Data` and (for Network) `Resource` string Enforcer = 28; // e.g., BPFLSM, AppArmor, eBPF Monitor string Action = 22; // e.g., Allow, Audit, Block string Result = 23; // e.g., Failed, Passed, Error @@ -127,6 +128,7 @@ message Log { string Operation = 15; string Resource = 16; string Data = 17; + map EventData = 33; // Parsed key/value data from `Data` and (for Network) `Resource` string Result = 18; // e.g., Success, Failed string Cwd = 25; @@ -148,6 +150,19 @@ message ExecEvent { } ``` +### `EventData`: structured key/value fields + +The gRPC `Alert` and `Log` payloads include an `EventData` map. + +* `EventData` is derived by parsing space-separated `key=value` pairs. +* KubeArmor parses `Data` for all operations. +* KubeArmor also parses `Resource` when `Operation` is `Network`. + +Example: + +* `Resource`: `sa_family=AF_INET sin_port=53 sin_addr=10.0.0.10` +* `EventData`: `{ "Sa_family": "AF_INET", "Sin_port": "53", "Sin_addr": "10.0.0.10" }` + These Protobuf definitions specify the exact structure and data types for the messages KubeArmor will send, ensuring that clients know exactly what data to expect. The `.pb.go` and `_grpc.pb.go` files are automatically generated from this `.proto` file and provide the Go code for serializing/deserializing these messages and implementing the gRPC service. Now, let's look at the Log Feeder implementation in Go.