[en] modify debug-cluster/audit

Signed-off-by: xin.li <xin.li@daocloud.io>

content/en/blog/_posts/2017-06-00-Kubernetes-1-7-Security-Hardening-Stateful-Application-Extensibility-Updates.md

@@ -19,7 +19,7 @@ Security:
 - [Node authorizer](/docs/reference/access-authn-authz/node/) and admission control plugin are new additions that restrict kubelet’s access to secrets, pods and other objects based on its node.
 - [Encryption for Secrets](/docs/tasks/administer-cluster/encrypt-data/), and other resources in etcd, is now available as alpha. 
 - [Kubelet TLS bootstrapping](/docs/admin/kubelet-tls-bootstrapping/) now supports client and server certificate rotation.
-- [Audit logs](/docs/tasks/debug-application-cluster/audit/) stored by the API server are now more customizable and extensible with support for event filtering and webhooks. They also provide richer data for system audit.
+- [Audit logs](/docs/tasks/debug/debug-cluster/audit/) stored by the API server are now more customizable and extensible with support for event filtering and webhooks. They also provide richer data for system audit.
 
 Stateful workloads:  
 

content/en/blog/_posts/2017-12-00-Using-Ebpf-In-Kubernetes.md

@@ -117,7 +117,7 @@ To achieve the best possible isolation, each function call would have to happen
 By using Landlock, we could isolate function calls from each other within the same container, making a temporary file created by one function call inaccessible to the next function call, for example. Integration between Landlock and technologies like Kubernetes-based serverless frameworks would be a ripe area for further exploration.  
 
 ## Auditing kubectl-exec with eBPF
-In Kubernetes 1.7 the [audit proposal](/docs/tasks/debug-application-cluster/audit/) started making its way in. It's currently pre-stable with plans to be stable in the 1.10 release. As the name implies, it allows administrators to log and audit events that take place in a Kubernetes cluster.   
+In Kubernetes 1.7 the [audit proposal](/docs/tasks/debug/debug-cluster/audit/) started making its way in. It's currently pre-stable with plans to be stable in the 1.10 release. As the name implies, it allows administrators to log and audit events that take place in a Kubernetes cluster.   
 
 While these events log Kubernetes events, they don't currently provide the level of visibility that some may require. For example, while we can see that someone has used `kubectl exec` to enter a container, we are not able to see what commands were executed in that session. With eBPF one can attach a BPF program that would record any commands executed in the `kubectl exec` session and pass those commands to a user-space program that logs those events. We could then play that session back and know the exact sequence of events that took place.
 ## Learn more about eBPF

content/en/blog/_posts/2018-07-18-11-ways-not-to-get-hacked.md

@@ -66,7 +66,7 @@ There are plenty of [good examples](https://docs.bitnami.com/kubernetes/how-to/c
 
 Incorrect or excessively permissive RBAC policies are a security threat in case of a compromised pod. Maintaining least privilege, and continuously reviewing and improving RBAC rules, should be considered part of the "technical debt hygiene" that teams build into their development lifecycle.
 
-[Audit Logging](/docs/tasks/debug-application-cluster/audit/) (beta in 1.10) provides customisable API logging at the payload (e.g. request and response), and also metadata levels. Log levels can be tuned to your organisation's security policy - [GKE](https://cloud.google.com/kubernetes-engine/docs/how-to/audit-logging#audit_policy) provides sane defaults to get you started.
+[Audit Logging](/docs/tasks/debug/debug-cluster/audit/) (beta in 1.10) provides customisable API logging at the payload (e.g. request and response), and also metadata levels. Log levels can be tuned to your organisation's security policy - [GKE](https://cloud.google.com/kubernetes-engine/docs/how-to/audit-logging#audit_policy) provides sane defaults to get you started.
 
 For read requests such as get, list, and watch, only the request object is saved in the audit logs; the response object is not. For requests involving sensitive data such as Secret and ConfigMap, only the metadata is exported. For all other requests, both request and response objects are saved in audit logs.
 

content/en/blog/_posts/2020-09-03-warnings/index.md

@@ -177,7 +177,7 @@ group_right() apiserver_request_total
 
 Metrics are a fast way to check whether deprecated APIs are being used, and at what rate,
 but they don't include enough information to identify particular clients or API objects.
-Starting in Kubernetes v1.19, [audit events](/docs/tasks/debug-application-cluster/audit/)
+Starting in Kubernetes v1.19, [audit events](/docs/tasks/debug/debug-cluster/audit/)
 for requests to deprecated APIs include an audit annotation of `"k8s.io/deprecated":"true"`.
 Administrators can use those audit events to identify specific clients or objects that need to be updated.
 

content/en/blog/_posts/2020-11-18-cloud-native-security-for-your-cluster/index.md

@@ -20,7 +20,7 @@ The paper attempts to _not_ focus on any specific [cloud native project](https:/
 When using Kubernetes as a workload orchestrator, some of the security controls this version of the whitepaper recommends are:
 * [Pod Security Policies](/docs/concepts/security/pod-security-policy/): Implement a single source of truth for “least privilege” workloads across the entire cluster
 * [Resource requests and limits](/docs/concepts/configuration/manage-resources-containers/#requests-and-limits): Apply requests (soft constraint) and limits (hard constraint) for shared resources such as memory and CPU
-* [Audit log analysis](/docs/tasks/debug-application-cluster/audit/): Enable Kubernetes API auditing and filtering for security relevant events
+* [Audit log analysis](/docs/tasks/debug/debug-cluster/audit/): Enable Kubernetes API auditing and filtering for security relevant events
 * [Control plane authentication and certificate root of trust](/docs/concepts/architecture/control-plane-node-communication/): Enable mutual TLS authentication with a trusted CA for communication within the cluster
 * [Secrets management](/docs/concepts/configuration/secret/): Integrate with a built-in or external secrets store
 

content/en/blog/_posts/2021-10-05-nsa-cisa-hardening.md

@@ -317,7 +317,7 @@ RequestResponse's including metadata and request / response bodies. While helpfu
 
 Each organization needs to evaluate their
 own threat model and build an audit policy that complements or helps troubleshooting incident response. Think
-about how someone would attack your organization and what audit trail could identify it. Review more advanced options for tuning audit logs in the official [audit logging documentation](/docs/tasks/debug-application-cluster/audit/#audit-policy).
+about how someone would attack your organization and what audit trail could identify it. Review more advanced options for tuning audit logs in the official [audit logging documentation](/docs/tasks/debug/debug-cluster/audit/#audit-policy).
 It's crucial to tune your audit logs to only include events that meet your threat model. A minimal audit policy that logs everything at `metadata` level can also be a good starting point. 
 
 Audit logging configurations can also be tested with

content/en/docs/concepts/cluster-administration/_index.md

@@ -59,7 +59,7 @@ Before choosing a guide, here are some considerations:
 
 * [Using Sysctls in a Kubernetes Cluster](/docs/tasks/administer-cluster/sysctl-cluster/) describes to an administrator how to use the `sysctl` command-line tool to set kernel parameters .
 
-* [Auditing](/docs/tasks/debug-application-cluster/audit/) describes how to interact with Kubernetes' audit logs.
+* [Auditing](/docs/tasks/debug/debug-cluster/audit/) describes how to interact with Kubernetes' audit logs.
 
 ### Securing the kubelet
   * [Control Plane-Node communication](/docs/concepts/architecture/control-plane-node-communication/)

content/en/docs/concepts/security/controlling-access.md

@@ -134,7 +134,7 @@ for the corresponding API object, and then written to the object store (shown as
 Kubernetes auditing provides a security-relevant, chronological set of records documenting the sequence of actions in a cluster.
 The cluster audits the activities generated by users, by applications that use the Kubernetes API, and by the control plane itself.
 
-For more information, see [Auditing](/docs/tasks/debug-application-cluster/audit/).
+For more information, see [Auditing](/docs/tasks/debug/debug-cluster/audit/).
 
 ## API server ports and IPs
 

content/en/docs/concepts/security/pod-security-admission.md

@@ -88,7 +88,7 @@ takes if a potential violation is detected:
 Mode | Description
 :---------|:------------
 **enforce** | Policy violations will cause the pod to be rejected.
-**audit** | Policy violations will trigger the addition of an audit annotation to the event recorded in the [audit log](/docs/tasks/debug-application-cluster/audit/), but are otherwise allowed.
+**audit** | Policy violations will trigger the addition of an audit annotation to the event recorded in the [audit log](/docs/tasks/debug/debug-cluster/audit/), but are otherwise allowed.
 **warn** | Policy violations will trigger a user-facing warning, but are otherwise allowed.
 {{< /table >}}
 

content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md

@@ -1396,7 +1396,7 @@ monitoring mechanisms help cluster admins to answer questions like:
 Sometimes it's useful to know which mutating webhook mutated the object in a API request, and what change did the
 webhook apply.
 
-In v1.16+, kube-apiserver performs [auditing](/docs/tasks/debug-application-cluster/audit/) on each mutating webhook
+In v1.16+, kube-apiserver performs [auditing](/docs/tasks/debug/debug-cluster/audit/) on each mutating webhook
 invocation. Each invocation generates an auditing annotation
 capturing if a request object is mutated by the invocation, and optionally generates an annotation capturing the applied
 patch from the webhook admission response. The annotations are set in the audit event for given request on given stage of

content/en/docs/reference/command-line-tools-reference/feature-gates.md

@@ -570,7 +570,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
   Docker Engine; no longer available. See
   [Device Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) for
   an alternative.
-- `AdvancedAuditing`: Enable [advanced auditing](/docs/tasks/debug-application-cluster/audit/#advanced-audit)
+- `AdvancedAuditing`: Enable [advanced auditing](/docs/tasks/debug/debug-cluster/audit/#advanced-audit)
 - `AffinityInAnnotations`: Enable setting
   [Pod affinity or anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity).
 - `AllowExtTrafficLocalEndpoints`: Enable a service to route external requests to node local endpoints.

content/en/docs/reference/glossary/event.md

@@ -21,5 +21,5 @@ or the continued existence of events with that reason.
 
 Events should be treated as informative, best-effort, supplemental data.
 
-In Kubernetes, [auditing](/docs/tasks/debug-application-cluster/audit/) generates a different kind of
+In Kubernetes, [auditing](/docs/tasks/debug/debug-cluster/audit/) generates a different kind of
 Event record (API group `audit.k8s.io`).

content/en/docs/reference/labels-annotations-taints/audit-annotations.md

@@ -11,7 +11,7 @@ namespace. These annotations apply to `Event` object from API group
 
 {{< note >}}
 The following annotations are not used within the Kubernetes API. When you
-[enable auditing](/docs/tasks/debug-application-cluster/audit/) in your cluster,
+[enable auditing](/docs/tasks/debug/debug-cluster/audit/) in your cluster,
 audit event data is written using `Event` from API group `audit.k8s.io`.
 The annotations apply to audit events. Audit events are different from objects in the
 [Event API](/docs/reference/kubernetes-api/cluster-resources/event-v1/) (API group
@@ -64,7 +64,7 @@ Example: `authorization.k8s.io/decision: "forbid"`
 
 This annotation indicates whether or not a request was authorized in Kubernetes audit logs.
 
-See [Auditing](/docs/tasks/debug-application-cluster/audit/) for more information.
+See [Auditing](/docs/tasks/debug/debug-cluster/audit/) for more information.
 
 ## authorization.k8s.io/reason
 
@@ -72,4 +72,4 @@ Example: `authorization.k8s.io/reason: "Human-readable reason for the decision"`
 
 This annotation gives reason for the [decision](#authorization-k8s-io-decision) in Kubernetes audit logs.
 
-See [Auditing](/docs/tasks/debug-application-cluster/audit/) for more information.
+See [Auditing](/docs/tasks/debug/debug-cluster/audit/) for more information.

content/en/docs/reference/using-api/deprecation-policy.md

@@ -286,7 +286,7 @@ behavior get removed.
 Starting in Kubernetes v1.19, making an API request to a deprecated REST API endpoint:
 
 1. Returns a `Warning` header (as defined in [RFC7234, Section 5.5](https://tools.ietf.org/html/rfc7234#section-5.5)) in the API response.
-2. Adds a `"k8s.io/deprecated":"true"` annotation to the [audit event](/docs/tasks/debug-application-cluster/audit/) recorded for the request.
+2. Adds a `"k8s.io/deprecated":"true"` annotation to the [audit event](/docs/tasks/debug/debug-cluster/audit/) recorded for the request.
 3. Sets an `apiserver_requested_deprecated_apis` gauge metric to `1` in the `kube-apiserver`
    process. The metric has labels for `group`, `version`, `resource`, `subresource` that can be joined
    to the `apiserver_request_total` metric, and a `removed_release` label that indicates the