From bfaa1061d0b7a997f48a8180521b397c8cf47bc5 Mon Sep 17 00:00:00 2001 From: Chris Tauchen Date: Wed, 19 Aug 2026 13:44:59 +0100 Subject: [PATCH] DOCS-3007: Rename allow-tigera tier to calico-system in Calico Cloud docs Calico Cloud 23 renames the allow-tigera tier to calico-system, but the Calico Cloud docs still described allow-tigera and the release notes never flagged the rename as a breaking change. The rename was written in May on docs/ce-3.23-ep2-oss-3.32-mirror-cc (b3703dbc) and never merged, while the Calico Enterprise half of the same work landed as 137a531e. This replays the Calico Cloud commit and extends it to the released tree: - Rename network-policy/policy-tiers/allow-tigera.mdx to calico-system.mdx in the Next tree and in calico-cloud_versioned_docs/version-23-2, and update the tiered-policy / network-policy index / configure-http-proxy / recommended-metrics / operations/disconnect cross-references and both sidebars. - Redirect the published allow-tigera URL to calico-system, for Calico Cloud and for the Calico Enterprise versions that already renamed the page. /calico-enterprise/latest and /calico-enterprise/3.24 have returned 404 since the Calico Enterprise rename shipped, and the /security/allow-tigera rule pointed straight into that 404. - Add the missed breaking change note to the release notes, under both 23.0.0 and 23.0.1. The note appears under both versions because 23.0.0 is delisted. Anyone following the documented upgrade path goes to 23.0.1, so a note filed only under 23.0.0 would never be read by the people it is written for. The note also covers policy names. A policy name is prefixed with the name of its tier, so renaming the tier renames every policy in it, which affects RBAC resourceNames, manifests, and any query keyed on a policy name. The original commit left the versioned trees alone, which was right before 23.0.0 shipped. Calico Cloud 23 now runs the renamed tier, so version-23-2 needs it too. Version 22-2 is not built, so it is left untouched. Also fix two artifacts of the original mechanical substitution, in Calico Cloud and in the already-merged Calico Enterprise copies so the two stay in sync: "an calico-system" should be "a calico-system", and "the calico-system using adjacent tiers" was missing the noun. Co-Authored-By: Claude Opus 5 (1M context) --- .../compliance/configure-http-proxy.mdx | 2 +- calico-cloud/network-policy/index.mdx | 2 +- .../policy-tiers/allow-tigera.mdx | 75 ------------------- .../policy-tiers/calico-system.mdx | 75 +++++++++++++++++++ .../policy-tiers/tiered-policy.mdx | 4 +- calico-cloud/operations/disconnect.mdx | 2 +- .../monitor/metrics/recommended-metrics.mdx | 4 +- .../compliance/configure-http-proxy.mdx | 2 +- .../version-23-2/network-policy/index.mdx | 2 +- .../policy-tiers/allow-tigera.mdx | 75 ------------------- .../policy-tiers/calico-system.mdx | 75 +++++++++++++++++++ .../policy-tiers/tiered-policy.mdx | 4 +- .../version-23-2/operations/disconnect.mdx | 2 +- .../monitor/metrics/recommended-metrics.mdx | 4 +- .../version-23-2/release-notes/index.mdx | 26 +++++++ .../version-23-2-sidebars.json | 2 +- .../policy-tiers/calico-system.mdx | 2 +- .../policy-tiers/tiered-policy.mdx | 2 +- .../policy-tiers/calico-system.mdx | 2 +- .../policy-tiers/tiered-policy.mdx | 2 +- .../policy-tiers/calico-system.mdx | 2 +- .../policy-tiers/tiered-policy.mdx | 2 +- sidebars-calico-cloud.js | 2 +- static/_redirects | 8 +- 24 files changed, 205 insertions(+), 173 deletions(-) delete mode 100644 calico-cloud/network-policy/policy-tiers/allow-tigera.mdx create mode 100644 calico-cloud/network-policy/policy-tiers/calico-system.mdx delete mode 100644 calico-cloud_versioned_docs/version-23-2/network-policy/policy-tiers/allow-tigera.mdx create mode 100644 calico-cloud_versioned_docs/version-23-2/network-policy/policy-tiers/calico-system.mdx diff --git a/calico-cloud/compliance/configure-http-proxy.mdx b/calico-cloud/compliance/configure-http-proxy.mdx index 40ac0750ad..59883c8b69 100644 --- a/calico-cloud/compliance/configure-http-proxy.mdx +++ b/calico-cloud/compliance/configure-http-proxy.mdx @@ -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. diff --git a/calico-cloud/network-policy/index.mdx b/calico-cloud/network-policy/index.mdx index 64679980e8..624ec3680f 100644 --- a/calico-cloud/network-policy/index.mdx +++ b/calico-cloud/network-policy/index.mdx @@ -35,7 +35,7 @@ $[prodname] extends the standard `NetworkPolicy` object to provide advanced netw - + diff --git a/calico-cloud/network-policy/policy-tiers/allow-tigera.mdx b/calico-cloud/network-policy/policy-tiers/allow-tigera.mdx deleted file mode 100644 index 24032898e5..0000000000 --- a/calico-cloud/network-policy/policy-tiers/allow-tigera.mdx +++ /dev/null @@ -1,75 +0,0 @@ ---- -description: Customize the behavior of the allow-tigera tier that Calico Cloud installs by default to keep its own components reachable. ---- - -# Change allow-tigera tier behavior - -:::warning -The `allow-tigera` 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 allow-tigera using adjacent tiers, you can inadvertently break critical cluster traffic. We highly recommend that you work with Support to implement changes around `allow-tigera` 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 `allow-tigera` 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 allow-tigera - -Tigera defines the `allow-tigera` 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 `allow-tigera` 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 allow-tigera - -If you want to change the way traffic is enforced by the `allow-tigera` tier, you must create policy in an adjacent tier to meet your needs. For example, if a policy in the `allow-tigera` tier allows or denies traffic, and you want to change how that traffic is enforced, you can create a policy in a tier before `allow-tigera` that selects the same traffic to make your desired changes. Similarly, if a policy in the `allow-tigera` tier passes or does not select traffic that you want to enforce, you can create a policy in a tier after `allow-tigera` to select this traffic to meet the desired behavior. - -### Example: use preceding tier to tighten security - -Let's say an `allow-tigera` 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 `allow-tigera`, you can create a policy that selects the same endpoint and contains ingress rules that deny traffic from that component and pass to `allow-tigera` for traffic from other components. - -```yaml - # allow-tigera.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 allow-tigera 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 allow-tigera. - 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 allow-tigera for other ingress/egress decisions for this endpoint. - - action: Pass -``` - -This example shows how you can change the impact of the `allow-tigera` tier on traffic without modifying the tier itself. This makes your changes more maintainable, and allows the allow-tigera 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 `allow-tigera` tier, contact Tigera Support. diff --git a/calico-cloud/network-policy/policy-tiers/calico-system.mdx b/calico-cloud/network-policy/policy-tiers/calico-system.mdx new file mode 100644 index 0000000000..330de170af --- /dev/null +++ b/calico-cloud/network-policy/policy-tiers/calico-system.mdx @@ -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. diff --git a/calico-cloud/network-policy/policy-tiers/tiered-policy.mdx b/calico-cloud/network-policy/policy-tiers/tiered-policy.mdx index b646020d45..7a77b79c9a 100644 --- a/calico-cloud/network-policy/policy-tiers/tiered-policy.mdx +++ b/calico-cloud/network-policy/policy-tiers/tiered-policy.mdx @@ -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. ::: diff --git a/calico-cloud/operations/disconnect.mdx b/calico-cloud/operations/disconnect.mdx index c63f8cdc8c..b5d58615d4 100644 --- a/calico-cloud/operations/disconnect.mdx +++ b/calico-cloud/operations/disconnect.mdx @@ -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 diff --git a/calico-cloud/operations/monitor/metrics/recommended-metrics.mdx b/calico-cloud/operations/monitor/metrics/recommended-metrics.mdx index 1ae1e97f70..e793fbf252 100644 --- a/calico-cloud/operations/monitor/metrics/recommended-metrics.mdx +++ b/calico-cloud/operations/monitor/metrics/recommended-metrics.mdx @@ -323,7 +323,7 @@ The following policy metrics are a separate endpoint exposed by Felix that are u | Traffic per rule | | | -------------------------------- | ------------------------------------------------------------ | | Metric | cnx_policy_rule_bytes
cnx_policy_rule_packets | -| Example value | cnx_policy_rule_bytes\{action="allow", endpoint="calico-metrics-port", instance="ip-10-0-1-20.ca-central-1.compute.internal", job="calico-node-metrics", namespace="calico-system", pod="calico-node-qzpkt", policy="es-kube-controller-access", rule_direction="egress", rule_index="1", service="calico-node-metrics", tier="allow-tigera", traffic_direction="inbound"\} | +| Example value | cnx_policy_rule_bytes\{action="allow", endpoint="calico-metrics-port", instance="ip-10-0-1-20.ca-central-1.compute.internal", job="calico-node-metrics", namespace="calico-system", pod="calico-node-qzpkt", policy="es-kube-controller-access", rule_direction="egress", rule_index="1", service="calico-node-metrics", tier="calico-system", traffic_direction="inbound"\} | | 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 | cnx_policy_rule_connections | -| Example value | cnx_policy_rule_connections\{endpoint="calico-metrics-port", instance="ip-10-0-1-20.ca-central-1.compute.internal", job="calico-node-metrics", namespace="calico-system", pod="calico-node-qzpkt", policy="es-kube-controller-access", rule_direction="egress", rule_index="0", service="calico-node-metrics", tier="allow-tigera", traffic_direction="outbound"\} | +| Example value | cnx_policy_rule_connections\{endpoint="calico-metrics-port", instance="ip-10-0-1-20.ca-central-1.compute.internal", job="calico-node-metrics", namespace="calico-system", pod="calico-node-qzpkt", policy="es-kube-controller-access", rule_direction="egress", rule_index="0", service="calico-node-metrics", tier="calico-system", traffic_direction="outbound"\} | | Explanation | Number connections handled by $[prodname] policy rules. | | Threshold value recommendation | This metric is similar to *Traffic per Rule* but this deals more with flow 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 | diff --git a/calico-cloud_versioned_docs/version-23-2/compliance/configure-http-proxy.mdx b/calico-cloud_versioned_docs/version-23-2/compliance/configure-http-proxy.mdx index 40ac0750ad..59883c8b69 100644 --- a/calico-cloud_versioned_docs/version-23-2/compliance/configure-http-proxy.mdx +++ b/calico-cloud_versioned_docs/version-23-2/compliance/configure-http-proxy.mdx @@ -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. diff --git a/calico-cloud_versioned_docs/version-23-2/network-policy/index.mdx b/calico-cloud_versioned_docs/version-23-2/network-policy/index.mdx index 64679980e8..624ec3680f 100644 --- a/calico-cloud_versioned_docs/version-23-2/network-policy/index.mdx +++ b/calico-cloud_versioned_docs/version-23-2/network-policy/index.mdx @@ -35,7 +35,7 @@ $[prodname] extends the standard `NetworkPolicy` object to provide advanced netw - + diff --git a/calico-cloud_versioned_docs/version-23-2/network-policy/policy-tiers/allow-tigera.mdx b/calico-cloud_versioned_docs/version-23-2/network-policy/policy-tiers/allow-tigera.mdx deleted file mode 100644 index 24032898e5..0000000000 --- a/calico-cloud_versioned_docs/version-23-2/network-policy/policy-tiers/allow-tigera.mdx +++ /dev/null @@ -1,75 +0,0 @@ ---- -description: Customize the behavior of the allow-tigera tier that Calico Cloud installs by default to keep its own components reachable. ---- - -# Change allow-tigera tier behavior - -:::warning -The `allow-tigera` 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 allow-tigera using adjacent tiers, you can inadvertently break critical cluster traffic. We highly recommend that you work with Support to implement changes around `allow-tigera` 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 `allow-tigera` 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 allow-tigera - -Tigera defines the `allow-tigera` 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 `allow-tigera` 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 allow-tigera - -If you want to change the way traffic is enforced by the `allow-tigera` tier, you must create policy in an adjacent tier to meet your needs. For example, if a policy in the `allow-tigera` tier allows or denies traffic, and you want to change how that traffic is enforced, you can create a policy in a tier before `allow-tigera` that selects the same traffic to make your desired changes. Similarly, if a policy in the `allow-tigera` tier passes or does not select traffic that you want to enforce, you can create a policy in a tier after `allow-tigera` to select this traffic to meet the desired behavior. - -### Example: use preceding tier to tighten security - -Let's say an `allow-tigera` 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 `allow-tigera`, you can create a policy that selects the same endpoint and contains ingress rules that deny traffic from that component and pass to `allow-tigera` for traffic from other components. - -```yaml - # allow-tigera.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 allow-tigera 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 allow-tigera. - 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 allow-tigera for other ingress/egress decisions for this endpoint. - - action: Pass -``` - -This example shows how you can change the impact of the `allow-tigera` tier on traffic without modifying the tier itself. This makes your changes more maintainable, and allows the allow-tigera 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 `allow-tigera` tier, contact Tigera Support. diff --git a/calico-cloud_versioned_docs/version-23-2/network-policy/policy-tiers/calico-system.mdx b/calico-cloud_versioned_docs/version-23-2/network-policy/policy-tiers/calico-system.mdx new file mode 100644 index 0000000000..330de170af --- /dev/null +++ b/calico-cloud_versioned_docs/version-23-2/network-policy/policy-tiers/calico-system.mdx @@ -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. diff --git a/calico-cloud_versioned_docs/version-23-2/network-policy/policy-tiers/tiered-policy.mdx b/calico-cloud_versioned_docs/version-23-2/network-policy/policy-tiers/tiered-policy.mdx index b646020d45..7a77b79c9a 100644 --- a/calico-cloud_versioned_docs/version-23-2/network-policy/policy-tiers/tiered-policy.mdx +++ b/calico-cloud_versioned_docs/version-23-2/network-policy/policy-tiers/tiered-policy.mdx @@ -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. ::: diff --git a/calico-cloud_versioned_docs/version-23-2/operations/disconnect.mdx b/calico-cloud_versioned_docs/version-23-2/operations/disconnect.mdx index c63f8cdc8c..b5d58615d4 100644 --- a/calico-cloud_versioned_docs/version-23-2/operations/disconnect.mdx +++ b/calico-cloud_versioned_docs/version-23-2/operations/disconnect.mdx @@ -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 diff --git a/calico-cloud_versioned_docs/version-23-2/operations/monitor/metrics/recommended-metrics.mdx b/calico-cloud_versioned_docs/version-23-2/operations/monitor/metrics/recommended-metrics.mdx index 1ae1e97f70..e793fbf252 100644 --- a/calico-cloud_versioned_docs/version-23-2/operations/monitor/metrics/recommended-metrics.mdx +++ b/calico-cloud_versioned_docs/version-23-2/operations/monitor/metrics/recommended-metrics.mdx @@ -323,7 +323,7 @@ The following policy metrics are a separate endpoint exposed by Felix that are u | Traffic per rule | | | -------------------------------- | ------------------------------------------------------------ | | Metric | cnx_policy_rule_bytes
cnx_policy_rule_packets | -| Example value | cnx_policy_rule_bytes\{action="allow", endpoint="calico-metrics-port", instance="ip-10-0-1-20.ca-central-1.compute.internal", job="calico-node-metrics", namespace="calico-system", pod="calico-node-qzpkt", policy="es-kube-controller-access", rule_direction="egress", rule_index="1", service="calico-node-metrics", tier="allow-tigera", traffic_direction="inbound"\} | +| Example value | cnx_policy_rule_bytes\{action="allow", endpoint="calico-metrics-port", instance="ip-10-0-1-20.ca-central-1.compute.internal", job="calico-node-metrics", namespace="calico-system", pod="calico-node-qzpkt", policy="es-kube-controller-access", rule_direction="egress", rule_index="1", service="calico-node-metrics", tier="calico-system", traffic_direction="inbound"\} | | 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 | cnx_policy_rule_connections | -| Example value | cnx_policy_rule_connections\{endpoint="calico-metrics-port", instance="ip-10-0-1-20.ca-central-1.compute.internal", job="calico-node-metrics", namespace="calico-system", pod="calico-node-qzpkt", policy="es-kube-controller-access", rule_direction="egress", rule_index="0", service="calico-node-metrics", tier="allow-tigera", traffic_direction="outbound"\} | +| Example value | cnx_policy_rule_connections\{endpoint="calico-metrics-port", instance="ip-10-0-1-20.ca-central-1.compute.internal", job="calico-node-metrics", namespace="calico-system", pod="calico-node-qzpkt", policy="es-kube-controller-access", rule_direction="egress", rule_index="0", service="calico-node-metrics", tier="calico-system", traffic_direction="outbound"\} | | Explanation | Number connections handled by $[prodname] policy rules. | | Threshold value recommendation | This metric is similar to *Traffic per Rule* but this deals more with flow 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 | diff --git a/calico-cloud_versioned_docs/version-23-2/release-notes/index.mdx b/calico-cloud_versioned_docs/version-23-2/release-notes/index.mdx index ce2fde281c..fe09ce41b9 100644 --- a/calico-cloud_versioned_docs/version-23-2/release-notes/index.mdx +++ b/calico-cloud_versioned_docs/version-23-2/release-notes/index.mdx @@ -16,6 +16,19 @@ import IconUser from '/img/icons/user-icon.svg'; Clusters upgrading from any earlier version of $[prodname] could hit it. The installer now corrects the cluster DNS policy while the upgrade runs, so $[prodname] components keep resolving names, Guardian connects without crash looping, and the upgrade finishes. +### Updating + +* ***Breaking change:*** The `allow-tigera` tier is renamed to `calico-system`. + The Tigera Operator moves its own policies into the new tier during the upgrade, but it does not update resources that you created. + Because a policy name is prefixed with the name of its tier, the policies in the tier are renamed with it, from `allow-tigera.` to `calico-system.`. + Before you upgrade, review anything that refers to the tier or to those policy names, including: + * Network policies that you added to the `allow-tigera` tier. + * RBAC rules that name `allow-tigera` or `allow-tigera.*` in `resourceNames`. + * Manifests, scripts, and automation that reference policies by their `allow-tigera.` names. + * Dashboards, alerts, and queries that filter on `tier="allow-tigera"` or on policy names. + + For more information, see [Change calico-system tier behavior](../network-policy/policy-tiers/calico-system.mdx). +

July 28, 2026 (version 23.0.0)

### New features and enhancements @@ -80,6 +93,19 @@ Upgrade to [version 23.0.1](#23.0.1) instead, which fixes the problem. If a cluster upgraded to version 23.0.0 and hit this problem, upgrading it to version 23.0.1 does not repair it. [Contact Support](../get-help/support.mdx) to return the cluster to a healthy state first, and then upgrade it. +### Updating + +* ***Breaking change:*** The `allow-tigera` tier is renamed to `calico-system`. + The Tigera Operator moves its own policies into the new tier during the upgrade, but it does not update resources that you created. + Because a policy name is prefixed with the name of its tier, the policies in the tier are renamed with it, from `allow-tigera.` to `calico-system.`. + Before you upgrade, review anything that refers to the tier or to those policy names, including: + * Network policies that you added to the `allow-tigera` tier. + * RBAC rules that name `allow-tigera` or `allow-tigera.*` in `resourceNames`. + * Manifests, scripts, and automation that reference policies by their `allow-tigera.` names. + * Dashboards, alerts, and queries that filter on `tier="allow-tigera"` or on policy names. + + For more information, see [Change calico-system tier behavior](../network-policy/policy-tiers/calico-system.mdx). +

June 22, 2026 (version 22.5.0)

### New features and enhancements diff --git a/calico-cloud_versioned_sidebars/version-23-2-sidebars.json b/calico-cloud_versioned_sidebars/version-23-2-sidebars.json index 3c6ab7f058..45b73b8bca 100644 --- a/calico-cloud_versioned_sidebars/version-23-2-sidebars.json +++ b/calico-cloud_versioned_sidebars/version-23-2-sidebars.json @@ -169,7 +169,7 @@ "items": [ "network-policy/policy-tiers/tiered-policy", "network-policy/policy-tiers/policy-tutorial-ui", - "network-policy/policy-tiers/allow-tigera", + "network-policy/policy-tiers/calico-system", "network-policy/policy-tiers/rbac-tiered-policies" ] }, diff --git a/calico-enterprise/network-policy/policy-tiers/calico-system.mdx b/calico-enterprise/network-policy/policy-tiers/calico-system.mdx index 8520c844d7..def400aacf 100644 --- a/calico-enterprise/network-policy/policy-tiers/calico-system.mdx +++ b/calico-enterprise/network-policy/policy-tiers/calico-system.mdx @@ -39,7 +39,7 @@ If you want to change the way traffic is enforced by the `calico-system` tier, y ### Example: use preceding tier to tighten security -Let's say an `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. +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. diff --git a/calico-enterprise/network-policy/policy-tiers/tiered-policy.mdx b/calico-enterprise/network-policy/policy-tiers/tiered-policy.mdx index bcdff8c073..addbdedb18 100644 --- a/calico-enterprise/network-policy/policy-tiers/tiered-policy.mdx +++ b/calico-enterprise/network-policy/policy-tiers/tiered-policy.mdx @@ -150,7 +150,7 @@ System tiers are added during installation and are hidden by default. :::warning -Although it is possible to change the behavior of the `calico-system` 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. +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. ::: diff --git a/calico-enterprise_versioned_docs/version-3.23-2/network-policy/policy-tiers/calico-system.mdx b/calico-enterprise_versioned_docs/version-3.23-2/network-policy/policy-tiers/calico-system.mdx index 8520c844d7..def400aacf 100644 --- a/calico-enterprise_versioned_docs/version-3.23-2/network-policy/policy-tiers/calico-system.mdx +++ b/calico-enterprise_versioned_docs/version-3.23-2/network-policy/policy-tiers/calico-system.mdx @@ -39,7 +39,7 @@ If you want to change the way traffic is enforced by the `calico-system` tier, y ### Example: use preceding tier to tighten security -Let's say an `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. +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. diff --git a/calico-enterprise_versioned_docs/version-3.23-2/network-policy/policy-tiers/tiered-policy.mdx b/calico-enterprise_versioned_docs/version-3.23-2/network-policy/policy-tiers/tiered-policy.mdx index bcdff8c073..addbdedb18 100644 --- a/calico-enterprise_versioned_docs/version-3.23-2/network-policy/policy-tiers/tiered-policy.mdx +++ b/calico-enterprise_versioned_docs/version-3.23-2/network-policy/policy-tiers/tiered-policy.mdx @@ -150,7 +150,7 @@ System tiers are added during installation and are hidden by default. :::warning -Although it is possible to change the behavior of the `calico-system` 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. +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. ::: diff --git a/calico-enterprise_versioned_docs/version-3.24-1/network-policy/policy-tiers/calico-system.mdx b/calico-enterprise_versioned_docs/version-3.24-1/network-policy/policy-tiers/calico-system.mdx index 8520c844d7..def400aacf 100644 --- a/calico-enterprise_versioned_docs/version-3.24-1/network-policy/policy-tiers/calico-system.mdx +++ b/calico-enterprise_versioned_docs/version-3.24-1/network-policy/policy-tiers/calico-system.mdx @@ -39,7 +39,7 @@ If you want to change the way traffic is enforced by the `calico-system` tier, y ### Example: use preceding tier to tighten security -Let's say an `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. +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. diff --git a/calico-enterprise_versioned_docs/version-3.24-1/network-policy/policy-tiers/tiered-policy.mdx b/calico-enterprise_versioned_docs/version-3.24-1/network-policy/policy-tiers/tiered-policy.mdx index bcdff8c073..addbdedb18 100644 --- a/calico-enterprise_versioned_docs/version-3.24-1/network-policy/policy-tiers/tiered-policy.mdx +++ b/calico-enterprise_versioned_docs/version-3.24-1/network-policy/policy-tiers/tiered-policy.mdx @@ -150,7 +150,7 @@ System tiers are added during installation and are hidden by default. :::warning -Although it is possible to change the behavior of the `calico-system` 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. +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. ::: diff --git a/sidebars-calico-cloud.js b/sidebars-calico-cloud.js index 514605887b..eecf9d7a93 100644 --- a/sidebars-calico-cloud.js +++ b/sidebars-calico-cloud.js @@ -128,7 +128,7 @@ module.exports = { items: [ 'network-policy/policy-tiers/tiered-policy', 'network-policy/policy-tiers/policy-tutorial-ui', - 'network-policy/policy-tiers/allow-tigera', + 'network-policy/policy-tiers/calico-system', 'network-policy/policy-tiers/rbac-tiered-policies', ], }, diff --git a/static/_redirects b/static/_redirects index f8618d2960..5be9eda639 100644 --- a/static/_redirects +++ b/static/_redirects @@ -304,7 +304,7 @@ /reference/other-install-methods/ https://docs.tigera.io/calico-enterprise/latest/getting-started 301 /reference/typha/* https://docs.tigera.io/calico-enterprise/latest/reference/component-resources/typha/:splat 301 /security/advanced-policy https://docs.tigera.io/calico-enterprise/latest/network-policy 301 -/security/allow-tigera https://docs.tigera.io/calico-enterprise/latest/network-policy/policy-tiers/allow-tigera 301 +/security/allow-tigera https://docs.tigera.io/calico-enterprise/latest/network-policy/policy-tiers/calico-system 301 /security/aws-integration/* https://docs.tigera.io/calico-enterprise/latest/network-policy/policy-firewalls/aws-integration/:splat 301 /security/calico-network-policy https://docs.tigera.io/calico-enterprise/latest/network-policy/beginners/calico-network-policy 301 /security/comms/* https://docs.tigera.io/calico-enterprise/latest/operations/comms/:splat 301 @@ -446,3 +446,9 @@ /calico-enterprise/3.24/compliance/compliance-reports-cis /calico-enterprise/3.24/release-notes 301 /calico-enterprise/3.24/reference/resources/compliance-reports/* /calico-enterprise/3.24/reference/resources/ 301 /calico-enterprise/3.24/reference/resources/globalreport /calico-enterprise/3.24/reference/resources/ 301 + +# allow-tigera tier renamed to calico-system, in Calico Cloud 23 and Calico Enterprise 3.23 +/calico-cloud/network-policy/policy-tiers/allow-tigera /calico-cloud/network-policy/policy-tiers/calico-system 301 +/calico-cloud/next/network-policy/policy-tiers/allow-tigera /calico-cloud/next/network-policy/policy-tiers/calico-system 301 +/calico-enterprise/latest/network-policy/policy-tiers/allow-tigera /calico-enterprise/latest/network-policy/policy-tiers/calico-system 301 +/calico-enterprise/3.24/network-policy/policy-tiers/allow-tigera /calico-enterprise/3.24/network-policy/policy-tiers/calico-system 301