# v1.6.0

## Release Notes

## New Features & Enhancements

### Default host kernel is now 6.18.6 (LTS)

Improves performance and device compatibility.

### PersistentVolume-based block device mounts

Support for PersistentVolumes and PersistentVolumeClaim-based mounting of high-performance block devices into Edera-managed Kubernetes workloads is now supported. See the [Kubernetes block devices guide](https://docs.edera.dev/guides/storage/kubernetes-block-devices/).

As with default Kubernetes, this is highly recommended for workloads that require high levels of disk performance, such as database containers and volumes.

CSI-managed block devices should also be supported via these APIs as in default Kubernetes, but not all CSI drivers or filesystem formats have been validated with Edera in this release.

### `OOMKilled` container status now tracked and reported

Edera-managed Kubernetes containers that exceed their configured memory limits and are terminated by the kernel OOMKiller now properly report their exit status to Kubernetes, as expected.

### Additional Kubernetes `securityContext` field support

- `securityContext.runAsUser` is now properly supported in Kubernetes specs for Edera-managed pods.
- `securityContext.runAsGroup` is now properly supported in Kubernetes specs for Edera-managed pods.
- `securityContext.runAsNonRoot` is now properly supported in Kubernetes specs for Edera-managed pods.
- `securityContext.fsGroup` is now properly supported in Kubernetes specs for Edera-managed pods.
- `securityContext.allowPrivilegeEscalation` is now properly supported in Kubernetes specs for Edera-managed pods. Note that use of this flag is strongly discouraged in favor of `securityContext.capabilities.drop: "[ALL]"`.

### New `protect-ctl` features

- The `host status` command now reports hypervisor memory.
- The `workload launch` command now supports directly mounting raw host block devices into workloads via the new `--block-device` flag. This is recommended for workloads that require high levels of disk performance, such as databases. The `--block-device` flag accepts 3 colon-separated arguments for source device, target mount path, and read-only status:

```
protect-ctl workload launch -z my-zone -n my-workload alpine:latest --block-device "src=/dev/rawblock01:dst=/mnt/workload-blockdev01:ro=false"
```

### Falco integration

- Edera Falco Plugin: Support Falco version [0.43.0](https://falco.org/blog/falco-0-43-0/)
- Edera Falco Plugin: Upgraded `libscap` with TOCTOU-resistant eBPF hooking.

### Miscellaneous

- All published binary versions now report the build SHA (for example, `1.5.1+sha.419a92`)
- Kernel debugfs/tracefs are now available inside of Edera zones (at `/sys/kernel/debug` and `/sys/kernel/debug/tracing` respectively).

## Bug Fixes

### Kubernetes integration

- Fixed issue where mishandled CNI DEL could cause slow IPAM leak with some CNI providers.
- OOMKilled status is now correctly reported for Edera-managed K8S pods.
- Fixed an issue where pod hostnames were not properly mapped inside pods and containers.
- Fixed an issue where loopback routes inside pods might not be correctly configured.
- Fixed an issue where file-based locking relying on select Linux VFS features might fail inside Edera-managed K8S pods.
- Fixed an issue where Edera-managed K8S pods did not report `Exited` and `Completed` states correctly in all scenarios.

### Core

- Fixed various issues around OCI image fetching from some registries.

### Installer

- Installer now checks for the presence of the `nft` binary.

## Known issues

- Zone kernel 6.16 or newer is required for Falco event streaming, this will be remedied in a subsequent release.
- PVH support is still experimental:
  - The static resource policy is nonfunctional for PVH zones.
  - K8S manifest resource allocation is nonfunctional under PVH

## Upgrade notes

There are no known breaking changes in this release from the previous release `v1.5.1`.

Last updated on 2026-03-10.