--- title: "Label standard and best practices for Kubernetes security" source: "https://www.tigera.io/blog/label-standard-and-best-practices-for-kubernetes-security/" --- [Technical Blog](https://www.tigera.io/category/technical-blog/) # Label standard and best practices for Kubernetes security By [Jad Sadek](https://www.tigera.io/blog/author/jad-sadek/) on Nov 02, 2021 • 6 min read In this blog post, I will be talking about label standard and best practices for [Kubernetes security](https://www.tigera.io/learn/guides/kubernetes-security/). This is a common area where I see organizations struggle to define the set of labels required to meet their security requirements. My advice is to always start with a hierarchical security design that is capable of achieving your enterprise security and compliance requirements, then define your label standard in alignment with your design. This is not meant to be a comprehensive guide for all your label requirements, but rather a framework that guides you through developing your own label standard to meet your specific security requirements. ## Kubernetes labels for network policies Labels are key/value pairs that are attached to Kubernetes objects to identify attributes that are intuitive for users and that are required for specific purposes, such as inventory reporting or the enforcement of an intent. ### Label classification [Kubernetes network policies](https://www.tigera.io/learn/guides/kubernetes-networking/kubernetes-networking-policy/) represent the intent of enforcing security controls to pods using labels to match intended endpoints. Label prefixes can be used to identify label classification. The following short-list is a high-level classification of endpoints required for developing a Kubernetes network policies design: - Multi-tenancy - Application [microsegmentation](https://www.tigera.io/learn/guides/microsegmentation/) - External endpoints - Host endpoints ### Label scope Labels that are required for defining network policies can have the following scope: - **Namespace –** Can be used to define multi-tenancy controls. Role-based access control (RBAC) can be used to restrict creation or modification of namespaces to ensure compliance with high-level multi-tenancy controls. - **Pod –** Can be used to define application microsegmentation controls within the context of one or multiple namespaces. - **[Networkset](http://docs.projectcalico.org/reference/resources/networkset) –** [Calico](https://www.projectcalico.org/) namespaced resource used for defining endpoints external to the cluster that are accessed by or require access to pods within a given namespace. - **[GlobalNetworkset](http://docs.projectcalico.org/reference/resources/globalnetworkset) –** Calico global resource for defining endpoints external to the cluster that are accessed by or require access to pods in any namespace. ### Reserved label keys You will typically want to restrict the use of certain label keys that can be essential for the integrity of your cluster. Restrictions can be implemented at runtime or in the CI/CD pipeline through mutating or validating webhooks. The following are examples of labels you need to reserve: - ***kubernetes* –** Reserved for Kubernetes nodes - ***tigera* and *calico* –** Reserved for Calico components - Any other identifiers for platform applications or hosts for your Kubernetes distribution or management Kubernetes environment ### Multi-tenancy labels Multi-tenancy labels can be used to identify endpoints belonging to a given tenant, or potentially multiple tenants in the case of shared services. Those endpoints can then be selected in network policies for defining East-West or North-South tenant controls. It is recommended to attach multi-tenancy labels to both pods and namespaces. Depending on your enterprise architecture, your definition of tenant might include any of the following: - Business unit - Development team - Application - Client - Shared services - Environment - Compliance - Asset classification Typical standard of multi-tenancy labels: - `sec./tenant-id: ` - `sec./environment: ` - `sec./compliance: ` Notes: - **sec –** Prefix that stands for security and identifies labels required for multi-tenancy - **tenant-uid –** A unique identifier of a tenant in your environment (e.g. sec.www.tigera.io/tenant-id:tigera-customer-success-dev) - **compliance-requirement-uid –** A unique identifier for a given compliance environment (e.g. sec.www.tigera.io/compliance: pci-dss-marketplace) ### Application microsegmentation labels Application microsegmentation labels can be used to identify endpoints backing microservices of a given application. Those endpoints can then be selected in network policies for defining East-West and North-South controls for microservice communication. Typically, a deployment model following one application per namespace fits most customer requirements, except for shared services, which typically need to be deployed in their own namespaces to be accessed by multiple tenants. It is recommended that you attach application microsegmentation labels to pods. Depending on your application architecture, application microsegmentation labels might include any of the following: - Application - Service - Application tier - Version Typical standard of application microsegmentation labels: - `app./name: ` - `app./instance: ` - `app./version: ` - `app./service: ` - `app./tier: ` ### External endpoint labels External endpoint labels can be used to identify endpoints external to the cluster. Those endpoints can then be selected in network policies for defining North-South controls for egress and ingress communication from and to your cluster endpoints. Depending on your enterprise security guidelines, you might require restricting external access for your cluster to any of the following: - Ingress: - From trusted load-balancers for your tenant for exposed services - From trusted subnets in your legacy infrastructure - From trusted partners - Egress: - To services in your legacy infrastructure - To trusted external API services - To trusted repository - To trusted fabric service Typical standard of external endpoint labels: - `eep./ingress-lb: ` - `eep./egress-api: ` - `eep./egress-db: ` - `eep./egress-repo: ` Note: - **eep –** Prefix that identifies external endpoints ### Host endpoint labels Host endpoint labels can be used to identify cluster hosts or external hosts. Those endpoints can then be selected in network policies for defining the following controls: - **Cluster hosts –** North-South and East-West controls for hosts-to-host, pod-to-host and pods with host networking communication. This is required for cluster hardening and for implementing control-plane and management-plane controls. - **External hosts –** North-South and East-West controls for host and legacy applications hosted on bare metal or virtual machines. This is effective for extending cloud-native controls to legacy hosts in integration or migration scenarios. Depending on your Kubernetes distribution and the role of the node in your cluster, host endpoint labels might include any of the following: - Kubernetes node role - Host function - Architecture - Operating system - Region - Datacenter - Rack - Affinity criteria External host endpoint labels might include multi-tenancy, application microsegmentation, and any of the above host endpoint labels as appropriate to secure the hosted legacy services. Typical examples of host endpoint labels, some of which can be native to your Kubernetes distribution: - `kubernetes.io/arch: amd64` - `kubernetes.io/os: linux` - `node-role.kubernetes.io/worker: true` - `node-role.kubernetes.io/egress-gateway: true` - `topology.kubernetes.io/region: ca-central-1` - `topology.kubernetes.io/zone: ca-central-1a` ## Best practices - Develop and communicate a label standard in your organization. - Define labels for security controls according to a hierarchical design that achieves your organization’s security and compliance objectives. - Use an intuitive language in your label definition that enables a quick and simple identification of labeled Kubernetes objects. - Use label key prefixes and suffixes to identify attributes required for asset classification. - Ensure the right labels are applied to Kubernetes objects by implementing label governance checks in your CI/CD pipeline or at runtime. - Develop a comprehensive set of labels that meets the deployment, reporting, and security requirements of different stakeholders in your organization. - Do not abuse the use of labels. Labels should be defined to achieve a specific and explicit purpose.   ***Did you know you can become a certified Calico operator? Learn container and Kubernetes networking and security fundamentals using Calico in this [free, self-paced certification course](https://academy.tigera.io/course/certified-calico-operator-level-1/).***   *Originally posted on [Help Net Security](http://www.helpnetsecurity.com/2021/05/26/kubernetes-security/)*   [Best Practices](https://www.tigera.io/tags/best-practices/) ## Related posts [![YouTube Let AI Prototypes Read Production. The Token Did the Work.](https://www.tigera.io/app/uploads/2026/10/YouTube-Let-AI-Prototypes-Read-Production-featured.png)](https://www.tigera.io/blog/youtube-let-ai-prototypes-read-production-the-token-did-the-work/) #### [YouTube Let AI Prototypes Read Production. The Token Did the Work.](https://www.tigera.io/blog/youtube-let-ai-prototypes-read-production-the-token-did-the-work/) By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/) on Oct 19, 2026 TL;DR: Google Cloud’s post of 22nd July 2026 on why AI apps fail in production describes how a YouTube team gets AI prototypes in front of user research in weeks instead of quarters: a prototyping... [Read more](https://www.tigera.io/blog/youtube-let-ai-prototypes-read-production-the-token-did-the-work/) [![From Merged PR to Governed Pod: Automating AI Agent Deployment on Kubernetes](https://www.tigera.io/app/uploads/2026/10/From-Merged-PR-to-Governed-Pod-featured.png)](https://www.tigera.io/blog/from-merged-pr-to-governed-pod-automating-ai-agent-deployment-on-kubernetes/) #### [From Merged PR to Governed Pod: Automating AI Agent Deployment on Kubernetes](https://www.tigera.io/blog/from-merged-pr-to-governed-pod-automating-ai-agent-deployment-on-kubernetes/) By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/) on Oct 13, 2026 In short, automating the AI agent lifecycle is this year’s pitch: Google Cloud’s walkthrough of 30th July 2026 turns the whole thing into a conversation with a coding agent. On Kubernetes the deploy half of... [Read more](https://www.tigera.io/blog/from-merged-pr-to-governed-pod-automating-ai-agent-deployment-on-kubernetes/) [![Gemini Never Left the Sandbox. The Sandbox Had a Door.](https://www.tigera.io/app/uploads/2026/10/gemini-featured.png)](https://www.tigera.io/blog/gemini-never-left-the-sandbox-the-sandbox-had-a-door/) #### [Gemini Never Left the Sandbox. The Sandbox Had a Door.](https://www.tigera.io/blog/gemini-never-left-the-sandbox-the-sandbox-had-a-door/) By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/) on Oct 7, 2026 In short, in May 2026 a Gemini model under evaluation by the AI security firm Irregular reached the systems of three real companies, and the incident has been reported as a breakout. By Google’s own... [Read more](https://www.tigera.io/blog/gemini-never-left-the-sandbox-the-sandbox-had-a-door/)