From 9f30347f23f110c45a7fc892cb13a41abd09b27c Mon Sep 17 00:00:00 2001 From: Tim Ramlot <42113979+inteon@users.noreply.github.com> Date: Wed, 6 Sep 2023 15:51:46 +0200 Subject: [PATCH] fix broken links Signed-off-by: Tim Ramlot <42113979+inteon@users.noreply.github.com> --- content/docs/concepts/acme-orders-challenges.md | 2 +- content/docs/contributing/external-issuers.md | 6 +++--- content/docs/projects/README.md | 6 +++--- content/docs/projects/approver-policy/README.md | 6 +++--- content/docs/reference/cmctl.md | 2 +- content/docs/tutorials/istio-csr/istio-csr.md | 2 +- content/docs/usage/README.md | 2 +- content/docs/usage/approver-policy.md | 4 ++-- content/docs/usage/certificaterequest.md | 2 +- content/docs/usage/csi-driver-spiffe.md | 10 +++++----- content/docs/usage/csi-driver.md | 4 ++-- content/docs/usage/csi.md | 2 +- content/docs/usage/kube-csr.md | 2 +- public/_redirects | 1 + 14 files changed, 26 insertions(+), 25 deletions(-) diff --git a/content/docs/concepts/acme-orders-challenges.md b/content/docs/concepts/acme-orders-challenges.md index 80c31606e4e..e7c67a4a6e2 100644 --- a/content/docs/concepts/acme-orders-challenges.md +++ b/content/docs/concepts/acme-orders-challenges.md @@ -20,7 +20,7 @@ In order to complete these challenges, cert-manager introduces two validation can be found on the Let's Encrypt website [here](https://letsencrypt.org/how-it-works/). An order represents a single certificate request which will be created automatically once a new -[`CertificateRequest`](./certificaterequest.md) resource referencing an ACME +[`CertificateRequest`](../usage/certificaterequest.md) resource referencing an ACME issuer has been created. `CertificateRequest` resources are created automatically by cert-manager once a [`Certificate`](./certificate.md) resource is created, has its specification changed, or needs renewal. diff --git a/content/docs/contributing/external-issuers.md b/content/docs/contributing/external-issuers.md index 4d18572fb31..f4408e1c15c 100644 --- a/content/docs/contributing/external-issuers.md +++ b/content/docs/contributing/external-issuers.md @@ -49,13 +49,13 @@ on how to write an external issuer using Kubebuilder and controller-runtime. ## Approval Before signing a certificate, Issuers **must** also ensure that the `CertificateRequest` is -[`Approved`](../concepts/certificaterequest.md#approval). +[`Approved`](../usage/certificaterequest.md#approval). If the `CertificateRequest` is not `Approved`, the issuer **must** not process it. Issuers are not responsible for approving `CertificateRequests` and should refuse to proceed if they find a certificate that is not approved. -If a `CertificateRequest` created for an issuance associated with a `Certificate` gets [`Denied`](../concepts/certificaterequest.md#approval), the issuance will be failed by cert-manager's issuing controller. +If a `CertificateRequest` created for an issuance associated with a `Certificate` gets [`Denied`](../usage/certificaterequest.md#approval), the issuance will be failed by cert-manager's issuing controller. ## Conditions @@ -65,7 +65,7 @@ status of that resource to a ready state, as this is what is used to signal to h controllers - such as the `Certificate` controller - that the resource is ready to be consumed. Conversely, if the `CertificateRequest` fails, it is as important to mark the resource as such, as this will -also be used as a signal to higher order controllers. Valid condition states are listed under [concepts](../concepts/certificaterequest.md#conditions). +also be used as a signal to higher order controllers. Valid condition states are listed under [concepts](../usage/certificaterequest.md#conditions). ## Implementation diff --git a/content/docs/projects/README.md b/content/docs/projects/README.md index 185df2fce43..8c9f870f401 100644 --- a/content/docs/projects/README.md +++ b/content/docs/projects/README.md @@ -8,19 +8,19 @@ that extend the project's functionality, and complement the core cert-manager fe These tools help with security, compliance and control. -- [istio-csr](./istio-csr.md): Secure Istio service mesh with istio-csr which is +- [istio-csr](../usage/istio-csr.md): Secure Istio service mesh with istio-csr which is an agent that allows for [Istio](https://istio.io) workload and control plane components to be secured using cert-manager. - [approver-policy](./approver-policy/README.md): a cert-manager **approver** that will automatically approve or deny certificate requests based on defined policy. -- [csi-driver](./csi-driver.md): +- [csi-driver](../usage/csi-driver.md): a Container Storage Interface (CSI) driver plugin for Kubernetes to work along cert-manager. The goal for this plugin is to seamlessly request and mount certificate key pairs to pods. This is useful for facilitating mTLS, or otherwise securing connections of pods with guaranteed present certificates whilst having all of the features that cert-manager provides. -- [csi-driver-spiffe](./csi-driver-spiffe.md): +- [csi-driver-spiffe](../usage/csi-driver-spiffe.md): another CSI driver plugin to work along cert-manager. This CSI driver transparently delivers [SPIFFE](https://spiffe.io/) [SVIDs](https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/#spiffe-verifiable-identity-document-svid) diff --git a/content/docs/projects/approver-policy/README.md b/content/docs/projects/approver-policy/README.md index bdad17d829b..4fc837b9690 100644 --- a/content/docs/projects/approver-policy/README.md +++ b/content/docs/projects/approver-policy/README.md @@ -4,14 +4,14 @@ description: 'Policy plugin for cert-manager' --- approver-policy is a cert-manager -[approver](../../concepts/certificaterequest.md#approval) +[approver](../../usage/certificaterequest.md#approval) that will approve or deny CertificateRequests based on policies defined in the `CertificateRequestPolicy` custom resource. ## Prerequisites [cert-manager must be installed](../../installation/README.md), and -the [the default approver in cert-manager must be disabled](../../concepts/certificaterequest.md#approver-controller). +the [the default approver in cert-manager must be disabled](../../usage/certificaterequest.md#approver-controller). > ⚠️ If the default approver is not disabled in cert-manager, approver-policy will > race with cert-manager and policy will be ineffective. @@ -69,7 +69,7 @@ If you are using approver-policy with [external issuers](../../configuration/external.md), you _must_ include their signer names so that approver-policy has permissions to approve and deny CertificateRequests that -[reference them](../../concepts/certificaterequest.md#rbac-syntax). +[reference them](../../usage/certificaterequest.md#rbac-syntax). For example, if using approver-policy for the internal issuer types, along with [google-cas-issuer](https://github.com/jetstack/google-cas-issuer), and [aws-privateca-issuer](https://github.com/cert-manager/aws-privateca-issuer), diff --git a/content/docs/reference/cmctl.md b/content/docs/reference/cmctl.md index 095c9dfe6e0..ed682a54ae0 100644 --- a/content/docs/reference/cmctl.md +++ b/content/docs/reference/cmctl.md @@ -74,7 +74,7 @@ Use "cmctl [command] --help" for more information about a command. ### Approve and Deny CertificateRequests CertificateRequests can be -[approved or denied](../concepts/certificaterequest.md#approval) using their +[approved or denied](../usage/certificaterequest.md#approval) using their respective cmctl commands: > **Note**: The internal cert-manager approver may automatically approve all diff --git a/content/docs/tutorials/istio-csr/istio-csr.md b/content/docs/tutorials/istio-csr/istio-csr.md index 32c5c1ae3e7..bf1f292b09f 100644 --- a/content/docs/tutorials/istio-csr/istio-csr.md +++ b/content/docs/tutorials/istio-csr/istio-csr.md @@ -78,7 +78,7 @@ kubectl create secret generic -n cert-manager istio-root-ca --from-file=ca.pem=c ## Installing istio-csr istio-csr is best installed via Helm, and it should be simple and quick to install. There -are a bunch of other configuration options for the helm chart, which you can check out [here](../../projects/istio-csr.md). +are a bunch of other configuration options for the helm chart, which you can check out [here](../../usage/istio-csr.md). ```console helm repo add jetstack https://charts.jetstack.io diff --git a/content/docs/usage/README.md b/content/docs/usage/README.md index f02af619dc4..f959a4fc607 100644 --- a/content/docs/usage/README.md +++ b/content/docs/usage/README.md @@ -23,7 +23,7 @@ There are several use cases and methods for requesting certificates through cert pods. - [Securing Istio Gateway](https://istio.io/docs/tasks/traffic-management/ingress/ingress-certmgr/): Secure your Istio Gateway in Kubernetes using cert-manager. -- [Securing Istio Service Mesh](./istio.md): Using the cert-manager +- [Securing Istio Service Mesh](./istio-csr.md): Using the cert-manager [Istio](https://istio.io) integration, secure the mTLS PKI for each pod through cert-manager managed certificates. - [Policy for cert-manager certificates](./approver-policy.md): Manage diff --git a/content/docs/usage/approver-policy.md b/content/docs/usage/approver-policy.md index b712d04b7f3..5b46016fd96 100644 --- a/content/docs/usage/approver-policy.md +++ b/content/docs/usage/approver-policy.md @@ -3,9 +3,9 @@ title: Policy for cert-manager certificates description: 'cert-manager usage: approver-policy' --- -cert-manager [CertificateRequests](../concepts/certificaterequest.md) can be +cert-manager [CertificateRequests](../usage/certificaterequest.md) can be rejected from being signed by using the [approval -API](../concepts/certificaterequest.md#approval). +API](../usage/certificaterequest.md#approval). [approver-policy](https://github.com/cert-manager/approver-policy) is a cert-manager project that enables you to write policy to automatically manage this approval mechanism. diff --git a/content/docs/usage/certificaterequest.md b/content/docs/usage/certificaterequest.md index 6f1d0929480..8d39d914997 100644 --- a/content/docs/usage/certificaterequest.md +++ b/content/docs/usage/certificaterequest.md @@ -4,7 +4,7 @@ description: 'cert-manager core concepts: CertificateRequests' --- The `CertificateRequest` is a namespaced resource in cert-manager that is used -to request X.509 certificates from an [`Issuer`](./issuer.md). The resource +to request X.509 certificates from an [`Issuer`](../concepts/issuer.md). The resource contains a base64 encoded string of a PEM encoded certificate request which is sent to the referenced issuer. A successful issuance will return a signed certificate, based on the certificate signing request. `CertificateRequests` are diff --git a/content/docs/usage/csi-driver-spiffe.md b/content/docs/usage/csi-driver-spiffe.md index 771ce6a1aed..ca52c226942 100644 --- a/content/docs/usage/csi-driver-spiffe.md +++ b/content/docs/usage/csi-driver-spiffe.md @@ -46,7 +46,7 @@ which is used to create and mount Pod volumes from. When a Pod is created with the CSI volume configured, the driver will locally generate a private key, and create a cert-manager -[CertificateRequest](../concepts/certificaterequest.md) +[CertificateRequest](../usage/certificaterequest.md) in the same Namespace as the Pod. The driver uses [CSI Token Request](https://kubernetes-csi.github.io/docs/token-requests.html) to both @@ -61,7 +61,7 @@ expiry of the signed certificate. #### Approver -A distinct [cert-manager approver](../concepts/certificaterequest.md#approval) +A distinct [cert-manager approver](../usage/certificaterequest.md#approval) Deployment is responsible for managing the approval and denial condition of created CertificateRequests that target the configured SPIFFE Trust Domain signer. @@ -78,7 +78,7 @@ The approver ensures that requests have: If any of these checks do not pass, the CertificateRequest will be marked as Denied, else it will be marked as Approved. The approver will only manage -CertificateRequests who request from the same [IssuerRef](../concepts/certificaterequest.md) +CertificateRequests who request from the same [IssuerRef](../usage/certificaterequest.md) that has been configured. ## Installation @@ -98,7 +98,7 @@ cert-manager `v1.3` or higher is also required. csi-driver-spiffe requires cert-manager to be [installed](../installation/README.md) but a default installation of cert-manager **will not work**. -> ⚠️ It is **vital** that the [default approver is disabled in cert-manager](../concepts/certificaterequest.md#approver-controller) ⚠️ +> ⚠️ It is **vital** that the [default approver is disabled in cert-manager](../usage/certificaterequest.md#approver-controller) ⚠️ If the default approver is not disabled, the csi-driver-spiffe approver will race with cert-manager and policy enforcement will become useless. @@ -149,7 +149,7 @@ cmctl approve -n cert-manager \ Install csi-driver-spiffe into the cluster using the issuer we configured. We must also configure the issuer resource type and name of the issuer we -configured so that the approver has [permissions to approve referencing CertificateRequests](../concepts/certificaterequest.md#rbac-syntax). +configured so that the approver has [permissions to approve referencing CertificateRequests](../usage/certificaterequest.md#rbac-syntax). Note that the `issuer.name`, `issuer.kind` and `issuer.group` will need to be changed to match the issuer you're actually using! diff --git a/content/docs/usage/csi-driver.md b/content/docs/usage/csi-driver.md index 9bd10b2dade..0037dda92b7 100644 --- a/content/docs/usage/csi-driver.md +++ b/content/docs/usage/csi-driver.md @@ -182,9 +182,9 @@ volumeAttributes: ## Requesting Certificates using the mounting Pod's ServiceAccount If the flag `--use-token-request` is enabled on the csi-driver DaemonSet, the -[CertificateRequest](../concepts/certificaterequest.md) resource will be created +[CertificateRequest](../usage/certificaterequest.md) resource will be created by the mounting Pod's ServiceAccount. This can be paired with -[approver-policy](./approver-policy/README.md) to enable advanced policy control +[approver-policy](../projects/approver-policy/README.md) to enable advanced policy control on a per-ServiceAccount basis. Ensure that you give permissions to Pod ServiceAccounts to create CertificateRequests diff --git a/content/docs/usage/csi.md b/content/docs/usage/csi.md index 5e1a6124b0b..fafd45bfc39 100644 --- a/content/docs/usage/csi.md +++ b/content/docs/usage/csi.md @@ -6,7 +6,7 @@ description: 'cert-manager usage: CSI driver' ## Enabling mTLS of Pods using the cert-manager CSI Driver A [Container Storage Interface (CSI) -driver](../projects/csi-driver.md) has been created to +driver](./csi-driver.md) has been created to facilitate mTLS of Pods running inside your cluster through use of cert-manager. Using this driver will ensure that the private key and corresponding signed certificate will be unique to each Pod and will be stored on disk to the node diff --git a/content/docs/usage/kube-csr.md b/content/docs/usage/kube-csr.md index a4ff6a1a532..0f7c41a3dfc 100644 --- a/content/docs/usage/kube-csr.md +++ b/content/docs/usage/kube-csr.md @@ -6,7 +6,7 @@ description: 'cert-manager usage: Kubernetes CertificateSigningRequest resources Kubernetes has an in-built [CertificateSigningRequest](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/) resource. This resource is similar to the cert-manager -[CertificateRequest](../concepts/certificaterequest.md) in that it is used to +[CertificateRequest](../usage/certificaterequest.md) in that it is used to request an X.509 signed certificate from a referenced Certificate Authority (CA). diff --git a/public/_redirects b/public/_redirects index c9e643e24b0..602ab23a176 100644 --- a/public/_redirects +++ b/public/_redirects @@ -7,6 +7,7 @@ https://cert-manager.netlify.com/* https://cert-manager.io/:splat 301! /docs/projects/istio-csr/ /docs/usage/istio-csr/ 301! /docs/projects/csi-driver/ /docs/usage/csi-driver/ 301! /docs/projects/csi-driver-spiffe/ /docs/usage/csi-driver-spiffe/ 301! +/docs/concepts/certificaterequest/ /docs/usage/certificaterequest/ 301! # Redirect all next-docs on the main site to the release-next preview https://cert-manager.io/next-docs/* https://release-next--cert-manager-website.netlify.app/docs/:splat 301!