---
title: "Introducing: Application Layer Policy"
source: "https://www.tigera.io/blog/introducing-application-layer-policy/"
---

[Technical Blog](https://www.tigera.io/category/technical-blog/)

# Introducing: Application Layer Policy

By [Spike Curtis](https://www.tigera.io/blog/author/spike/) on Dec 04, 2017 • 6 min read

**Security is a moving target.** Each year we see more sophisticated attacks and ever larger scale breaches. At the same time, enterprises are calling for more deployment flexibility—across availability zones and cloud providers—to meet worldwide customer demand and exacting uptime requirements.

These two forces have led to the development and popularization of the *Zero Trust Network Security Model*. The core idea behind this model is that we abandon the assumption that network locality is sufficient to establish trust. Instead, we authenticate and authorize each network flow using multiple attributes. Crucially, each workload is issued the means to cryptographically prove its identity as part of the authentication process.

In this way, **trust is removed from the network**. While this might seem scary at first, it is actually quite liberating since it frees us from complex configuration for securing traffic from zone-to-zone or cloud-to-cloud. However, Zero Trust Networks have been a challenge to realize, requiring custom glue code to integrate authentication, authorization, encryption and policy enforcement at multiple points in the application stack.

Since, at Tigera, we are trying to bring **secure application connectivity** to all adopters of cloud native technologies, we thought long and hard about how to enable the Zero Trust approach in a way that would be easily consumable by everyone.

**Today we are announcing Application Layer Policy for Calico**, which, when combined with the open source [Istio project](http://istio.io/), will make it simple for anyone to build their own Zero Trust Networks. Application Layer Policy builds on Calico’s proven policy model, extending Calico to support policy from the Network Layer all the way up to the Application Layer.

Application Layer Policy for Calico has the following benefits:

- **Operational simplicity and ease of adoption** - Unified L3-7 policy following well established Kubernetes idioms - Label-based flexibility puts organizations in control - Fully compatible with existing Calico Policy

- **Cloud native & legacy** - Works with containers, VMs and standalone hosts - Allows incremental adoption of Istio - Single policy management API for across diverse deployments

Istio places a high-performance application layer proxy ([Envoy](http://www.envoyproxy.io/), originally built by the Lyft team, and now a project within the Cloud Native Computing Foundation) in front of each workload to which all application connectivity functions are delegated. In this way the workloads form a “service mesh.” The proxy provides consistent and centrally managed functions without application code changes, and the distributed data plane allows horizontal scale-out. These functions enhance reliability (e.g. retries and circuit breaking), visibility (e.g. metrics and tracing), and security—the focus of this announcement. The Istio control plane issues key and certificate pairs to each workload which can be used for mutually authenticated TLS for all workload-to-workload connections.

“It’s great to see Tigera playing an active role in the Istio community and extending Kubernetes network policy support to application level enforcement using Istio. In fact, [Google Kubernetes Engine](http://cloud.google.com/kubernetes-engine/) already offers Calico for enforcing Kubernetes network policy controls and we look forward to customers using this capability with both GKE and Istio. The work they are doing with Calico integration is a nice addition to the Istio security options available to users.”

– Varun Talwar, Product Manager at Google for Istio.

Application Layer Policy builds on this authentication layer to enact **fine-grained access control**. When an operator enables access to a service via Application Layer Policy, Calico performs multiple checks including against the workload ID in the certificate, and network layer information like expected IP provided by the cluster manager (e.g. Kubernetes). Multi-layer checks are performed automatically—there is no need to write multiple policies for the different layers. Application Layer Policy can be substantially more fine grained than existing policy, down to the API method or resource.

In addition to multiple authorization checks, Application Layer Policy is also **enforced at multiple locations**: the existing iptables enforcement and a new enforcement point built into the Istio proxy. Multiple layers of defenses impede attackers, yet are now easy to configure thanks to the unified Application Layer Policy in Calico which provides a single point of control for developers and operators.

“I’m excited to see the Istio and Envoy contributions from the team at Tigera. Properly securing microservices is one of the hardest things to get right, and I think a lot of folks are going to be interested in the capabilities they are building.”

– Matt Klein, Software Engineer at Lyft and maintainer of Envoy

Like Calico, Istio is designed to support multiple environments including containers, VMs and bare metal to bridge the gap from existing systems and deployments to newer cloud native workloads. Application Layer Policy can be gradually adopted and built into existing deployments. Cryptographic verification of identity is enforced as soon as Istio is enabled for a workload; policy changes are not required.

Calico is available in **hosted Kubernetes offerings from Google and IBM (Amazon EKS and Microsoft AKS both coming soon!)**, and works in every other major cloud via a manifest install.

“We selected Calico as our Kubernetes network provider due to the simplicity of its IP management for containers and specifically for its ability to support Kubernetes network policies. We are excited about Calico’s introduction of Application Layer Policy and we are looking forward to exposing this new feature into the [IBM Cloud Container Service](http://www.ibm.com/cloud/container-service).”

– Dan Berg, Distinguished Engineer for Container Service at IBM

**Application Layer Policy for Calico is available today as an early-access preview.** Check out the [code on GitHub](http://github.com/projectcalico/app-policy) and work through some example policies that demonstrate its power. In the coming weeks we will be working hard to move it from preview to production readiness in an upcoming version of Calico. We will also be building enterprise grade configurability and visibility options for Application Layer Policy in upcoming Tigera offerings (stay tuned for some exciting news on that front!).

Find us this week at CloudNativeCon / KubeCon in Austin, where we will be at booth D5, and I will be highlighting Calico Application Layer Policy in my keynote “[Progress Toward Zero Trust Kubernetes Networks](http://sched.co/CUEF)” at 10:15am on Thursday Dec 7th.

[Open Source](https://www.tigera.io/tags/open-source/)[Products](https://www.tigera.io/tags/products/)[Service Mesh](https://www.tigera.io/tags/service-mesh/)

## Related posts

[![Meet Mylo: An AI-native way to work with Calico](https://www.tigera.io/app/uploads/2026/09/Meet-Mylo-An-AI-native-way-to-work-with-Calico.png)](https://www.tigera.io/blog/meet-mylo-an-ai-native-way-to-work-with-calico/)

#### [Meet Mylo: An AI-native way to work with Calico](https://www.tigera.io/blog/meet-mylo-an-ai-native-way-to-work-with-calico/)

By [Phil DiCorpo](https://www.tigera.io/blog/author/phil-dicorpo/)
on Sep 3, 2026

A library of Calico tools and skills — delivered through the Calico MCP Server What if your hardest network question took ten minutes instead of ten days? Anyone who has operated Kubernetes networking at scale...

[Read more](https://www.tigera.io/blog/meet-mylo-an-ai-native-way-to-work-with-calico/)

[![The Safest Place to Run an AI Agent Is On a Cluster That Doesn’t Trust It](https://www.tigera.io/app/uploads/2026/08/The-Safest-Place-to-Run-an-AI-Agent-Is-On-a-Cluster-That-Doesnt-Trust-It.png)](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/)

#### [The Safest Place to Run an AI Agent Is On a Cluster That Doesn’t Trust It](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/)

By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/)
on Aug 27, 2026

Every organization running AI agents has already made a hosting decision. Most made it by accident. The sales team switched on the agent built into their CRM. Engineering is piloting a coding agent in a...

[Read more](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/)

[![AI Red Team Agents Automate Attacks on your AI Agents. Runtime Policies Automate their Defense.](https://www.tigera.io/app/uploads/2026/08/AI-Red-Team-Agents-Automate-Attacks-on-your-AI-Agents.-Runtime-Policies-Automate-their-Defense.png)](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/)

#### [AI Red Team Agents Automate Attacks on your AI Agents. Runtime Policies Automate their Defense.](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/)

By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/)
on Aug 24, 2026

The AI red teaming market grew up fast this year. OpenAI bought Promptfoo, Cisco and Microsoft shipped automated attack suites, and a seed-stage startup publicly compromised 50 of 55 live customer service bots. These platforms...

[Read more](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/)

<!-- plugin=object-cache-pro client=phpredis metric#hits=6258 metric#misses=38 metric#hit-ratio=99.4 metric#bytes=2147835 metric#prefetches=0 metric#store-reads=410 metric#store-writes=34 metric#store-hits=402 metric#store-misses=27 metric#sql-queries=42 metric#ms-total=1750.86 metric#ms-cache=85.06 metric#ms-cache-avg=0.1920 metric#ms-cache-ratio=4.9 sample#redis-hits=45631463 sample#redis-misses=7843969 sample#redis-hit-ratio=85.3 sample#redis-ops-per-sec=257 sample#redis-evicted-keys=0 sample#redis-used-memory=69411816 sample#redis-used-memory-rss=70148096 sample#redis-memory-fragmentation-ratio=1.0 sample#redis-connected-clients=1 sample#redis-tracking-clients=0 sample#redis-rejected-connections=0 sample#redis-keys=6192 -->
