The shift to 5G Standalone (5G SA) represents a fundamental architectural change in telecommunications, moving from monolithic, hardware-centric systems to a highly distributed, cloud-native architecture. While this disaggregation offers agility, flexibility, and scalability, it simultaneously introduces a massive new attack surface. Securing this environment is paramount, particularly given the critical nature of telco networks as national infrastructure and the stringent compliance requirements imposed by regulatory bodies worldwide.

In this complex, cloud-native domain, the 5G Core manages thousands of distributed Cloud-native Network Functions (CNFs). To effectively secure such an environment, the mandate is clear: we must enforce consistent, granular security policies across every site, cluster, and CNF. This is the gold standard of security that modern telco platforms must achieve. 

VMware Telco Cloud Platform leverages its Kubernetes Policy Manager to meet this gold standard of security along with the security governance standards and hardening recommendations established by the NSA and CISA. Kubernetes Policy Manager makes use of Open Policy Agent (OPA) and Gatekeeper to provide a standardized framework for policy-driven orchestration and governance.

Figure 1: Kubernetes Policy Manager

Open Policy Agent (OPA): The Policy Service

OPA acts as the universal policy engine. Its primary role is to interpret and evaluate sophisticated, telco-grade security rules written in Rego. Rego is a high-level, declarative policy language specifically designed for OPA. Rego allows security teams to express complex constraints—from image security and network policies to resource limits and configuration best practices—in a clear, auditable format. OPA decouples policy logic from the enforcement point, making policies highly reusable across various systems, whether Kubernetes, service meshes, or APIs.

Gatekeeper: The Enforcement Mechanism

Gatekeeper tightly integrates OPA into the Kubernetes ecosystem. It functions as a Kubernetes Admission Controller, intercepting all requests made to the Kubernetes API server—specifically CREATE, UPDATE, and DELETE operations. By sitting in the admission control path, Gatekeeper uses the policies defined in OPA to decide whether an incoming configuration is compliant. If the configuration violates a policy, Gatekeeper rejects the request proactively, preventing the insecure configuration from ever reaching the cluster state. Such violations are termed as Admission-time Violations and an alert is raised for such violations by Kubernetes Policy Manager.

The Kubernetes Policy Manager also tracks CNFs deployed before policy enforcement that are found to violate security constraints. These types of violations are termed Audit-time Violations. These violating CNFs are not immediately evicted. However, while the security violation persists, the Kubernetes Policy Manager prevents any subsequent Lifecycle Management (LCM) operations from being performed on them.

Kubernetes Policy Manager translates the enforced security policies into standard Kubernetes constructs, which are then applied to the CaaS clusters. This translation results in the creation of two types of Kubernetes Custom Resources (CRs): Constraint Templates and Constraints.

Figure 2: Kubernetes Custom Resources

• Constraint Template: This CR holds the core of the security logic. It encapsulates the Rego policy logic, defining what the policy is (e.g., all containers must run as non-root). This separation allows policy developers to manage the logic independently.
• Constraint: This CR applies the policy to a specific scope. It defines where the policy should be enforced (e.g., enforce the non-root policy only on CNFs in the core-network namespace, but exempt those in the management namespace).

Using this robust setup, the Kubernetes Policy Manager provides continuous and comprehensive security guardrails:

• Proactive Prevention: By enforcing policies at the admission stage, the system acts as a shift-left security mechanism. It proactively prevents insecure configurations, unauthorized resource deployments, or non-compliant settings from ever being instantiated in the 5G Core.
• Continuous Compliance: The declarative nature of the policies, coupled with Gatekeeper’s audit capabilities, ensures continuous compliance. The system doesn’t just block new insecure configurations; it can also audit the existing cluster state against the defined policies, identifying and flagging resources that may have drifted out of compliance.
• Full Auditability: Every policy enforcement action and every policy evaluation is logged and auditable. This ensures that Telcos can demonstrate adherence to the most stringent regulatory and industry compliance requirements, providing a verifiable record of security posture.

Now let’s run through the steps for implementing and testing the capabilities of Kubernetes Policy Manager:

Deploy OPA 

1. The first step is deploying the policy engine. To deploy the OPA, log into Telco Cloud Automation and navigate to Fleet Management -> Security Policies. Then click on the Open Policy Agent (OPA) tab. 

2. Select the CaaS workload cluster (e.g., caas-wld-02) and click Deploy OPA. Click Deploy OPA again to confirm. 

3. This action triggers the deployment of the OPA and Gatekeeper pods to the cluster, activating the policy enforcement layer.

Enforce Policies 

1. Once the deployment is successful, we can enforce specific security policies. The policies could be based on the company requirements or compliance standards such as NSA-CISA and STIG. As an example, let’s enforce the k8spspprivilegedcontainer policy, which prevents containers requesting root privilege from being spun up. 
2. To do that, let’s navigate to the Security Policies tab. Then click on the ellipsis next to k8spspprivilegedcontainer policy and click Manage Policy. 

3. Click on Assign Cluster, select the workload cluster (e.g., caas-wld-02a), and click Assign Policy to Clusters. 

4. The policy enforcement process is initiated and the policy status changes to Active once completed.

5. Similarly, let’s also apply a second policy, k8scontainerequests, which mandates that containers must have resource requests set.

Test OPA in action

1. Now let’s test the policy enforcement by deploying a CNF that violates the assigned security policies. Navigate to the Configuration sub-section in the GitOps section and click Create New. Click Select next to Select Workload Cluster, select the workload cluster (e.g., caas-wld-02a), and click OK.

2. Then click Configure Gitops. Provide a name for the CNF. Select its relevant repository details, select the manifest and values repositories, and click Save Configuration. And then click Save. 

3. The CNF deployment begins. 

4. You can log into the CaaS cluster via CLI and run kubectl describe replicaset command to get the deployment progress. As expected, the pod spin-up request is denied by Kubernetes Policy Manager. The admission denial occurs because the containers violated both enforced policies: they requested privileged access and failed to define resource requests.

By leveraging the Kubernetes Policy Manager in VMware Telco Cloud Platform, organizations can shift their security posture to proactive governance. This approach reduces the potential for human error, automates compliance checks, and ensures that 5G infrastructure is secure by design from the outset. With the Kubernetes Policy Manager integrated into the Telco Cloud Platform, service providers are empowered to manage a secure, sovereign telco cloud environment reliably and at massive scale. This capability is essential for meeting stringent regulatory requirements and maintaining high service availability.