--- title: "Securing Namespaces and Services in Kubernetes" source: "https://www.tigera.io/blog/securing-namespaces-and-services-in-kubernetes/" --- [Technical Blog](https://www.tigera.io/category/technical-blog/) # Securing Namespaces and Services in Kubernetes By [Casey Davenport](https://www.tigera.io/blog/author/caseydavenport/) on Nov 06, 2015 • 3 min read ## **Namespace and Service Policy** Calico has provided secure networking for Kubernetes clusters for a while now, as demonstrated in this [blog post](https://www.tigera.io/blog/calico-network-policy-comes-to-kubernetes/) from earlier this year.  Our annotation-based security policy allows fine-grained policy declaration at the pod-level.  We’ve recently been working to bring that policy to Kubernetes namespaces and services. ### **Policy at the Namespace Boundary** We think that Kubernetes namespaces are a logical choice for coarse-grained network policy.   This allows you to secure groups of pods using broad strokes, eliminating the need to declare policy on each pod individually.  In this design, namespaces can be declared as “open” or “closed”.  Pods and services in open namespaces are accessible from anywhere, while pods and services in a closed namespace are accessible only from within that namespace.  You can think of this as a logical firewall at the namespace boundary (though in Calico, each pod in that namespace is protected by its own iptables firewall).  This allows you to do things like isolate applications, tenants, or development and production workspaces. The demo video above uses two closed namespaces – client and webapp.  Pods and Services created in a closed namespace are only accessible by other pods within that same namespace, unless they are exposed using a service (see below).  This allows you to secure your applications from the outside world. A common use for an “open” namespace would be for services like DNS, which need to be accessible across the entire cluster. ### **Applying Policy using Services** A closed namespace isn’t particularly useful on its own, since nothing within the namespace is accessible to the outside world! That’s where services come in.  Services allow you to expose pods outside of a closed namespace – essentially poking holes in the logical namespace firewall. In the video above, we expose the frontend service by applying a special label – “projectcalico-policy=open”.  This indicates that the service should be exposed outside of a closed namespace.  Kubernetes services already know which ports and protocols should be accessible on the underlying pods, so we can open the precise IP / protocol / port combination to expose the service. ### **What’s Next?** We’d love to see this simple API implemented in Kubernetes, removing the need for special labels, and replacing them with native fields in the API.  We’ve proposed this approach to the Kubernetes community in this [issue](http://github.com/kubernetes/kubernetes/issues/13459), and we’d love to hear your feedback. While this demo is still a proof-of-concept, we imagine this API being built upon down the road, allowing for more general intent-based policy.  For example, a Kubernetes API object specifically for painting network policy across a selection of pods, or using a label selector to expose services to a group of pods or other services based on labels, allowing fine-grained control of who can access your services. [Open Source](https://www.tigera.io/tags/open-source/)[Project Calico](https://www.tigera.io/tags/project-calico/) ## Related posts [![What’s new in Calico: Spring 2026 Release](https://www.tigera.io/app/uploads/2026/06/Whats-New-in-Calico-NEW-TEMPLATE-2026.png)](https://www.tigera.io/blog/whats-new-in-calico-spring-2026-release/) [Company Blog](https://www.tigera.io/category/company-blog/) #### [What’s new in Calico: Spring 2026 Release](https://www.tigera.io/blog/whats-new-in-calico-spring-2026-release/) By [Veronika Smolik](https://www.tigera.io/blog/author/veronika-smolik/) on Jun 2, 2026 Kubernetes has come a long way since its debut in 2014. It’s gone from running a couple of containerized microservices to orchestrating fleets of production workloads spanning everything from AI agents to full scale VMs... [Read more](https://www.tigera.io/blog/whats-new-in-calico-spring-2026-release/) [![Kubernetes Operational Maturity: Secure and Resilient Cluster Federation with Cluster Mesh](https://www.tigera.io/app/uploads/2026/05/Kubernetes-Operational-Maturity-Secure-and-Resilient-Cluster-Federation-with-Cluster-Mesh.png)](https://www.tigera.io/blog/kubernetes-operational-maturity-secure-and-resilient-cluster-federation-with-cluster-mesh/) #### [Kubernetes Operational Maturity: Secure and Resilient Cluster Federation with Cluster Mesh](https://www.tigera.io/blog/kubernetes-operational-maturity-secure-and-resilient-cluster-federation-with-cluster-mesh/) By [Veronika Smolik](https://www.tigera.io/blog/author/veronika-smolik/) on May 25, 2026 Practically no one runs a single Kubernetes cluster in production these days. Maybe that’s how it started but data sovereignty requirements, acquisitions, AI initiatives and the need for edge servers, among other considerations, have pulled... [Read more](https://www.tigera.io/blog/kubernetes-operational-maturity-secure-and-resilient-cluster-federation-with-cluster-mesh/) [![What’s New in Calico v3.32](https://www.tigera.io/app/uploads/2026/05/Green-Please-use-a-different-background-color-alternately-1.png)](https://www.tigera.io/blog/whats-new-in-calico-v3-32/) #### [What’s New in Calico v3.32](https://www.tigera.io/blog/whats-new-in-calico-v3-32/) By [Reza Ramezanpour](https://www.tigera.io/blog/author/rezar/) on May 13, 2026 We’re excited to announce the release of Calico Open Source v3.32! 🎉 This release corresponds with Kubernetes v1.36 (Codename Haru) and it goes beyond just sharing a cat as the mascot of the release, it... [Read more](https://www.tigera.io/blog/whats-new-in-calico-v3-32/)