In a previous post, we explored how to streamline Cilium NetworkPolicies in OpenShift by automatically isolating Namespaces when a Project is created. This provides a strong foundation for running OpenShift as a multitenant Kubernetes platform. But what happens when tenants need to communicate with each other? Platform teams often need to allow access to shared services while still enforcing strict boundaries between workloads. For example, a hospital network may have patient portals, billing systems, and telehealth apps that all need file handling. A shared file/media service can manage insurance card uploads, medical records, profile photos, and billing PDFs with this shared file/media service. This is where Isovalent Networking for Kubernetes stands out. Instead of stopping at Layer 3 and Layer 4 controls like the default OVN-Kubernetes, it enables Layer 7 policy enforcement directly in the network without introducing additional components. In this post, we walk through a practical scenario using CiliumNetworkPolicies and CiliumClusterwideNetworkPolicies on OpenShift to enforce HTTP method based access in a multitenant/microservices environment. This gives platform engineers a simple and effective way to manage cross-tenant communication by leveraging capabilities already built into Cilium. OpenShift Projects and Multitenancy OpenShift has long treated multitenancy as a core platform concern. If you are joining from my previous blog, you may recall that rather than exposing raw namespaces directly, OpenShift uses Projects as the primary tenant-facing construct. A Project is backed by a Kubernetes namespace, but also includes opinionated workflows around RBAC, quotas, templates, image registry access, and self-service controls. This model gives platform teams a clean separation between cluster administrators and tenant owners. Administrators can define platform-wide guardrails, while application teams are granted scoped control within their assigned Projects. Isovalent Networking for Kubernetes fits naturally into this operating model. Namespace-scoped CiliumNetworkPolicy resources allow tenant teams to define application-specific connectivity inside their Projects, while CiliumClusterwideNetworkPolicy enables platform administrators to enforce consistent security controls across every Project in the cluster. This creates a layered model where OpenShift manages tenancy boundaries and lifecycle, while Cilium extends those boundaries with Layer 7 visibility and cluster-wide network enforcement. When NetworkPolicies Aren’t Enough Let’s take a simple multitenant setup in OpenShift with three namespaces: tenant-a tenant-b shared-services Both tenant namespaces should be isolated from each other, while still being able to access a shared service. This is a common pattern for platform teams supporting multiple application teams on the same cluster. At first glance, everything appears to work as expected. From tenant-a, we can reach tenant-b’s web service: We can also access the shared configuration API: Which also includes its admin endpoint: This is where the problem begins. Tenant workloads should not be able to access each other directly, and they certainly should not be able to access administrative endpoints for other tenants. A typical approach is to use Kubernetes NetworkPolicies on OpenShift to enforce isolation: Deny all ingress into tenant-a and tenant-b, effectively isolating the workloads. Allow both tenants to access the shared config-api service on TCP port 8080 After applying these policies, tenant isolation looks correct on the surface. Access from tenant-a to tenant-b is now blocked: Access to the shared service still works as expected: However, there is still a critical gap: This is where the process falls short. Standard Kubernetes NetworkPolicies on OpenShift operate at Layer 3 and Layer 4. They can control which pods and namespaces communicate, and on which ports, but they cannot inspect or enforce rules based on HTTP paths or methods. In this example, allowing TCP port 8080 means all HTTP traffic is allowed, including sensitive administrative endpoints. For platform teams running multitenant environments, this creates a real challenge: You can allow access to a service But you cannot restrict how that service is used Traditionally, enforcing Layer 7 controls requires introducing additional components such as API gateways, ingress controllers, or service meshes. While effective, these approaches add operational overhead, increase resource consumption, and introduce more moving parts for platform teams to manage. So can we enforce fine-grained, application aware policies in the CNI on OpenShift without adding that extra complexity? Enforcing Layer 7 Policy with Cilium Cilium enables Layer 7 enforcement directly within the CNI by combining eBPF with an embedded Envoy proxy. eBPF programs handle high-performance packet processing in the kernel and can selectively redirect traffic that requires deeper inspection. When a policy includes Layer 7 rules, traffic is steered to a local Envoy instance running on the node, where application protocols such as HTTP are parsed and evaluated against policy. This model allows Cilium to enforce application-aware rules without requiring sidecars or external proxies. Instead of introducing new infrastructure, Layer 7 enforcement becomes an extension of the networking layer itself. Platform teams can define policies based on HTTP methods and paths, while Cilium and Envoy handle enforcement inline as traffic flows through the system. Applying this to the previous scenario, we can now restrict access to the shared config-api so that tenants are only allowed to perform GET requests against /api/, while preventing access to the /admin/ endpoint. With this policy in place, the behavior now aligns with the intended design. Access to other tenant workloads remains blocked: Access to the shared API is still allowed: But attempts to reach the admin endpoint are now explicitly denied: Take a look at the message when trying to reach the admin endpoint. Instead of silently dropping traffic, the request is evaluated at Layer 7 and rejected with an explicit response. In this case, the client receives an HTTP 403 denial rather than a timeout, making it clear that the request was understood but not permitted. Making Policy Non-Optional So far, the examples have used CiliumNetworkPolicy resources, which are namespace-scoped. This works well, however, it assumes that tenants are responsible for defining and maintaining their own policies. In multitenant environments, platform teams often need stronger guarantees. Policies should not be optional, and in many cases, they should not be able to be overwritten by tenant workloads. So how can platform teams ensure policies are enforced cluster-wide? This is where CiliumClusterwideNetworkPolicy becomes an essential part of the platform engineer’s toolbox. CiliumClusterwideNetworkPolicy allows cluster administrators to define and enforce network policies across all namespaces. Unlike namespace-scoped policies, these rules apply cluster-wide and cannot be bypassed by tenant-defined policies. This creates a clear separation of responsibilities, where the platform enforces baseline security and tenants build on top of it. For example, the tenant isolation model described earlier can be enforced globally by default. Instead of relying on each namespace to define a deny policy, a cluster administrator can define a single CCNP that prevents traffic between tenants unless explicitly allowed. This approach enables: Non-overridable security controls enforced by the platform Consistent tenant isolation across the entire cluster Delegated policy management, where tenants can allow traffic without weakening baseline protections Combined with Layer 7 enforcement, CCNPs allow platform teams to define both who can communicate and how that communication is allowed, all from a central control point. Control Without Compromise In real-world multitenant environments, shared services often expose both standard and administrative endpoints. Without Layer 7 enforcement, any tenant with network access to a service can potentially interact with functionality that was never intended for them. With Isovalent Networking for Kubernetes on OpenShift, platform teams can use Cilium to safely expose shared services while ensuring that: Only approved API paths are accessible Administrative endpoints remain protected Tenant boundaries are enforced at the application layer At the same time, by combining namespace-scoped CiliumNetworkPolicy with cluster-wide CiliumClusterwideNetworkPolicy, platform teams can extend these guarantees from individual services to the entire cluster, ensuring consistent enforcement across all tenants. This shifts enforcement from the application into the platform, reducing reliance on individual services to correctly implement and maintain access controls. Summary In OpenShift environments, OVN-Kubernetes and traditional Kubernetes NetworkPolicies provide a solid foundation for Layer 3 and Layer 4 isolation. They are effective for establishing basic tenant boundaries, but as soon as applications require more granular access control, their limitations become apparent. Once traffic is allowed to a service, there is no native way to distinguish between safe and sensitive application-level operations. By extending the networking layer with Isovalent Networking for Kubernetes and Cilium on OpenShift, platform teams can enforce policy at both the namespace and cluster scope. With CiliumNetworkPolicies, teams gain fine-grained Layer 7 control over how services are accessed, while CiliumClusterwideNetworkPolicy enables consistent, non-overridable security controls across all tenants. Together, these capabilities provide a simpler and more powerful model for securing multitenant environments without introducing additional infrastructure such as service meshes or API gateways.