From b3d333b67a295c7c8acc42c7391d4d7a8438413b Mon Sep 17 00:00:00 2001
From: Mark Lewis <56076038+ml4@users.noreply.github.com>
Date: Fri, 31 Mar 2023 00:42:25 +0100
Subject: [PATCH] Update kubernetes.mdx (#19567)

Correct 2 typos
---
 website/content/docs/secrets/kubernetes.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/content/docs/secrets/kubernetes.mdx b/website/content/docs/secrets/kubernetes.mdx
index 049fd032213d..345485cac855 100644
--- a/website/content/docs/secrets/kubernetes.mdx
+++ b/website/content/docs/secrets/kubernetes.mdx
@@ -39,7 +39,7 @@ management tool.
 
    It's necessary to ensure that the service account Vault uses will have permissions to manage
    service account tokens, and optionally manage service accounts, roles, and role bindings. These
-   permissions can be managed using a Kuberentes role or cluster role. The role is attached to the
+   permissions can be managed using a Kubernetes role or cluster role. The role is attached to the
    Vault service account with a role binding or cluster role binding.
 
    For example, a minimal cluster role to create service account tokens is:
@@ -321,7 +321,7 @@ $ vault write kubernetes/roles/auto-managed-sa-role \
 
 ~> **Note**: Vault's service account will also need access to the resources it is granting
 access to. This can be done for the examples above with `kubectl -n test create rolebinding --role test-role-list-pods --serviceaccount=vault:vault vault-test-role-abilities`.
-This is how Kuberentes prevents privilege escalation.
+This is how Kubernetes prevents privilege escalation.
 You can read more in the
 [Kubernetes RBAC documentation](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping).