--- title: "Leveraging Service Accounts for Label-based Security" source: "https://wordpress-1075849-4005834.cloudwaysapps.com/blog/label-based-security-is-great-but-who-watches-the-watchers/" --- [Technical Blog](https://wordpress-1075849-4005834.cloudwaysapps.com/category/technical-blog/) # Leveraging Service Accounts for Label-based Security By [Christopher Liljenstolpe](https://wordpress-1075849-4005834.cloudwaysapps.com/blog/author/liljenstolpe/) on Jan 31, 2019 • 4 min read One of the key Kubernetes security concepts is that workload identity is tied back to information that the orchestrator has. The orchestrator is actually the authoritative entity for what the actual workloads are in the platform. Kubernetes uses labels to select objects and to identify collections of objects that satisfy certain conditions. We, and others in the Kubernetes networking space, often talk about using Kubernetes ‘labels’ as identity bearers.  Label selectors are the primary thing that native Kubernetes network policy uses to identify the pods which a policy matches on. (Tigera Secure and Tigera’s Project Calico follow the same paradigm and provide even richer network policy capabilities using labels to identify collections of workloads.) Here is an example of a pod definition: ``` `apiVersion: v1 kind: Pod metadata: Labels: name: nginx frontend: server spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80` ``` Kubernetes Role-Based Authentication (RBAC) allows for the ability to control who can manipulate individual API objects, some examples of which include Pods, Services, Deployments, and Service Accounts.  This means that it is possible to grant (or deny) a user or group of users the ability to manipulate given API objects (such as launch pods, destroy services, etc.) It should be noted that labels are not an API object, but part of other API objects.  That means that if you grant a developer the permissions to create pods (create permissions on the Pod API object) they can add any labels that they want to that pod). In many organizations, this is sufficient as there has to be a level of trust in the people actually creating and launching the workloads.  However, in some organizations, especially ones with multiple groups with their own security responsibilities, or organizations with specific requirements, such as compliance or regulatory concerns, not having the ability to control who can attach certain labels on workloads is a problem. It would seem that it would be easy, from a network policy implementation perspective, to control what labels are honored, labels are used for many things in Kubernetes, not just network policy.  It could lead to confusion and chaos if certain parts of Kubernetes ‘honored’ a given label, and other parts of the platform did not. A solution to this requirement comes in the form of another API object that can be attached to workloads in  Kubernetes is the service account. Below is an example of a service account API object, and pod with that service account: ``` `apiVersion: v1 kind: ServiceAccount metadata: name: build-robot apiVersion: v1 kind: Pod metadata: name: my-pod spec: serviceAccountName: build-robot Label: automation == "build"` ``` Service accounts (since they are an API object) are discretely RBAC controlled which means that each service account can have its own RBAC permissions.  Furthermore, service accounts, like all other Kubernetes objects, can themselves have labels. This means that there is a fairly fine-grained RBAC controlled label artifact that is available in Kubernetes. It happens that we at Tigera have extended our network policy implementation to use Service Accounts, and labels in service accounts as another ‘selector’ in our policy definition. The following is an example of a Calico network policy, first matching a label, and next matching a service account can be seen below: ``` `apiVersion: projectcalico.org/v3 kind: GlobalNetworkPolicy metadata: name: allow-frontend spec: selector: custDB == 'server' types: - Ingress ingress: - action: Allow protocol: TCP source: selector: frontend == 'server' destination: ports: - 8080 apiVersion: projectcalico.org/v3 kind: GlobalNetworkPolicy metadata: name: allow-frontend spec: selector: custDB == 'server' types: - Ingress ingress: - action: Allow protocol: TCP source: serviceAccounts: selector: automation == 'build' destination: ports: - 8080` ``` There are some things to be aware of, when using service accounts, however.  Each pod can only have a single service account bound to it. You can think of a service account as being a unique pod identifier. However, since service accounts can also be labeled (like any other Kubernetes API object).  This means that those labels can be used to create ‘groups’ of service accounts, just like label selectors for pods, services, network policies which follow standard Kubernetes practice. Since Service Accounts are a separate API object, you can use RBAC to restrict which users can manipulate the service account and its labels.  This allows the designation of specific trusted entities (code and/or people) who can grant the necessary and required selectors (service account labels) to a given service account, and make that service account available in a given namespace.  This capability, available in both Tigera Secure and Tigra’s Project Calico, provides a tighter level of control over how policies are applied in your cluster. ————————————————- [**Free Online Training**](https://wordpress-1075849-4005834.cloudwaysapps.com/events/) Access Live and On-Demand Kubernetes Tutorials [**Calico Enterprise – Free Trial**](https://www.calicocloud.io/home) Solve Common Kubernetes Roadblocks and Advance Your Enterprise Adoption [Open Source](https://wordpress-1075849-4005834.cloudwaysapps.com/tags/open-source/)[Products](https://wordpress-1075849-4005834.cloudwaysapps.com/tags/products/)[Project Calico](https://wordpress-1075849-4005834.cloudwaysapps.com/tags/project-calico/) Add Tigera as a preferred source on Google to see more of our content in your search results. [![Add as a preferred source on Google](https://wordpress-1075849-4005834.cloudwaysapps.com/app/themes/tigera2021/dist/img/google-preferred-source-light.png)](https://www.google.com/preferences/source?q=tigera.io) ## Related posts [![What’s New in Calico: Winter 2026 Release](https://wordpress-1075849-4005834.cloudwaysapps.com/app/uploads/2026/03/What-is-new-in-Calico-winter-2026.png)](https://wordpress-1075849-4005834.cloudwaysapps.com/blog/whats-new-in-calico-winter-2026-release/) [Company Blog](https://wordpress-1075849-4005834.cloudwaysapps.com/category/company-blog/) #### [What’s New in Calico: Winter 2026 Release](https://wordpress-1075849-4005834.cloudwaysapps.com/blog/whats-new-in-calico-winter-2026-release/) By [Veronika Smolik](https://wordpress-1075849-4005834.cloudwaysapps.com/blog/author/veronika-smolik/) on Mar 4, 2026 AI Powered Intelligence, Unified Traffic Observability and Scalable Infrastructure Management As anyone managing one or more Kubernetes clusters knows by now, scaling can introduce an exponentially growing number of problems. The sheer volume of metrics,... [Read more](https://wordpress-1075849-4005834.cloudwaysapps.com/blog/whats-new-in-calico-winter-2026-release/) [![Join Calico at KubeCon Europe 2026: AI Agents, Silent Discos, and Dutch Delights!](https://wordpress-1075849-4005834.cloudwaysapps.com/app/uploads/2026/02/Blog-Kubecon-Euro-2026-.png)](https://wordpress-1075849-4005834.cloudwaysapps.com/blog/calico-at-kubecon-cloudnativecon-europe2026/) #### [Join Calico at KubeCon Europe 2026: AI Agents, Silent Discos, and Dutch Delights!](https://wordpress-1075849-4005834.cloudwaysapps.com/blog/calico-at-kubecon-cloudnativecon-europe2026/) By [Tigera Team](https://wordpress-1075849-4005834.cloudwaysapps.com/blog/author/marketingtigera-io/) on Feb 25, 2026 The cloud-native community is heading to the historic canals and vibrant tech scene of Amsterdam for KubeCon + CloudNativeCon Europe 2026! From March 23–26, Amsterdam will be buzzing with the latest in Kubernetes, platform engineering,... [Read more](https://wordpress-1075849-4005834.cloudwaysapps.com/blog/calico-at-kubecon-cloudnativecon-europe2026/) [![Project Calico 3.30+ Hackathon: Show Us What You Can Build!](https://wordpress-1075849-4005834.cloudwaysapps.com/app/uploads/2026/02/Blog-Hackathon-.png)](https://wordpress-1075849-4005834.cloudwaysapps.com/blog/project-calico-3-30-hackathon-show-us-what-you-can-build/) #### [Project Calico 3.30+ Hackathon: Show Us What You Can Build!](https://wordpress-1075849-4005834.cloudwaysapps.com/blog/project-calico-3-30-hackathon-show-us-what-you-can-build/) By [Tigera Team](https://wordpress-1075849-4005834.cloudwaysapps.com/blog/author/marketingtigera-io/) on Feb 17, 2026 Build the Future of Cloud-Native Networking! 🚀 The Calico community moves fast. With the releases of Calico 3.30 and 3.31, brings improvements in scalability, network security, and visibility. Now, we want to see what YOU... [Read more](https://wordpress-1075849-4005834.cloudwaysapps.com/blog/project-calico-3-30-hackathon-show-us-what-you-can-build/)