From 162d17311b69fdc99454d8178a4d2d47e1f2a263 Mon Sep 17 00:00:00 2001
From: Alen Haric <aharic88@gmail.com>
Date: Wed, 3 Apr 2024 13:56:24 -0400
Subject: [PATCH 1/3] updated automatic cert-manager rotation docs to walk
 users through process of using cert-manager for entire trust chain

Signed-off-by: Alen Haric <aharic88@gmail.com>
---
 ...-rotating-control-plane-tls-credentials.md | 248 ++++++++++---
 ...ically-rotating-webhook-tls-credentials.md | 333 +++++++++---------
 2 files changed, 356 insertions(+), 225 deletions(-)

diff --git a/linkerd.io/content/2.15/tasks/automatically-rotating-control-plane-tls-credentials.md b/linkerd.io/content/2.15/tasks/automatically-rotating-control-plane-tls-credentials.md
index 3c332585e5..fa8b52dc4c 100644
--- a/linkerd.io/content/2.15/tasks/automatically-rotating-control-plane-tls-credentials.md
+++ b/linkerd.io/content/2.15/tasks/automatically-rotating-control-plane-tls-credentials.md
@@ -6,14 +6,15 @@ aliases = [ "use_external_certs" ]
 
 Linkerd's [automatic mTLS](../../features/automatic-mtls/) feature generates TLS
 certificates for proxies and automatically rotates them without user
-intervention. These certificates are derived from a *trust anchor*, which is
-shared across clusters, and an *issuer certificate*, which is specific to the
+intervention. These certificates are derived from a _trust anchor_, which is
+shared across clusters, and an _issuer certificate_, which is specific to the
 cluster.
 
 While Linkerd automatically rotates the per-proxy TLS certificates, it does not
-rotate the issuer certificate. In this doc, we'll describe how to set up
-automatic rotation of the issuer certificate and its corresponding private key
-using the cert-manager project.
+rotate the issuer certificate. Linkerd's out-of-the-box installations generate
+static self-signed certificates with a validity of one year but require manual
+rotation by the user to prevent expiry. While this setup is convenient for quick
+start testing, it's not advisable nor recommended for production environments.
 
 {{< trylpt >}}
 
@@ -24,17 +25,23 @@ for making TLS credentials from external sources available to Kubernetes
 clusters.
 
 Cert-manager is very flexible. You can configure it to pull certificates from
-secrets managemenet solutions such as [Vault](https://www.vaultproject.io).  In
+secrets managemenet solutions such as [Vault](https://www.vaultproject.io). In
 this guide, we'll focus on a self-sufficient setup: we will configure
 cert-manager to act as an on-cluster
 [CA](https://en.wikipedia.org/wiki/Certificate_authority) and have it re-issue
 Linkerd's issuer certificate and private key on a periodic basis, derived from
-the trust anchor.
+the trust anchor. Additionally, we will use trust-manager create a trust bundle
+which will allow Linkerd to verify the authenticity of certificates issued by
+cert-manager.
 
 ### Cert manager as an on-cluster CA
 
-As a first step, [install cert-manager on your
-cluster](https://cert-manager.io/docs/installation/).
+As a first step,
+[install cert-manager on your cluster](https://cert-manager.io/docs/installation/),
+then
+[install trust-manager](https://cert-manager.io/docs/trust/trust-manager/installation/)
+and configure it to use "linkerd" as the
+[trust namespace](https://cert-manager.io/docs/trust/trust-manager/installation/#trust-namespace).
 
 Next, create the namespace that cert-manager will use to store its
 Linkerd-related resources. For simplicity, we suggest reusing the default
@@ -44,46 +51,111 @@ Linkerd control plane namespace:
 kubectl create namespace linkerd
 ```
 
-#### Save the signing key pair as a Secret
+#### Give cert-manager necessary RBAC permissions
 
-Next, using the [`step`](https://smallstep.com/cli/) tool, create a signing key
-pair and store it in a Kubernetes Secret in the namespace created above:
+By default cert-manager will only create certificate secrets in the namespace
+where it is installed. Linkerd, however, requires the cert secrets to be created
+in the linkerd namespace. To do this we will create a `ServiceAccount` for
+cert-manager in the linkerd namespace with the required permissions.
 
 ```bash
-step certificate create root.linkerd.cluster.local ca.crt ca.key \
-  --profile root-ca --no-password --insecure &&
-  kubectl create secret tls \
-    linkerd-trust-anchor \
-    --cert=ca.crt \
-    --key=ca.key \
-    --namespace=linkerd
+kubectl apply -f - <<EOF
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+  name: cert-manager
+  namespace: linkerd
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: Role
+metadata:
+  name: cert-manager-secret-creator
+  namespace: linkerd
+rules:
+  - apiGroups: [""]
+    resources: ["secrets"]
+    verbs: ["create", "get", "update", "patch"]
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: RoleBinding
+metadata:
+  name: cert-manager-secret-creator-binding
+  namespace: linkerd
+subjects:
+  - kind: ServiceAccount
+    name: cert-manager
+    namespace: linkerd
+roleRef:
+  kind: Role
+  name: cert-manager-secret-creator
+  apiGroup: rbac.authorization.k8s.io
+EOF
 ```
 
-For a longer-lived trust anchor certificate, pass the `--not-after` argument
-to the step command with the desired value (e.g. `--not-after=87600h`).
+#### Create the trust root ClusterIssuer
+
+To begin, create a self-signing `ClusterIssuer` for the Linkerd trust root
+certificate.
+
+```bash
+kubectl apply -f - <<EOF
+apiVersion: cert-manager.io/v1
+kind: ClusterIssuer
+metadata:
+  name: linkerd-trust-root-issuer
+spec:
+  selfSigned: {}
+EOF
+```
 
-#### Create an Issuer referencing the secret
+#### Create a trust root certificate
 
-With the Secret in place, we can create a cert-manager "Issuer" resource that
-references it:
+Now create a cert-manager `Certificate` resource which uses the
+previously-created `ClusterIssuer`:
 
 ```bash
 kubectl apply -f - <<EOF
 apiVersion: cert-manager.io/v1
-kind: Issuer
+kind: Certificate
 metadata:
   name: linkerd-trust-anchor
   namespace: linkerd
+spec:
+  commonName: root.linkerd.cluster.local
+  isCA: true
+  duration: 87600h0m0s
+  renewBefore: 87264h0m0s
+  issuerRef:
+    name: linkerd-trust-root-issuer
+    kind: ClusterIssuer
+  privateKey:
+    algorithm: ECDSA
+  secretName: linkerd-trust-anchor
+EOF
+```
+
+#### Create Linkerd identity issuer
+
+Using the previously-generated trust root certificate, create a Linkerd identity
+`Issuer`:
+
+```bash
+kubectl apply -f - <<EOF
+apiVersion: cert-manager.io/v1
+kind: Issuer
+metadata:
+  name: linkerd-identity-issuer
+  namespace: linkerd
 spec:
   ca:
     secretName: linkerd-trust-anchor
 EOF
 ```
 
-#### Create a Certificate resource referencing the Issuer
+#### Create a Certificate resource referencing the issuer
 
-Finally, we can create a cert-manager "Certificate" resource which uses this
-Issuer to generate the desired certificate:
+Next, create a Linkerd identity issuer certificate which will act as an
+intermediary signing CA for all Linkerd mTLS proxy certificates:
 
 ```bash
 kubectl apply -f - <<EOF
@@ -93,12 +165,6 @@ metadata:
   name: linkerd-identity-issuer
   namespace: linkerd
 spec:
-  secretName: linkerd-identity-issuer
-  duration: 48h
-  renewBefore: 25h
-  issuerRef:
-    name: linkerd-trust-anchor
-    kind: Issuer
   commonName: identity.linkerd.cluster.local
   dnsNames:
   - identity.linkerd.cluster.local
@@ -106,40 +172,112 @@ spec:
   privateKey:
     algorithm: ECDSA
   usages:
-  - cert sign
-  - crl sign
-  - server auth
-  - client auth
+    - cert sign
+    - crl sign
+    - server auth
+    - client auth
+  duration: 28h0m0s
+  renewBefore: 25h0m0s
+  issuerRef:
+    name: linkerd-identity-issuer
+    kind: Issuer
+  privateKey:
+    algorithm: ECDSA
+  secretName: linkerd-identity-issuer
 EOF
 ```
 
 (In the YAML manifest above, the `duration` key instructs cert-manager to
-consider certificates as valid for `48` hours and the `renewBefore` key indicates
-that cert-manager will attempt to issue a new certificate `25` hours before
-expiration of the current one. These values can be customized to your liking.)
+consider certificates as valid for `48` hours and the `renewBefore` key
+indicates that cert-manager will attempt to issue a new certificate `25` hours
+before expiration of the current one. These values can be customized to your
+liking.)
+
+#### Create Linkerd trust bundle
+
+Lastly, we will also need to create a trust bundle which will allow Linkerd's
+identity controller to verify the authenticity of certificates issued by
+cert-manager:
+
+```bash
+kubectl apply -f - <<EOF
+apiVersion: trust.cert-manager.io/v1alpha1
+kind: Bundle
+metadata:
+  name: linkerd-identity-trust-roots
+  namespace: linkerd
+spec:
+  sources:
+    - secret:
+        name: "linkerd-trust-anchor"
+        key: "ca.crt"
+  target:
+    configMap:
+      key: "ca-bundle.crt"
+EOF
+```
+
+## Summary & Validation
+
+Below are the resources created for managing Linkerd identity certificates with
+cert-manager:
 
-At this point, cert-manager can now use this Certificate resource to obtain TLS
-credentials, which will be stored in a secret named `linkerd-identity-issuer`.
-To validate your newly-issued certificate, you can run:
+- Namespace: `linkerd` (to store certificates and secrets)
+- RBAC Permissions: ServiceAccount, Role, and RoleBinding in the `linkerd`
+  namespace for cert-manager
+- ClusterIssuer: `linkerd-trust-root-issuer` (self-signed ClusterIssuer)
+- Certificate: `linkerd-trust-anchor` (in the `linkerd` namespace, referencing
+  `linkerd-trust-root-issuer`)
+- Issuer: `linkerd-identity-issuer` (to manage Linkerd identity certificates)
+- Certificate: `linkerd-identity-issuer` (in the `linkerd` namespace, acting as
+  an intermediary signing CA)
+- Trust Bundle: `linkerd-identity-trust-roots` (to allow Linkerd's identity
+  controller to verify certificate authenticity)
+
+To validate creation and status, run the following commands:
 
 ```bash
-kubectl get secret linkerd-identity-issuer -o yaml -n linkerd
+# Check namespace creation
+kubectl get namespaces linkerd
+
+# Check RBAC permissions
+kubectl get serviceaccount,role,rolebinding -n linkerd
+
+# Check ClusterIssuer creation
+kubectl get clusterissuers linkerd-trust-root-issuer
+
+# Check Certificate creation
+kubectl get certificates -n linkerd
+
+# Check Issuer creation
+kubectl get issuers.cert-manager.io -n linkerd
+
+# Check Trust Bundle creation
+kubectl get bundles -n linkerd
 ```
 
-Now we just need to inform Linkerd to consume these credentials.
+## Consuming cert-manager identity certificates
+
+To have Linkerd consume cert-manager created certificates you will need to add
+the following to your values file or pass them in as flags at runtime.
+
+| Field                    | Value             |
+| ------------------------ | ----------------- |
+| `identity.externalCA`    | true              |
+| `identity.issuer.scheme` | kubernetes.io/tls |
 
-## Using these credentials with CLI installation
+### Using these credentials with CLI installation
 
 For CLI installation, the Linkerd control plane should be installed with the
 `--identity-external-issuer` flag, which instructs Linkerd to read certificates
 from the `linkerd-identity-issuer` secret. Whenever certificate and key stored
-in the secret are updated, the `identity` service will automatically detect
-this change and reload the new credentials.
+in the secret are updated, the `identity` service will automatically detect this
+change and reload the new credentials.
 
 Voila! We have set up automatic rotation of Linkerd's control plane TLS
 credentials.
 
-## Using these credentials with a Helm installation
+### Using these credentials with a Helm installation
 
 For installing with Helm, first install the `linkerd-crds` chart:
 
@@ -147,13 +285,11 @@ For installing with Helm, first install the `linkerd-crds` chart:
 helm install linkerd-crds -n linkerd --create-namespace linkerd/linkerd-crds
 ```
 
-Then install the `linkerd-control-plane` chart, setting the
-`identityTrustAnchorsPEM` to the value of `ca.crt` in the
-`linkerd-identity-issuer` Secret:
+Then install the `linkerd-control-plane` chart:
 
 ```bash
 helm install linkerd-control-plane -n linkerd \
-  --set-file identityTrustAnchorsPEM=ca.crt \
+  --set identity.externalCA=true \
   --set identity.issuer.scheme=kubernetes.io/tls \
   linkerd/linkerd-control-plane
 ```
@@ -199,5 +335,5 @@ following instructions to install and configure Linkerd to use it.
 
 ## See also
 
-* [Automatically Rotating Webhook TLS Credentials](../automatically-rotating-webhook-tls-credentials/)
-* [Manually rotating Linkerd's trust anchor credentials](../manually-rotating-control-plane-tls-credentials/)
+- [Automatically Rotating Webhook TLS Credentials](../automatically-rotating-webhook-tls-credentials/)
+- [Manually rotating Linkerd's trust anchor credentials](../manually-rotating-control-plane-tls-credentials/)
diff --git a/linkerd.io/content/2.15/tasks/automatically-rotating-webhook-tls-credentials.md b/linkerd.io/content/2.15/tasks/automatically-rotating-webhook-tls-credentials.md
index db5ab64b06..50a94c1fcc 100644
--- a/linkerd.io/content/2.15/tasks/automatically-rotating-webhook-tls-credentials.md
+++ b/linkerd.io/content/2.15/tasks/automatically-rotating-webhook-tls-credentials.md
@@ -4,32 +4,33 @@ description = "Use cert-manager to automatically rotate webhook TLS credentials.
 +++
 
 The Linkerd control plane contains several components, called webhooks, which
-are called directly by Kubernetes itself.  The traffic from Kubernetes to the
+are called directly by Kubernetes itself. The traffic from Kubernetes to the
 Linkerd webhooks is secured with TLS and therefore each of the webhooks requires
-a secret containing TLS credentials.  These certificates are different from the
+a secret containing TLS credentials. These certificates are different from the
 ones that the Linkerd proxies use to secure pod-to-pod communication and use a
-completely separate trust chain.  For more information on rotating the TLS
+completely separate trust chain. For more information on rotating the TLS
 credentials used by the Linkerd proxies, see
 [Automatically Rotating Control Plane TLS Credentials](../use_external_certs/).
 
-By default, when Linkerd is installed
-with the Linkerd CLI or with the Linkerd Helm chart, TLS credentials are
-automatically generated for all of the webhooks.  If these certificates expire
-or need to be regenerated for any reason, performing a
-[Linkerd upgrade](../upgrade/) (using the Linkerd CLI or using Helm) will
-regenerate them.
+By default, when Linkerd is installed with the Linkerd CLI or with the Linkerd
+Helm chart, TLS credentials are automatically generated for all of the webhooks.
+If these certificates expire or need to be regenerated for any reason,
+performing a [Linkerd upgrade](../upgrade/) (using the Linkerd CLI or using
+Helm) will regenerate them.
 
-This workflow is suitable for most users.  However, if you need these webhook
-certificates to be rotated automatically on a regular basis, it is possible to
-use cert-manager to automatically manage them.
+Unless absolutely necessary, it is recommended to allow the CLI/Helm to create
+and update webhook certificates automatically through the install and upgrade
+process. However, if you need these webhook certificates to be rotated
+automatically on a regular basis, it is possible to use cert-manager to
+automatically manage them.
 
 {{< trylpt >}}
 
 ## Install Cert manager
 
-As a first step, [install cert-manager on your
-cluster](https://cert-manager.io/docs/installation/)
-and create  the namespaces that cert-manager will use to store its
+As a first step,
+[install cert-manager on your cluster](https://cert-manager.io/docs/installation/)
+and create the namespaces that cert-manager will use to store its
 webhook-related resources. For simplicity, we suggest using the default
 namespace linkerd uses:
 
@@ -51,66 +52,116 @@ kubectl create namespace linkerd-jaeger
 kubectl label namespace linkerd-jaeger linkerd.io/extension=jaeger
 ```
 
-## Save the signing key pair as a Secret
+{{< note >}} The following namespace-bound templates and commands can be re-used
+for Linkerd extensions including viz and jaeger by modifying the namespace of
+each to match that of the extension. {{< /note >}}
 
-Next, we will use the [`step`](https://smallstep.com/cli/) tool, to create a
-signing key pair which will be used to sign each of the webhook certificates:
+## Give cert-manager necessary RBAC permissions
+
+By default cert-manager will only create certificate secrets in the namespace
+where it is installed. Linkerd and its extensions, however, require the cert
+secrets to be created in the namespaces where they run. To do this we will
+create a `ServiceAccount` for cert-manager in the appropriate namespaces with
+the required permissions.
 
 ```bash
-step certificate create webhook.linkerd.cluster.local ca.crt ca.key \
-  --profile root-ca --no-password --insecure --san webhook.linkerd.cluster.local
+kubectl apply -f - <<EOF
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+  name: cert-manager
+  namespace: linkerd
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: Role
+metadata:
+  name: cert-manager-secret-creator
+  namespace: linkerd
+rules:
+  - apiGroups: [""]
+    resources: ["secrets"]
+    verbs: ["create", "get", "update", "patch"]
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: RoleBinding
+metadata:
+  name: cert-manager-secret-creator-binding
+  namespace: linkerd
+subjects:
+  - kind: ServiceAccount
+    name: cert-manager
+    namespace: linkerd
+roleRef:
+  kind: Role
+  name: cert-manager-secret-creator
+  apiGroup: rbac.authorization.k8s.io
+EOF
+```
 
-kubectl create secret tls webhook-issuer-tls --cert=ca.crt --key=ca.key --namespace=linkerd
+## Create the trust root issuer
 
-# ignore if not using the viz extension
-kubectl create secret tls webhook-issuer-tls --cert=ca.crt --key=ca.key --namespace=linkerd-viz
+To begin, create a self-signing `ClusterIssuer` for the Linkerd trust root
+certificate.
 
-# ignore if not using the jaeger extension
-kubectl create secret tls webhook-issuer-tls --cert=ca.crt --key=ca.key --namespace=linkerd-jaeger
+```bash
+kubectl apply -f - <<EOF
+apiVersion: cert-manager.io/v1
+kind: ClusterIssuer
+metadata:
+  name: linkerd-trust-root-issuer
+spec:
+  selfSigned: {}
+EOF
 ```
 
-## Create Issuers referencing the secrets
+## Create a trust root certificate
 
-With the Secrets in place, we can create cert-manager "Issuer" resources that
-reference them:
+Now create a cert-manager `Certificate` resource which uses the
+previously-created `ClusterIssuer`:
 
 ```bash
 kubectl apply -f - <<EOF
 apiVersion: cert-manager.io/v1
-kind: Issuer
+kind: Certificate
 metadata:
-  name: webhook-issuer
+  name: linkerd-trust-anchor
   namespace: linkerd
 spec:
-  ca:
-    secretName: webhook-issuer-tls
----
-# ignore if not using the viz extension
-apiVersion: cert-manager.io/v1
-kind: Issuer
-metadata:
-  name: webhook-issuer
-  namespace: linkerd-viz
-spec:
-  ca:
-    secretName: webhook-issuer-tls
----
-# ignore if not using the jaeger extension
+  commonName: root.linkerd.cluster.local
+  isCA: true
+  duration: 87600h0m0s
+  renewBefore: 87264h0m0s
+  issuerRef:
+    name: linkerd-trust-root-issuer
+    kind: ClusterIssuer
+  privateKey:
+    algorithm: ECDSA
+  secretName: linkerd-trust-anchor
+EOF
+```
+
+## Create Linkerd webhook issuer
+
+Using the previously-generated trust root certificate, create a separate
+`ClusterIssuer` for Linkerd webhook certificates:
+
+```bash
+kubectl apply -f - <<EOF
 apiVersion: cert-manager.io/v1
 kind: Issuer
 metadata:
-  name: webhook-issuer
-  namespace: linkerd-jaeger
+  name: linkerd-webhook-issuer
+  namespace: linkerd
 spec:
   ca:
-    secretName: webhook-issuer-tls
+    secretName: linkerd-trust-anchor
 EOF
 ```
 
 ## Issuing certificates and writing them to secrets
 
-Finally, we can create cert-manager "Certificate" resources which use the
-Issuers to generate the desired certificates:
+Finally, we can create cert-manager `Certificate` resources which use the
+issuers to generate the desired certificates:
 
 ```bash
 kubectl apply -f - <<EOF
@@ -124,7 +175,7 @@ spec:
   duration: 24h
   renewBefore: 1h
   issuerRef:
-    name: webhook-issuer
+    name: linkerd-webhook-issuer
     kind: Issuer
   commonName: linkerd-policy-validator.linkerd.svc
   dnsNames:
@@ -146,7 +197,7 @@ spec:
   duration: 24h
   renewBefore: 1h
   issuerRef:
-    name: webhook-issuer
+    name: linkerd-webhook-issuer
     kind: Issuer
   commonName: linkerd-proxy-injector.linkerd.svc
   dnsNames:
@@ -167,7 +218,7 @@ spec:
   duration: 24h
   renewBefore: 1h
   issuerRef:
-    name: webhook-issuer
+    name: linkerd-webhook-issuer
     kind: Issuer
   commonName: linkerd-sp-validator.linkerd.svc
   dnsNames:
@@ -177,88 +228,65 @@ spec:
     algorithm: ECDSA
   usages:
   - server auth
----
-# ignore if not using the viz extension
-apiVersion: cert-manager.io/v1
-kind: Certificate
-metadata:
-  name: tap
-  namespace: linkerd-viz
-spec:
-  secretName: tap-k8s-tls
-  duration: 24h
-  renewBefore: 1h
-  issuerRef:
-    name: webhook-issuer
-    kind: Issuer
-  commonName: tap.linkerd-viz.svc
-  dnsNames:
-  - tap.linkerd-viz.svc
-  isCA: false
-  privateKey:
-    algorithm: ECDSA
-  usages:
-  - server auth
----
-# ignore if not using the viz extension
-apiVersion: cert-manager.io/v1
-kind: Certificate
-metadata:
-  name: linkerd-tap-injector
-  namespace: linkerd-viz
-spec:
-  secretName: tap-injector-k8s-tls
-  duration: 24h
-  renewBefore: 1h
-  issuerRef:
-    name: webhook-issuer
-    kind: Issuer
-  commonName: tap-injector.linkerd-viz.svc
-  dnsNames:
-  - tap-injector.linkerd-viz.svc
-  isCA: false
-  privateKey:
-    algorithm: ECDSA
-  usages:
-  - server auth
----
-# ignore if not using the jaeger extension
-apiVersion: cert-manager.io/v1
-kind: Certificate
-metadata:
-  name: jaeger-injector
-  namespace: linkerd-jaeger
-spec:
-  secretName: jaeger-injector-k8s-tls
-  duration: 24h
-  renewBefore: 1h
-  issuerRef:
-    name: webhook-issuer
-    kind: Issuer
-  commonName: jaeger-injector.linkerd-jaeger.svc
-  dnsNames:
-  - jaeger-injector.linkerd-jaeger.svc
-  isCA: false
-  privateKey:
-    algorithm: ECDSA
-  usages:
-  - server auth
 EOF
 ```
 
-At this point, cert-manager can now use these Certificate resources to obtain
-TLS credentials, which are stored in the  `linkerd-proxy-injector-k8s-tls`,
-`linkerd-sp-validator-k8s-tls`, `tap-k8s-tls`, `tap-injector-k8s-tls` and
-`jaeger-injector-k8s-tls` secrets respectively.
+## Summary & Validation
+
+Below are the resources created for managing Linkerd webhook certificates with
+cert-manager:
+
+- Namespace: `linkerd` (to store certificates and secrets)
+- RBAC Permissions: ServiceAccount, Role, and RoleBinding in the `linkerd`
+  namespace for cert-manager
+- ClusterIssuer: `linkerd-trust-root-issuer` (self-signed ClusterIssuer)
+- Certificate: `linkerd-trust-anchor` (in the `linkerd` namespace, referencing
+  `linkerd-trust-root-issuer`)
+- Issuer: `linkerd-webhook-issuer` (to manage Linkerd webhook certificates)
+- Certificates & Secrets:
+  - `linkerd-policy-validator`: Policy validator certificate and secret
+  - `linkerd-proxy-injector`: Proxy injector certificate and secret
+  - `linkerd-sp-validator`: Service profile validator certificate and secret
+
+To validate creation and status, run the following commands:
+
+```bash
+# Check namespace creation
+kubectl get namespaces linkerd
+
+# Check RBAC permissions
+kubectl get serviceaccount,role,rolebinding -n linkerd
+
+# Check ClusterIssuer creation
+kubectl get clusterissuers linkerd-trust-root-issuer
+
+# Check Certificate creation
+kubectl get certificates -n linkerd
+
+# Check Issuer creation
+kubectl get issuers.cert-manager.io -n linkerd
+```
+
+## Consuming cert-manager webhook certificates
 
-Now we just need to inform Linkerd to consume these credentials.
+To have Linkerd consume cert-manager created certificates you will need to add
+the following to your values file or pass them in as flags at runtime.
+
+| Field                                 | Value                              |
+| ------------------------------------- | ---------------------------------- |
+| `proxyInjector.externalSecret`        | true                               |
+| `proxyInjector.injectCaFromSecret`    | "linkerd-proxy-injector-k8s-tls"   |
+| `policyValidator.externalSecret`      | true                               |
+| `policyValidator.injectCaFromSecret`  | "linkerd-policy-validator-k8s-tls" |
+| `profileValidator.externalSecret`     | true                               |
+| `profileValidator.injectCaFromSecret` | "linkerd-sp-validator-k8s-tls"     |
 
 ## Using these credentials with CLI installation
 
 To configure Linkerd to use the credentials from cert-manager rather than
 generating its own:
 
-```bash
+````bash
 # first, install the Linkerd CRDs
 linkerd install --crds | kubectl apply -f -
 
@@ -266,28 +294,13 @@ linkerd install --crds | kubectl apply -f -
 # from cert-manager
 linkerd install \
   --set policyValidator.externalSecret=true \
-  --set-file policyValidator.caBundle=ca.crt \
+  --set-file policyValidator.injectCaFromSecret=linkerd-policy-validator-k8s-tls \
   --set proxyInjector.externalSecret=true \
-  --set-file proxyInjector.caBundle=ca.crt \
+  --set-file proxyInjector.injectCaFromSecret=linkerd-proxy-injector-k8s-tls \
   --set profileValidator.externalSecret=true \
-  --set-file profileValidator.caBundle=ca.crt \
+  --set-file profileValidator.injectCaFromSecret=linkerd-sp-validator-k8s-tls \
   | kubectl apply -f -
 
-# ignore if not using the viz extension
-linkerd viz install \
-  --set tap.externalSecret=true \
-  --set-file tap.caBundle=ca.crt \
-  --set tapInjector.externalSecret=true \
-  --set-file tapInjector.caBundle=ca.crt \
-  | kubectl apply -f -
-
-# ignore if not using the jaeger extension
-linkerd jaeger install
-  --set webhook.externalSecret=true \
-  --set-file webhook.caBundle=ca.crt \
-  | kubectl apply -f -
-```
-
 ## Installing with Helm
 
 A similar pattern can be used with Helm:
@@ -304,37 +317,19 @@ helm install linkerd-control-plane \
   --set-file identity.issuer.tls.crtPEM=... \
   --set-file identity.issuer.tls.keyPEM=... \
   --set policyValidator.externalSecret=true \
-  --set-file policyValidator.caBundle=ca.crt \
+  --set-file policyValidator.injectCaFromSecret=linkerd-policy-validator-k8s-tls \
   --set proxyInjector.externalSecret=true \
-  --set-file proxyInjector.caBundle=ca.crt \
+  --set-file proxyInjector.injectCaFromSecret=linkerd-proxy-injector-k8s-tls \
   --set profileValidator.externalSecret=true \
-  --set-file profileValidator.caBundle=ca.crt \
+  --set-file profileValidator.injectCaFromSecret=linkerd-sp-validator-k8s-tls \
   linkerd/linkerd-control-plane \
   -n linkerd
+````
 
-# ignore if not using the viz extension
-helm install linkerd-viz \
-  --set tap.externalSecret=true \
-  --set-file tap.caBundle=ca.crt \
-  --set tapInjector.externalSecret=true \
-  --set-file tapInjector.caBundle=ca.crt \
-  linkerd/linkerd-viz \
-  -n linkerd-viz --create-namespace
-
-# ignore if not using the jaeger extension
-helm install linkerd-jaeger \
-  --set webhook.externalSecret=true \
-  --set-file webhook.caBundle=ca.crt \
-  linkerd/linkerd-jaeger \
-  -n linkerd-jaeger --create-namespace
-```
-
-{{< note >}}
-When installing the `linkerd-control-plane` chart, you _must_ provide the
-issuer trust root and issuer credentials as described in [Installing Linkerd
-with Helm](../install-helm/).
-{{< /note >}}
+{{< note >}} When installing the `linkerd-control-plane` chart, you _must_
+provide the issuer trust root and issuer credentials as described in
+[Installing Linkerd with Helm](../install-helm/). {{< /note >}}
 
-See [Automatically Rotating Control Plane TLS
-Credentials](../automatically-rotating-control-plane-tls-credentials/)
+See
+[Automatically Rotating Control Plane TLS Credentials](../automatically-rotating-control-plane-tls-credentials/)
 for details on how to do something similar for control plane credentials.

From 4d37a1d652e92042d2aa25117ac540096582321c Mon Sep 17 00:00:00 2001
From: Alen Haric <aharic88@gmail.com>
Date: Wed, 3 Apr 2024 13:58:26 -0400
Subject: [PATCH 2/3] fixed style recommendations

Signed-off-by: Alen Haric <aharic88@gmail.com>
---
 .../automatically-rotating-control-plane-tls-credentials.md   | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/linkerd.io/content/2.15/tasks/automatically-rotating-control-plane-tls-credentials.md b/linkerd.io/content/2.15/tasks/automatically-rotating-control-plane-tls-credentials.md
index fa8b52dc4c..7ce1dbade5 100644
--- a/linkerd.io/content/2.15/tasks/automatically-rotating-control-plane-tls-credentials.md
+++ b/linkerd.io/content/2.15/tasks/automatically-rotating-control-plane-tls-credentials.md
@@ -6,8 +6,8 @@ aliases = [ "use_external_certs" ]
 
 Linkerd's [automatic mTLS](../../features/automatic-mtls/) feature generates TLS
 certificates for proxies and automatically rotates them without user
-intervention. These certificates are derived from a _trust anchor_, which is
-shared across clusters, and an _issuer certificate_, which is specific to the
+intervention. These certificates are derived from a **trust anchor**, which is
+shared across clusters, and an **issuer certificate**, which is specific to the
 cluster.
 
 While Linkerd automatically rotates the per-proxy TLS certificates, it does not

From c0f7d3cea9a2d538613534af01de8af95cc446a5 Mon Sep 17 00:00:00 2001
From: Alen Haric <aharic88@gmail.com>
Date: Wed, 3 Apr 2024 14:09:50 -0400
Subject: [PATCH 3/3] fixing linter style conflicts

Signed-off-by: Alen Haric <aharic88@gmail.com>
---
 .../automatically-rotating-control-plane-tls-credentials.md   | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/linkerd.io/content/2.15/tasks/automatically-rotating-control-plane-tls-credentials.md b/linkerd.io/content/2.15/tasks/automatically-rotating-control-plane-tls-credentials.md
index 7ce1dbade5..4ba7f7d662 100644
--- a/linkerd.io/content/2.15/tasks/automatically-rotating-control-plane-tls-credentials.md
+++ b/linkerd.io/content/2.15/tasks/automatically-rotating-control-plane-tls-credentials.md
@@ -6,8 +6,8 @@ aliases = [ "use_external_certs" ]
 
 Linkerd's [automatic mTLS](../../features/automatic-mtls/) feature generates TLS
 certificates for proxies and automatically rotates them without user
-intervention. These certificates are derived from a **trust anchor**, which is
-shared across clusters, and an **issuer certificate**, which is specific to the
+intervention. These certificates are derived from a *trust anchor*, which is
+shared across clusters, and an *issuer certificate*, which is specific to the
 cluster.
 
 While Linkerd automatically rotates the per-proxy TLS certificates, it does not