Merge pull request #29154 from cslauritsen/patch-1

mark adjectival phrases with hyphens

content/en/docs/tasks/administer-cluster/securing-a-cluster.md

@@ -26,7 +26,7 @@ and provides recommendations on overall security.
 
 ## Controlling access to the Kubernetes API
 
-As Kubernetes is entirely API driven, controlling and limiting who can access the cluster and what actions
+As Kubernetes is entirely API-driven, controlling and limiting who can access the cluster and what actions
 they are allowed to perform is the first line of defense.
 
 ### Use Transport Layer Security (TLS) for all API traffic
@@ -40,7 +40,7 @@ potentially unsecured traffic.
 ### API Authentication
 
 Choose an authentication mechanism for the API servers to use that matches the common access patterns
-when you install a cluster. For instance, small single user clusters may wish to use a simple certificate
+when you install a cluster. For instance, small, single-user clusters may wish to use a simple certificate
 or static Bearer token approach. Larger clusters may wish to integrate an existing OIDC or LDAP server that
 allow users to be subdivided into groups.
 
@@ -54,7 +54,7 @@ Consult the [authentication reference document](/docs/reference/access-authn-aut
 Once authenticated, every API call is also expected to pass an authorization check. Kubernetes ships
 an integrated [Role-Based Access Control (RBAC)](/docs/reference/access-authn-authz/rbac/) component that matches an incoming user or group to a
 set of permissions bundled into roles. These permissions combine verbs (get, create, delete) with
-resources (pods, services, nodes) and can be namespace or cluster scoped. A set of out of the box
+resources (pods, services, nodes) and can be namespace-scoped or cluster-scoped. A set of out-of-the-box
 roles are provided that offer reasonable default separation of responsibility depending on what
 actions a client might want to perform. It is recommended that you use the
 [Node](/docs/reference/access-authn-authz/node/) and
@@ -69,8 +69,8 @@ With authorization, it is important to understand how updates on one object may
 other places. For instance, a user may not be able to create pods directly, but allowing them to
 create a deployment, which creates pods on their behalf, will let them create those pods
 indirectly. Likewise, deleting a node from the API will result in the pods scheduled to that node
-being terminated and recreated on other nodes. The out of the box roles represent a balance
+being terminated and recreated on other nodes. The out-of-the box roles represent a balance
-between flexibility and the common use cases, but more limited roles should be carefully reviewed
+between flexibility and common use cases, but more limited roles should be carefully reviewed
 to prevent accidental escalation. You can make roles specific to your use case if the out-of-box ones don't meet your needs.
 
 Consult the [authorization reference section](/docs/reference/access-authn-authz/authorization/) for more information.
@@ -104,7 +104,7 @@ reserved resources like memory, or to provide default limits when none are speci
 ### Controlling what privileges containers run with
 
 A pod definition contains a [security context](/docs/tasks/configure-pod-container/security-context/)
-that allows it to request access to running as a specific Linux user on a node (like root),
+that allows it to request access to run as a specific Linux user on a node (like root),
 access to run privileged or access the host network, and other controls that would otherwise
 allow it to run unfettered on a hosting node. [Pod security policies](/docs/concepts/policy/pod-security-policy/)
 can limit which users or service accounts can provide dangerous security context settings. For example, pod security policies can limit volume mounts, especially `hostPath`, which are aspects of a pod that should be controlled.
@@ -155,10 +155,10 @@ within their namespaces. Many of the supported [Kubernetes networking providers]
 now respect network policy.
 
 Quota and limit ranges can also be used to control whether users may request node ports or
-load balanced services, which on many clusters can control whether those users applications
+load-balanced services, which on many clusters can control whether those users applications
 are visible outside of the cluster.
 
-Additional protections may be available that control network rules on a per plugin or per
+Additional protections may be available that control network rules on a per-plugin or per-
 environment basis, such as per-node firewalls, physically separating cluster nodes to
 prevent cross talk, or advanced networking policy.
 
@@ -169,7 +169,7 @@ By default these APIs are accessible by pods running on an instance and can cont
 credentials for that node, or provisioning data such as kubelet credentials. These credentials
 can be used to escalate within the cluster or to other cloud services under the same account.
 
-When running Kubernetes on a cloud platform limit permissions given to instance credentials, use
+When running Kubernetes on a cloud platform, limit permissions given to instance credentials, use
 [network policies](/docs/tasks/administer-cluster/declare-network-policy/) to restrict pod access
 to the metadata API, and avoid using provisioning data to deliver secrets.
 
@@ -177,7 +177,7 @@ to the metadata API, and avoid using provisioning data to deliver secrets.
 
 By default, there are no restrictions on which nodes may run a pod.  Kubernetes offers a
 [rich set of policies for controlling placement of pods onto nodes](/docs/concepts/scheduling-eviction/assign-pod-node/)
-and the [taint based pod placement and eviction](/docs/concepts/scheduling-eviction/taint-and-toleration/)
+and the [taint-based pod placement and eviction](/docs/concepts/scheduling-eviction/taint-and-toleration/)
 that are available to end users. For many clusters use of these policies to separate workloads
 can be a convention that authors adopt or enforce via tooling.
 
@@ -223,8 +223,9 @@ do not use.
 The shorter the lifetime of a secret or credential the harder it is for an attacker to make
 use of that credential. Set short lifetimes on certificates and automate their rotation. Use
 an authentication provider that can control how long issued tokens are available and use short
-lifetimes where possible. If you use service account tokens in external integrations, plan to
+lifetimes where possible. If you use service-account tokens in external integrations, plan to
-rotate those tokens frequently. For example, once the bootstrap phase is complete, a bootstrap token used for setting up nodes should be revoked or its authorization removed.
+rotate those tokens frequently. For example, once the bootstrap phase is complete, a bootstrap 
+token used for setting up nodes should be revoked or its authorization removed.
 
 ### Review third party integrations before enabling them
 
@@ -246,7 +247,8 @@ and may grant an attacker significant visibility into the state of your cluster.
 your backups using a well reviewed backup and encryption solution, and consider using full disk
 encryption where possible.
 
-Kubernetes supports [encryption at rest](/docs/tasks/administer-cluster/encrypt-data/), a feature introduced in 1.7, and beta since 1.13. This will encrypt `Secret` resources in etcd, preventing
+Kubernetes supports [encryption at rest](/docs/tasks/administer-cluster/encrypt-data/), a feature 
+introduced in 1.7, and beta since 1.13. This will encrypt `Secret` resources in etcd, preventing
 parties that gain access to your etcd backups from viewing the content of those secrets. While
 this feature is currently beta, it offers an additional level of defense when backups
 are not encrypted or an attacker gains read access to etcd.