Skip to content

known_limitations.adoc

Latest commit

 

History

History
72 lines (38 loc) · 5.68 KB

known_limitations.adoc

File metadata and controls

72 lines (38 loc) · 5.68 KB
Raw

Known limitations

Table of Contents

This document tracks the current, known limitations of runtime-enforcer. Some of these are explicit design decisions, and some are constraints inherited from upstream components (kernel/eBPF, Kubernetes, container runtimes). The goal is to help you understand the limitations and make informed decisions about your runtime-enforcer deployment.

Learning cap: 100 allowed executables per proposal

During learning, runtime-enforcer writes observed executable paths into a WorkloadPolicyProposal under spec.rulesByContainer[*].executables.allowed.

To bound proposal growth, the learning controller stops adding new entries once the proposal contains 100 distinct allowed executables in total (summed across all containers in rulesByContainer). This is a design decision.

  • Impact: if a workload executes more than 100 distinct executables, the proposal will become “full” and additional executables will not be learned automatically. In that case you may need to curate/trim the list or manage policy contents manually.

Full workload name may not be extracted in some scenarios

With NRI, runtime-enforcer derives the workload name from the pod name format and a small set of well-known labels. In some scenarios this information is not sufficient to reconstruct the original controller name.

This can happen when Kubernetes truncates pod names due to the 63-character limit (common with long Deployment/DaemonSet names), which can remove parts of the name and/or separators that would otherwise allow reliable parsing.

In these cases, runtime-enforcer may only be able to report a shortened/best-effort workload name and will not be able to extract the full workload name.

  • Impact: workload names shown in policy proposals and violation reporting can be incomplete and may not exactly match the original Kubernetes resource name. Since workload type/name is also used to derive the WorkloadPolicyProposal resource name, the proposal may be created under an unexpected name, which can make it look like learning did not happen.

Static pods: API-server Pod UID cannot be resolved via NRI

For Kubernetes static pods, the Pod UID used by the kubelet and the Pod UID assigned by the Kubernetes API server can differ.

In the NRI context, runtime-enforcer cannot reliably retrieve the API-server Pod UID for static pods, and will instead rely on the UID available via NRI.

  • Impact: when correlating runtime-enforcer events/policies with Kubernetes objects, the Pod UID may not match what you see on the Pod object returned by the Kubernetes API for static pods.

VAP-based protections are not applied prior to Kubernetes 1.30

runtime-enforcer uses Kubernetes Validating Admission Policy (VAP) to enforce admission-time protections (for example, preventing changes that would add/remove/update the security.rancher.io/policy label on Pods).

VAP is only available as admissionregistration.k8s.io/v1 starting in Kubernetes 1.30. On Kubernetes versions prior to v1.30, runtime-enforcer does not apply any VAP-based protections.

Earlier Kubernetes versions exposed Validating Admission Policy as admissionregistration.k8s.io/v1beta1, but runtime-enforcer won’t support it. This is a design decision.

  • Impact: on Kubernetes 1.29 and earlier, changes that should be blocked by VAP (such as mutating security.rancher.io/policy on existing Pods) may be allowed.

NRI may not be enabled by default for containerd prior to v2.0

runtime-enforcer requires NRI to be enabled in the container runtime. On containerd versions prior to v2.0, NRI may be available but not enabled by default, depending on how containerd is packaged/configured in your distribution.

  • Impact: if NRI is not enabled, runtime-enforcer will not be able to learn/resolve container identity correctly and may fail to operate as expected. You have to enable NRI manually.

ReplicaSet are not supported as a workload for learning

runtime-enforcer does not currently learn policies with ReplicaSet as the workload identity.

In the NRI context, runtime-enforcer derives the “workload kind/name” primarily from the pod name and a small set of well-known labels. This works for common workload types (i.e. Deployment, DaemonSet), but it is not sufficient to reliably identify a pod as belonging to a ReplicaSet in the general case.

As a result, pods created by standalone ReplicaSet may be treated as plain Pod workloads for learning and reporting purposes.

  • Impact: policy proposals and violation reporting may not group/label these pods under a ReplicaSet workload, and may not match the workload identity you expect. Please use other workload types (i.e. Deployment, DaemonSet) when you want reliable workload attribution and policy learning.

arm64: kernels prior to 6.4 are not supported

On arm64/aarch64, runtime-enforcer requires a Linux kernel version >= 6.4.

  • Impact: on older arm64 kernels, runtime-enforcer may fail to load eBPF programs or may not function correctly.

cri-dockerd is not supported

runtime-enforcer does not support running Kubernetes with Docker via cri-dockerd, and we do not plan to add support for this in the future.

runtime-enforcer relies on container-runtime integration that provides consistent container/pod identity information (NRI). cri-dockerd does not meet this requirement, so container attribution and policy enforcement behavior is not reliable in that environment.

  • Impact: runtime-enforcer may fail to start correctly, or may be unable to reliably attribute processes to containers/workloads. Please use a supported container runtime (containerd or CRI-O) instead.