Global Telecom selects AccuKnox

Global Telecom Leader Selects AccuKnox for Container Runtime Security

 |  Edited : August 06, 2026

A top-tier telecom ran a 36 use-case container security POC against six vendors, on-prem and air-gapped. Here is what it tested and why AccuKnox won.

Reading Time: 4 minutes

TL;DR

  • A top-tier global telecom and cloud operator picked AccuKnox for container runtime security after one of the most demanding POCs we have run.
  • The POC covered 36 use cases across runtime enforcement, cluster misconfiguration, Kubernetes identity, vulnerability management, and compliance mapping.
  • Everything ran on-prem with no external network access during install, on a Kubernetes stack the customer had built and acquired itself.
  • We were evaluated head to head against five well-known CNAPP and container security vendors plus one telecom-specific eBPF runtime product.
  • 30 of 36 criteria passed outright in the first pass. The gaps were configuration issues rather than capability gaps, which closed quickly leading to a customer win

Runtime Coverage Across Kubernetes, CRI-O, containerd, Docker and Edge Infrastructure

The customer is a large e-commerce operator that has expanded into mobile network operations and cloud services over the past decade. Its infrastructure spans:

  • Managed and self-hosted Kubernetes
  • A separately acquired container orchestration platform
  • Containers on VMs
  • Docker, containerd, CRI-O, Podman
  • Bare metal on ARM and x86
  • Edge nodes co-located with radio infrastructure

A tool scoped to manage Kubernetes alone would cover roughly a third of this estate. The requirement was a single agent and control plane with consistent behavior across all runtime types.

Learn more about AccuKnox’s Cloud Workload Protection Platform (CWPP)

GlobalTelcoLeader 2a

The deployment footprint one agent had to cover. Enforcement, isolation and monitoring were scored separately.

Evaluation Scope for Container Security 

The customer evaluated runtime security across three independent domains, each with its own pass criteria.

CategoryScope
EnforcementInline, preemptive controls on file, process, and network activity at runtime. Policy violations are denied, not logged post-hoc.
IsolationMulti-tenant clusters with workloads from different business units sharing nodes. Tenant-to-tenant blast radius was scored as a primary criterion.
MonitoringThreat detection, behavioral anomaly detection, image vulnerability scanning, registry-based admission control, and identity risk discovery across service accounts and roles.

Air-Gapped Deployment Inside the Customer’s Own Premises

Agents were deployed on the customer’s on-prem cluster, covering databases, web servers, internal AI agent workloads, and general application workloads. Agent telemetry fed into an AccuKnox control plane hosted in the customer’s own data center, which handled scheduled reporting and real-time alerting to the security team.

Control plane specs: single VM, 8 vCPUs, 32 GB RAM, 256 GB volume. Installed from a signed offline bundle. No internet connectivity at any point during install or operation.

GlobalTelcoLeader 1

POC architecture. Agents in the customer’s cluster, control plane in the customer’s data center, nothing leaving the perimeter.

The process involved a comprehensive evaluation against 6 other Container Security vendors.

Technical Evaluation Criteria for a Successful CWPP PoC – A Checklist

Each of the 36 criteria had a written pass condition, defined and executed by the customer. 

  • Writing to /bin or /boot from inside a running container returns Permission Denied; the attempt is logged with full context in the control plane.
  • Modification of trusted root certificate stores or CA bundles is blocked at the syscall level.
  • Execution from /tmp is blocked or flagged per policy.
  • Known crypto-mining binaries cannot execute.
  • docker, crictl, kubectl, and network scanners (nmap, masscan) cannot run from inside a container.
  • Environment variable access is denied by default (prevents secret leakage via /proc).
  • Application behavior is auto-baselined; deviations are flagged with accept/discard controls.
  • Zero-trust process allow-listing: only explicitly permitted binaries execute.
  • Network activity is restricted to processes identified as trusted based on observed behavior.

Additional scored areas: CIS benchmark scanning, MITRE ATT&CK mapping of policies and violations, NIST 800-53 control mapping, privileged container detection, host PID/IPC usage, writable hostPath volumes, missing CPU/memory limits, externally exposed workloads, and anonymous-access service accounts.

The Kubernetes Identity and Entitlement Management (KIEM) required identification of: 

  1. every user/service/namespace holding ClusterAdmin, 
  2. over-permissioned service accounts, 
  3. roles not bound to a live workload, and 
  4. subjects able to create roles or role bindings. 

Vulnerability management required scanning of running images with findings scoped to cluster/namespace/workload, plus a triage lifecycle (suppress, accept-risk, remediate)

Evaluation Outcome

30 of 36 criteria passed cleanly on the first run. Two passed partially. Secrets-in-manifests scanning was scheduled for the second phase.

GlobalTelcoLeader 2

Scored on the customer’s own scorecard, first pass, no retries.

See how runtime policies are applied to monitor and block unauthorized process, file, and network activity inside Kubernetes workloads.

AccuKnox’s CWPP Differentiators Evaluated By Top Global Company

Consistent Runtime Enforcement Across Mixed Execution Environments

The customer’s environment extended beyond Kubernetes to Docker, containerd, CRI-O, Podman, virtual machines, bare metal, and ARM-based edge infrastructure. AccuKnox enforced the same runtime policies across every supported environment using a single kernel-level agent, eliminating the need for runtime-specific enforcement models.
kubearmor ebpf lsm architecture

Syscall-Level Enforcement Instead of Post-Execution Response

The evaluation distinguished between platforms that terminate malicious processes after execution and those that prevent unauthorized operations before they occur. AccuKnox enforces policy at the syscall layer using eBPF and Linux Security Modules (LSM), denying unauthorized file, process, and network operations before execution completes.
GlobalTelcoLeader 6

Air-Gapped Operation

The deployment was evaluated in a fully air-gapped environment where neither installation nor runtime operations could rely on internet connectivity. AccuKnox was deployed from a signed offline bundle, with agents and the control plane operating entirely within the customer’s network perimeter.
GlobalTelcoLeader 3

Behavioral Policy Generation for Least-Privilege Enforcement

Maintaining runtime allow-lists manually across thousands of workloads was impractical. Instead, AccuKnox generated workload-specific runtime policies by observing normal application behavior, allowing security teams to review and enforce least-privilege policies without extensive manual authoring.
GlobalTelcoLeader 4

Kubernetes Identity and RBAC Graph Analysis

Beyond runtime enforcement, the evaluation assessed Kubernetes identity risks, including ClusterAdmin assignments, over-permissioned service accounts, unused RBAC roles, and privilege escalation paths. These checks were treated as operational security requirements rather than compliance-only controls.
GlobalTelcoLeader 5
platform CWPP inside look

Final Thoughts

Large enterprises increasingly expect runtime enforcement that prevents unauthorized activity before it executes, operates consistently across Kubernetes and non-Kubernetes environments, and can be deployed entirely within air-gapped infrastructure.

This evaluation demonstrated that runtime protection is ultimately measured by real-world prevention under customer-defined conditions. Across 36 independently tested scenarios, AccuKnox delivered the enforcement, portability, and operational flexibility required to secure one of the industry’s most complex container environments.

AccuKnox product dashboard showing runtime protection for every workload

FAQ

What is container runtime security?

Protection applied while a container is running, as opposed to scanning an image before it deploys. It watches and controls file, process and network activity inside the container, and either audits or blocks actions that fall outside policy.

How is inline prevention different from detect-and-kill?

Detect-and-kill lets the process start, then terminates it. The action it was performing may already be complete. Inline prevention denies the syscall itself, so the read, write or network connection never happens.

Does this work outside Kubernetes?

Yes. The same agent covers VMs, bare metal on ARM and x86, standalone container runtimes like Docker, containerd, CRI-O and Podman, and lightweight edge nodes.

Can it run without internet access?

Yes. Both agents and control planes deploy fully on-prem from an offline bundle, with no outbound connectivity required during or after installation.

What does auto-discovered policy actually produce?

The platform observes normal application behavior and generates a candidate allow-list of processes, file paths and network peers. A security engineer reviews it in the control plane, then applies it in audit mode or block mode. Anything outside the baseline gets flagged with the option to extend the policy or treat it as a violation.

Ready For A Personalized Security Assessment?

“Choosing AccuKnox was driven by opensource KubeArmor’s novel use of eBPF and LSM technologies, delivering runtime security”

idt

Golan Ben-Oni

Chief Information Officer

“At Prudent, we advocate for a comprehensive end-to-end methodology in application and cloud security. AccuKnox excelled in all areas in our in depth evaluation.”

prudent

Manoj Kern

CIO

“Tible is committed to delivering comprehensive security, compliance, and governance for all of its stakeholders.”

tible

Merijn Boom

Managing Director

×