← Book home
Part 7 · Advanced and Future Security
29

Cloud-Native 5G Security

The core is now software on Kubernetes — secure it like it

"The 5G core isn't a rack of telecom appliances anymore. It's containers on Kubernetes — and it inherits every cloud-native attack the IT world spent a decade learning to fear." — THE CLOUD-NATIVE REALITY

Modern 5G cores are Cloud-Native Functions (CNFs): containerized software orchestrated by Kubernetes, often on shared or public cloud. This unlocks elasticity and automation — and adds a whole layer of attack surface beneath the 3GPP one. This chapter covers container and image security, Kubernetes hardening for telco, service mesh, secrets management (including where K lives), CI/CD and supply chain, and multi-tenancy.

🎯 Learning objectives
📘 Standards reference box — Chapter 29
ReferenceTitleNote
TS 33.501 / 33.8485G security / virtualization security studyRel-18 edition
CIS / NISTKubernetes & container hardening benchmarkscurrent
GSMA / NESASNFVI & cloud security guidancecurrent

Checked June 2026 — verify against the latest 3GPP version.

29.1 The Cloud-Native 5G Stack

FIGURE 29.1The Cloud-Native 5G Stack — Layers of Trust
SBA / 3GPP security (Ch 1-28)the layer this book covered CNF containersimage vulns, escape Kubernetes orchestrationRBAC, network policy, secrets host OSkernel, isolation hardware / NFVIfirmware, tenancy 3GPP security (top) sits on FOUR cloud layers — a compromise of any lower layer can undermine everything above it
Purpose: the layered reality. This book secured the top layer; the four cloud layers beneath it are new attack surface that can undermine the 3GPP security above.
FIGURE 29.2Container Image Supply Chain for CNFs
source + depsscan dependencies base imageminimal, trusted build (CI)SBOM, sign scanvuln gate registrysigned only deployverify signature a backdoor in any stage rides to production — sign + scan + SBOM + verify-at-deploy closes the chain (Ch 24)
Purpose: the supply chain as a pipeline to secure. Each stage is a point an attacker can poison; signing, scanning, SBOM, and deploy-time verification close it.
FIGURE 29.3Kubernetes Hardening Map for Telco Clusters
K8s clusterruns the CNFs RBAC least privilege network policies (segment) no privileged pods secrets encryption at rest admission control (policy) pod security standards
Purpose: the K8s hardening checklist (CIS-aligned). A telco core on Kubernetes needs every one of these — RBAC, network policy, no privileged pods, secrets encryption, admission control, pod security.
FIGURE 29.4Pod / Namespace Isolation for Network Functions
namespace: accessAMF, SMF podsnetwork policy: limited namespace: crown-jewelUDM/ARPF podsstrict isolation + HSM namespace: exposureNEF podsDMZ-style isolation align K8s isolation with 3GPP blast-radius (Ch 3): the UDM namespace gets the strictest controls
Purpose: map cloud isolation to 3GPP blast radius. The crown-jewel NFs (Chapter 3) get the strictest namespace isolation and HSM backing at the K8s layer too.
FIGURE 29.5Service Mesh and SBA mTLS — Sidecars vs Native
service mesh (sidecar mTLS) mesh handles mTLS between pods central policy, observability ⚠ the mesh itself is now critical + overhead, complexity native TLS (NF does it) NF implements SBA mTLS directly fewer moving parts but per-NF cert lifecycle (Ch10) 3GPP-defined behavior
Purpose: two ways to deliver SBA mTLS. A service mesh centralizes it (but becomes critical itself); native TLS keeps 3GPP behavior with per-NF certs (Chapter 10). Many operators blend both.
FIGURE 29.6Secrets Management — Keys and Certs
the anti-pattern secrets in env vars, config files, or baked into images → exfiltrated with one image/pod compromise the pattern ✓ secrets in a vault (dynamic, rotated) ✓ K and operator constants in HSM ✓ short-lived tokens/certs compromise of a pod ≠ loss of the keys
Purpose: secrets are where cloud-native cores most often fail. Env-var/file secrets are exfiltrated with one compromise; vault + HSM keeps secrets out of the blast radius.
FIGURE 29.7Where the Long-Term Key K Lives in a Cloud Core
ARPF containersoftware logic onlyNO K in pod memory call HSMK + f1-f5 insidenever leaves results onlyvectors, not K in a cloud core, K in an HSM is non-negotiable — a container is too exposed to hold the network's master secret (Ch 11)
Purpose: the most important cloud-native rule. The long-term key K must live in an HSM, not a container — a pod is far too exposed to hold the master secret (Chapter 11).
FIGURE 29.8CI/CD Pipeline Security Gates
code scan (SAST) dependency scan image scan sign + SBOM policy gate → deploy the CI/CD pipeline is now part of the attack surface — gate it, or a poisoned commit reaches production NFs (Ch 24)
Purpose: the pipeline is production-critical. Security gates at each CI/CD stage stop a poisoned commit or dependency from reaching live NFs — the supply-chain defense (Chapter 24).
FIGURE 29.9Multi-Tenancy Risks on Shared Clusters
shared cluster / nodes tenant/slice A sensitive NF tenant/slice B shared nodes = potential side channels/escape between tenants → dedicate nodes/clusters for crown-jewel NFs
Purpose: the shared-cluster trade-off. Co-locating tenants/slices on shared nodes risks cross-tenant escape; crown-jewel NFs (UDM) often warrant dedicated nodes or clusters.
FIGURE 29.10NFVI / Host Escape Threat Path
compromised containerapp vuln container escape→ host host compromise→ all pods on node defenseskernel hardening, no privileged, runtime sec a container escape on a node holding the UDM is the cloud path to the crown jewels — kernel hardening + no privileged pods break it
Purpose: the worst-case cloud path — escape to host to crown jewels. Defense in depth (kernel hardening, no privileged pods, runtime security) breaks the chain before it reaches the UDM.
FIGURE 29.11Cloud-Native Observability for Security
container/host logsruntime detection K8s audit logsAPI/RBAC events SIEM+ 3GPP telemetry (Ch26) unified SOC viewcloud + telecom (Ch27) the SOC needs BOTH planes: 3GPP signaling telemetry (Ch26) AND cloud-native runtime/K8s telemetry — an attack may show only in one
Purpose: unify the two telemetry planes. A cloud-native core attack may appear only in container/K8s logs, not 3GPP signaling — the SOC (Chapter 27) needs both.
FIGURE 29.12Cloud-Native 5G Hardening Checklist
CLOUD-NATIVE 5G — HARDENING ESSENTIALS ☑ image signing + scanning + SBOM; verify at deploy ☑ K8s hardening (RBAC, network policy, no privileged, PSS) ☑ secrets in vault; K + constants in HSM ☑ CI/CD security gates ☑ namespace/node isolation aligned to blast radius ☑ dedicate nodes/cluster for crown-jewel NFs ☑ runtime security + kernel hardening (escape) ☑ unified cloud + 3GPP observability to the SOC
Purpose: the cloud-native security job on one card. These eight controls protect the four layers beneath 3GPP security — and feed the audit (Chapter 28).

29.2 The Practical Operator View

29.3 Threats and Mitigations

ThreatVectorDefense
Supply-chain backdoorpoisoned image/dependencysign/scan/SBOM, deploy verification
Container escape → hostapp/kernel vulnno privileged pods, kernel hardening, runtime sec
Secrets exfiltrationenv-var/file secretsvault, HSM for K, short-lived tokens
K8s privilege abuseweak RBACleast privilege, admission control
Cross-tenant escapeshared nodesnode/cluster dedication for sensitive NFs
Pipeline compromiseCI/CD as attack pathsecurity gates, signed artifacts

29.4 Terminology

TermMeaning
CNFCloud-Native Function — containerized NF
NFVINetwork Function Virtualization Infrastructure (the platform)
SBOMSoftware Bill of Materials
service meshSidecar-based connectivity/security layer (e.g., mTLS)
PSSPod Security Standards

Real network example. A cloud-native 5G core stored its NFs' TLS private keys and OAuth signing material as Kubernetes secrets mounted as files, base64-encoded but unencrypted at rest, and the long-term key K's operator constants were in an env var on the ARPF pod "for performance." A red team that obtained read access to one node's filesystem (via a container escape from an unrelated, vulnerable app pod sharing the node) recovered the NF keys and the ARPF constants — effectively the core's crown jewels — without ever touching a 3GPP interface. The 3GPP security was flawless; the cloud layer beneath it gave everything away. Fixes: secrets moved to a vault with encryption at rest and short-lived issuance, K and constants moved into an HSM, crown-jewel NFs given dedicated nodes, and no-privileged-pod + kernel-hardening policies to break the escape path. In a cloud-native core, the platform is the new perimeter — and the master secret belongs in hardware.

★ Chapter Summary

? Review Questions

  1. What four cloud layers sit beneath 3GPP security, and why do they matter?
  2. How do you secure the CNF image supply chain end to end?
  3. Name five Kubernetes hardening controls for a telco core.
  4. Where must the long-term key K live in a cloud core, and why?
  5. Why is the CI/CD pipeline part of the attack surface?
  6. Describe the container-escape-to-crown-jewel path and its defenses.
  7. Why must the SOC unify cloud and 3GPP telemetry?
  8. A core's 3GPP security is perfect but its keys are stolen via a node compromise. What went wrong and how do you fix it?
🧪 Mini lab — find the secrets

In a lab Kubernetes cluster running a CNF (or Open5GS containerized): (1) Inspect how secrets are stored — env vars? mounted files? Kubernetes secrets (base64 ≠ encrypted)? (2) Determine whether a read of one pod/node filesystem would expose another NF's keys. (3) Move one secret into a vault with encryption-at-rest and short-lived issuance; confirm the pod can no longer leak it at rest. (4) Identify where K (or its lab equivalent) lives and argue why it belongs in an HSM. (5) Check for privileged pods and a missing no-escape policy. You've now audited the platform layer that this book's 3GPP security depends on — and that attackers increasingly target instead of the protocols.

← Chapter 28 Chapter 29 Chapter 30 →