chore: Fix Markdown spelling issues found by codespell (#5139)

See,

```
codespell  $(find . -type f -name '*.md')
```

Signed-off-by: Mario Trangoni <mjtrangoni@gmail.com>
Co-authored-by: Gergely Brautigam <skarlso777@gmail.com>

DEPRECATING.md

@@ -73,7 +73,7 @@ Any maintainer may propose deprecating a feature, component, or behavior (both i
 
 The proposal must clearly outline the rationale for deprecation, the impact on users, and any alternatives, if such.
 
-The proposal must be formalized by submiting a `design` document as a Pull Request.
+The proposal must be formalized by submitting a `design` document as a Pull Request.
 
 ### Showcase to Maintainers
 

deploy/charts/external-secrets/README.md

@@ -52,7 +52,7 @@ The command removes all the Kubernetes components associated with the chart and
 | certController.image.repository | string | `"oci.external-secrets.io/external-secrets/external-secrets"` |  |
 | certController.image.tag | string | `""` |  |
 | certController.imagePullSecrets | list | `[]` |  |
-| certController.log | object | `{"level":"info","timeEncoding":"epoch"}` | Specifices Log Params to the Certificate Controller |
+| certController.log | object | `{"level":"info","timeEncoding":"epoch"}` | Specifies Log Params to the Certificate Controller |
 | certController.metrics.listen.port | int | `8080` |  |
 | certController.metrics.service.annotations | object | `{}` | Additional service annotations |
 | certController.metrics.service.enabled | bool | `false` | Enable if you use another monitoring tool than Prometheus to scrape the metrics |
@@ -126,7 +126,7 @@ The command removes all the Kubernetes components associated with the chart and
 | imagePullSecrets | list | `[]` |  |
 | installCRDs | bool | `true` | If set, install and upgrade CRDs through helm chart. |
 | leaderElect | bool | `false` | If true, external-secrets will perform leader election between instances to ensure no more than one instance of external-secrets operates at a time. |
-| log | object | `{"level":"info","timeEncoding":"epoch"}` | Specifices Log Params to the External Secrets Operator |
+| log | object | `{"level":"info","timeEncoding":"epoch"}` | Specifies Log Params to the External Secrets Operator |
 | metrics.listen.port | int | `8080` |  |
 | metrics.service.annotations | object | `{}` | Additional service annotations |
 | metrics.service.enabled | bool | `false` | Enable if you use another monitoring tool than Prometheus to scrape the metrics |
@@ -181,7 +181,7 @@ The command removes all the Kubernetes components associated with the chart and
 | topologySpreadConstraints | list | `[]` |  |
 | webhook.affinity | object | `{}` |  |
 | webhook.annotations | object | `{}` | Annotations to place on validating webhook configuration. |
-| webhook.certCheckInterval | string | `"5m"` | Specifices the time to check if the cert is valid |
+| webhook.certCheckInterval | string | `"5m"` | Specifies the time to check if the cert is valid |
 | webhook.certDir | string | `"/tmp/certs"` |  |
 | webhook.certManager.addInjectorAnnotations | bool | `true` | Automatically add the cert-manager.io/inject-ca-from annotation to the webhooks and CRDs. As long as you have the cert-manager CA Injector enabled, this will automatically setup your webhook's CA to the one used by cert-manager. See https://cert-manager.io/docs/concepts/ca-injector |
 | webhook.certManager.cert.annotations | object | `{}` | Add extra annotations to the Certificate resource. |
@@ -206,8 +206,8 @@ The command removes all the Kubernetes components associated with the chart and
 | webhook.image.repository | string | `"oci.external-secrets.io/external-secrets/external-secrets"` |  |
 | webhook.image.tag | string | `""` | The image tag to use. The default is the chart appVersion. |
 | webhook.imagePullSecrets | list | `[]` |  |
-| webhook.log | object | `{"level":"info","timeEncoding":"epoch"}` | Specifices Log Params to the Webhook |
-| webhook.lookaheadInterval | string | `""` | Specifices the lookaheadInterval for certificate validity |
+| webhook.log | object | `{"level":"info","timeEncoding":"epoch"}` | Specifies Log Params to the Webhook |
+| webhook.lookaheadInterval | string | `""` | Specifies the lookaheadInterval for certificate validity |
 | webhook.metrics.listen.port | int | `8080` |  |
 | webhook.metrics.service.annotations | object | `{}` | Additional service annotations |
 | webhook.metrics.service.enabled | bool | `false` | Enable if you use another monitoring tool than Prometheus to scrape the metrics |

deploy/charts/external-secrets/values.yaml

@@ -100,7 +100,7 @@ createOperator: true
 # -- Specifies the number of concurrent ExternalSecret Reconciles external-secret executes at
 # a time.
 concurrent: 1
-# -- Specifices Log Params to the External Secrets Operator
+# -- Specifies Log Params to the External Secrets Operator
 log:
   level: info
   timeEncoding: epoch
@@ -283,12 +283,12 @@ webhook:
   annotations: {}
   # -- Specifies whether a webhook deployment be created. If set to false, crds.conversion.enabled should also be set to false otherwise the kubeapi will be hammered because the conversion is looking for a webhook endpoint.
   create: true
-  # -- Specifices the time to check if the cert is valid
+  # -- Specifies the time to check if the cert is valid
   certCheckInterval: "5m"
-  # -- Specifices the lookaheadInterval for certificate validity
+  # -- Specifies the lookaheadInterval for certificate validity
   lookaheadInterval: ""
   replicaCount: 1
-  # -- Specifices Log Params to the Webhook
+  # -- Specifies Log Params to the Webhook
   log:
     level: info
     timeEncoding: epoch
@@ -476,7 +476,7 @@ certController:
   create: true
   requeueInterval: "5m"
   replicaCount: 1
-  # -- Specifices Log Params to the Certificate Controller
+  # -- Specifies Log Params to the Certificate Controller
   log:
     level: info
     timeEncoding: epoch

design/001-design-crd-v1beta1.md

@@ -38,7 +38,7 @@ This design documentation aims to capture some final changes for ExternalSecrets
 ### Goals
 
 - Define a beta CRD
-- Define strucutre for getting all provider secrets
+- Define structure for getting all provider secrets
 - Define structure for new templating engine
 ### Non-Goals
 
@@ -96,7 +96,7 @@ spec:
       data:
         config.yml: |
           endpoints:
-          - https://{{ .data.user }}:{{ .data.password }}@api.exmaple.com
+          - https://{{ .data.user }}:{{ .data.password }}@api.example.com
 
       templateFrom:
       - configMap:
@@ -208,4 +208,4 @@ status:
     reason: "ConfigError"
     message: "SecretStore validation failed"
     lastTransitionTime: "2019-08-12T12:33:02Z"
-```
+```

design/002-pushsecret.md

@@ -165,7 +165,7 @@ status:
 ```
 
 ### Behavior
-When checking PushSecret for the Source Secret, check existing labels for SecretStore reference of that particular Secret. If this SecretStore reference is an object in PushSecret SecretStore lists, a SecretSyncError should be emited as we cannot sync the secret to the same SecretStore.
+When checking PushSecret for the Source Secret, check existing labels for SecretStore reference of that particular Secret. If this SecretStore reference is an object in PushSecret SecretStore lists, a SecretSyncError should be emitted as we cannot sync the secret to the same SecretStore.
 
 If the SecretStores are all fine or if the Secret has no labels (secret created by user / another tool), for Each SecretStore, get the SyncState of this store (New, SecretSynced, SecretSyncedErr).
 

design/004-datafrom-key-rewrite.md

@@ -154,7 +154,7 @@ After applying `GetAllSecrets` or `GetSecretMap`, a rewrite logic is applied by
 
 It would not be trivial to replace a specific set of existing characters for new characters with this strategy. This could be implemented with a `replace` method afterwards.
 
-There are also some known limitations to golang regexp library, which implementes RE2. Some of the known limitations include:
+There are also some known limitations to golang regexp library, which implements RE2. Some of the known limitations include:
 * Lack of ability to do lookaheads or lookbehinds
 * Lack of negation expressions
 * Lack of support to conditionl branches.
@@ -169,4 +169,4 @@ A list of compatibility and known limitations considering other commonly used re
 + It should be possible to remove paths with the `rewrite` operation.
 
 ## Alternatives
-Add provider-specific ConversionStrategies, which would be painfully hard to maintain.
+Add provider-specific ConversionStrategies, which would be painfully hard to maintain.

design/005-secret-generator-group.md

@@ -94,7 +94,7 @@ spec:
 
 #### `SecretStoreRef` vs. `SourceRef`
 
-In order to accomodate the generator implementation we need to enhance the `spec.secretStoreRef` functionality
+In order to accommodate the generator implementation we need to enhance the `spec.secretStoreRef` functionality
 and add `data[].sourceRef` and `dataFrom[].sourceRef` that allows a user to reference generator resources.
 This allows us to:
 
@@ -264,7 +264,7 @@ Cons:
 
 #### (2) with an intermediate GenerateRequest
 
-This is very similar to [cert-manager's external issuer API](https://cert-manager.io/docs/contributing/external-issuers/) that allows users to implement their own controller to issue certifiates.
+This is very similar to [cert-manager's external issuer API](https://cert-manager.io/docs/contributing/external-issuers/) that allows users to implement their own controller to issue certificates.
 We maintain some core generator controllers and leave the implementation of others up to the user.
 
 ```

design/006-LTS-release.md

@@ -24,7 +24,7 @@ will build and push the artifact to ghcr.
 
 Bug Fixes will be merged onto each release branch individually.
 This is achieved by creating separate PRs from a corresponding branch of the release
-(e.g. bug fixes targetting `release-1.0` should be created from `release-1.0` branch).
+(e.g. bug fixes targeting `release-1.0` should be created from `release-1.0` branch).
 Once approved and merged into `main` or `release-x.y`, ou build pipeline will build and push the artifact to ghcr
 
 ## Process

design/010-pushsecret-metadata.md

@@ -150,7 +150,7 @@ spec:
 
 **PROS**
 - familiar structure for Kubernetes users, other projectes use that pattern already
-- we may be able to re-use existing tooling, e.g. for validating the structure and generating documentation
+- we may be able to reuse existing tooling, e.g. for validating the structure and generating documentation
 
 **CONS**
 - may confuse users if they encounter a nested custom resource
@@ -196,4 +196,4 @@ spec:
 - more concise, less boilerplate
 
 **CONS**
-- no ability to directly re-use existing tooling
+- no ability to directly reuse existing tooling

design/011-deprecate-olm.md

@@ -15,8 +15,9 @@ This Proposal was approved on community meeting of 4th december 2024 (meeting no
 As part of our Release process, we currently build & maintain several docker images, helm releases, bundle manifests for users, and OLM builds via a community effort based on olm helm operator.
 
 However, OLM helm operator itself would require a better support and constant maintenance, and its process when building OLM builds is already not automated anymore.
+
 ## Summary
-Stpo building OLM Releases
+Stop building OLM Releases
 
 ## Motivation
 Make maintenance lives easier for a project that is struggling to get maintainers together :)
@@ -37,7 +38,7 @@ None
 Users might complain - but then they can fork the archived repository to build their own OLM builds locally.
 
 ## Alternatives
-Find community members to handle the maintanence aspect of it. Have a new dedicated OLM repository in/out of the org. Make this be maintained by other parties than external-secrets maintainers.
+Find community members to handle the maintenance aspect of it. Have a new dedicated OLM repository in/out of the org. Make this be maintained by other parties than external-secrets maintainers.
 
 Do not use the current olm helm operator anymore as anyways this is not really supported.
 

design/012-sync-to-custom-resource.md

@@ -96,7 +96,7 @@ Only one `templateFrom` entry can be set if its type is `target: Manifest`.
   * `creationPolicy`, `updatePolicy`, and `deletionPolicy` must be compatible when `target != Secret`
   * One of the two must be implemented:
     * a feature flag `--unsafe-allow-non-secret-targets` must be set to allow this feature. If not set, `template.manifest` should cause error to the reconciliation.
-    * Feature is always eniabled - but Warnings must be emited whenever `target.manifest` is used pointing to the use of sensitive information on open manifests.
+    * Feature is always enabled - but Warnings must be emitted whenever `target.manifest` is used pointing to the use of sensitive information on open manifests.
       * Warnings should be disabled with feature flags
 * deployment:
   * Extra RBAC options must be available on helm values (to allow the usage of this feature)

design/design-crd-spec.md

@@ -165,7 +165,7 @@ spec:
       data:
         config.yml: |
           endpoints:
-          - https://{{ .data.user }}:{{ .data.password }}@api.exmaple.com
+          - https://{{ .data.user }}:{{ .data.password }}@api.example.com
 
       # Uses an existing template from configmap
       # Secret is fetched, merged and templated within the referenced configMap data

docs/api/components.md

@@ -7,7 +7,7 @@ hide:
 
 ## Overview
 
-Exernal Secrets comes with three components: `Core Controller`, `Webhook` and `Cert Controller`.
+External Secrets comes with three components: `Core Controller`, `Webhook` and `Cert Controller`.
 
 This is due to the need to implement conversion webhooks in order to convert custom resources between api versions and
 to provide a ValidatingWebhook for the `ExternalSecret` and `SecretStore` resources.

docs/api/controller-options.md

@@ -37,7 +37,7 @@ The core controller is invoked without a subcommand and can be configured with t
 
 ## Cert Controller Flags
 
-| Name                       | Type     | Default                  | Descripton                                                                                                            |
+| Name                       | Type     | Default                  | Description                                                                                                            |
 | -------------------------- | -------- | ------------------------ | --------------------------------------------------------------------------------------------------------------------- |
 | `--crd-requeue-interval`   | duration | 5m0s                     | Time duration between reconciling CRDs for new certs                                                                  |
 | `--enable-leader-election` | boolean  | false                    | Enable leader election for controller manager. Enabling this will ensure there is only one active controller manager. |

docs/api/generator/mfa.md

@@ -38,4 +38,4 @@ timeLeft: 25
 
 !!! warning "Usage of the token might fail on first try if it JUST expired"
 It is possible that from requesting the token to actually using it, the token might be already out of date if timeLeft was
-very low to begin with. Therefor, the code that uses this token should allow for retries with new tokens.
+very low to begin with. Therefore, the code that uses this token should allow for retries with new tokens.

docs/api/metrics.md

@@ -103,7 +103,7 @@ histogram_quantile(0.99,
 ```
 
 #### Controller Reconcile Error
-The controller should be able to reconcile resources without errors. When errors occurr secret delivery may be impacted which could cascade down to the secret consuming applications.
+The controller should be able to reconcile resources without errors. When errors occur secret delivery may be impacted which could cascade down to the secret consuming applications.
 
 ```
 sum(increase(

docs/contributing/release.md

@@ -20,7 +20,7 @@ Otherwise the `latest` documentation will point to the older version. Also avoid
 1. Update `version` and/or `appVersion` in `Chart.yaml` and run `make helm.docs helm.update.appversion helm.test.update helm.test`
 1. push to branch and open pr
 1. run `/ok-to-test-managed` commands for all cloud providers
-1. merge PR if everyhing is green
+1. merge PR if everything is green
 1. CI picks up the new chart version and creates a new GitHub Release for it
 1. create/merge into release branch
     1. on a `minor` release: create a new branch `release-x.y`

docs/eso-blogs.md

@@ -25,7 +25,7 @@ set up a local environment with Docker Desktop and how to deploy ESO and Conjur
 
 ## [Tutorial: Getting Started with External Secrets Operator on Kubernetes using AWS Secrets Manager](https://ptuladhar3.medium.com/getting-started-with-external-secrets-operator-on-kubernetes-using-aws-secrets-manager-6dc403d9630c)
 
-Puru writes about getting started using ESO with AWS Secrets Manager. He uses illustrations to explain ESO to new users and get's you to quickly start using ESO, as article is easy to follow along. [Getting Started with External Secrets Operator on Kubernetes using AWS Secrets Manager](https://ptuladhar3.medium.com/getting-started-with-external-secrets-operator-on-kubernetes-using-aws-secrets-manager-6dc403d9630c)
+Puru writes about getting started using ESO with AWS Secrets Manager. He uses illustrations to explain ESO to new users and gets you to quickly start using ESO, as article is easy to follow along. [Getting Started with External Secrets Operator on Kubernetes using AWS Secrets Manager](https://ptuladhar3.medium.com/getting-started-with-external-secrets-operator-on-kubernetes-using-aws-secrets-manager-6dc403d9630c)
 
 ## [Tutorial: How to Set External-Secrets with Azure KeyVault](https://blog.container-solutions.com/tutorial-external-secrets-with-azure-keyvault)
 
@@ -75,7 +75,7 @@ Emin writes about the Push Secret feature of ESO and how this new feature revers
 
 ## [GCP Secret Manager with self-hosted Kubernetes](https://medium.com/@jjlakis/gcp-secret-manager-with-self-hosted-kubernetes-db35d01d65f0)
 
-Jacek writes about bringing GCP secrets to on-premises cluster through External Secrets Operator intergration with workload identity.
+Jacek writes about bringing GCP secrets to on-premises cluster through External Secrets Operator integration with workload identity.
 
 ## [Injecting AWS Secrets in a Kubernetes Cluster with External Secrets Operator](https://blog.devops.dev/injecting-external-secrets-in-a-kubernetes-cluster-1e9bbe0f0d5b)
 

docs/guides/all-keys-one-secret.md

@@ -9,7 +9,7 @@ Then create a secret in Google Cloud Secret Manager that contains a JSON string
 ![secret-value](../pictures/screenshot_json_string_gcp_secret_value.png)
 
 Let's call this secret all-keys-example-secret on Google Cloud.
- 
+
 
 ### Creating dataFrom external secret
 
@@ -18,19 +18,19 @@ Now, when creating our ExternalSecret resource, instead of using the data field,
 ```yaml
 {% include 'gcpsm-data-from-external-secret.yaml' %}
 ```
-Here, "example" is the name of the external secret that will be created in our cluster.    
-Whereas, "secret-to-be-created" is the name of Kubernetes secrets that will be created.    
-Note: Since these secrets are namespace-based resources, you can also explicitly specify the "namespace" under the "metadata" block of the above external secret file.    
-when we use, 
+Here, "example" is the name of the external secret that will be created in our cluster.
+Whereas, "secret-to-be-created" is the name of Kubernetes secrets that will be created.
+Note: Since these secrets are namespace-based resources, you can also explicitly specify the "namespace" under the "metadata" block of the above external secret file.
+when we use,
 
 ```
   dataFrom:
   - extract:
       key: all-keys-example-secret
 ```
-We get all the key-value pairs present over the remote secret store (GCP or AWS or Azure) and can pass either all or a few key-values as environment variables.    
-Please note that, "all-keys-example-secret" is the name of your secret present on GCP/AWS secrets manager/Azure    
-    
+We get all the key-value pairs present over the remote secret store (GCP or AWS or Azure) and can pass either all or a few key-values as environment variables.
+Please note that, "all-keys-example-secret" is the name of your secret present on GCP/AWS secrets manager/Azure
+
 We can pass a few secrets as env variables as below:
 ```
         env:
@@ -46,18 +46,18 @@ We can pass a few secrets as env variables as below:
                 name: secret-to-be-created
                 key: surname
 ```
- 
-Here,    
-\<key1\> and \<key2> are the names of keys that will be created and passed as env variables.    
-\<secret-to-be-created\>: is the name of your Kubernetes secret created by you.    
-\<username\> and \<surname>: is the particular key in the secrets manager whose value you want to pass.    
+
+Here,
+\<key1\> and \<key2> are the names of keys that will be created and passed as env variables.
+\<secret-to-be-created\>: is the name of your Kubernetes secret created by you.
+\<username\> and \<surname>: is the particular key in the secrets manager whose value you want to pass.
 To check both values we can run:
 ```
 kubectl get secret secret-to-be-created -n <namespace> -o jsonpath='{.data.username}' | base64 -d
 kubectl get secret secret-to-be-created -n <namespace> -o jsonpath='{.data.surname}' | base64 -d
 ```
 
-Also, if you have a large number of secrets and you want to pass all of them as enviromnent variables, then either you can replicate the above steps in your deployment file for all the keys or you can use the envFrom block as below:    
+Also, if you have a large number of secrets and you want to pass all of them as environment variables, then either you can replicate the above steps in your deployment file for all the keys or you can use the envFrom block as below:
 
 ```
     spec:

docs/guides/generator.md

@@ -6,7 +6,7 @@ These values can be used with the other features like `rewrite` or `template`. I
 
 ## Reference Custom Resource
 
-Generators can be defined as a custom resource and re-used across different ExternalSecrets. **Every invocation creates a new set of values**. I.e. you can not share the same value produced by a generator across different `ExternalSecrets` or `spec.dataFrom[]` entries.
+Generators can be defined as a custom resource and reused across different ExternalSecrets. **Every invocation creates a new set of values**. I.e. you can not share the same value produced by a generator across different `ExternalSecrets` or `spec.dataFrom[]` entries.
 
 ```yaml
 apiVersion: external-secrets.io/v1

docs/guides/getallsecrets.md

@@ -36,7 +36,7 @@ By default, kubernetes Secrets accepts only a given range of characters. `Find`
 
 If you happen to have a case where a conflict is happening, you can use the `rewrite` block to apply a regexp on one of the find operations (for more information please refer to [Rewriting Keys from DataFrom](datafrom-rewrite.md)).
 
-You can also set  `dataFrom.find.conversionStrategy: Unicode` to reduce the collistion probability. When using `Unicode`, any invalid character will be replaced by its unicode, in the form of `_UXXXX_`. In this case, the available kubernetes keys would be `a_c` and `a_U2215_c`, hence avoiding most of possible conflicts.
+You can also set  `dataFrom.find.conversionStrategy: Unicode` to reduce the collision probability. When using `Unicode`, any invalid character will be replaced by its unicode, in the form of `_UXXXX_`. In this case, the available kubernetes keys would be `a_c` and `a_U2215_c`, hence avoiding most of possible conflicts.
 
 
 

docs/guides/templating.md

@@ -130,7 +130,7 @@ You can achieve that by using the `filterPEM` function to extract a specific typ
 {% include 'filterpem-template-v2-external-secret.yaml' %}
 ```
 
-In case you have a secret that contains a (partial) certificate chain you can extract the `leaf`, `intermediate` or `root` certificate(s) using the `filterCertChain` function. See the following example on how to use the `filterPEM` and `filterCertChain` functions together to split the certificate chain into a `tls.crt` part only containting the leaf certificate and a `ca.crt` part with all the intermediate certificates.
+In case you have a secret that contains a (partial) certificate chain you can extract the `leaf`, `intermediate` or `root` certificate(s) using the `filterCertChain` function. See the following example on how to use the `filterPEM` and `filterCertChain` functions together to split the certificate chain into a `tls.crt` part only containing the leaf certificate and a `ca.crt` part with all the intermediate certificates.
 
 ```yaml
 {% include 'filtercertchain-template-v2-external-secret.yaml' %}

docs/guides/using-esoctl-tool.md

@@ -33,7 +33,7 @@ And secret data is:
 token: dG9rZW4=
 ```
 
-Therefor if there is a PushSecret or an ExternalSecret object that the user would like to test the template for,
+Therefore if there is a PushSecret or an ExternalSecret object that the user would like to test the template for,
 simply put it into a file along with the data it's using, and run this command.
 
 The output will be something like this:

docs/provider/1password-automation.md

@@ -28,7 +28,7 @@ _**The 1Password API calls the entries in vaults 'Items'. These docs use the sam
 * Ordered vaults
     * Specify an ordered list of vaults in a SecretStore and the value will be sourced from the first vault with a matching Item.
     * If no matching Item is found, an error is returned.
-    * This supports having a default or shared set of values that can also be overriden for specific environments.
+    * This supports having a default or shared set of values that can also be overridden for specific environments.
 * `dataFrom`:
     * `find.path` is equated to Item Title.
     * `find.name.regexp` is equated to field Labels.

docs/provider/hashicorp-vault.md

@@ -293,7 +293,7 @@ A static token is stored in a `Kind=Secret` and is used to authenticate with vau
 #### AppRole authentication example
 
 [AppRole authentication](https://www.vaultproject.io/docs/auth/approle) reads the secret id from a
-`Kind=Secret` and uses the specified `roleId` to aquire a temporary token to fetch secrets.
+`Kind=Secret` and uses the specified `roleId` to acquire a temporary token to fetch secrets.
 
 ```yaml
 {% include 'vault-approle-store.yaml' %}

docs/provider/openbao.md

@@ -4,4 +4,4 @@ External Secrets Operator integrates with [OpenBao](https://openbao.org) for sec
 
 The integration was tested with [External Secrets Operator v0.16.1](https://github.com/external-secrets/external-secrets/releases/tag/v0.16.1) and [OpenBao v2.2.0](https://github.com/openbao/openbao/releases/tag/v2.2.0)
 
-Please refer to the [HashiCorp Vault Provider](./hashicorp-vault.md) documentation for further informations.
+Please refer to the [HashiCorp Vault Provider](./hashicorp-vault.md) documentation for further information.

docs/provider/oracle-vault.md

@@ -29,7 +29,7 @@ Select tenancy in the top right to see your tenancy OCID as shown below.
 Select your user in the top right to see your user OCID as shown below.
 ![region-details](../pictures/screenshot_user_OCID.png)
 
-Your fingerprint will be attatched to your API key, once it has been generated. Private keys can be created or uploaded on the same page as the your user OCID.
+Your fingerprint will be attached to your API key, once it has been generated. Private keys can be created or uploaded on the same page as the your user OCID.
 ![fingerprint-details](../pictures/screenshot_fingerprint.png)
 
 Once you click "Add API Key" you will be shown the following, where you can download the key in the necessary PEM format for API requests. Creating a private key will automatically generate a fingerprint.
@@ -90,7 +90,7 @@ kubectl get secret oracle-secret-to-create -o jsonpath='{.data.dev-secret-test}'
 
 ## PushSecrets and retrieving multiple secrets.
 When using [PushSecrets](https://external-secrets.io/latest/guides/pushsecrets/), the compartment OCID and encryption key OCID must be specified in the
-Oracle SecretStore. You can find your compartment and encrpytion key OCIDs in the OCI console.
+Oracle SecretStore. You can find your compartment and encryption key OCIDs in the OCI console.
 
 If [retrieving multiple secrets](https://external-secrets.io/latest/guides/getallsecrets/) by tag or regex, only the compartment OCID must be specified.