From abeaf3e5ea75e26fd923b35fca1e0a5380e14882 Mon Sep 17 00:00:00 2001 From: Chad Lauritsen Date: Thu, 29 Jul 2021 12:46:32 -0400 Subject: [PATCH] mark adjectival phrases with hyphens --- .../administer-cluster/securing-a-cluster.md | 28 ++++++++++--------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/content/en/docs/tasks/administer-cluster/securing-a-cluster.md b/content/en/docs/tasks/administer-cluster/securing-a-cluster.md index 090e292966..ba820cbe0a 100644 --- a/content/en/docs/tasks/administer-cluster/securing-a-cluster.md +++ b/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 -between flexibility and the common use cases, but more limited roles should be carefully reviewed +being terminated and recreated on other nodes. The out-of-the box roles represent a balance +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 -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. +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. ### 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.