Enforcing Enterprise Security Controls in Kubernetes using Calico Enterprise

Hybrid cloud infrastructures run critical business resources and are subject to some of the strictest network security controls. Irrespective of the industry and resource types, these controls broadly fall into three categories.

  1. Segmenting environments (Dev, Staging, Prod)
  2. Enforcing zones (DMZ, Trusted, etc.)
  3. Compliance requirements (GDPR, PCI DSS)

Workloads (pods) running on Kubernetes are ephemeral in nature, and IP-based controls are no longer effective. The challenge is to enforce the organizational security controls on the workloads and Kubernetes nodes themselves. Customers need the following capabilities:

  • Ability to implement security controls both globally and on a per-app basis: Global controls help enforce segmentation across the cluster, and work well when the workloads are classified into different environments and/or zones using labels. As long as the labels are in place, these controls will work for any new workloads.
  • Generate alerts if security controls are tampered with: Anyone with valid permissions can make changes to the controls. There is a possibility that these controls can be modified without proper authorization or even with a malicious intent to bypass the security. Hence, it is important to monitor changes to the policies.
  • Produce an audit log showing changes to security controls over time: This is important for compliance purposes.

Existing security tools are designed for hosts and do not understand Kubernetes and pods. With Calico Enterprise, you can apply our enterprise security controls to both Kubernetes nodes and pods. Another aspect to consider is monitoring and visibility. Traditional tools are built for IP-based connectivity monitoring. With Kubernetes, you need visibility into the pod, namespace, policy, and labels for a connection. Without Kubernetes-aware logs, there is no visibility into network connectivity. Without visibility, troubleshooting and compliance monitoring becomes really difficult.

How Does It Work?

Kubernetes nodes and workloads must be labeled appropriately, and the app on-boarding workflow must ensure that the labels (required for security controls) are applied to the workloads. Even if the resources auto-scale up or down and are ephemeral, the label ensures a consistent selector for the workload. Then the security controls are applied in a declarative manner. A policy example is shown in the diagram on the right. Irrespective of whether the labels DEV and PROD apply to pods or nodes, Calico Enterprise will enforce the policy.

Policy Tiers

As you grow to hundreds of policies and have different teams accessing the cluster, you will need to plan for role separation. A very common practice is to separate Security, Ops and Dev teams. You may wish to implement the policy model so that each team has access to only its policies. Calico Enterprise provides policy tiers for this purpose. Tiers are Kubernetes resources that can be controlled using role-based access control (RBAC).  The diagram, below, illustrates the tiering model.

  • Platform tier has the policies for basic cluster component communication and access to resources like storage.
  • Security tier has organizational controls. Security and Compliance teams have access to this tier.
  • All applications can be placed under the App tier, or you may further segregate the individual apps (or business unit) into their own tiers.

Note that some customers prefer to have a platform tier in the left-most column, to give highest preference to basic cluster functioning. It all comes down to the security blueprint of your organization.

Calico Enterprise provides you with comprehensive data on endpoints, policies and logs. Auditors need reports and actionable information, which is typically delivered in the form of logs and reports. You can define the scope of the report or an alert as a Kubernetes resource in Calico Enterprise. Access to reports can be controlled by role (e.g., for individual teams) and are available for download from the UI.


  • Enterprise Security Controls fulfills some baseline requirements in your Kubernetes journey
  • Audit logs for the controls help you to meet organizational and regulatory compliance requirements
  • Rich flow logs with Kubernetes context help you with troubleshooting and compliance, and accelerate your Kubernetes adoption

Using Enterprise Security Controls

It’s important to adapt your existing security controls to Kubernetes. Here are some recommended approaches:

  • Build your blueprint for Enterprise Security Controls in Kubernetes and get stakeholder approval. Your blueprint should have a well-defined label taxonomy.
  • Use Calico Enterprise tiers to implement role separation. This enables you to implement organizational controls cluster-wide, and still allow the Dev team to define policies for their applications. This helps to facilitate agile adoption.
  • Use Calico Enterprise flow visualization and dashboards for visibility and troubleshooting. Provide access to the Dev team to enable them to resolve their app connectivity issues faster.

Want to learn more?  Explore these resources…

Policy tiers: http://docs.tigera.io/security/tiered-policy#the-default-tier-always-last
Protect Kubernetes nodes: http://docs.tigera.io/security/protect-hosts#how-to
Flow and audit logs: http://docs.tigera.io/security/logs/
Compliance reports: http://docs.tigera.io/security/compliance-reports/

Join our mailing list

Get updates on blog posts, workshops, certification programs, new releases, and more!