diff --git a/versioned_docs/version-2.12/how-to-guides/advanced-user-guides/compliance-scan-guides/skip-tests.md b/versioned_docs/version-2.12/how-to-guides/advanced-user-guides/compliance-scan-guides/skip-tests.md index c28eb027a4b..dee5bff565a 100644 --- a/versioned_docs/version-2.12/how-to-guides/advanced-user-guides/compliance-scan-guides/skip-tests.md +++ b/versioned_docs/version-2.12/how-to-guides/advanced-user-guides/compliance-scan-guides/skip-tests.md @@ -6,12 +6,12 @@ title: Skip Tests -Compliancescans can be run using test profiles with user-defined skips. +Compliance scans can be run using test profiles with user-defined skips. -To skip tests, you will create a custom Compliancescan profile. A profile contains the configuration for the Compliancescan, which includes the benchmark versions to use and any specific tests to skip in that benchmark. +To skip tests, you will create a custom Compliance scan profile. A profile contains the configuration for the Compliance scan, which includes the benchmark versions to use and any specific tests to skip in that benchmark. 1. In the upper left corner, click **☰ > Cluster Management**. -1. On the **Clusters** page, go to the cluster where you want to run a Compliancescan and click **Explore**. +1. the **Clusters** page, go to the cluster where you want to run a Compliance scan and click **Explore**. 1. Click **Compliance > Profile**. 1. From here, you can create a profile in multiple ways. To make a new profile, click **Create** and fill out the form in the UI. To make a new profile based on an existing profile, go to the existing profile and click **⋮ Clone**. If you are filling out the form, add the tests to skip using the test IDs, using the relevant Compliance as a reference. If you are creating the new test profile as YAML, you will add the IDs of the tests to skip in the `skipTests` directive. You will also give the profile a name: diff --git a/versioned_docs/version-2.12/integrations-in-rancher/compliance-scans/compliance-scans.md b/versioned_docs/version-2.12/integrations-in-rancher/compliance-scans/compliance-scans.md index 06663aaf770..757fdc9d24b 100644 --- a/versioned_docs/version-2.12/integrations-in-rancher/compliance-scans/compliance-scans.md +++ b/versioned_docs/version-2.12/integrations-in-rancher/compliance-scans/compliance-scans.md @@ -119,4 +119,4 @@ For more information about configuring the custom resources for the scans, profi ## How-to Guides -Please refer to the [CIS Scan Guides](../../how-to-guides/advanced-user-guides/compliance-scan-guides/compliance-scan-guides.md) to learn how to run CIS scans. \ No newline at end of file +Please refer to the [Compliance Scan Guides](../../how-to-guides/advanced-user-guides/compliance-scan-guides/compliance-scan-guides.md) to learn how to run Compliance scans. diff --git a/versioned_docs/version-2.12/integrations-in-rancher/compliance-scans/configuration-reference.md b/versioned_docs/version-2.12/integrations-in-rancher/compliance-scans/configuration-reference.md index 9ad9c40b18e..4406a091acf 100644 --- a/versioned_docs/version-2.12/integrations-in-rancher/compliance-scans/configuration-reference.md +++ b/versioned_docs/version-2.12/integrations-in-rancher/compliance-scans/configuration-reference.md @@ -72,7 +72,7 @@ A benchmark version is the name of benchmark to run using `kube-bench`, as well A `ClusterScanBenchmark` defines the Compliance `BenchmarkVersion` name and test configurations. The `BenchmarkVersion` name is a parameter provided to the `kube-bench` tool. -By default, a few `BenchmarkVersion` names and test configurations are packaged as part of the CIS scan application. When this feature is enabled, these default BenchmarkVersions will be automatically installed and available for users to create a ClusterScanProfile. +By default, a few `BenchmarkVersion` names and test configurations are packaged as part of the Compliance scan application. When this feature is enabled, these default BenchmarkVersions will be automatically installed and available for users to create a ClusterScanProfile. :::caution @@ -106,4 +106,4 @@ metadata: spec: clusterProvider: "" minKubernetesVersion: 1.15.0 -``` \ No newline at end of file +``` diff --git a/versioned_docs/version-2.12/integrations-in-rancher/compliance-scans/custom-benchmark.md b/versioned_docs/version-2.12/integrations-in-rancher/compliance-scans/custom-benchmark.md index ecf83196136..fc4bf0e3b4b 100644 --- a/versioned_docs/version-2.12/integrations-in-rancher/compliance-scans/custom-benchmark.md +++ b/versioned_docs/version-2.12/integrations-in-rancher/compliance-scans/custom-benchmark.md @@ -9,13 +9,14 @@ title: Creating a Custom Benchmark Version for Running a Cluster Scan Each Benchmark Version defines a set of test configuration files that define the Compliance tests to be run by the kube-bench tool. The `rancher-compliance` application installs a few default Benchmark Versions which are listed under Compliance application menu. -But there could be some Kubernetes cluster setups that require custom configurations of the Benchmark tests. For example, the path to the Kubernetes config files or certs might be different than the standard location where the upstream CIS Benchmarks look for them. -It is now possible to create a custom Benchmark Version for running a cluster scan using the `rancher-compliance` application. +But in the following cases, a custom configuration or remediation may be required: -When a cluster scan is run, you need to select a Profile which points to a specific Benchmark Version. +- Non-standard file locations: When Kubernetes binaries, configuration or certificate paths deviate from upstream benchmark defaults. +Example: Unlike traditional Kubernetes, K3s bundles control plane components into a single binary. Therefore,` --anonymous-auth` flag presence and configuration should be verified in K3s' logs (`journalctl`), not via `kube-apiserver` process checks (`ps`). -Follow all the steps below to add a custom Benchmark Version and run a scan using it. +- Alternative risk mitigations: If a setup doesn't meet a check but has an equally effective compensating control with justification. Or simply is not concerned by the check requirement because of its design. +Example: By default, K3s embeds the api server within the k3s process. There is no API server pod specification file, so verifying the latter's file permissions is not required. ## 1. Prepare the Custom Benchmark Version ConfigMap diff --git a/versioned_docs/version-2.12/integrations-in-rancher/compliance-scans/skipped-and-not-applicable-tests.md b/versioned_docs/version-2.12/integrations-in-rancher/compliance-scans/skipped-and-not-applicable-tests.md deleted file mode 100644 index 965d015d9c8..00000000000 --- a/versioned_docs/version-2.12/integrations-in-rancher/compliance-scans/skipped-and-not-applicable-tests.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: Skipped and Not Applicable Tests ---- - - - - - -This section lists the tests that are skipped in the permissive test profile for RKE. - -> All the tests that are skipped and not applicable on this page will be counted as Not Applicable in the v2.5 generated report. The skipped test count will only mention the user-defined skipped tests. This allows user-skipped tests to be distinguished from the tests that are skipped by default in the RKE permissive test profile. - -## CIS Benchmark v1.5 - -### CIS Benchmark v1.5 Skipped Tests - -| Number | Description | Reason for Skipping | -| ---------- | ------------- | --------- | -| 1.1.12 | Ensure that the etcd data directory ownership is set to etcd:etcd (Automated) | A system service account is required for etcd data directory ownership. Refer to Rancher's hardening guide for more details on how to configure this ownership. | -| 1.2.6 | Ensure that the --kubelet-certificate-authority argument is set as appropriate (Automated) | When generating serving certificates, functionality could break in conjunction with hostname overrides which are required for certain cloud providers. | -| 1.2.16 | Ensure that the admission control plugin PodSecurityPolicy is set (Automated) | Enabling Pod Security Policy can cause applications to unexpectedly fail. | -| 1.2.33 | Ensure that the --encryption-provider-config argument is set as appropriate (Manual) | Enabling encryption changes how data can be recovered as data is encrypted. | -| 1.2.34 | Ensure that encryption providers are appropriately configured (Manual) | Enabling encryption changes how data can be recovered as data is encrypted. | -| 4.2.6 | Ensure that the --protect-kernel-defaults argument is set to true (Automated) | System level configurations are required before provisioning the cluster in order for this argument to be set to true. | -| 4.2.10 | Ensure that the--tls-cert-file and --tls-private-key-file arguments are set as appropriate (Automated) | When generating serving certificates, functionality could break in conjunction with hostname overrides which are required for certain cloud providers. | -| 5.1.5 | Ensure that default service accounts are not actively used. (Automated) | Kubernetes provides default service accounts to be used. | -| 5.2.2 | Minimize the admission of containers wishing to share the host process ID namespace (Automated) | Enabling Pod Security Policy can cause applications to unexpectedly fail. | -| 5.2.3 | Minimize the admission of containers wishing to share the host IPC namespace (Automated) | Enabling Pod Security Policy can cause applications to unexpectedly fail. | -| 5.2.4 | Minimize the admission of containers wishing to share the host network namespace (Automated) | Enabling Pod Security Policy can cause applications to unexpectedly fail. | -| 5.2.5 | Minimize the admission of containers with allowPrivilegeEscalation (Automated) | Enabling Pod Security Policy can cause applications to unexpectedly fail. | -| 5.3.2 | Ensure that all Namespaces have Network Policies defined (Automated) | Enabling Network Policies can prevent certain applications from communicating with each other. | -| 5.6.4 | The default namespace should not be used (Automated) | Kubernetes provides a default namespace. | - -### CIS Benchmark v1.5 Not Applicable Tests - -| Number | Description | Reason for being not applicable | -| ---------- | ------------- | --------- | -| 1.1.1 | Ensure that the API server pod specification file permissions are set to 644 or more restrictive (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for kube-apiserver. All configuration is passed in as arguments at container run time. | -| 1.1.2 | Ensure that the API server pod specification file ownership is set to root:root (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for kube-apiserver. All configuration is passed in as arguments at container run time. | -| 1.1.3 | Ensure that the controller manager pod specification file permissions are set to 644 or more restrictive (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for controller-manager. All configuration is passed in as arguments at container run time. | -| 1.1.4 | Ensure that the controller manager pod specification file ownership is set to root:root (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for controller-manager. All configuration is passed in as arguments at container run time. | -| 1.1.5 | Ensure that the scheduler pod specification file permissions are set to 644 or more restrictive (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for scheduler. All configuration is passed in as arguments at container run time. | -| 1.1.6 | Ensure that the scheduler pod specification file ownership is set to root:root (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for scheduler. All configuration is passed in as arguments at container run time. | -| 1.1.7 | Ensure that the etcd pod specification file permissions are set to 644 or more restrictive (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for etcd. All configuration is passed in as arguments at container run time. | -| 1.1.8 | Ensure that the etcd pod specification file ownership is set to root:root (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for etcd. All configuration is passed in as arguments at container run time. | -| 1.1.13 | Ensure that the admin.conf file permissions are set to 644 or more restrictive (Automated) | Clusters provisioned by RKE does not store the kubernetes default kubeconfig credentials file on the nodes. | -| 1.1.14 | Ensure that the admin.conf file ownership is set to root:root (Automated) | Clusters provisioned by RKE does not store the kubernetes default kubeconfig credentials file on the nodes. | -| 1.1.15 | Ensure that the scheduler.conf file permissions are set to 644 or more restrictive (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for scheduler. All configuration is passed in as arguments at container run time. | -| 1.1.16 | Ensure that the scheduler.conf file ownership is set to root:root (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for scheduler. All configuration is passed in as arguments at container run time. | -| 1.1.17 | Ensure that the controller-manager.conf file permissions are set to 644 or more restrictive (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for controller-manager. All configuration is passed in as arguments at container run time. | -| 1.1.18 | Ensure that the controller-manager.conf file ownership is set to root:root (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for controller-manager. All configuration is passed in as arguments at container run time. | -| 1.3.6 | Ensure that the RotateKubeletServerCertificate argument is set to true (Automated) | Clusters provisioned by RKE handles certificate rotation directly through RKE. | -| 4.1.1 | Ensure that the kubelet service file permissions are set to 644 or more restrictive (Automated) | Clusters provisioned by RKE doesn’t require or maintain a configuration file for the kubelet service. All configuration is passed in as arguments at container run time. | -| 4.1.2 | Ensure that the kubelet service file ownership is set to root:root (Automated) | Clusters provisioned by RKE doesn’t require or maintain a configuration file for the kubelet service. All configuration is passed in as arguments at container run time. | -| 4.1.9 | Ensure that the kubelet configuration file has permissions set to 644 or more restrictive (Automated) | Clusters provisioned by RKE doesn’t require or maintain a configuration file for the kubelet. All configuration is passed in as arguments at container run time. | -| 4.1.10 | Ensure that the kubelet configuration file ownership is set to root:root (Automated) | Clusters provisioned by RKE doesn’t require or maintain a configuration file for the kubelet. All configuration is passed in as arguments at container run time. | -| 4.2.12 | Ensure that the RotateKubeletServerCertificate argument is set to true (Automated) | Clusters provisioned by RKE handles certificate rotation directly through RKE. | \ No newline at end of file diff --git a/versioned_docs/version-2.12/reference-guides/best-practices/rancher-managed-clusters/monitoring-best-practices.md b/versioned_docs/version-2.12/reference-guides/best-practices/rancher-managed-clusters/monitoring-best-practices.md index afa372b23a4..ffa2096211d 100644 --- a/versioned_docs/version-2.12/reference-guides/best-practices/rancher-managed-clusters/monitoring-best-practices.md +++ b/versioned_docs/version-2.12/reference-guides/best-practices/rancher-managed-clusters/monitoring-best-practices.md @@ -98,7 +98,7 @@ Monitoring the availability and performance of all your internal workloads is vi ## Security Monitoring -In addition to monitoring workloads to detect performance, availability or scalability problems, the cluster and the workloads running into it should also be monitored for potential security problems. A good starting point is to frequently run and alert on [CIS Scans](../../../how-to-guides/advanced-user-guides/compliance-scan-guides/compliance-scan-guides.md) which check if the cluster is configured according to security best practices. +In addition to monitoring workloads to detect performance, availability or scalability problems, the cluster and the workloads running into it should also be monitored for potential security problems. A good starting point is to frequently run and alert on [Compliance Scans](../../../how-to-guides/advanced-user-guides/compliance-scan-guides/compliance-scan-guides.md) which check if the cluster is configured according to security best practices. For the workloads, you can have a look at Kubernetes and Container security solutions like [NeuVector](https://www.suse.com/products/neuvector/), [Falco](https://falco.org/), [Aqua Kubernetes Security](https://www.aquasec.com/solutions/kubernetes-container-security/), [SysDig](https://sysdig.com/). diff --git a/versioned_docs/version-2.12/reference-guides/cluster-configuration/rancher-server-configuration/rke2-cluster-configuration.md b/versioned_docs/version-2.12/reference-guides/cluster-configuration/rancher-server-configuration/rke2-cluster-configuration.md index a76cb30552d..44d7d22123b 100644 --- a/versioned_docs/version-2.12/reference-guides/cluster-configuration/rancher-server-configuration/rke2-cluster-configuration.md +++ b/versioned_docs/version-2.12/reference-guides/cluster-configuration/rancher-server-configuration/rke2-cluster-configuration.md @@ -133,9 +133,9 @@ If the cloud provider you want to use is not listed as an option, you will need The default [pod security admission configuration template](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md) for the cluster. -##### Worker CIS Profile +##### Worker Compliance Profile -Select a [CIS benchmark](../../../how-to-guides/advanced-user-guides/cis-scan-guides/cis-scan-guides.md) to validate the system configuration against. +Select a [compliance benchmark](../../../how-to-guides/advanced-user-guides/compliance-scan-guides/compliance-scan-guides.md) to validate the system configuration against. ##### Project Network Isolation diff --git a/versioned_docs/version-2.12/reference-guides/monitoring-v2-configuration/receivers.md b/versioned_docs/version-2.12/reference-guides/monitoring-v2-configuration/receivers.md index b1237e3646b..16e3940e735 100644 --- a/versioned_docs/version-2.12/reference-guides/monitoring-v2-configuration/receivers.md +++ b/versioned_docs/version-2.12/reference-guides/monitoring-v2-configuration/receivers.md @@ -351,29 +351,29 @@ receivers: - service_key: 'database-integration-key' ``` -## Example Route Config for CIS Scan Alerts +## Example Route Config for Compliance Scan Alerts -While configuring the routes for `rancher-cis-benchmark` alerts, you can specify the matching using the key-value pair `job: rancher-cis-scan`. +While configuring the routes for `rancher-compliance` alerts, you can specify the matching using the key-value pair `job: rancher-compliance-scan`. -For example, the following example route configuration could be used with a Slack receiver named `test-cis`: +For example, the following example route configuration could be used with a Slack receiver named `test-compliance`: ```yaml spec: - receiver: test-cis + receiver: test-compliance group_by: # - string group_wait: 30s group_interval: 30s repeat_interval: 30s match: - job: rancher-cis-scan + job: rancher-compliance-scan # key: string match_re: {} # key: string ``` -For more information on enabling alerting for `rancher-cis-benchmark`, see [this section.](../../how-to-guides/advanced-user-guides/cis-scan-guides/enable-alerting-for-rancher-cis-benchmark.md) +For more information on enabling alerting for `rancher-compliance-benchmark`, see [this section.](../../how-to-guides/advanced-user-guides/compliance-scan-guides/enable-alerting-for-rancher-compliance.md) ## Trusted CA for Notifiers diff --git a/versioned_docs/version-2.12/reference-guides/rancher-cluster-tools.md b/versioned_docs/version-2.12/reference-guides/rancher-cluster-tools.md index ad46fbdd9d2..b89ff4a1299 100644 --- a/versioned_docs/version-2.12/reference-guides/rancher-cluster-tools.md +++ b/versioned_docs/version-2.12/reference-guides/rancher-cluster-tools.md @@ -42,8 +42,8 @@ Rancher's integration with Istio was improved in Rancher v2.5. For more information, refer to the Istio documentation [here.](../integrations-in-rancher/istio/istio.md) -## CIS Scans +## Compliance Scans -Rancher can run a security scan to check whether Kubernetes is deployed according to security best practices as defined in the CIS Kubernetes Benchmark. +Rancher can run a security scan to check whether Kubernetes is deployed according to security best practices as defined in most recognized Kubernetes Security Benchmarks, such as STIG. -For more information, refer to the CIS scan documentation [here.](../how-to-guides/advanced-user-guides/cis-scan-guides/cis-scan-guides.md) \ No newline at end of file +For more information, refer to the Compliance scan documentation [here.](../how-to-guides/advanced-user-guides/compliance-scan-guides/compliance-scan-guides.md) diff --git a/versioned_docs/version-2.12/reference-guides/rancher-security/rancher-security.md b/versioned_docs/version-2.12/reference-guides/rancher-security/rancher-security.md index f16699b8ac6..a39be982169 100644 --- a/versioned_docs/version-2.12/reference-guides/rancher-security/rancher-security.md +++ b/versioned_docs/version-2.12/reference-guides/rancher-security/rancher-security.md @@ -31,22 +31,14 @@ On this page, we provide security related documentation along with resources to NeuVector is an open-source, container-focused security application that is now integrated into Rancher. NeuVector provides production security, DevOps vulnerability protection, and a container firewall, et al. Please see the [Rancher docs](../../integrations-in-rancher/neuvector/neuvector.md) and the [NeuVector docs](https://open-docs.neuvector.com/) for more information. -## Running a CIS Security Scan on a Kubernetes Cluster +## Running a Compliance Security Scan on a Kubernetes Cluster -Rancher leverages [kube-bench](https://github.com/aquasecurity/kube-bench) to run a security scan to check whether Kubernetes is deployed according to security best practices as defined in the [CIS](https://www.cisecurity.org/cis-benchmarks/) (Center for Internet Security) Kubernetes Benchmark. +Rancher leverages [kube-bench](https://github.com/aquasecurity/kube-bench) to run a security scan to check whether Kubernetes is deployed according to security best practices. -The CIS Kubernetes Benchmark is a reference document that can be used to establish a secure configuration baseline for Kubernetes. - -The Center for Internet Security (CIS) is a 501(c\)(3) non-profit organization, formed in October 2000, with a mission to "identify, develop, validate, promote, and sustain best practice solutions for cyber defense and build and lead communities to enable an environment of trust in cyberspace". - -CIS Benchmarks are best practices for the secure configuration of a target system. CIS Benchmarks are developed through the generous volunteer efforts of subject matter experts, technology vendors, public and private community members, and the CIS Benchmark Development team. - -The Benchmark provides recommendations of two types: Automated and Manual. We run tests related to only Automated recommendations. - -When Rancher runs a CIS security scan on a cluster, it generates a report showing the results of each test, including a summary with the number of passed, skipped and failed tests. The report also includes remediation steps for any failed tests. - -For details, refer to the section on [security scans](../../how-to-guides/advanced-user-guides/cis-scan-guides/cis-scan-guides.md). +When Rancher runs a Compliance scan on a cluster, it generates a report showing the results of each test, including a summary with the number of passed, skipped and failed tests. The report also includes remediation steps for any failed tests. +For details, refer to the section on [security scans](../../how-to-guides/advanced-user-guides/compliance-scan-guides/compliance-scan-guides.md). +` ## SELinux RPM [Security-Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) is a security enhancement to Linux. After being historically used by government agencies, SELinux is now industry standard and is enabled by default on CentOS 7 and 8.