DOCS-550: Updates to kubernetes-default-deny.mdx

calico-cloud/network-policy/beginners/kubernetes-default-deny.mdx

@@ -2,15 +2,22 @@
 description: Create a default deny network policy so pods that are missing policy are not allowed traffic until appropriate network policy is defined.
 ---
 
-# Enable default deny for Kubernetes pods
+# Enable a default deny policy for Kubernetes pods
 
 ## Big picture
 
 Enable a default deny policy for Kubernetes pods using Kubernetes or {{prodname}} network policy.
 
 ## Value
 
-A **default deny** network policy provides an enhanced security posture -- so pods without policy (or incorrect policy) are not allowed traffic until appropriate network policy is defined.
+A **default deny** network policy provides an enhanced security posture so pods without policy (or incorrect policy) are not allowed traffic until appropriate network policy is defined.
+
+## Features
+
+This how-to guide uses the following {{prodname}} features:
+
+- **NetworkPolicy**
+- **GlobalNetworkPolicy**
 
 ## Concepts
 
@@ -26,53 +33,70 @@ For compatibility with Kubernetes, **{{prodname}} network policy** enforcement f
 
 For other endpoint types (VMs, host interfaces), the default behavior is to deny traffic. Only traffic specifically allowed by network policy is allowed, even if no network policies apply to the endpoint.
 
-### Best practice: implicit default deny policy
-
-We recommend creating an implicit default deny policy for your Kubernetes pods, regardless of whether you use {{prodname}} or Kubernetes network policy. This ensures that unwanted traffic is denied by default. Note that implicit default deny policy always occurs last; if any other policy allows the traffic, then the deny does not come into effect. The deny is executed only after all other policies are evaluated.
-
 ## How to
 
-Although you can use any of the following policies to create default deny policy for Kubernetes pods, we recommend using the {{prodname}} global network policy. A {{prodname}} global network policy applies to all workloads (VMs and containers) in all namespaces, as well as hosts (computers that run the hypervisor for VMs, or container runtime for containers). Using a {{prodname}} global network policy supports a conservative security stance for protecting resources.
-
-- [Enable default deny {{prodname}} global network policy, non-namespaced](#enable-default-deny-{{prodnamedash}}-global-network-policy-non-namespaced)
-- [Enable default deny {{prodname}} network policy, namespaced](#enable-default-deny-{{prodnamedash}}-network-policy-namespaced)
-- [Enable default deny Kubernetes policy, namespaced](#enable-default-deny-kubernetes-policy-namespaced)
-
-### Enable default deny {{prodname}} global network policy, non-namespaced
+- [Create a default deny network policy](#crate-a-default-deny-network-policy)
+- [Create a global default deny network policy](#create-a-global-default-deny-network-policy)
 
-You can use a {{prodname}} global network policy to enable a default deny across your whole cluster. The following example applies to all workloads (VMs and containers) in all namespaces, as well as hosts (computers that run the hypervisor for VMs, or container runtime for containers).
+### Create a default deny network policy
 
-:::note
+Immediately after installation, a best practice is to create a namespaced default deny network policy to secure pods without policy or incorrect policy until you can put policies in place and test them.
 
-Before applying the following please continue reading the rest of this section to find out why this might not be the best policy to apply to your cluster.
-
-:::
+In the following example, we create a {{prodname}} default deny **NetworkPolicy** for all workloads in the namespace, **engineering**.
 
 ```yaml
 apiVersion: projectcalico.org/v3
-kind: GlobalNetworkPolicy
+kind: NetworkPolicy
 metadata:
   name: default-deny
+  namespace: engineering
 spec:
   selector: all()
   types:
     - Ingress
     - Egress
 ```
 
-The above policy applies to all pods and host endpoints, including Kubernetes control plane and {{prodname}} control plane nodes and pods.
-Such policy has the potential to break your cluster if you do not already have the correct "Allow" policies and {{prodname}} [failsafe ports](../../reference/component-resources/node/felix/configuration.mdx) in place to ensure control plane traffic does not get blocked.
+Here's an equivalent default deny **Kubernetes network policy** for all pods in the namespace, **engineering**
+
+```yaml
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: default-deny
+  namespace: engineering
+spec:
+  podSelector: {}
+  policyTypes:
+    - Ingress
+    - Egress
+```
+
+### Create a global default deny policy
+
+A default deny policy ensures that unwanted traffic (ingress and egress) is denied by default without you having to remember default deny/allow behavior of Kubernetes and {{prodname}} policies. This policy can also help mitigate risks of lateral malicious attacks.
 
-As an alternative best practice we recommend to use the following example, which applies a default-deny behaviour to all non-system pods. The policy
-also allows access kube-dns, which simplifies per pod policies since you don't need to duplicate the DNS rules in every policy.
+#### Best practice #1: Allow, stage, then deny
+
+We recommend that you create a global default deny policy after you complete writing policy for the traffic that you want to allow. The following steps summarizes the best practice to test and lock down the cluster to block unwanted traffic:
+
+1. Create a global default deny policy and test it in a staging environment. (The policy will show all the traffic that would be blocked if it were converted into a deny.)
+1. Create network policies to individually allow the traffic shown as blocked in step 1 until no connections are denied.
+1. Enforce the global default deny policy.
+
+#### Best practice #2: Keep the scope to non-system pods
+
+A global default deny policy applies to the entire cluster including all workloads in all namespaces, hosts (computers that run the hypervisor for VMs or container runtime for containers), including Kubernetes control plane and {{prodname}} control plane nodes and pods.
+
+For this reason, the best practice is to create a global default deny policy for **non-system pods** as shown in the following example.
 
 ```yaml
 apiVersion: projectcalico.org/v3
 kind: GlobalNetworkPolicy
 metadata:
   name: deny-app-policy
 spec:
-  namespaceSelector: has(projectcalico.org/name) && projectcalico.org/name not in {"kube-system", "calico-system", "calico-apiserver"}
+  namespaceSelector: has(projectcalico.org/name) && projectcalico.org/name not in {"kube-system", "calico-system", "tigera-system"}
   types:
   - Ingress
   - Egress
@@ -92,43 +116,32 @@ spec:
       - 53
 ```
 
-It is important to note the above policy deliberately excludes the `kube-system`, `calico-system` and `calico-apiserver` namespaces by using a negative `namespaceSelector` to avoid impacting any control plane components. To secure the control plane you can write specific policies for each control plane component, though you should do so with care, ideally at cluster creation time, since getting these wrong can leave your cluster in a broken state. We recommend you always make sure you have the correct {{prodname}} [failsafe ports](../../reference/component-resources/node/felix/configuration.mdx) in place before you start trying to create policies for the control plane.
+Note the following:
+
+- Even though we call this policy "global default deny", the above policy is not explicitly denying traffic. By selecting the traffic with the `namespaceSelector` but not specifying an allow, the traffic is denied after all other policy is evaluated. This design also makes it unnecessary to ensure any specific order (priority) for the default-deny policy.
+- Allowing access to `kube-dns` simplifies per-pod policies because you don't need to duplicate the DNS rules in every policy
+- The policy deliberately excludes the `kube-system`, `calico-system`, and `tigera-system` namespaces by using a negative `namespaceSelector` to avoid impacting any control plane components
+
+In a staging environment, verify that the policy does not block any necessary traffic before enforcing it.
 
-### Enable default deny {{prodname}} network policy, namespaced
+### Don't try this!
 
-In the following example, we enable a default deny **NetworkPolicy** for all workloads in the namespace, **engineering**.
+The following policy works and looks fine on the surface. But as described in Best practices #2, the policy is too broad in scope and could break your cluster. Therefore, we do not recommend adding this type of policy, even if you have verified allowed traffic in your staging environment.
 
 ```yaml
 apiVersion: projectcalico.org/v3
-kind: NetworkPolicy
+kind: GlobalNetworkPolicy
 metadata:
-  name: default-deny
-  namespace: engineering
+  name: default.default-deny
 spec:
+  tier: default
   selector: all()
   types:
     - Ingress
     - Egress
 ```
 
-### Enable default deny Kubernetes policy, namespaced
-
-In the following example, we enable a default deny **Kubernetes network policy** for all pods in the namespace, **engineering**.
-
-```yaml
-apiVersion: networking.k8s.io/v1
-kind: NetworkPolicy
-metadata:
-  name: default-deny
-  namespace: engineering
-spec:
-  podSelector: {}
-  policyTypes:
-    - Ingress
-    - Egress
-```
-
 ## Additional resources
 
 - [Network policy](../../reference/resources/networkpolicy.mdx)
-- [Global network policy](../../reference/resources/globalnetworkpolicy.mdx)
+- [Global network policy](../../reference/resources/globalnetworkpolicy.mdx)

calico-cloud_versioned_docs/version-19-1/network-policy/beginners/kubernetes-default-deny.mdx

@@ -2,15 +2,22 @@
 description: Create a default deny network policy so pods that are missing policy are not allowed traffic until appropriate network policy is defined.
 ---
 
-# Enable default deny for Kubernetes pods
+# Enable a default deny policy for Kubernetes pods
 
 ## Big picture
 
 Enable a default deny policy for Kubernetes pods using Kubernetes or {{prodname}} network policy.
 
 ## Value
 
-A **default deny** network policy provides an enhanced security posture -- so pods without policy (or incorrect policy) are not allowed traffic until appropriate network policy is defined.
+A **default deny** network policy provides an enhanced security posture so pods without policy (or incorrect policy) are not allowed traffic until appropriate network policy is defined.
+
+## Features
+
+This how-to guide uses the following {{prodname}} features:
+
+- **NetworkPolicy**
+- **GlobalNetworkPolicy**
 
 ## Concepts
 
@@ -26,53 +33,70 @@ For compatibility with Kubernetes, **{{prodname}} network policy** enforcement f
 
 For other endpoint types (VMs, host interfaces), the default behavior is to deny traffic. Only traffic specifically allowed by network policy is allowed, even if no network policies apply to the endpoint.
 
-### Best practice: implicit default deny policy
-
-We recommend creating an implicit default deny policy for your Kubernetes pods, regardless of whether you use {{prodname}} or Kubernetes network policy. This ensures that unwanted traffic is denied by default. Note that implicit default deny policy always occurs last; if any other policy allows the traffic, then the deny does not come into effect. The deny is executed only after all other policies are evaluated.
-
 ## How to
 
-Although you can use any of the following policies to create default deny policy for Kubernetes pods, we recommend using the {{prodname}} global network policy. A {{prodname}} global network policy applies to all workloads (VMs and containers) in all namespaces, as well as hosts (computers that run the hypervisor for VMs, or container runtime for containers). Using a {{prodname}} global network policy supports a conservative security stance for protecting resources.
-
-- [Enable default deny {{prodname}} global network policy, non-namespaced](#enable-default-deny-{{prodnamedash}}-global-network-policy-non-namespaced)
-- [Enable default deny {{prodname}} network policy, namespaced](#enable-default-deny-{{prodnamedash}}-network-policy-namespaced)
-- [Enable default deny Kubernetes policy, namespaced](#enable-default-deny-kubernetes-policy-namespaced)
-
-### Enable default deny {{prodname}} global network policy, non-namespaced
+- [Create a default deny network policy](#crate-a-default-deny-network-policy)
+- [Create a global default deny network policy](#create-a-global-default-deny-network-policy)
 
-You can use a {{prodname}} global network policy to enable a default deny across your whole cluster. The following example applies to all workloads (VMs and containers) in all namespaces, as well as hosts (computers that run the hypervisor for VMs, or container runtime for containers).
+### Create a default deny network policy
 
-:::note
+Immediately after installation, a best practice is to create a namespaced default deny network policy to secure pods without policy or incorrect policy until you can put policies in place and test them.
 
-Before applying the following please continue reading the rest of this section to find out why this might not be the best policy to apply to your cluster.
-
-:::
+In the following example, we create a {{prodname}} default deny **NetworkPolicy** for all workloads in the namespace, **engineering**.
 
 ```yaml
 apiVersion: projectcalico.org/v3
-kind: GlobalNetworkPolicy
+kind: NetworkPolicy
 metadata:
   name: default-deny
+  namespace: engineering
 spec:
   selector: all()
   types:
     - Ingress
     - Egress
 ```
 
-The above policy applies to all pods and host endpoints, including Kubernetes control plane and {{prodname}} control plane nodes and pods.
-Such policy has the potential to break your cluster if you do not already have the correct "Allow" policies and {{prodname}} [failsafe ports](../../reference/component-resources/node/felix/configuration.mdx) in place to ensure control plane traffic does not get blocked.
+Here's an equivalent default deny **Kubernetes network policy** for all pods in the namespace, **engineering**
+
+```yaml
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: default-deny
+  namespace: engineering
+spec:
+  podSelector: {}
+  policyTypes:
+    - Ingress
+    - Egress
+```
+
+### Create a global default deny policy
+
+A default deny policy ensures that unwanted traffic (ingress and egress) is denied by default without you having to remember default deny/allow behavior of Kubernetes and {{prodname}} policies. This policy can also help mitigate risks of lateral malicious attacks.
 
-As an alternative best practice we recommend to use the following example, which applies a default-deny behaviour to all non-system pods. The policy
-also allows access kube-dns, which simplifies per pod policies since you don't need to duplicate the DNS rules in every policy.
+#### Best practice #1: Allow, stage, then deny
+
+We recommend that you create a global default deny policy after you complete writing policy for the traffic that you want to allow. The following steps summarizes the best practice to test and lock down the cluster to block unwanted traffic:
+
+1. Create a global default deny policy and test it in a staging environment. (The policy will show all the traffic that would be blocked if it were converted into a deny.)
+1. Create network policies to individually allow the traffic shown as blocked in step 1 until no connections are denied.
+1. Enforce the global default deny policy.
+
+#### Best practice #2: Keep the scope to non-system pods
+
+A global default deny policy applies to the entire cluster including all workloads in all namespaces, hosts (computers that run the hypervisor for VMs or container runtime for containers), including Kubernetes control plane and {{prodname}} control plane nodes and pods.
+
+For this reason, the best practice is to create a global default deny policy for **non-system pods** as shown in the following example.
 
 ```yaml
 apiVersion: projectcalico.org/v3
 kind: GlobalNetworkPolicy
 metadata:
   name: deny-app-policy
 spec:
-  namespaceSelector: has(projectcalico.org/name) && projectcalico.org/name not in {"kube-system", "calico-system", "calico-apiserver"}
+  namespaceSelector: has(projectcalico.org/name) && projectcalico.org/name not in {"kube-system", "calico-system", "tigera-system"}
   types:
   - Ingress
   - Egress
@@ -92,43 +116,32 @@ spec:
       - 53
 ```
 
-It is important to note the above policy deliberately excludes the `kube-system`, `calico-system` and `calico-apiserver` namespaces by using a negative `namespaceSelector` to avoid impacting any control plane components. To secure the control plane you can write specific policies for each control plane component, though you should do so with care, ideally at cluster creation time, since getting these wrong can leave your cluster in a broken state. We recommend you always make sure you have the correct {{prodname}} [failsafe ports](../../reference/component-resources/node/felix/configuration.mdx) in place before you start trying to create policies for the control plane.
+Note the following:
+
+- Even though we call this policy "global default deny", the above policy is not explicitly denying traffic. By selecting the traffic with the `namespaceSelector` but not specifying an allow, the traffic is denied after all other policy is evaluated. This design also makes it unnecessary to ensure any specific order (priority) for the default-deny policy.
+- Allowing access to `kube-dns` simplifies per-pod policies because you don't need to duplicate the DNS rules in every policy
+- The policy deliberately excludes the `kube-system`, `calico-system`, and `tigera-system` namespaces by using a negative `namespaceSelector` to avoid impacting any control plane components
+
+In a staging environment, verify that the policy does not block any necessary traffic before enforcing it.
 
-### Enable default deny {{prodname}} network policy, namespaced
+### Don't try this!
 
-In the following example, we enable a default deny **NetworkPolicy** for all workloads in the namespace, **engineering**.
+The following policy works and looks fine on the surface. But as described in Best practices #2, the policy is too broad in scope and could break your cluster. Therefore, we do not recommend adding this type of policy, even if you have verified allowed traffic in your staging environment.
 
 ```yaml
 apiVersion: projectcalico.org/v3
-kind: NetworkPolicy
+kind: GlobalNetworkPolicy
 metadata:
-  name: default-deny
-  namespace: engineering
+  name: default.default-deny
 spec:
+  tier: default
   selector: all()
   types:
     - Ingress
     - Egress
 ```
 
-### Enable default deny Kubernetes policy, namespaced
-
-In the following example, we enable a default deny **Kubernetes network policy** for all pods in the namespace, **engineering**.
-
-```yaml
-apiVersion: networking.k8s.io/v1
-kind: NetworkPolicy
-metadata:
-  name: default-deny
-  namespace: engineering
-spec:
-  podSelector: {}
-  policyTypes:
-    - Ingress
-    - Egress
-```
-
 ## Additional resources
 
 - [Network policy](../../reference/resources/networkpolicy.mdx)
-- [Global network policy](../../reference/resources/globalnetworkpolicy.mdx)
+- [Global network policy](../../reference/resources/globalnetworkpolicy.mdx)