Full text
International Journal of Computer Techniques–IJCT Volume 12 Issue 6, November 2025 Open Access and Peer Review Journal ISSN 2394-2231 https://ijctjournal.org/ ISSN :2394-2231 http://www.ijctjournal.org Page 103 The Zero Trust Imperative for 5G and Cloud-Native Telecom Operators Krishnaveni Palanivelu [email protected] Abstract The evolution of telecommunications networks from hardware-driven infrastructure to cloudnative architectures has fundamentally changed the security landscape. Traditional perimeterbaseddefense modelsnolonger sufficein a5Gand TelcoCloudenvironment where workloads, APIs, and network functions are distributed across physical, virtual, and cloud-native domains. Zero TrustArchitecture (ZTA)— based on theprincipleof“never trust, always verify” —has emerged as a foundational approach for securing modern telco networks. This paper explores the key concepts of Zero Trust in the context of 5G and Telco Cloud, outlines common implementationchallenges, andprovides practical strategies for integrating ZTA into existing OpenShift-orKubernetes-based environments. Real-world examples fromnetworkslicing, CNF deployment, and multi-cluster orchestration illustrate how operators can build a resilient, identity-driven, and continuously verified telco security posture. 1. Introduction Telecommunications networks have traditionally relied on perimeter security, assuming that entities insidethe network are trustworthy. This model worked reasonably well for legacy systems, where the infrastructure was static and tightly controlled. However, the introductionof 5G, Network FunctionVirtualization(NFV),and Cloud-Native NetworkFunctions (CNFs) has dissolved this perimeter. Telco infrastructure is nowcomposed of: Multi-vendorCNFsrunning in OpenShiftor Kubernetes clusters Dynamic APIs connectingcore, transport,and edge networks Distributededge nodesand partner integrations Each of these elements increases the attack surface, making implicit trust dangerous. Zero Trust Architectureprovides a framework to authenticate, authorize, and continuously validate every entity — human, device, or workload — before granting access or connectivity. 2. What is Zero Trust Architecture (ZTA)? Zero Trust is not a product, but a security philosophy. It assumes that threatsexist both inside and outside the network and that no communication or transaction should be trusted by default. According to NIST SP 800-207, the core principles of Zero Trust are: 1. Allentitiesare untrustedby default. 2. Access is granted based on identityand policy, withthe least privilege possible.
International Journal of Computer Techniques–IJCT Volume 12 Issue 6, November 2025 Open Access and Peer Review Journal ISSN 2394-2231 https://ijctjournal.org/ ISSN :2394-2231 http://www.ijctjournal.org Page 104 3. Continuous monitoring and verification are mandatory. 4. Microsegmentation ensures that lateral movement is restricted. 5. Automation and policy enforcement are integratedacross systems. Whenadaptedtothetelcoecosystem,ZTAextendsbeyondITboundaries—it governsnetwork slices, control planes, management APIs, CNFs, and inter-cluster communication. 3. Why Telco NetworksNeed Zero Trust 3.1 Expanded Attack Surface 5G introduces a distributed architecture with multiple trust boundaries — from the core network to the edge. Network slicing allows multiple tenants and applications to coexist, increasing the risk of cross-slice attacks. APIs used for orchestration and service exposure(e.g., NEF, NSSF) are accessible externally. Multi-vendorCNFs introducesoftwaresupply chain vulnerabilities. 3.2 Dynamic and Ephemeral Components In cloud-native environments, workloads are ephemeral — pods and containers appear, disappear,and scaledynamically.Traditional IP-based security controlscan’t track these entities effectively. 3.3 Supply Chain Risks Telcos increasingly rely on open-source software, external vendors, and CI/CD pipelines. Without verification, malicious or compromised container images can infiltrate production clusters. 3.4 Regulatory Pressure Regulatoryframeworkslike3GPPSA3,GSMANESAS,andNISTZeroTrustguidelinesrequire stronger isolation, traceability, and encryption across all network planes. 4. Key Components of Zero Trust in Telco Cloud ImplementingZeroTrustrequiresadaptingitspillarstothetelcoecosystem. ZTA Pillar Telco Adaptation Identityand Access Management (IAM) Identity-basedaccessforusers,APIs,andworkloads.Integration with LDAP, OAuth, or OpenID for operators and CNFs. Network Segmentation Use of microsegmentation at Layer 3–7 via Kubernetes NetworkPolicies, SDN, or service mesh. Continuous Monitoring Centralized logging and real-time behavior analytics using
International Journal of Computer Techniques–IJCT Volume 12 Issue 6, November 2025 Open Access and Peer Review Journal ISSN 2394-2231 https://ijctjournal.org/ ISSN :2394-2231 http://www.ijctjournal.org Page 105 Prometheus,Grafana,and AI-based anomalydetection. Policy Enforcement Useof OpenPolicy Agent (OPA), Kyverno, or admission controllers to enforce runtime compliance. EncryptionandTrust Anchors TLS forall intra-clusterand inter-cluster communication;use of TPM and Secure Boot for hardware trust.
International Journal of Computer Techniques–IJCT Volume 12 Issue 6, November 2025 Open Access and Peer Review Journal ISSN 2394-2231 https://ijctjournal.org/ ISSN :2394-2231 http://www.ijctjournal.org Page 106 5. Practical Challenges and Real-World Scenarios 5.1 Challenge1:LegacyIntegration Scenario: A telco operator runs a hybrid setup — part of the 5G Core on an OpenShift cluster, and legacy EPC functionson bare metal. Legacy nodes lack identity-based authentication,dependingonly on IP whitelisting. Problem: This creates“blind trust”zones where compromised systems can access control-plane interfaces. Solution: Implement an identity proxy using APIgateways or service mesh sidecars that enforce mTLS (mutual TLS) and JWT-basedserviceidentityeven for legacycomponents.Graduallyphaseout IP-based ACLs. 5.2 Challenge 2: Multi-Cluster Communication in Hub-Spoke Architectures Scenario: A telco cloud uses a central hub cluster for orchestration and multiple edge clusters for CNF workloads. These clusters communicate via APIs over WAN links. Problem: If the connection between clusters isn’tauthenticated or encrypted, an attacker could impersonate an API call or inject malicious payloads. Solution: Establishcluster federation using OpenShift ACM (AdvancedCluster Management) or similar tools with mutual certificate-based trust. Use service mesh federation (e.g., Istio or OpenShiftService Mesh) for secure servicetoservice communication with automatic key rotation. 5.3 Challenge 3: Insecure CNF Supply Chain Scenario: A CNFvendor deliversDocker images viaan internalregistry. There’s no validation of image integrity or content. Problem: Malicious or outdated images can be introduced into production, leading to runtime exploits. Solution: Implementimagesigning(usingSigstore,Cosign,orRedHatQuay) andenforce verification during deployment. Integrate software composition analysis (SCA) and vulnerability scanning in CI/CD pipelines.
International Journal of Computer Techniques–IJCT Volume 12 Issue 6, November 2025 Open Access and Peer Review Journal ISSN 2394-2231 https://ijctjournal.org/ ISSN :2394-2231 http://www.ijctjournal.org Page 107 Use Kubernetes admission controllers to reject unsigned or unverified images. 5.4 Challenge4: LateralMovement BetweenCNFs Scenario: TwoCNFs share thesame OpenShiftnamespace anduse thesamedefault network. Problem: A compromise in one CNF can beused to probeor exploit another, due to flat network connectivity. Solution: Enforcenamespace-level isolation with NetworkPolicies. Use Service Mesh Authorization Policies to restrict traffic between services. Adopt RBAC (Role-Based Access Control) to isolate service accounts and API access. 5.5 Challenge 5: Human Access and Privilege Escalation Scenario: Operational users access both management (OneView, SR Linux) and control-plane systems with shared credentials. Problem: If one credentialis compromised, it can bereused acrosssystems. Solution: Centralize authentication using LDAP/Active Directory + SSO (Keycloak, RHSSO). Apply leastprivilege access (e.g.,“break-glass”emergency accounts). Enable MFA(Multi-Factor Authentication) and session monitoringfor privileged operations. Auditall changes using SIEM integration. 6. ImplementationFrameworkforZeroTrustinTelcoCloud Step 1: Identity Foundation Define identities for all entities — users, CNFs, APIs, and infrastructure components. Implement strong authentication mechanisms using certificates and tokens. Managelifecycle viaIAM systems (Keycloak,RHSSO). Step 2:Network Microsegmentation Define trustboundaries: control plane,data plane,and managementplane. Apply NetworkPolicies in OpenShift for each CNF namespace. Use service mesh to implement mTLS between services.
International Journal of Computer Techniques–IJCT Volume 12 Issue 6, November 2025 Open Access and Peer Review Journal ISSN 2394-2231 https://ijctjournal.org/ ISSN :2394-2231 http://www.ijctjournal.org Page 108 Separate customer-facing CNFs from internal components via VLANs or SDN overlays. Step 3: Continuous Verification Monitoreveryaccess eventand flowusing telemetry(Prometheus,Loki, ELK). Implementbehavioral anomaly detection using AI models trained on normal traffic baselines. Feed alertsinto SecurityOrchestration,Automation, and Response (SOAR) tools. Step 4: Policy Enforcement and Automation Apply Open Policy Agent (OPA) or Kyverno for runtime policy checks. Examplepolicy: block deployment of any container imagenot signed by a trusted key. Automate compliance audits via Ansible + OpenSCAP. Step 5: Data Protection Encrypt all communication (TLS 1.3+). Useetcd encryption at rest in OpenShift. Implement securekey management (Vault, KMS). ProtectbackupandDRdatawithintegrityverification. 7. Real-World Example: Zero Trust in a 5G Core Deployment ArchitectureOverview A Tier-1 telco deployedits 5G Core(AMF, SMF, UPF, PCF) on OpenShift acrosstwo clusters — control plane (hub) and user plane (edge). Challenges Mixedvendor CNFs withdifferent securitymaturity levels Legacy NMS systems without identity-based access API communication across WAN links Implementation 1. IdentityandCertificates: Each CNF received an x.509 certificateissued by an internal PKI, managed via OpenShift certmanager. 2. Microsegmentation: Each CNF namespace implemented network policies limiting traffic only to approved services (e.g., AMF ↔ SMF). 3. ServiceMesh: Deployed Istio for encrypted service-to-service communication using mTLS.
International Journal of Computer Techniques–IJCT Volume 12 Issue 6, November 2025 Open Access and Peer Review Journal ISSN 2394-2231 https://ijctjournal.org/ ISSN :2394-2231 http://www.ijctjournal.org Page 109 4. Continuous Monitoring: IntegratedPrometheus and GrafanawithSIEM(Splunk)foranomalydetection. 5. Policy Enforcement: Admission controller rejected unsigned CNF images. 6. Human Access Control: All administrative access via Keycloak with MFA. Outcome Reduced blast radius from potential CNF compromise Unified visibility across clusters Compliance with GSMA NESAS security baseline 8. Measuring Success: KPIs for Zero Trust Adoption Metric Description Goal Authentication coverage % of services using mTLS or token-based auth >95% Segmentation coverage % of namespaces with NetworkPolicies >90% Image verification rate % ofworkloads using signed images 100% Privilege access reduction # of shared credentials eliminated Target: 0 Detection-to-responsetime Mean time to detect/respond(MTTD/MTTR) <5 min G. Overcoming Common Pitfalls Pitfall Recommendation TreatingZeroTrustasa singleproduct Design aframeworkwithmultipleintegrated controls Over-segmentation causing performance Balance security withnetwork throughput; validate issues latency Manual certificate management Automatevia cert-manager or Vault Ignoring runtime visibility Deploy continuous security monitoring with anomaly alerts Lackof executive sponsorship TieZero Trust to compliance and businessrisk reduction
International Journal of Computer Techniques–IJCT Volume 12 Issue 6, November 2025 Open Access and Peer Review Journal ISSN 2394-2231 https://ijctjournal.org/ ISSN :2394-2231 http://www.ijctjournal.org Page 110 10. Future Outlook As telco networks evolve toward 6G, AI-driven orchestration, and quantum-resilient encryption, Zero Trust will become the default design principle rather than an add-on. Future systems will leverage: AI-based identity scoring for adaptive access control Confidential computing for workload isolation Post-quantumencryption for long-termdata integrity Thejourneyto ZeroTrust is continuous,but earlyadopters arealready achieving measurable security and operational benefits. 11. Conclusion Zero Trust is nota one-time deploymentbut a strategictransformationinhowtelconetworks are designed, deployed, and operated. By eliminating implicit trust, enforcing strongidentity verification, andcontinuously monitoring every connection,operatorscan securedynamic, distributed 5Gand TelcoCloud environments against evolving threats. As telcos embrace cloud-native architectures,Zero Trustoffers a unified, scalable, and standards-aligned approach to protect their mostcritical infrastructure — ensuringresilience, compliance, and customer trust. References 1. NIST Special Publication 800-207 — Zero Trust Architecture, 2020. 2. 3GPPTS 33.501— Security architecture andprocedures for 5G system, Release17. 3. GSMA NESAS — Network Equipment Security Assurance Scheme, 2023. 4. Red Hat — Securing Cloud-Native 5G Networks, Technical Whitepaper, 2024. 5. ETSINFV-SEC 003— Security; Security and TrustGuidance forNFV Architectural Framework, 2022. 6. CNCF— Cloud Native Security Whitepaper, 2023. 7. Gartner — Zero TrustSecurity for 5Gand Edge Computing, 2024.