In this blog post, I will be talking about label standard and best practices for 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.
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.
Kubernetes network policies 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:
Labels that are required for defining network policies can have the following scope:
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:
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:
Typical standard of multi-tenancy 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:
Typical standard of application microsegmentation 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:
Typical standard of external 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:
Depending on your Kubernetes distribution and the role of the node in your cluster, host endpoint labels might include any of the following:
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:
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.
Originally posted on Help Net Security
Get updates on blog posts, new releases and more!