From 68f19c811ee23e95da21c3ee8530930fc62426f9 Mon Sep 17 00:00:00 2001 From: Jim Bugwadia Date: Sun, 4 Aug 2024 23:28:21 -0700 Subject: [PATCH] fix links Signed-off-by: Jim Bugwadia --- content/en/docs/introduction/admission-controllers.md | 2 +- content/en/docs/security/_index.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/introduction/admission-controllers.md b/content/en/docs/introduction/admission-controllers.md index acf06d586..c0914252d 100644 --- a/content/en/docs/introduction/admission-controllers.md +++ b/content/en/docs/introduction/admission-controllers.md @@ -99,7 +99,7 @@ In this example, the API server has been instructed to send any creation request The controller is the other half of the dynamic admission controller story. Something must be listening for the requests sent by the API server and be prepared to respond. This is typically implemented by a controller running in the same cluster as a Pod. This controller, like the API server with the webhook, must have some instruction for how to respond to requests. This instruction is provided to it in the form of a **policy**. A policy is typically another Kubernetes resource, but this time a [Custom Resource](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/), which the controller uses to determine that response. Once the controller examines the policy it is prepared to make a decision for resources it receives. -For example, as you may have learned in the [validation quick start section](../introduction/_index.md#validation), a policy such as `require-labels` can be used to instruct the controller how to respond in the case where it receives a matching request. If the Pod has a label named `team` then its creation will be allowed. If it does not, it will be prevented. +For example, as you may have learned in the [validation quick start section](../introduction/quick-start.md#validate-resources), a policy such as `require-labels` can be used to instruct the controller how to respond in the case where it receives a matching request. If the Pod has a label named `team` then its creation will be allowed. If it does not, it will be prevented. Controllers receiving requests from the Kubernetes API server do so over HTTP/REST. The contents of that request are a "packaging" or "wrapping" of the resource, which has been defined via the webhook, in addition to other pertinent information about who or what made the request. This package is called an `AdmissionReview`. More details on this packaging format along with an example can be seen [here](../writing-policies/jmespath.md#admissionreview). diff --git a/content/en/docs/security/_index.md b/content/en/docs/security/_index.md index 8c26dca4b..8a188cdff 100644 --- a/content/en/docs/security/_index.md +++ b/content/en/docs/security/_index.md @@ -242,7 +242,7 @@ Kyverno Pods are configured to follow security best practices and conform to the ### RBAC -The Kyverno RBAC configurations are described in the [installation](../installation/customization.md#roles-and-permissions) section. +The Kyverno RBAC configurations are described in the [installation](../installation/customization.md#role-based-access-controls) section. Use the following command to view all Kyverno roles: