Fixes and suggestions

calico/network-policy/policy-rules/log-rules.mdx

@@ -4,11 +4,11 @@ description: Debug your policies with Log rules.
 # Use Log action to debug policies
 
 ## Big picture
-Calico Log rules are powerful resources that can be implemented in an environment to log the matching traffic and allowing you to determine how your policies are behaving.
+$[prodname] Log rules are powerful resources that can be implemented in an environment to log the matching traffic and allowing you to determine how your policies are behaving.
 
 
 ## Value
-Calico has a unique `Log` action that provides traffic observability and logging which is missing in the standard Kubernetes Network Policy. This unique action can be used by security teams and admins to troubleshoot their policies and make sure that their cluster security posture is doing what its expected to do.
+$[prodname] has a unique `Log` action that provides traffic observability and logging which is missing in the standard Kubernetes Network Policy. This unique action can be used by security teams and admins to troubleshoot their policies and make sure that their cluster security posture is doing what its expected to do.
 
 
 ## Requirements
@@ -18,8 +18,8 @@ import TabItem from '@theme/TabItem';
 
 <Tabs groupId='log-rules'>
 <TabItem label="eBPF" value="eBPF">
-    - Calico 3.29+
-    - Linux Kernel 5.16+
+    - $[prodname] 3.29 and above
+    - Linux Kernel 5.16 and above
 
     eBPF policy logs depend on advanced kernel features introduced in Linux Kernel 5.16 and later. If you encounter a scenario where logs only display the traffic verdict (e.g., ALLOWED or DENIED) without detailed information about IP packets, it indicates that your system is running on an older kernel version lacking the necessary capabilities.
 
@@ -30,16 +30,17 @@ import TabItem from '@theme/TabItem';
 
     :::note
 
-    Keep in mind that `logs` action doesn't output anything if you are running a `Kind` cluster given that `rsyslogd` is not installed in `Kind` created clusters. 
+    In a containerized Kubernetes environment, such as Kind, sending `syslog` messages to the Kernel is not permitted. This limitation is by the design to prevent a noisy neighbor scenario since both containers and the host share the same Kernel.
 
     :::
 
-    iptables/ipvs logs are sent to the syslog, this requires your host installation to have the rsyslog package.
+    Iptable logs are sent to the syslog.
+
 </TabItem>
 </Tabs>
 
 ## Concepts
-A Calico policy with the action `Log` serves as a diagnostic tool that captures and logs network traffic information based on the rules and criteria specified. By leveraging the `Log` action, administrators gain insight into how traffic is evaluated by their policies, enabling them to debug, refine, and validate their network security posture.
+A $[prodname] policy with the action `Log` serves as a diagnostic tool that captures and logs network traffic information based on the rules and criteria specified. By leveraging the `Log` action, administrators gain insight into how traffic is evaluated by their policies, enabling them to debug, refine, and validate their network security posture.
 
 
 :::caution
@@ -60,14 +61,13 @@ In the iptables dataplane, the Log action logs the traffic at the point of evalu
 
 <Tabs groupId='log-rules'>
 <TabItem label="eBPF" value="eBPF">
+
 eBPF policy logs are sent to the trace pipe and can be viewed by using the following command:
 ```bash
 kubectl exec -n calico-system -it ds/calico-node -- bpftool prog tracelog
 ```
 
-An eBPF log starts with the pid name and ID 
-
-Following with 
+The precise format of the eBPF trace logs depends on your kernel and sysctl settings.  However, a typical log format includes the active process and PID (`curl-5288` in the example), the CPU number (`[000]`), various flags, a timestamp and then the log message.  Note that, for incoming packets, the reported process may not be the process that eventually receives the packet; it is typically a kernel IRQ process, or another process that happened to trigger a poll of the network interface.
 
 Example of eBPF logs:
 ```bash
@@ -80,11 +80,14 @@ curl-5288    [000] ..s2.  3055.982021: bpf_trace_printk: cali527b0801ecb-E: poli
 
 </TabItem>
 <TabItem label="iptables/ipvs" value="iptables">
-Policy logs are sent to the syslog, this requires your host installation to have the rsyslog package.
+The $[prodname] `Log` action generates a `LOG` rule in iptables. The location and method for accessing these logs can vary depending on your Linux distribution. By default, $[prodname] prefixes these log entries with `calico-packet`, making it easier to filter them.
 
-Use the following command to access your policy logs
+The following commands are some of the usual places that you can search for the policy log outputs:
 ```bash
-journalctl | egrep calico-packet
+journalctl
+/var/log/syslog
+/var/log/kern.log
+/var/log/kern.log
 ```
 
 Example of iptable logs:
@@ -107,21 +110,21 @@ For a complete and efficient observability, consider exploring the use of [Flow
 Using log rules may not be the most effective way to achieve comprehensive observability. While network observability can be achieved by utilizing log actions, this approach may introduce performance overhead in busy clusters.
 ::: 
 
-To effectively utilize Log actions, place them at the bottom of your policy tiers to capture any traffic not explicitly matched by higher-priority policies. This approach helps identify unhandled traffic and reveals gaps in your policy configuration. By analyzing the logged traffic, you can gain insights into its characteristics, such as source, destination, and protocol. Use this information to create targeted policies that address the specific traffic patterns. Once implemented, verify the changes by checking if the corresponding traffic no longer appears in the logs, indicating that your new policies are successfully handling it.
+To effectively utilize Log actions, place them at the bottom of your policy tiers to capture any traffic not explicitly matched by lower-priority policies. This approach helps identify unhandled traffic and reveals gaps in your policy configuration. By analyzing the logged traffic, you can gain insights into its characteristics, such as source, destination, and protocol. Use this information to create targeted policies that address the specific traffic patterns. Once implemented, verify the changes by checking if the corresponding traffic no longer appears in the logs, indicating that your new policies are successfully handling it and remove your Log policies/rules since they can put a huge overhead on your cluster.
 
 
 To make the most of log actions, follow these guidelines:  
 
-    1. **Order Matters:** Assign log actions a high `order` value to ensure they are evaluated after all higher-priority rules.  
-    1. **Explicit Allow Rule:** Always pair a log action with an explicit allow rule immediately after it. Otherwise, traffic may be denied due to the tier's implicit deny action.  
-    1. **Comprehensive Protection:** Ensure both namespaced and non-namespaced resources are covered by enabling `hostEndpoint` for logging and protecting all traffic in your cluster.  
+    1. **Order Matters:** Assign log actions a high `order` value to ensure they are evaluated after all lower-priority policies.  
+    1. **Explicit Allow Rule:** Always pair a log action with an explicit `Allow` rule immediately after it. Otherwise, traffic may be denied due to the tier's implicit default action.  
+    1. **Comprehensive Protection:** Ensure both namespaced and non-namespaced resources are covered by enabling `hostEndpoint` for protecting your host in addition to Pods and workloads.  
 
 By strategically placing log actions at the bottom of your policy tiers, you can capture unhandled traffic and identify gaps in your policy configuration. Analyze the logged traffic to gather insights about source, destination, and protocol, and use this data to create targeted policies. Once implemented, validate by checking if the corresponding traffic is no longer logged, indicating the new policies are effective.  
 
 
 ### Logging an unprotected cluster 
 
-Kubernetes' default behavior permits all traffic, making early security implementation essential. Calico’s `GlobalNetworkPolicy` with the `Log` action is a powerful tool for monitoring cluster traffic. It allows you to observe, analyze, and secure traffic flows. A single `GlobalNetworkPolicy` can be used to log all traffic across the cluster, providing comprehensive insights for your security strategy.  
+Kubernetes' default behavior permits all traffic, making early security implementation essential. $[prodname]'s `GlobalNetworkPolicy` with the `Log` action is a powerful tool for monitoring cluster traffic. It allows you to observe, analyze, and secure traffic flows. A single `GlobalNetworkPolicy` can be used to log all traffic across the cluster, providing comprehensive insights for your security strategy.  
 
 
 To log all traffic across the entire cluster, define a GlobalNetworkPolicy:
@@ -167,13 +170,14 @@ spec:
 
 ### Logging all traffic in a cluster
 
-By default, Calico policies apply only to namespaced resources (e.g., Pods, ServiceAccounts). To achieve total protection, enable hostEndpoint support to include non-namespaced resources and host nodes.
+By default, $[prodname] policies apply only to namespaced resources (e.g., Pods, ServiceAccounts). To achieve total protection, enable hostEndpoint support to include non-namespaced resources and host nodes.
 
 To log all traffic involving host endpoints, enable auto-creation of host endpoints:
 ```bash
 kubectl patch kubecontrollersconfiguration default --type=merge --patch='{"spec": {"controllers": {"node": {"hostEndpoint": {"autoCreate": "Enabled"}}}}}'
 ```
 
+Please ensure you disable policy logging by removing the Log policies once you have finalized your environment security, as it can impact cluster performance.
 
 ## Additional resources