chore: spelling

Signed-off-by: Peter Fiddes <[email protected]>

.spelling

@@ -624,6 +624,7 @@ Rollout
 rollout
 JKS-formatted
 changeit
+walkthrough
 
 # TEMPORARY
 # these are temporarily ignored because the spellchecker

content/docs/tutorials/certificate-defaults/README.md

@@ -6,13 +6,13 @@ values to Certificate resources without enforcing them.
 
 *Last Verified: 08 September 2023*
 
-There has been a long standing [issue](https://github.com/cert-manager/cert-manager/issues/2239) in [cert-manager](https://cert-manager.io/) about how to set default valueson Certificate resources, also known in the issue as presets. In this tutorial we will walk through using [Kyverno](https://kyverno.io/), an open source policy tool to help us setup some useful defaults for our user's Certificates. 
+There has been a long standing [issue](https://github.com/cert-manager/cert-manager/issues/2239) in [cert-manager](https://cert-manager.io/) about how to set default values on Certificate resources, also known in the issue as presets. In this tutorial we will walk through using [Kyverno](https://kyverno.io/), an open source policy tool to help us setup some useful defaults for our user's Certificates. 
 
-**Objective**: The end goal here is that a user specifies as little as posible in the `Certificate` resource, and they have all the default values automatically applied.
+**Objective**: The end goal here is that a user specifies as little as possible in the `Certificate` resource, and they have all the default values automatically applied.
 
 There are some other good reasons you might want to do this:
 
-- Defaults allow users to benefit from not having to set config options, minimising their YAML resource.
+- Defaults allow users to benefit from not having to set config options, minimizing their YAML resource.
 - Defaults allow users to override for their use case when needed.
 - Defaults allow cluster operators to decide what the default should be, rather than having to rely on an in-built default from cert-manager
 
@@ -27,7 +27,7 @@ command-line tool which allows you to configure Kubernetes clusters.
 1. [helm](https://helm.sh/): A package manager for Kubernetes.
 1. [yq](https://github.com/mikefarah/yq#install): A command line tool for
 parsing YAML with helpful coloring.
-1. [kind](https://kind.sigs.k8s.io/) (**OPTIONAL**): For creating a local kubernetes environment that runs in docker or other container runtime.
+1. [kind](https://kind.sigs.k8s.io/) (**OPTIONAL**): For creating a local Kubernetes environment that runs in docker or other container runtime.
 
 ## Setup
 
@@ -61,7 +61,7 @@ We are going to look only at setting fields inside the `Certificate` specificati
 
 We will setup some `ClusterPolicy` resources and `Certificate` resources in this guide. We will make reference to a `ClusterIssuer` in the `Certificate` spec that doesn't exist, but for this tutorial the issuer is not required as we won't actually be requesting certificates. That means anyone can walk through this guide even without their own domain.
 
-### Optionl field defaults
+### Optional field defaults
 
 Lets set some simple fields, fields that you might find you either don't know to set or aren't really concerned about the consequences of setting them. So we will do this following "defaulting":
 
@@ -193,7 +193,7 @@ Lets set some simple fields, fields that you might find you either don't know to
       secretName: test-revision-cert
     ```
 
-1. We have successfully defaulted the `privateKey` and `revisionHistoryLimit` fields. Let's actualy override all of these to validate that we can still set what we want as an end user. Here is a new `Certificate` resource to use fro testing called "test-revision-override":
+1. We have successfully defaulted the `privateKey` and `revisionHistoryLimit` fields. Let's actually override all of these to validate that we can still set what we want as an end user. Here is a new `Certificate` resource to use fro testing called "test-revision-override":
 
     ```yaml
     apiVersion: cert-manager.io/v1
@@ -255,13 +255,13 @@ Lets set some simple fields, fields that you might find you either don't know to
 
 ### Required field defaults
 
-This section is a little more nuanced and requires a minor tweak to the default cert-manager installtion to work. When a `Certificate` resource is applied to a Kubernetes cluster, mutating webhooks are applied before validating webhooks. When the existing cert-manager mutating webhook runs, if there is no value in a required field, it will add the required field with an empty value such as: `secretName: ""`. The consequence of this action is that our Kyverno policy will not apply as an empty value is already present.
+This section is a little more nuanced and requires a minor tweak to the default cert-manager installation to work. When a `Certificate` resource is applied to a Kubernetes cluster, mutating webhooks are applied before validating webhooks. When the existing cert-manager mutating webhook runs, if there is no value in a required field, it will add the required field with an empty value such as: `secretName: ""`. The consequence of this action is that our Kyverno policy will not apply as an empty value is already present.
 
 There are some potential fixes for this issue:
 
-1. Rename the cert-manager-webook mutating and validating webhooks with `z-<existing_name>` so that they execute last, after the Kyverno webhooks.
+1. Rename the "cert-manager-webook" mutating and validating webhooks with `z-<existing_name>` so that they execute last, after the Kyverno webhooks.
 
-1. We fix cert-manage mutatingwebhookconfiguration to not mess with `Certificate` resource as in [this PR](https://github.com/cert-manager/cert-manager/pull/6311).
+1. We fix cert-manager "mutatingwebhookconfiguration" to not mess with `Certificate` resource as in [this PR](https://github.com/cert-manager/cert-manager/pull/6311).
 
 1. You use enforcement in your policy to explicitly override the value regardless of what the user sets.
 
@@ -477,7 +477,7 @@ Now we can set a Kyverno `ClusterPolicy` to apply default values any of the `Cer
 
 ## Summary
 
-This is a fairly simple example of how easy it can be to setup *defaults* or *presets* for your cluster `Certificates`. We've shown how policy doesn't have to mean "enforce", and that you can allow your cluster's users to reduce thir YAML whilst maintaining the flexibility to override any value in specific use cases. You may have noticed that in the second policy we actually used some `Certificate` resource metadata to create the `secretName` field. You read more about this on the [Kyverno documentation](yamls/cert-test-revision-override.yaml). Perhaps you also noticed just how minimal we made the `Certificate` resource towards the end, supplying only a `dnsName` entry. That was exactly our goal for this tutorial.
+This is a fairly simple example of how easy it can be to setup *defaults* or *presets* for your cluster `Certificates`. We've shown how policy doesn't have to mean "enforce", and that you can allow your cluster's users to reduce their YAML whilst maintaining the flexibility to override any value in specific use cases. You may have noticed that in the second policy we actually used some `Certificate` resource metadata to create the `secretName` field. You read more about this on the [Kyverno documentation](yamls/cert-test-revision-override.yaml). Perhaps you also noticed just how minimal we made the `Certificate` resource towards the end, supplying only a `dnsName` entry. That was exactly our goal for this tutorial.
 
 ### Reference links