tigera · ctauchen · Aug 19, 2026
@@ -8,7 +8,7 @@ $[prodname] supports the use of HTTP proxies for connections that leave the clus
 
 `HTTP_PROXY`, `HTTPS_PROXY`, and `NO_PROXY` environment variables can be set on $[prodname] containers by using a mutating admission webhook, or by configuration through the Installation CR if preferred. In the latter case, the Tigera Operator will be responsible for setting proxy environment variables on $[prodname] containers that egress out of the cluster.
 
-With either environment variable configuration method, the Tigera Operator will detect the proxy environment variables that are set on $[prodname] containers that egress out of the cluster and ensure that network policy in the allow-tigera tier allows these connections.
+With either environment variable configuration method, the Tigera Operator will detect the proxy environment variables that are set on $[prodname] containers that egress out of the cluster and ensure that network policy in the calico-system tier allows these connections.
 
 This page will outline how to configure an HTTP proxy using the Installation CR.
 

@@ -35,7 +35,7 @@ $[prodname] extends the standard `NetworkPolicy` object to provide advanced netw
 
 <DocCardLinkLayout>
   <DocCardLink docId='network-policy/policy-tiers/tiered-policy' />
-  <DocCardLink docId='network-policy/policy-tiers/allow-tigera' />
+  <DocCardLink docId='network-policy/policy-tiers/calico-system' />
   <DocCardLink docId='network-policy/policy-tiers/policy-tutorial-ui' />
   <DocCardLink docId='network-policy/policy-tiers/rbac-tiered-policies' />
 </DocCardLinkLayout>

@@ -0,0 +1,75 @@
+---
+description: Customize the behavior of the calico-system tier that Calico Cloud installs by default to keep its own components reachable.
+---
+
+# Change calico-system tier behavior
+
+:::warning
+The `calico-system` tier contains policies that secure $[prodname] components and is critical to cluster integrity. It is controlled by the Tigera Operator, and policies in the tier should not be edited, and the tier should not be moved. Although you can change the behavior of calico-system using adjacent tiers, you can inadvertently break critical cluster traffic. We highly recommend that you work with Support to implement changes around `calico-system` to prevent service disruption.
+
+:::
+
+## Big picture
+
+Change traffic behavior of the tier that secures $[prodname] components.
+
+## Value
+
+Although the tier that secures $[prodname] components cannot be changed, you can create policies in adjacent tiers to change its behavior.
+
+## Concepts
+
+$[prodname] automatically creates the `calico-system` tier during installation with network policies that select traffic to and from Tigera components. These policies ensure that traffic required for $[prodname] operation is allowed, and that any unnecessary traffic involving Tigera components is denied. This tier prevents disruption of $[prodname] functionality in case of network policy misconfiguration impacting Tigera components, and denies unexpected traffic in case of defect or compromise.
+
+### Ownership and management of calico-system
+
+Tigera defines the `calico-system` tier and manages the policies within it. The Tigera Operator installs and monitors these policies, ensuring they always match the state defined by Tigera. Management by the Operator also ensures integrity for upgrades.
+
+:::note
+
+The `calico-system` tier and its policies should not be edited, and the tier should not be moved. However, if you inadvertently make changes they are automatically reverted by the Operator to ensure your cluster is always protected.
+
+:::
+
+## Tutorial
+
+### Change behavior of calico-system
+
+If you want to change the way traffic is enforced by the `calico-system` tier, you must create policy in an adjacent tier to meet your needs. For example, if a policy in the `calico-system` tier allows or denies traffic, and you want to change how that traffic is enforced, you can create a policy in a tier before `calico-system` that selects the same traffic to make your desired changes. Similarly, if a policy in the `calico-system` tier passes or does not select traffic that you want to enforce, you can create a policy in a tier after `calico-system` to select this traffic to meet the desired behavior.
+
+### Example: use preceding tier to tighten security
+
+Let's say a `calico-system` policy allows ingress traffic from a $[prodname] component that you do not use, and you want to tighten enforcement to not allow this traffic.
+
+Within a tier that comes before `calico-system`, you can create a policy that selects the same endpoint and contains ingress rules that deny traffic from that component and pass to `calico-system` for traffic from other components.
+
+```yaml
+ # calico-system.es-gateway-access allows ingress from deep packet inspection, a feature not utilized for the purpose of this example.
+ # This policy tightens the scope of allowed ingress to es-gateway without modifying the calico-system policy directly.
+
+apiVersion: projectcalico.org/v3
+kind: NetworkPolicy
+metadata:
+  name: preceding-tier.es-gateway-access
+  namespace: tigera-elasticsearch
+spec:
+   # Place in a tier prior to calico-system.
+  tier: preceding-tier
+
+   # Select the same endpoint as the original policy.
+  selector: k8s-app == 'tigera-secure-es-gateway'
+  ingress:
+     # Select the same component ingress.
+    - source:
+        selector: k8s-app == 'tigera-dpi'
+        namespaceSelector: name == 'tigera-dpi'
+       # Enact different behavior (originally: Allow)
+      action: Deny
+
+     # Defer to calico-system for other ingress/egress decisions for this endpoint.
+    - action: Pass
+```
+
+This example shows how you can change the impact of the `calico-system` tier on traffic without modifying the tier itself. This makes your changes more maintainable, and allows the calico-system tier to continue to receive updates as $[prodname] evolves without you needing to reconcile your changes each release.
+
+For help to manage or change the behavior of the `calico-system` tier, contact Tigera Support.
@@ -85,11 +85,11 @@ to the baseline admin network policy `Tier`. The `BaselineAdminNetworkPolicy` is
 
 System tiers are added during installation and are hidden by default.
 
-- **allow-tigera** tier contains policies to secure $[prodname] components and are controlled by the Tigera Operator. These policies should not be edited, and the tier should not be moved. Inadvertent changes are automatically reverted by the Operator to ensure your cluster is always protected.
+- **calico-system** tier contains policies to secure $[prodname] components and are controlled by the Tigera Operator. These policies should not be edited, and the tier should not be moved. Inadvertent changes are automatically reverted by the Operator to ensure your cluster is always protected.
 
 :::warning
 
-Although it is possible to change the behavior of the `allow-tigera` using adjacent tiers, it is not a trivial task. You can break critical cluster traffic and impact the operation of $[prodname]. To prevent loss of cluster services, see [Change allow-tigera tier behavior](allow-tigera.mdx), and contact Support for help.
+Although it is possible to change the behavior of the `calico-system` tier using adjacent tiers, it is not a trivial task. You can break critical cluster traffic and impact the operation of $[prodname]. To prevent loss of cluster services, see [Change calico-system tier behavior](calico-system.mdx), and contact Support for help.
 
 :::
 

@@ -13,7 +13,7 @@ a simple script to migrate your cluster to open-source Project Calico.
 The script migrates all applicable $[prodname] components to open-source Project Calico; this includes
 removal and cleanup of all $[prodname] components that have no equivalents in Project Calico.
 Because Project Calico does not have the tier resource, the script will exit if any policies
-exist in any tier except for the `default` or `allow-tigera` tiers.
+exist in any tier except for the `default` or `calico-system` tiers.
 To remove policies from tiers, you have these options:
 
 - Manually move policies out of tiers prior to running the script

@@ -323,7 +323,7 @@ The following policy metrics are a separate endpoint exposed by Felix that are u
 | Traffic per rule                 |                                                              |
 | -------------------------------- | ------------------------------------------------------------ |
 | Metric                           | <code>cnx_policy_rule_bytes</code><br /><code>cnx_policy_rule_packets</code> |
-| Example value                    | <code>cnx_policy_rule_bytes\{<strong>action</strong>="allow", <strong>endpoint</strong>="calico-metrics-port", <strong>instance</strong>="ip-10-0-1-20.ca-central-1.compute.internal", <strong>job</strong>="calico-node-metrics", <strong>namespace</strong>="calico-system", <strong>pod</strong>="calico-node-qzpkt", <strong>policy</strong>="es-kube-controller-access", <strong>rule_direction</strong>="egress", <strong>rule_index</strong>="1", <strong>service</strong>="calico-node-metrics", <strong>tier</strong>="allow-tigera", <strong>traffic_direction</strong>="inbound"\}</code> |
+| Example value                    | <code>cnx_policy_rule_bytes\{<strong>action</strong>="allow", <strong>endpoint</strong>="calico-metrics-port", <strong>instance</strong>="ip-10-0-1-20.ca-central-1.compute.internal", <strong>job</strong>="calico-node-metrics", <strong>namespace</strong>="calico-system", <strong>pod</strong>="calico-node-qzpkt", <strong>policy</strong>="es-kube-controller-access", <strong>rule_direction</strong>="egress", <strong>rule_index</strong>="1", <strong>service</strong>="calico-node-metrics", <strong>tier</strong>="calico-system", <strong>traffic_direction</strong>="inbound"\}</code> |
 | Explanation                      | Number of bytes or packets handled by $[prodname] network policy rules. |
 | Threshold value recommendation   | This metric should usually be non-zero (unless expected).  A zero value indicates the rule is not matching any packets, and could be surplus to requirements. |
 | Threshold breach symptoms        | N/A                                                          |
@@ -335,7 +335,7 @@ The following policy metrics are a separate endpoint exposed by Felix that are u
 | Connections per policy rule      |                                                              |
 | -------------------------------- | ------------------------------------------------------------ |
 | Metric                           | <code>cnx_policy_rule_connections</code>                                |
-| Example value                    | <code>cnx_policy_rule_connections\{<strong>endpoint</strong>="calico-metrics-port", <strong>instance</strong>="ip-10-0-1-20.ca-central-1.compute.internal", <strong>job</strong>="calico-node-metrics", <strong>namespace</strong>="calico-system", <strong>pod</strong>="calico-node-qzpkt", <strong>policy</strong>="es-kube-controller-access", <strong>rule_direction</strong>="egress", <strong>rule_index</strong>="0", <strong>service</strong>="calico-node-metrics", <strong>tier</strong>="allow-tigera", <strong>traffic_direction</strong>="outbound"\}</code> |
+| Example value                    | <code>cnx_policy_rule_connections\{<strong>endpoint</strong>="calico-metrics-port", <strong>instance</strong>="ip-10-0-1-20.ca-central-1.compute.internal", <strong>job</strong>="calico-node-metrics", <strong>namespace</strong>="calico-system", <strong>pod</strong>="calico-node-qzpkt", <strong>policy</strong>="es-kube-controller-access", <strong>rule_direction</strong>="egress", <strong>rule_index</strong>="0", <strong>service</strong>="calico-node-metrics", <strong>tier</strong>="calico-system", <strong>traffic_direction</strong>="outbound"\}</code> |
 | Explanation                      | Number connections handled by $[prodname] policy rules.              |
 | Threshold value recommendation   | This metric is similar to *Traffic per Rule* but this deals more with <strong>flow</strong> monitoring. This metric should usually be non-zero. A zero value indicates that the rule is not matching any packets and could be surplus to requirements. |
 | Threshold breach symptoms        | N/A                                                          |

@@ -8,7 +8,7 @@ $[prodname] supports the use of HTTP proxies for connections that leave the clus
 
 `HTTP_PROXY`, `HTTPS_PROXY`, and `NO_PROXY` environment variables can be set on $[prodname] containers by using a mutating admission webhook, or by configuration through the Installation CR if preferred. In the latter case, the Tigera Operator will be responsible for setting proxy environment variables on $[prodname] containers that egress out of the cluster.
 
-With either environment variable configuration method, the Tigera Operator will detect the proxy environment variables that are set on $[prodname] containers that egress out of the cluster and ensure that network policy in the allow-tigera tier allows these connections.
+With either environment variable configuration method, the Tigera Operator will detect the proxy environment variables that are set on $[prodname] containers that egress out of the cluster and ensure that network policy in the calico-system tier allows these connections.
 
 This page will outline how to configure an HTTP proxy using the Installation CR.
 

@@ -35,7 +35,7 @@ $[prodname] extends the standard `NetworkPolicy` object to provide advanced netw
 
 <DocCardLinkLayout>
   <DocCardLink docId='network-policy/policy-tiers/tiered-policy' />
-  <DocCardLink docId='network-policy/policy-tiers/allow-tigera' />
+  <DocCardLink docId='network-policy/policy-tiers/calico-system' />
   <DocCardLink docId='network-policy/policy-tiers/policy-tutorial-ui' />
   <DocCardLink docId='network-policy/policy-tiers/rbac-tiered-policies' />
 </DocCardLinkLayout>