Learn Calico - GlobalNetworkPolicy & Tiers

#Introduction

The NetworkPolicy from episode 5 is limited to a single namespace. In a production cluster with dozens of teams, you need policies that apply cluster-wide and an evaluation order you can control. That's the material of episode 6: GlobalNetworkPolicy, GlobalNetworkSet, and tiers.

Have you ever wondered: if two policies from different namespaces contradict each other, who wins? The answer is determined by tiers. This structure is what lets Calico build deterministic layered security, from the platform layer down to the application layer.

#GlobalNetworkPolicy

#Selection Without Namespace Limits

GlobalNetworkPolicy selects workloads across the entire cluster, regardless of namespace. This is perfect for security baselines: a global default deny, rules for kube-system, or rules for workloads with specific labels wherever they are.

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: security-default-deny
spec:
  tier: security
  order: 100
  selector: all()
  types:
    - Ingress
    - Egress
  ingress: []
  egress: []

The all() selector matches every endpoint in the cluster. A policy with ingress: [] and egress: [] becomes a global closure: anything that doesn't pass a rule in an earlier tier will be denied.

#GlobalNetworkSet

GlobalNetworkSet is a labeled collection of IPs that can be used as a policy source or destination without writing IPs one by one. Useful for IP lists that change dynamically — for example, office IP ranges.

apiVersion: projectcalico.org/v3
kind: GlobalNetworkSet
metadata:
  name: office-range
  labels:
    role: trusted
spec:
  nets:
    - 203.0.113.0/24
    - 198.51.100.0/24

A policy can then use source.selector: role == 'trusted' to match all IPs in that set.

#Tiers: The Policy Evaluation Hierarchy

#The Concept of Tiers

All Calico policies are evaluated in tiers — ordered groups of policies. Tiers are created explicitly, and every policy points to its tier. Evaluation starts from the tier with the smallest order to the largest; the first matching rule determines the action and stops evaluation. There are three default tiers commonly used:

• security: for mandatory rules from the platform team, such as default deny and blocklists.
• platform: for shared rules, such as access to monitoring or DNS.
• application: for each application team's own policies.

#Creating a Tier

apiVersion: projectcalico.org/v3
kind: Tier
metadata:
  name: application
spec:
  order: 300
  mode: Enforce

mode: Enforce means the rules in this tier are actually applied. Other modes, such as Disable, are used when you want to temporarily disable an entire tier without deleting its policies.

#Complete Evaluation Order

security (order 100) -> platform (order 200) -> application (order 300)
   |   rule matches?      |    rule matches?        |    rule matches?
   |   Allow/Deny/Pass    |    Allow/Deny/Pass      |    Allow/Deny/Pass
   +--- if matches, done ---+------------------------+

The key principle: if a rule in the security tier already decides Allow, traffic is forwarded and the tiers below it are no longer evaluated. This is why the security team can enforce rules that application teams can't override.

#Practice: Baseline and Per-Team Policies

#Deployment Workflow

A common production pattern: the platform team creates the baseline in the security and platform tiers, then hands namespaces and the application tier to application teams. Here's a command sequence to build it:

calicoctl apply -f security-default-deny.yaml
calicoctl create -f tier-platform.yaml
calicoctl apply -f platform-allow-dns.yaml
calicoctl get tiers
calicoctl get globalnetworkpolicy -o wide

calicoctl get tiers shows the tiers along with their order. Notice the sequence: the global deny is installed first, then platform allow rules such as DNS.

#Per-Team Policies in the Application Tier

Application teams can place their policies in the application tier with the same order; the order between policies within one tier is determined by each policy's order value:

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: payments-allow-api
  namespace: payments
spec:
  tier: application
  order: 100
  selector: app == 'api'
  ingress:
    - action: Allow
      protocol: TCP
      source:
        selector: app == 'web'
      destination:
        ports: [443]

If an application team makes a configuration mistake, these rules only apply within the application tier — the baseline in the security tier still protects the cluster.

#Verifying Evaluation

To make sure policies are truly active, use commands that show the endpoints they match:

calicoctl get networkpolicy -n payments -o yaml
calicoctl get workloadendpoints -n payments --export
calicoctl get globalnetworkpolicy --export -o yaml

--export shows resources together with the extra labels the runtime adds, making it easier to read the actual state.

#Conclusion

Episode 6 gives you full control over policy evaluation order: GlobalNetworkPolicy for cluster-wide rules, GlobalNetworkSet for dynamic IP lists, and tiers for separating the platform's security authority from the applications'.

Key takeaways:

• GlobalNetworkPolicy selects all endpoints without namespace limits.
• Tiers determine evaluation order; the first matching rule determines the action.
• A cluster-wide default deny is built with the all() selector and an empty policy.
• GlobalNetworkSet creates labeled IP lists that policies can select.
• The platform baseline in the security tier can't be overridden by team policies.
• calicoctl get tiers and --export help verify enforcement.

In the next episode, episode 7, we dive into basic observability — flow logs, Prometheus metrics from Felix and Typha, and dataplane troubleshooting to see whether policies and endpoints are really applied on nodes.