Skip to content

Commit

Permalink
Fix Typos
Browse files Browse the repository at this point in the history
Signed-off-by: Chin-Ya Huang <[email protected]>
  • Loading branch information
c3y1huang authored and brandond committed Dec 4, 2020
1 parent 2124bdc commit 8696265
Show file tree
Hide file tree
Showing 2 changed files with 14 additions and 14 deletions.
20 changes: 10 additions & 10 deletions docs/security/hardening_guide.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,16 +11,16 @@ RKE2 is designed to be "hardened by default" and pass the majority of the Kubern

To help ensure these above requirements are met, RKE2 can be started with the `profile` flag set to `cis-1.5`. This flag generally does two things:

1. Checks that host-level requirements have been met. If they haven't, RKE2 will exit with a fatal error describing the unmet requirements..
1. Checks that host-level requirements have been met. If they haven't, RKE2 will exit with a fatal error describing the unmet requirements.
2. Configures runtime Pod Security Policies and Network Policies that allow the cluster to pass associated controls.

> **Note:** The profile's flag only valid value is `cis-1.5`. It accepts a string value to allow for other profiles in the future.
The following secction outlines the specific actions that are taken when the `profile` flag is set to `cis-1.5`.
The following section outlines the specific actions that are taken when the `profile` flag is set to `cis-1.5`.

## Host-level Requirements

There are two areas of of Host-level requirements: kernel parameters and etcd process/directory configuration. These are outlined in this section.
There are two areas of Host-level requirements: kernel parameters and etcd process/directory configuration. These are outlined in this section.

### Ensure `protect-kernel-defaults` is set
This is a kubelet flag that will cause the kubelet to exit if the required kernel parameters are unset or are set to values that are different from the kubelet's defaults.
Expand All @@ -29,14 +29,14 @@ When the `profile` flag is set, RKE2 will set the flag to true.

> **Note:** `protect-kernel-defaults` is exposed a top-level flag for RKE2. If you have set `profile` to "cis-1.5" and `protect-kernel-defaults` to false explicitly, RKE2 will exit with an error.
RKE2 will also check the same kernel parameters that the kubelet does and exit with an error following the same rules as the kubelet. This is done as a convenience to help the operator more quickly and easily identify what kernel parameters are violationg the kubelet defaults.
RKE2 will also check the same kernel parameters that the kubelet does and exit with an error following the same rules as the kubelet. This is done as a convenience to help the operator more quickly and easily identify what kernel parameters are violating the kubelet defaults.

### Ensure etcd is started properly
The CIS Benchmark requires that the etcd data directory be owned by the `etcd` user and group. This implicitly requires the etcd process to be ran as the host-level `etcd` user. To acheive this, RKE2 takes several steps when started with the cis-1.5 profile:
The CIS Benchmark requires that the etcd data directory be owned by the `etcd` user and group. This implicitly requires the etcd process to be ran as the host-level `etcd` user. To achieve this, RKE2 takes several steps when started with the cis-1.5 profile:

1. Check that the `etcd` user and group exists on the host. If they don't, exit with an error.
2. Create etcd's data directory with `etcd` as the user and group owner.
3. Ensure the etcd process is ran as the `etcd` user and group by setting the etcd static pod's SecurityContext approopriately.
3. Ensure the etcd process is ran as the `etcd` user and group by setting the etcd static pod's SecurityContext appropriately.

### Setting up hosts
This section gives you the commands necessary to configure your host to meet the above requirements.
Expand Down Expand Up @@ -83,7 +83,7 @@ When ran with the cis-1.5 profile, RKE2 will put a much more restrictive set of
### NetworkPolicies

When ran with the cis-1.5 profile, RKE2 will put NetworkPolicies in place that pass the CIS Benchmark for Kubernetes's built-in namespcaes. These namespaces are: `kube-system`, `kube-public`, `kube-node-lease`, and `default`.
When ran with the cis-1.5 profile, RKE2 will put NetworkPolicies in place that passes the CIS Benchmark for Kubernetes's built-in namespaces. These namespaces are: `kube-system`, `kube-public`, `kube-node-lease`, and `default`.

The NetworkPolicy used will only allow pods within the same namespace to talk to each other. The notable exception to this is that it allows DNS requests to be resolved.

Expand All @@ -106,7 +106,7 @@ Ensure that default service accounts are not actively used. (Scored)
<details>
<summary>Rationale</summary>

Kubernetes provides a default service account which is used by cluster workloads where no specific service account is assigned to the pod.
Kubernetes provides a default service account that is used by cluster workloads where no specific service account is assigned to the pod.

Where access to the Kubernetes API from a pod is required, a specific service account should be created for that pod, and rights granted to that service account.

Expand All @@ -115,9 +115,9 @@ The default service account should be configured such that it does not provide a

The remediation for this is to update the `automountServiceAccountToken` field to `false` for the `default` service account in each namespace.

For `default` service accounts in the built-in namespaces (`kube-system`, `kube-public`, `kube-node-lease`, and `default`), RKE2 does not automatically do this. You can manually update this field on these service accounts to passs the control.
For `default` service accounts in the built-in namespaces (`kube-system`, `kube-public`, `kube-node-lease`, and `default`), RKE2 does not automatically do this. You can manually update this field on these service accounts to pass the control.


## Conclusion

If you have followed this guide, your RKE2 cluster will be configured to pass the CIS Kubernetes Benchmark. You can review our [CIS Benchmark Self-Assessment Guide](cis_self_assessment.md) to understand how we verified each of the benchmark and how you can do the same on your cluster.
If you have followed this guide, your RKE2 cluster will be configured to pass the CIS Kubernetes Benchmark. You can review our [CIS Benchmark Self-Assessment Guide](cis_self_assessment.md) to understand how we verified each of the benchmarks and how you can do the same on your cluster.
8 changes: 4 additions & 4 deletions docs/security/policies.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,12 +7,12 @@ This document describes how RKE2 configures PodSecurityPolicies and NetworkPolic

RKE2 can be ran with or without the `profile: cis-1.5` configuration parameter. This will cause it to apply different PodSecurityPolicies (PSPs) at start-up.

* If ran with the `cis-1.5` profile, RKE2 will apply a restrictive policy called `global-restricted-psp` to all namespaces except `kube-system`. The `kube-system` namespace needs a less restrictive policy named `system-unrestricted-psp` in order to launch critical components.
* If ran without the `cis-1.5` profile, RKE2 will apply a completely unrestricted policy called `global-unrestricted-psp`, which is the equivalent of running without the PSP admission controller enabled.
* If running with the `cis-1.5` profile, RKE2 will apply a restrictive policy called `global-restricted-psp` to all namespaces except `kube-system`. The `kube-system` namespace needs a less restrictive policy named `system-unrestricted-psp` in order to launch critical components.
* If running without the `cis-1.5` profile, RKE2 will apply a completely unrestricted policy called `global-unrestricted-psp`, which is the equivalent of running without the PSP admission controller enabled.

RKE2 will put these policies in place upon initial startup, but will not modify them after that, unless explicitly triggered by the cluster operator as described below. This is to allow the operator to fully control the PSPs without RKE2's defaults adding interference.

Creation and application of the PSPs is controlled by the presence or absence of certain annotations on the `kube-system` namespace. These map directly to the PSPs which can be created and are:
The creation and application of the PSPs are controlled by the presence or absence of certain annotations on the `kube-system` namespace. These map directly to the PSPs which can be created and are:

* `psp.rke2.io/global-restricted`
* `psp.rke2.io/system-unrestricted`
Expand All @@ -25,7 +25,7 @@ The following logic is performed at startup for the policies and their annotatio
* In the case of the `global-unrestricted-psp`, the policy is not recreated. This is to account for moving between CIS and non-CIS modes without making the cluster less secure.
* At the time of creating a policy, cluster roles and cluster role bindings are also created to ensure the appropriate policies are put into use by default.

So, after initial start-up, operators can modify or delete RKE2's policies and RKE2 will respect those changes. Additionally, to "reset" a policy, an operator just needs to delete the associated annotation from the `kube-system` namespace and restart RKE2.
So, after the initial start-up, operators can modify or delete RKE2's policies and RKE2 will respect those changes. Additionally, to "reset" a policy, an operator just needs to delete the associated annotation from the `kube-system` namespace and restart RKE2.

The policies are outlined below.

Expand Down

0 comments on commit 8696265

Please sign in to comment.