mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-29 22:49:17 +00:00
Merge branch 'v2.12.0' into gce
This commit is contained in:
Billy Tat
-17
@@ -1,17 +0,0 @@
|
||||
---
|
||||
title: CIS Scan Guides
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides"/>
|
||||
</head>
|
||||
|
||||
- [Install rancher-cis-benchmark](install-rancher-cis-benchmark.md)
|
||||
- [Uninstall rancher-cis-benchmark](uninstall-rancher-cis-benchmark.md)
|
||||
- [Run a Scan](run-a-scan.md)
|
||||
- [Run a Scan Periodically on a Schedule](run-a-scan-periodically-on-a-schedule.md)
|
||||
- [Skip Tests](skip-tests.md)
|
||||
- [View Reports](view-reports.md)
|
||||
- [Enable Alerting for rancher-cis-benchmark](enable-alerting-for-rancher-cis-benchmark.md)
|
||||
- [Configure Alerts for Periodic Scan on a Schedule](configure-alerts-for-periodic-scan-on-a-schedule.md)
|
||||
- [Create a Custom Benchmark Version to Run](create-a-custom-benchmark-version-to-run.md)
|
||||
-13
@@ -1,13 +0,0 @@
|
||||
---
|
||||
title: Create a Custom Benchmark Version for Running a Cluster Scan
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides/create-a-custom-benchmark-version-to-run"/>
|
||||
</head>
|
||||
|
||||
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-cis-benchmark` application.
|
||||
|
||||
For details, see [this page.](../../../integrations-in-rancher/cis-scans/custom-benchmark.md)
|
||||
-24
@@ -1,24 +0,0 @@
|
||||
---
|
||||
title: Enable Alerting for Rancher CIS Benchmark
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides/enable-alerting-for-rancher-cis-benchmark"/>
|
||||
</head>
|
||||
|
||||
Alerts can be configured to be sent out for a scan that runs on a schedule.
|
||||
|
||||
:::note Prerequisite:
|
||||
|
||||
Before enabling alerts for `rancher-cis-benchmark`, make sure to install the `rancher-monitoring` application and configure the Receivers and Routes. For more information, see [this section.](../../../reference-guides/monitoring-v2-configuration/receivers.md)
|
||||
|
||||
While configuring the routes for `rancher-cis-benchmark` alerts, you can specify the matching using the key-value pair `job: rancher-cis-scan`. An example route configuration is [here.](../../../reference-guides/monitoring-v2-configuration/receivers.md#example-route-config-for-cis-scan-alerts)
|
||||
|
||||
:::
|
||||
|
||||
While installing or upgrading the `rancher-cis-benchmark` Helm chart, set the following flag to `true` in the `values.yaml`:
|
||||
|
||||
```yaml
|
||||
alerts:
|
||||
enabled: true
|
||||
```
|
||||
-21
@@ -1,21 +0,0 @@
|
||||
---
|
||||
title: Install Rancher CIS Benchmark
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides/install-rancher-cis-benchmark"/>
|
||||
</head>
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, go to the cluster where you want to install CIS Benchmark and click **Explore**.
|
||||
1. In the left navigation bar, click **Apps > Charts**.
|
||||
1. Click **CIS Benchmark**
|
||||
1. Click **Install**.
|
||||
|
||||
**Result:** The CIS scan application is deployed on the Kubernetes cluster.
|
||||
|
||||
:::note
|
||||
|
||||
If you are running Kubernetes v1.24 or earlier, and have a [Pod Security Policy](../../new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md) (PSP) hardened cluster, CIS Benchmark 4.0.0 and later disable PSPs by default. To install CIS Benchmark on a PSP-hardened cluster, set `global.psp.enabled` to `true` in the values before installing the chart. [Pod Security Admission](../../new-user-guides/authentication-permissions-and-global-configuration/pod-security-standards.md) (PSA) hardened clusters aren't affected.
|
||||
|
||||
:::
|
||||
-26
@@ -1,26 +0,0 @@
|
||||
---
|
||||
title: Run a Scan
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides/run-a-scan"/>
|
||||
</head>
|
||||
|
||||
When a ClusterScan custom resource is created, it launches a new CIS scan on the cluster for the chosen ClusterScanProfile.
|
||||
|
||||
:::note
|
||||
|
||||
There is currently a limitation of running only one CIS scan at a time for a cluster. If you create multiple ClusterScan custom resources, they will be run one after the other by the operator, and until one scan finishes, the rest of the ClusterScan custom resources will be in the "Pending" state.
|
||||
|
||||
:::
|
||||
|
||||
To run a scan,
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, go to the cluster where you want to run a CIS scan and click **Explore**.
|
||||
1. Click **CIS Benchmark > Scan**.
|
||||
1. Click **Create**.
|
||||
1. Choose a cluster scan profile. The profile determines which CIS Benchmark version will be used and which tests will be performed. If you choose the Default profile, then the CIS Operator will choose a profile applicable to the type of Kubernetes cluster it is installed on.
|
||||
1. Click **Create**.
|
||||
|
||||
**Result:** A report is generated with the scan results. To see the results, click the name of the scan that appears.
|
||||
-38
@@ -1,38 +0,0 @@
|
||||
---
|
||||
title: Skip Tests
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides/skip-tests"/>
|
||||
</head>
|
||||
|
||||
CIS scans can be run using test profiles with user-defined skips.
|
||||
|
||||
To skip tests, you will create a custom CIS scan profile. A profile contains the configuration for the CIS 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 CIS scan and click **Explore**.
|
||||
1. Click **CIS Benchmark > 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 CIS Benchmark 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:
|
||||
|
||||
```yaml
|
||||
apiVersion: cis.cattle.io/v1
|
||||
kind: ClusterScanProfile
|
||||
metadata:
|
||||
annotations:
|
||||
meta.helm.sh/release-name: clusterscan-operator
|
||||
meta.helm.sh/release-namespace: cis-operator-system
|
||||
labels:
|
||||
app.kubernetes.io/managed-by: Helm
|
||||
name: "<example-profile>"
|
||||
spec:
|
||||
benchmarkVersion: cis-1.5
|
||||
skipTests:
|
||||
- "1.1.20"
|
||||
- "1.1.21"
|
||||
```
|
||||
1. Click **Create**.
|
||||
|
||||
**Result:** A new CIS scan profile is created.
|
||||
|
||||
When you [run a scan](./run-a-scan.md) that uses this profile, the defined tests will be skipped during the scan. The skipped tests will be marked in the generated report as `Skip`.
|
||||
-13
@@ -1,13 +0,0 @@
|
||||
---
|
||||
title: Uninstall Rancher CIS Benchmark
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides/uninstall-rancher-cis-benchmark"/>
|
||||
</head>
|
||||
|
||||
1. From the **Cluster Dashboard,** go to the left navigation bar and click **Apps > Installed Apps**.
|
||||
1. Go to the `cis-operator-system` namespace and check the boxes next to `rancher-cis-benchmark-crd` and `rancher-cis-benchmark`.
|
||||
1. Click **Delete** and confirm **Delete**.
|
||||
|
||||
**Result:** The `rancher-cis-benchmark` application is uninstalled.
|
||||
-23
@@ -1,23 +0,0 @@
|
||||
---
|
||||
title: View Reports
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides/view-reports"/>
|
||||
</head>
|
||||
|
||||
To view the generated CIS scan reports,
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, go to the cluster where you want to run a CIS scan and click **Explore**.
|
||||
1. Click **CIS Benchmark > Scan**.
|
||||
1. The **Scans** page will show the generated reports. To see a detailed report, go to a scan report and click the name.
|
||||
|
||||
One can download the report from the Scans list or from the scan detail page.
|
||||
|
||||
To get the verbose version of the CIS scan results, run the following command on the cluster that was scanned. Note that the scan must be completed before this can be done.
|
||||
|
||||
```console
|
||||
export REPORT="scan-report-name"
|
||||
kubectl get clusterscanreport $REPORT -o json |jq ".spec.reportJSON | fromjson" | jq -r ".actual_value_map_data" | base64 -d | gunzip | jq .
|
||||
```
|
||||
+16
@@ -0,0 +1,16 @@
|
||||
---
|
||||
title: Compliance Scan Guides
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/compliance-scan-guides"/>
|
||||
</head>
|
||||
|
||||
- [Install rancher-compliance](install-rancher-compliance.md)
|
||||
- [Uninstall rancher-compliance](uninstall-rancher-compliance.md)
|
||||
- [Run a Scan](run-a-scan.md)
|
||||
- [Run a Scan Periodically on a Schedule](run-a-scan-periodically-on-a-schedule.md)
|
||||
- [View Reports](view-reports.md)
|
||||
- [Enable Alerting for rancher-compliance](enable-alerting-for-rancher-compliance.md)
|
||||
- [Configure Alerts for Periodic Scan on a Schedule](configure-alerts-for-periodic-scan-on-a-schedule.md)
|
||||
- [Create a Custom Benchmark Version to Run](create-a-custom-compliance-version-to-run.md)
|
||||
+8
-8
@@ -3,7 +3,7 @@ title: Configure Alerts for Periodic Scan on a Schedule
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides/configure-alerts-for-periodic-scan-on-a-schedule"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/compliance-scan-guides/configure-alerts-for-periodic-scan-on-a-schedule"/>
|
||||
</head>
|
||||
|
||||
It is possible to run a ClusterScan on a schedule.
|
||||
@@ -12,27 +12,27 @@ A scheduled scan can also specify if you should receive alerts when the scan com
|
||||
|
||||
Alerts are supported only for a scan that runs on a schedule.
|
||||
|
||||
The CIS Benchmark application supports two types of alerts:
|
||||
The compliance application supports two types of alerts:
|
||||
|
||||
- Alert on scan completion: This alert is sent out when the scan run finishes. The alert includes details including the ClusterScan's name and the ClusterScanProfile name.
|
||||
- Alert on scan failure: This alert is sent out if there are some test failures in the scan run or if the scan is in a `Fail` state.
|
||||
|
||||
:::note Prerequisite
|
||||
|
||||
Before enabling alerts for `rancher-cis-benchmark`, make sure to install the `rancher-monitoring` application and configure the Receivers and Routes. For more information, see [this section.](../../../reference-guides/monitoring-v2-configuration/receivers.md)
|
||||
Before enabling alerts for `rancher-compliance`, make sure to install the `rancher-monitoring` application and configure the Receivers and Routes. For more information, see [this section.](../../../reference-guides/monitoring-v2-configuration/receivers.md)
|
||||
|
||||
While configuring the routes for `rancher-cis-benchmark` alerts, you can specify the matching using the key-value pair `job: rancher-cis-scan`. An example route configuration is [here.](../../../reference-guides/monitoring-v2-configuration/receivers.md#example-route-config-for-cis-scan-alerts)
|
||||
While configuring the routes for `rancher-compliance` alerts, you can specify the matching using the key-value pair `job: rancher-compliance-scan`. An example route configuration is [here.](../../../reference-guides/monitoring-v2-configuration/receivers.md#example-route-config-for-compliance-scan-alerts)
|
||||
|
||||
:::
|
||||
|
||||
To configure alerts for a scan that runs on a schedule,
|
||||
|
||||
1. Please enable alerts on the `rancher-cis-benchmark` application. For more information, see [this page](../../../how-to-guides/advanced-user-guides/cis-scan-guides/enable-alerting-for-rancher-cis-benchmark.md).
|
||||
1. Please enable alerts on the `rancher-compliance` application. For more information, see [this page](../../../how-to-guides/advanced-user-guides/compliance-scan-guides/enable-alerting-for-rancher-compliance.md).
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, go to the cluster where you want to run a CIS scan and click **Explore**.
|
||||
1. Click **CIS Benchmark > Scan**.
|
||||
1. On the **Clusters** page, go to the cluster where you want to run a Compliance scan and click **Explore**.
|
||||
1. Click **compliance > Scan**.
|
||||
1. Click **Create**.
|
||||
1. Choose a cluster scan profile. The profile determines which CIS Benchmark version will be used and which tests will be performed. If you choose the Default profile, then the CIS Operator will choose a profile applicable to the type of Kubernetes cluster it is installed on.
|
||||
1. Choose a cluster scan profile. The profile determines which compliance version will be used and which tests will be performed. If you choose the Default profile, then the Compliance Operator will choose a profile applicable to the type of Kubernetes cluster it is installed on.
|
||||
1. Choose the option **Run scan on a schedule**.
|
||||
1. Enter a valid [cron schedule expression](https://en.wikipedia.org/wiki/Cron#CRON_expression) in the field **Schedule**.
|
||||
1. Check the boxes next to the Alert types under **Alerting**.
|
||||
+13
@@ -0,0 +1,13 @@
|
||||
---
|
||||
title: Create a Custom Compliance Version for Running a Cluster Scan
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/compliance-scan-guides/create-a-custom-compliance-version-to-run"/>
|
||||
</head>
|
||||
|
||||
There could be some Kubernetes cluster setups that require custom configurations of the Compliance tests. For example, the path to the Kubernetes config files or certs might be different than the standard location where the upstream Compliance look for them.
|
||||
|
||||
It is now possible to create a custom compliance version for running a cluster scan using the `rancher-compliance` application.
|
||||
|
||||
For details, see [this page.](../../../integrations-in-rancher/compliance-scans/custom-benchmark.md)
|
||||
+24
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: Enable Alerting for Rancher Compliance
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/compliance-scan-guides/enable-alerting-for-rancher-compliance"/>
|
||||
</head>
|
||||
|
||||
Alerts can be configured to be sent out for a scan that runs on a schedule.
|
||||
|
||||
:::note Prerequisite:
|
||||
|
||||
Before enabling alerts for `rancher-compliance`, make sure to install the `rancher-monitoring` application and configure the Receivers and Routes. For more information, see [this section.](../../../reference-guides/monitoring-v2-configuration/receivers.md)
|
||||
|
||||
While configuring the routes for `rancher-compliance` alerts, you can specify the matching using the key-value pair `job: rancher-compliance-scan`. An example route configuration is [here.](../../../reference-guides/monitoring-v2-configuration/receivers.md#example-route-config-for-compliance-scan-alerts)
|
||||
|
||||
:::
|
||||
|
||||
While installing or upgrading the `rancher-compliance` Helm chart, set the following flag to `true` in the `values.yaml`:
|
||||
|
||||
```yaml
|
||||
alerts:
|
||||
enabled: true
|
||||
```
|
||||
+15
@@ -0,0 +1,15 @@
|
||||
---
|
||||
title: Install Rancher Compliance
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/compliance-scan-guides/install-rancher-compliance"/>
|
||||
</head>
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, go to the cluster where you want to install Compliance and click **Explore**.
|
||||
1. In the left navigation bar, click **Apps > Charts**.
|
||||
1. Click **Compliance**
|
||||
1. Click **Install**.
|
||||
|
||||
**Result:** The compliance scan application is deployed on the Kubernetes cluster.
|
||||
+4
-4
@@ -3,15 +3,15 @@ title: Run a Scan Periodically on a Schedule
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides/run-a-scan-periodically-on-a-schedule"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/compliance-scan-guides/run-a-scan-periodically-on-a-schedule"/>
|
||||
</head>
|
||||
|
||||
To run a ClusterScan on a schedule,
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, go to the cluster where you want to run a CIS scan and click **Explore**.
|
||||
1. Click **CIS Benchmark > Scan**.
|
||||
1. Choose a cluster scan profile. The profile determines which CIS Benchmark version will be used and which tests will be performed. If you choose the Default profile, then the CIS Operator will choose a profile applicable to the type of Kubernetes cluster it is installed on.
|
||||
1. On the **Clusters** page, go to the cluster where you want to run a Compliance scan and click **Explore**.
|
||||
1. Click **Compliance > Scan**.
|
||||
1. Choose a cluster scan profile. The profile determines which Compliance version will be used and which tests will be performed. If you choose the Default profile, then the Compliance Operator will choose a profile applicable to the type of Kubernetes cluster it is installed on.
|
||||
1. Choose the option **Run scan on a schedule**.
|
||||
1. Enter a valid <a href="https://en.wikipedia.org/wiki/Cron#CRON_expression" target="_blank">cron schedule expression</a> in the field **Schedule**.
|
||||
1. Choose a **Retention** count, which indicates the number of reports maintained for this recurring scan. By default this count is 3. When this retention limit is reached, older reports will get purged.
|
||||
+26
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: Run a Scan
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/compliance-scan-guides/run-a-scan"/>
|
||||
</head>
|
||||
|
||||
When a ClusterScan custom resource is created, it launches a new compliance scan on the cluster for the chosen ClusterScanProfile.
|
||||
|
||||
:::note
|
||||
|
||||
There is currently a limitation of running only one compliance scan at a time for a cluster. If you create multiple ClusterScan custom resources, they will be run one after the other by the operator, and until one scan finishes, the rest of the ClusterScan custom resources will be in the "Pending" state.
|
||||
|
||||
:::
|
||||
|
||||
To run a scan,
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, go to the cluster where you want to run a compliance scan and click **Explore**.
|
||||
1. Click **Compliance > Scan**.
|
||||
1. Click **Create**.
|
||||
1. Choose a cluster scan profile. The profile determines which Compliance version will be used and which tests will be performed. If you choose the Default profile, then the Compliance Operator will choose a profile applicable to the type of Kubernetes cluster it is installed on.
|
||||
1. Click **Create**.
|
||||
|
||||
**Result:** A report is generated with the scan results. To see the results, click the name of the scan that appears.
|
||||
+13
@@ -0,0 +1,13 @@
|
||||
---
|
||||
title: Uninstall Rancher Compliance
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/compliance-scan-guides/uninstall-rancher-compliance"/>
|
||||
</head>
|
||||
|
||||
1. From the **Cluster Dashboard,** go to the left navigation bar and click **Apps > Installed Apps**.
|
||||
1. Go to the `compliance-operator-system` namespace and check the boxes next to `rancher-compliance-crd` and `rancher-compliance`.
|
||||
1. Click **Delete** and confirm **Delete**.
|
||||
|
||||
**Result:** The `rancher-compliance` application is uninstalled.
|
||||
+23
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: View Reports
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/compliance-scan-guides/view-reports"/>
|
||||
</head>
|
||||
|
||||
To view the generated Compliance scan reports,
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, go to the cluster where you want to run a Compliance scan and click **Explore**.
|
||||
1. Click **Compliance > Scan**.
|
||||
1. The **Scans** page will show the generated reports. To see a detailed report, go to a scan report and click the name.
|
||||
|
||||
One can download the report from the Scans list or from the scan detail page.
|
||||
|
||||
To get the verbose version of the compliance scan results, run the following command on the cluster that was scanned. Note that the scan must be completed before this can be done.
|
||||
|
||||
```console
|
||||
export REPORT="scan-report-name"
|
||||
kubectl get clusterscanreports.compliance.cattle.io $REPORT -o json |jq ".spec.reportJSON | fromjson" | jq -r ".actual_value_map_data" | base64 -d | gunzip | jq .
|
||||
```
|
||||
+138
@@ -0,0 +1,138 @@
|
||||
---
|
||||
title: Configure Rancher as an OIDC provider
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/configure-oidc-provider"/>
|
||||
</head>
|
||||
|
||||
Rancher can function as a standard OpenID Connect (OIDC) provider, allowing external applications to use Rancher for authentication.
|
||||
This can be used for enabling single sign-on (SSO) across Rancher Prime components. For example, see the [documentation](https://documentation.suse.com/cloudnative/suse-observability/next/en/setup/security/authentication/oidc.html) for configuring the OIDC provider for SUSE Observability.
|
||||
|
||||
The OIDC provider can be enabled with the `oidc-provider` feature flag. When this flag is on the following endpoints are available:
|
||||
|
||||
- `https://{rancher-url}/oidc/authorize`: This endpoint initiates the authentication flow. If a user is already logged into Rancher, it returns an authorization code. Otherwise, it redirects the user to the Rancher login page. Authorization codes and related request information are securely stored in session secrets. Codes are single-use and expire after 10 minutes.
|
||||
|
||||
- `https://{rancher-url}/oidc/token`: This endpoint exchanges an authorization code for an `id_token`, `access_token`, and `refresh_token`.
|
||||
|
||||
- `https://{rancher-url}/oidc/.well-known/openid-configuration`: This endpoint returns a JSON document containing the OIDC provider's configuration, including endpoint URLs, supported scopes, claims, and other relevant details.
|
||||
|
||||
- `https://{rancher-url}/oidc/userinfo`: This endpoint provides information about the authenticated user.
|
||||
|
||||
The OIDC provider supports the OIDC Authentication Code Flow with PKCE.
|
||||
|
||||
## Configure OIDCClient
|
||||
|
||||
An `OIDCClient` represents an external application that will be authenticating against Rancher.
|
||||
|
||||
### Programmatically
|
||||
|
||||
Create an `OIDCClient`:
|
||||
|
||||
```yaml
|
||||
apiVersion: management.cattle.io/v3
|
||||
kind: OIDCClient
|
||||
metadata:
|
||||
name: oidc-client-test
|
||||
spec:
|
||||
tokenExpirationSeconds: 600 # expiration of the id_token and access_token
|
||||
refreshTokenExpirationSeconds: 3600 # expiration of the refresh_token
|
||||
redirectURIs:
|
||||
- "https://myredirecturl.com" # replace with your redirect url
|
||||
```
|
||||
Rancher automatically generates a client ID and client secret for each `OIDCClient`.
|
||||
Once the resource is created, Rancher populates the status field with the client id:
|
||||
|
||||
```yaml
|
||||
apiVersion: management.cattle.io/v3
|
||||
kind: OIDCClient
|
||||
metadata:
|
||||
name: oidc-client-test
|
||||
spec:
|
||||
tokenExpirationSeconds: 600 # expiration of the id_token and access_token
|
||||
refreshTokenExpirationSeconds: 3600 # expiration of the refresh_token
|
||||
redirectURIs:
|
||||
- "https://myredirecturl.com" # replace with your redirect url
|
||||
status:
|
||||
clientID: client-xxx
|
||||
clientSecrets:
|
||||
client-secret-1:
|
||||
createdAt: "xxx"
|
||||
lastFiveCharacters: xxx
|
||||
```
|
||||
|
||||
Rancher automatically generates a Kubernetes `Secret` in the `cattle-oidc-client-secrets` namespace for each `OIDCClient` resource. The Secret's name matches the `OIDCClient` client ID.
|
||||
Initially, the `Secret` contains a single client secret.
|
||||
|
||||
To retrieve the client secret:
|
||||
|
||||
```
|
||||
kubectl get secret client-xxx -n cattle-oidc-client-secrets -o jsonpath="{.data.client-secret-1}" | base64 -d
|
||||
```
|
||||
|
||||
Output:
|
||||
|
||||
```
|
||||
secret-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
|
||||
```
|
||||
|
||||
You can now use this client ID and client secret in your OIDC client application.
|
||||
|
||||
#### Managing Client Secrets
|
||||
|
||||
You can manage multiple client secrets per `OIDCClient`. Use annotations on the `OIDCClient` resource to perform secret operations:
|
||||
|
||||
- Creation: Adding the `cattle.io/oidc-client-secret-create: true` annotation triggers the creation of a new client secret.
|
||||
- Removal: Adding the `cattle.io/oidc-client-secret-remove:client-secret-1` annotation removes the specified client secrets.
|
||||
- Regeneration: Adding the `cattle.io/oidc-client-secret-regenerate:client-secret-1` annotation regenerates the specified client secrets.
|
||||
|
||||
### Rancher UI
|
||||
|
||||
Create an OIDCClient:
|
||||
|
||||
1. In the top left corner, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation menu, click **OIDC Apps**.
|
||||
1. Click **Add Application**. Fill out the **Create OIDC App** form.
|
||||
1. Click **Add Application**.
|
||||
|
||||
#### Managing Client Secrets
|
||||
|
||||
In the OIDC App page:
|
||||
|
||||
- Creation: Click **Add new secret**.
|
||||
- Removal: Click **⋮ > Delete**
|
||||
- Regeneration: Click **⋮ > Regenerate**
|
||||
|
||||
## Signing key
|
||||
|
||||
A default key pair for signing the `id_token`, `access_token`, and `refresh_token` tokens is created by Rancher in a `Secret` called `oidc-signing-key` in the `cattle-system` namespace. Only one key will be used for signing, but multiple public keys can be returned in the jwks endpoint in order to avoid disruption when doing a key rotation.
|
||||
|
||||
### Rotation without disruption
|
||||
|
||||
In order to create a new key pair for signing you need to manually create a new keypair and add it to the `oidc-signing-key` `Secret`
|
||||
|
||||
Example:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: oidc-signing-key
|
||||
type: Opaque
|
||||
data:
|
||||
key2.pem: <base64-encoded-new-private-key>
|
||||
key1.pub: <base64-encoded-old-public-key>
|
||||
key2.pub: <base64-encoded-new-public-key>
|
||||
```
|
||||
|
||||
Rancher will sign tokens using `key2.pem`, while the JWKS endpoint will serve both `key1.pub` and `key2.pub`. This ensures a smooth
|
||||
key rotation from `key1` to `key2` without disrupting existing token verification. Note that only one private key (.pem) can be stored in the
|
||||
secret at a time, and each key pair must share the same base name, differing only by their suffix: .pem for the private key and .pub for the public key.
|
||||
|
||||
### Rotation with disruption
|
||||
|
||||
Removing the `oidc-signing-key` `Secret` will cause Rancher to regenerate the signing key on the next restart.
|
||||
|
||||
:::warning
|
||||
This will invalidate all previously issued `id_token`, `access_token`, and `refresh_token` tokens making them unusable.
|
||||
:::
|
||||
-1
@@ -39,7 +39,6 @@ Values set from the Rancher API will override the value passed in through the co
|
||||
|
||||
When installing Rancher with a Helm chart, use the `--set` option. In the below example, two features are enabled by passing the feature flag names in a comma separated list:
|
||||
|
||||
For Kubernetes v1.25 or later, set `global.cattle.psp.enabled` to `false` when using Rancher v2.7.2-v2.7.4. This is not necessary for Rancher v2.7.5 and above, but you can still manually set the option if you choose.
|
||||
|
||||
```
|
||||
helm install rancher rancher-latest/rancher \
|
||||
|
||||
-1
@@ -17,7 +17,6 @@ Detailed information can be found in [this announcement](https://forums.suse.com
|
||||
:::note Prerequisites:
|
||||
|
||||
- Only a user with the `cluster-admin` [Kubernetes default role](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) assigned can configure and install Istio in a Kubernetes cluster.
|
||||
- If you have pod security policies, you will need to install Istio with the CNI enabled. For details, see [this section.](../../../integrations-in-rancher/istio/configuration-options/pod-security-policies.md)
|
||||
- To install Istio on an RKE2 cluster, additional steps are required. For details, see [this section.](../../../integrations-in-rancher/istio/configuration-options/install-istio-on-rke2-cluster.md)
|
||||
- To install Istio in a cluster where project network isolation is enabled, additional steps are required. For details, see [this section.](../../../integrations-in-rancher/istio/configuration-options/project-network-isolation.md)
|
||||
|
||||
|
||||
-43
@@ -1,43 +0,0 @@
|
||||
---
|
||||
title: Applying Pod Security Policies to Projects
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/manage-projects/manage-pod-security-policies"/>
|
||||
</head>
|
||||
|
||||
:::note
|
||||
|
||||
These cluster options are only available for [clusters in which Rancher has launched Kubernetes](../../new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md).
|
||||
|
||||
:::
|
||||
|
||||
You can always assign a pod security policy (PSP) to an existing project if you didn't assign one during creation.
|
||||
|
||||
### Prerequisites
|
||||
|
||||
- Create a Pod Security Policy within Rancher. Before you can assign a default PSP to an existing project, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies](../../new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md).
|
||||
- Assign a default Pod Security Policy to the project's cluster. You can't assign a PSP to a project until one is already applied to the cluster. For more information, see [the documentation about adding a pod security policy to a cluster](../../new-user-guides/manage-clusters/add-a-pod-security-policy.md).
|
||||
|
||||
### Applying a Pod Security Policy
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, go to the cluster where you want to move a namespace and click **Explore**.
|
||||
1. Click **Cluster > Projects/Namespaces**.
|
||||
1. Find the project that you want to add a PSP to. From that project, select **⋮ > Edit Config**.
|
||||
1. From the **Pod Security Policy** drop-down, select the PSP you want to apply to the project.
|
||||
Assigning a PSP to a project will:
|
||||
|
||||
- Override the cluster's default PSP.
|
||||
- Apply the PSP to the project.
|
||||
- Apply the PSP to any namespaces you add to the project later.
|
||||
|
||||
1. Click **Save**.
|
||||
|
||||
**Result:** The PSP is applied to the project and any namespaces added to the project.
|
||||
|
||||
:::note
|
||||
|
||||
Any workloads that are already running in a cluster or project before a PSP is assigned will not be checked to determine if they comply with the PSP. Workloads would need to be cloned or upgraded to see if they pass the PSP.
|
||||
|
||||
:::
|
||||
-1
@@ -24,7 +24,6 @@ You can use projects to perform actions like:
|
||||
- [Set resource quotas](manage-project-resource-quotas/manage-project-resource-quotas.md)
|
||||
- [Manage namespaces](../../new-user-guides/manage-namespaces.md)
|
||||
- [Configure tools](../../../reference-guides/rancher-project-tools.md)
|
||||
- [Configure pod security policies](manage-pod-security-policies.md)
|
||||
|
||||
### Authorization
|
||||
|
||||
|
||||
+60
@@ -0,0 +1,60 @@
|
||||
---
|
||||
title: Configure Amazon Cognito
|
||||
description: Create an Amazon Cognito user pool and configure Rancher to work with Amazon Cognito. Your users can then sign into Rancher using their login from Amazon Cognito.
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-amazon-cognito"/>
|
||||
</head>
|
||||
|
||||
If your organization uses Amazon Cognito for user authentication, you can configure Rancher to allow login using Amazon Cognito credentials. The following instructions describe how to configure Rancher to work with Amazon Cognito:
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- In Rancher:
|
||||
- Amazon Cognito is disabled.
|
||||
|
||||
:::note
|
||||
Consult the Amazon Cognito [documentation](https://aws.amazon.com/cognito/getting-started/) to configure the user pool.
|
||||
:::
|
||||
|
||||
- In Amazon Cognito:
|
||||
- Create a new user pool or use an existing one.
|
||||
- In the `App client` settings, set the redirect URL to `https://yourRancherHostURL/verify-auth`. Replace `yourRancherHostURL` with the actual hostname of your Rancher instance (e.g., https://rancher.example.com/verify-auth).
|
||||
|
||||
## Configuring Amazon Cognito in Rancher
|
||||
|
||||
1. In the upper left corner of the Rancher UI, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation bar, click **Auth Provider**.
|
||||
1. Select **Amazon Cognito**.
|
||||
1. Complete the **Configure an Amazon Cognito account** form. For help with filling the form, see the [configuration reference](#configuration-reference).
|
||||
1. Click **Enable**.
|
||||
|
||||
Rancher will redirect you to the Amazon Cognito login page. Enter your Amazon Cognito credentials to validate your Rancher configuration.
|
||||
|
||||
:::note
|
||||
|
||||
You may need to disable your popup blocker to see the Amazon Cognito login page.
|
||||
|
||||
:::
|
||||
|
||||
**Result:** Rancher is configured to work with your Amazon Cognito using the OIDC protocol. Your users can now sign into Rancher using their Amazon Cognito logins.
|
||||
|
||||
:::note
|
||||
User and group search is not supported for Amazon Cognito. When assigning permissions to a Project or Cluster, you must manually enter the UserID generated by Cognito
|
||||
if the user has not yet logged in to Rancher. However, if the user has previously logged in, you can assign permissions using their username or email address.
|
||||
:::
|
||||
|
||||
## Configuration Reference
|
||||
|
||||
| Field | Description |
|
||||
| ------------------------- |-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| Client ID | The Client ID of your Amazon Cognito App Client. |
|
||||
| Client Secret | The generated Secret of your Amazon Cognito App Client. |
|
||||
| Issuer | The Issuer URL of your Amazon Cognito App Client. It follows the format `https://cognito-idp.{region}.amazonaws.com/{userPoolId}`, and can be found in the App Client settings page. Rancher uses the Issuer URL to fetch all of the required URLs. |
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### You are not redirected to your authentication provider
|
||||
|
||||
If you fill out the **Configure an Amazon Cognito account** form and click on **Enable**, and you are not redirected to Amazon Cognito, verify your Amazon Cognito configuration.
|
||||
-6
@@ -38,12 +38,6 @@ The user retention feature is disabled by default.
|
||||
|
||||
For more information, see [Enabling User Retention](../../advanced-user-guides/enable-user-retention.md).
|
||||
|
||||
## Pod Security Policies
|
||||
|
||||
_Pod Security Policies_ (or PSPs) are objects that control security-sensitive aspects of pod specification, e.g. root privileges. If a pod does not meet the conditions specified in the PSP, Kubernetes will not allow it to start, and Rancher will display an error message.
|
||||
|
||||
For more information how to create and use PSPs, see [Pod Security Policies](create-pod-security-policies.md).
|
||||
|
||||
## Provisioning Drivers
|
||||
|
||||
Drivers in Rancher allow you to manage which providers can be used to provision [hosted Kubernetes clusters](../kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/set-up-clusters-from-hosted-kubernetes-providers.md) or [nodes in an infrastructure provider](../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md) to allow Rancher to deploy and manage Kubernetes.
|
||||
|
||||
-82
@@ -1,82 +0,0 @@
|
||||
---
|
||||
title: Creating Pod Security Policies
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies"/>
|
||||
</head>
|
||||
|
||||
:::caution
|
||||
Pod Security Policies are only available in Kubernetes until v1.24. [Pod Security Standards](pod-security-standards.md) are the built-in alternative.
|
||||
:::
|
||||
|
||||
[Pod Security Policies (PSPs)](https://kubernetes.io/docs/concepts/security/pod-security-policy/) are objects that control security-sensitive aspects of the pod specification (such as root privileges).
|
||||
|
||||
If a pod doesn't meet the conditions specified in the PSP, Kubernetes won't allow it to start, and Rancher will display the following error message: `Pod <NAME> is forbidden: unable to validate...`.
|
||||
|
||||
|
||||
## How PSPs Work
|
||||
|
||||
You can assign PSPs at the cluster or project level.
|
||||
|
||||
PSPs work through inheritance:
|
||||
|
||||
- By default, PSPs assigned to a cluster are inherited by its projects, as well as any namespaces added to those projects.
|
||||
- **Exception:** Namespaces that are not assigned to projects do not inherit PSPs, regardless of whether the PSP is assigned to a cluster or project. Because these namespaces have no PSPs, workload deployments to these namespaces will fail, which is the default Kubernetes behavior.
|
||||
- You can override the default PSP by assigning a different PSP directly to the project.
|
||||
|
||||
Any workloads that are already running in a cluster or project before a PSP is assigned will not be checked if it complies with the PSP. Workloads would need to be cloned or upgraded to see if they pass the PSP.
|
||||
|
||||
Read more about Pod Security Policies in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/pod-security-policy/).
|
||||
|
||||
## Default PSPs
|
||||
|
||||
Rancher ships with three default Pod Security Policies (PSPs): the `restricted-noroot`, `restricted` and `unrestricted` policies.
|
||||
|
||||
### Restricted-NoRoot
|
||||
|
||||
This policy is based on the Kubernetes [example restricted policy](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/policy/restricted-psp.yaml). It significantly restricts what types of pods can be deployed to a cluster or project. This policy:
|
||||
|
||||
- Prevents pods from running as a privileged user and prevents escalation of privileges.
|
||||
- Validates that server-required security mechanisms are in place, such as restricting what volumes can be mounted to only the core volume types and preventing root supplemental groups from being added.
|
||||
|
||||
### Restricted
|
||||
|
||||
This policy is a relaxed version of the `restricted-noroot` policy, with almost all the restrictions in place, except for the fact that it allows running containers as a privileged user.
|
||||
|
||||
### Unrestricted
|
||||
|
||||
This policy is equivalent to running Kubernetes with the PSP controller disabled. It has no restrictions on what pods can be deployed into a cluster or project.
|
||||
|
||||
:::note important
|
||||
|
||||
When disabling PSPs, default PSPs are **not** automatically deleted from your cluster. You must manually delete them if they're no longer needed.
|
||||
|
||||
:::
|
||||
|
||||
## Creating PSPs
|
||||
|
||||
Using Rancher, you can create a Pod Security Policy using our GUI rather than creating a YAML file.
|
||||
|
||||
### Requirements
|
||||
|
||||
Rancher can only assign PSPs for clusters that are [launched using RKE](../launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md).
|
||||
|
||||
You must enable PSPs at the cluster level before you can assign them to a project. This can be configured by [editing the cluster](../../../reference-guides/cluster-configuration/cluster-configuration.md).
|
||||
|
||||
It is a best practice to set PSP at the cluster level.
|
||||
|
||||
We recommend adding PSPs during cluster and project creation instead of adding it to an existing one.
|
||||
|
||||
### Creating PSPs in the Rancher UI
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. In the left navigation bar, click **Pod Security Policies**.
|
||||
1. Click **Add Policy**.
|
||||
1. Name the policy.
|
||||
1. Complete each section of the form. Refer to the [Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) for more information on what each policy does.
|
||||
1. Click **Create**.
|
||||
|
||||
## Configuration
|
||||
|
||||
The Kubernetes documentation on PSPs is [here](https://kubernetes.io/docs/concepts/policy/pod-security-policy/).
|
||||
+28
@@ -196,6 +196,34 @@ As previously mentioned, custom roles can be defined for use at the cluster or p
|
||||
|
||||
When defining a custom role, you can grant access to specific resources or specify roles from which the custom role should inherit. A custom role can be made up of a combination of specific grants and inherited roles. All grants are additive. This means that defining a narrower grant for a specific resource **will not** override a broader grant defined in a role that the custom role is inheriting from.
|
||||
|
||||
#### UpdatePSA For Project Level
|
||||
|
||||
About defining custom roles, you can grant permission to a user to create or update *PSA* policies when defining namespaces within projects.
|
||||
|
||||
To do so, you can use the following `RoleTemplate` to be applied on the cluster:
|
||||
|
||||
```yaml
|
||||
apiVersion: management.cattle.io/v3
|
||||
builtin: false
|
||||
context: project
|
||||
description: ''
|
||||
displayName: Manage PSA Labels
|
||||
external: false
|
||||
hidden: false
|
||||
kind: RoleTemplate
|
||||
metadata:
|
||||
name: namespaces-psa
|
||||
rules:
|
||||
- apiGroups:
|
||||
- management.cattle.io
|
||||
resources:
|
||||
- projects
|
||||
verbs:
|
||||
- updatepsa
|
||||
```
|
||||
|
||||
When creating a new project (from the **Members** tab), click **Add** to add the user and select **Custom** > **Create Namespaces** (to allow the user to create namespaces). Then click **Add** again and select `UpdatePSA` project role template from the list of **Project Permissions**.gt
|
||||
|
||||
### Default Cluster and Project Roles
|
||||
|
||||
By default, when a standard user creates a new cluster or project, they are automatically assigned an ownership role: either [cluster owner](#cluster-roles) or [project owner](#project-roles). However, in some organizations, these roles may overextend administrative access. In this use case, you can change the default role to something more restrictive, such as a set of individual roles or a custom role.
|
||||
|
||||
-57
@@ -11,54 +11,6 @@ They became available and were turned on by default in Kubernetes v1.23, and rep
|
||||
|
||||
PSS define security levels for workloads. PSAs describe requirements for pod security contexts and related fields. PSAs reference PSS levels to define security restrictions.
|
||||
|
||||
## Upgrade to Pod Security Standards (PSS)
|
||||
|
||||
Ensure that you migrate all PSPs to another workload security mechanism. This includes mapping your current PSPs to Pod Security Standards for enforcement with the [PSA controller](https://kubernetes.io/docs/concepts/security/pod-security-admission/). If the PSA controller won't meet all of your organization's needs, we recommend that you use a policy engine, such as [Kubewarden](https://www.kubewarden.io/), [Kyverno](https://kyverno.io/), or [NeuVector](https://neuvector.com/). Refer to the documentation of your policy engine of choice for more information on how to migrate from PSPs.
|
||||
|
||||
:::caution
|
||||
You must add your new policy enforcement mechanisms _before_ you remove the PodSecurityPolicy objects. If you don't, you may create an opportunity for privilege escalation attacks within the cluster.
|
||||
:::
|
||||
|
||||
### Removing PodSecurityPolicies from Rancher-Maintained Apps & Marketplace Workloads
|
||||
|
||||
Rancher v2.7.2 offers a new major version of Rancher-maintained Helm charts. v102.x.y allows you to remove PSPs that were installed with previous versions of the chart. This new version replaces non-standard PSPs switches with the standardized `global.cattle.psp.enabled` switch, which is turned off by default.
|
||||
|
||||
You must perform the following steps _while still in Kubernetes v1.24_:
|
||||
1. Configure the PSA controller to suit your needs. You can use one of Rancher's built-in [PSA Configuration Templates](#pod-security-admission-configuration-templates), or create a custom template and apply it to the clusters that you are migrating.
|
||||
|
||||
1. Map your active PSPs to Pod Security Standards:
|
||||
1. See which PSPs are still active in your cluster:
|
||||
:::caution
|
||||
This strategy may miss workloads that aren't currently running, such as CronJobs, workloads currently scaled to zero, or workloads that haven't rolled out yet.
|
||||
:::
|
||||
|
||||
```shell
|
||||
kubectl get pods \
|
||||
--all-namespaces \
|
||||
--output jsonpath='{.items[*].metadata.annotations.kubernetes\.io\/psp}' \
|
||||
| tr " " "\n" | sort -u
|
||||
```
|
||||
|
||||
1. Follow the Kubernetes guide on [Mapping PSPs to Pod Security Standards](https://kubernetes.io/docs/reference/access-authn-authz/psp-to-pod-security-standards/) to apply PSSs to your workloads that were relying on PSPs. See [Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission controller](https://kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/) for more details.
|
||||
|
||||
1. To remove PSPs from Rancher charts, upgrade the charts to the latest v102.x.y version _before_ you upgrade to Kubernetes v1.25. Make sure that the **Enable PodSecurityPolicies** option is **disabled**. This will remove any PSPs that were installed with previous chart versions.
|
||||
|
||||
:::info important
|
||||
If you want to upgrade your charts to v102.x.y, but don't plan on upgrading your clusters to Kubernetes v1.25 and moving away from PSPs, make sure that you select the option **Enable PodSecurityPolicies** for each chart that you are upgrading.
|
||||
:::
|
||||
|
||||
### Cleaning Up Releases After a Kubernetes v1.25 Upgrade
|
||||
|
||||
If you experience problems while removing PSPs from your charts, or have charts that don't contain a built-in mechanism for removing PSPs, your chart upgrades or deletions might fail with an error message such as the following:
|
||||
```console
|
||||
Error: UPGRADE FAILED: resource mapping not found for name: "<object-name>" namespace: "<object-namespace>" from "": no matches for kind "PodSecurityPolicy" in version "policy/v1beta1"
|
||||
ensure CRDs are installed first
|
||||
```
|
||||
|
||||
This happens when Helm tries to query the cluster for objects that were stored in a previous release's data blob. To clean up these releases and avoid this error, use the `helm-mapkubeapis` Helm plugin. To learn more about `helm-mapkubeapis`, how it works, and how it can be fine-tuned for your use case, see the [official Helm documentation](https://github.com/helm/helm-mapkubeapis#readme).
|
||||
|
||||
Note that Helm plugin installation is local to the machine that you run the commands from. Therefore, make sure that you run both the installation and cleanup from the same machine.
|
||||
|
||||
#### Install `helm-mapkubeapis`
|
||||
|
||||
1. Open your terminal in the machine you intend to use `helm-mapkubeapis` from and install the plugin:
|
||||
@@ -110,15 +62,6 @@ After you install the `helm-mapkubeapis` plugin, clean up the releases that beca
|
||||
|
||||
1. Finally, after reviewing the changes, perform a full run with `helm mapkubeapis <release-name> --namespace <release-namespace>`.
|
||||
|
||||
#### Upgrading Charts to a Version That Supports Kubernetes v1.25
|
||||
|
||||
You can proceed with your upgrade once any releases that had lingering PSPs are cleaned up. For Rancher-maintained workloads, follow the steps outlined in the [Removing PodSecurityPolicies from Rancher-maintained Apps & Marketplace workloads](#removing-podsecuritypolicies-from-rancher-maintained-apps--marketplace-workloads) section of this document.
|
||||
For workloads not maintained by Rancher, refer to the vendor documentation.
|
||||
|
||||
:::caution
|
||||
Do not skip this step. Applications incompatible with Kubernetes v1.25 aren't guaranteed to work after a cleanup.
|
||||
:::
|
||||
|
||||
## Pod Security Admission Configuration Templates
|
||||
|
||||
Rancher offers PSA configuration templates. These are pre-defined security configurations that you can apply to a cluster. Rancher admins (or those with the right permissions) can [create, manage, and edit](./psa-config-templates.md) PSA templates.
|
||||
|
||||
+2
-2
@@ -70,7 +70,7 @@ To perform a backup, a custom resource of type Backup must be created.
|
||||
folder: rancher
|
||||
region: us-west-2
|
||||
endpoint: s3.us-west-2.amazonaws.com
|
||||
resourceSetName: rancher-resource-set
|
||||
resourceSetName: rancher-resource-set-full
|
||||
encryptionConfigSecretName: encryptionconfig
|
||||
schedule: "@every 1h"
|
||||
retentionCount: 10
|
||||
@@ -78,7 +78,7 @@ To perform a backup, a custom resource of type Backup must be created.
|
||||
|
||||
:::note
|
||||
|
||||
When creating the Backup resource using YAML editor, the `resourceSetName` must be set to `rancher-resource-set`
|
||||
When creating the Backup resource using YAML editor, the `resourceSetName` must be set to `rancher-resource-set-full` or `rancher-resource-set-basic`.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+1
-1
@@ -28,7 +28,7 @@ The `rancher-backup` operator introduces three custom resources: Backups, Restor
|
||||
|
||||
The ResourceSet defines which Kubernetes resources need to be backed up. The ResourceSet is not available to be configured in the Rancher UI because the values required to back up Rancher are predefined. This ResourceSet should not be modified.
|
||||
|
||||
When a Backup custom resource is created, the `rancher-backup` operator calls the `kube-apiserver` to get the resources in the ResourceSet (specifically, the predefined `rancher-resource-set`) that the Backup custom resource refers to.
|
||||
When a Backup custom resource is created, the `rancher-backup` operator calls the `kube-apiserver` to get the resources in the ResourceSet that the Backup custom resource refers to.
|
||||
|
||||
The operator then creates the backup file in the .tar.gz format and stores it in the location configured in the Backup resource.
|
||||
|
||||
|
||||
-1
@@ -168,7 +168,6 @@ Follow the steps to [install cert-manager](../../../getting-started/installation
|
||||
|
||||
Use the same version of Helm to install Rancher, that was used on the first cluster.
|
||||
|
||||
For Kubernetes v1.25 or later, set `global.cattle.psp.enabled` to `false` when using Rancher v2.7.2-v2.7.4. This is not necessary for Rancher v2.7.5 and above, but you can still manually set the option if you choose.
|
||||
|
||||
```bash
|
||||
helm install rancher rancher-latest/rancher \
|
||||
|
||||
+16
-10
@@ -57,6 +57,14 @@ GKE Autopilot clusters aren't supported. See [Compare GKE Autopilot and Standard
|
||||
9. If you are using self-signed certificates, you will receive the message `certificate signed by unknown authority`. To work around this validation, copy the command starting with `curl` displayed in Rancher to your clipboard. Then run the command on a node where kubeconfig is configured to point to the cluster you want to import.
|
||||
10. When you finish running the command(s) on your node, click **Done**.
|
||||
|
||||
:::important
|
||||
|
||||
The `NO_PROXY` environment variable is not standardized, and the accepted format of the value can differ between applications. When configuring the `NO_PROXY` variable in Rancher, the value must adhere to the format expected by Golang.
|
||||
|
||||
Specifically, the value should be a comma-delimited string which only contains IP addresses, CIDR notation, domain names, or special DNS labels (e.g. `*`). For a full description of the expected value format, refer to the [**upstream Golang documentation**](https://pkg.go.dev/golang.org/x/net/http/httpproxy#Config)
|
||||
|
||||
:::
|
||||
|
||||
**Result:**
|
||||
|
||||
- Your cluster is registered and assigned a state of **Pending**. Rancher is deploying resources to manage your cluster.
|
||||
@@ -162,6 +170,13 @@ You can define the default behavior for newly created clusters or existing ones
|
||||
|
||||
Changes to the global **imported-cluster-version-management** setting take effect during the cluster’s next reconciliation cycle.
|
||||
|
||||
:::note
|
||||
|
||||
If version management is enabled for a cluster, Rancher will deploy the system-upgrade-controller app, along with the associated Plans and other required Kubernetes resources, to the cluster.
|
||||
If version management is disabled, Rancher will remove these components from the cluster.
|
||||
|
||||
:::
|
||||
|
||||
## Configuring RKE2 and K3s Cluster Upgrades
|
||||
|
||||
:::tip
|
||||
@@ -269,15 +284,7 @@ Therefore, when Rancher registers a cluster, it assumes that several capabilitie
|
||||
|
||||
However, if the cluster has a certain capability, such as the ability to use a pod security policy, a user of that cluster might still want to select pod security policies for the cluster in the Rancher UI. In order to do that, the user will need to manually indicate to Rancher that pod security policies are enabled for the cluster.
|
||||
|
||||
By annotating a registered cluster, it is possible to indicate to Rancher that a cluster was given a pod security policy, or another capability, outside of Rancher.
|
||||
|
||||
This example annotation indicates that a pod security policy is enabled:
|
||||
|
||||
```json
|
||||
"capabilities.cattle.io/pspEnabled": "true"
|
||||
```
|
||||
|
||||
The following annotation indicates Ingress capabilities. Note that the values of non-primitive objects need to be JSON encoded, with quotations escaped.
|
||||
By annotating a registered cluster, it is possible to indicate to Rancher that a cluster was given Ingress capabilities, or another capability, outside of Rancher. The following annotation indicates Ingress capabilities. Note that the values of non-primitive objects need to be JSON encoded, with quotations escaped.
|
||||
|
||||
```json
|
||||
"capabilities.cattle.io/ingressCapabilities": "[
|
||||
@@ -294,7 +301,6 @@ These capabilities can be annotated for the cluster:
|
||||
- `loadBalancerCapabilities`
|
||||
- `nodePoolScalingSupported`
|
||||
- `nodePortRange`
|
||||
- `pspEnabled`
|
||||
- `taintSupport`
|
||||
|
||||
All the capabilities and their type definitions can be viewed in the Rancher API view, at `[Rancher Server URL]/v3/schemas/capabilities`.
|
||||
|
||||
+53
-18
@@ -14,15 +14,16 @@ This page is about secrets in general. For details on setting up a private regis
|
||||
|
||||
:::
|
||||
|
||||
When configuring a workload, you'll be able to choose which secrets to include. Like config maps, secrets can be referenced by workloads as either an environment variable or a volume mount.
|
||||
When configuring a workload, you are able to choose which secrets to include. Like config maps, secrets can be referenced by workloads as either an environment variable or a volume mount.
|
||||
|
||||
Mounted secrets will be updated automatically unless they are mounted as subpath volumes. For details on how updated secrets are propagated, refer to the [Kubernetes documentation.](https://kubernetes.io/docs/concepts/configuration/secret/#mounted-secrets-are-updated-automatically)
|
||||
Mounted secrets are updated automatically unless they are mounted as subpath volumes. For details on how updated secrets are propagated, refer to the [Kubernetes documentation.](https://kubernetes.io/docs/concepts/configuration/secret/#mounted-secrets-are-updated-automatically)
|
||||
|
||||
## Creating Secrets in Namespaces
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. Go to the cluster where you want to add a secret and click **Explore**.
|
||||
1. To navigate to secrets, you may click either **Storage > Secrets** or **More Resources > Core > Secrets**.
|
||||
1. Select the **Namespaced** tab.
|
||||
1. Click **Create**.
|
||||
1. Select the type of secret you want to create.
|
||||
1. Select a **Namespace** for the secret.
|
||||
@@ -48,32 +49,66 @@ Mounted secrets will be updated automatically unless they are mounted as subpath
|
||||
|
||||
**Result:** Your secret is added to the namespace you chose. You can view the secret in the Rancher UI by clicking either **Storage > Secrets** or **More Resources > Core > Secrets**.
|
||||
|
||||
Mounted secrets will be updated automatically unless they are mounted as subpath volumes. For details on how updated secrets are propagated, refer to the [Kubernetes documentation.](https://kubernetes.io/docs/concepts/configuration/secret/#mounted-secrets-are-updated-automatically)
|
||||
Mounted secrets are updated automatically unless they are mounted as subpath volumes. For details on how updated secrets are propagated, refer to the [Kubernetes documentation.](https://kubernetes.io/docs/concepts/configuration/secret/#mounted-secrets-are-updated-automatically)
|
||||
|
||||
|
||||
## Creating Secrets in Projects
|
||||
|
||||
Before v2.6, secrets were required to be in a project scope. Projects are no longer required, and you may use the namespace scope instead. As a result, the Rancher UI was updated to reflect this new functionality. However, you may still create project-scoped secrets if desired. Note that you have to first enable the `legacy` feature flag and look at a single project to do so. Use the following steps to set up your project-level secret:
|
||||
When creating a secret in a project scope, the secret is copied into all namespaces within the project.
|
||||
|
||||
1. In the upper left corner, click **☰ > Global Settings** in the dropdown.
|
||||
1. Click **Feature Flags**.
|
||||
1. Go to the `legacy` feature flag and click **Activate**.
|
||||
1. In the upper left corner, click **☰ > Cluster Management** in the dropdown.
|
||||
1. Go to the cluster that you created and click **Explore.**
|
||||
1. Click **Legacy > Projects**.
|
||||
1. In the top navigation bar, filter to see only one project.
|
||||
1. In the left navigation bar, click **Secrets**.
|
||||
1. Click **Add Secret**.
|
||||
### Creating a Project Scoped Secret in the UI
|
||||
|
||||
**Result:** Your secret is added to the individual project you chose. You can view the secret in the Rancher UI by clicking either **Storage > Secrets** or **More Resources > Core > Secrets**.
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. Go to the cluster where you want to add a secret and click **Explore**.
|
||||
1. To navigate to secrets, you may click either **Storage > Secrets** or **More Resources > Core > Secrets**.
|
||||
1. Select the **Project Scoped** tab.
|
||||
1. Click **Create Project Scoped Secret**.
|
||||
1. Select the type of secret you want to create.
|
||||
1. Select a **Project** for the secret.
|
||||
1. Enter a **Name** for the secret.
|
||||
|
||||
Since project-scoped secrets are set at the project level, any changes made at the namespace level will be overwritten.
|
||||
:::note
|
||||
|
||||
:::note
|
||||
Kubernetes classifies secrets, certificates, and registries all as [secrets](https://kubernetes.io/docs/concepts/configuration/secret/), and no two secrets in a namespace can have duplicate names. If you create a project scoped secret that has the same name as an existing secret in one of the project namespaces, the existing secret is overwritten.
|
||||
|
||||
Project-scoped secrets on the local cluster are only visible when a single project is selected.
|
||||
:::
|
||||
|
||||
:::
|
||||
1. From **Data**, click **Add** to add a key-value pair. Add as many values as you need.
|
||||
|
||||
:::tip
|
||||
|
||||
You can add multiple key-value pairs to the secret by copying and pasting.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
|
||||
1. Click **Save**.
|
||||
|
||||
**Result:** Your secret is added to each namespace within the project. You can view the secret in the Rancher UI by clicking either **Storage > Secrets** or **More Resources > Core > Secrets**.
|
||||
|
||||
### Creating a Project Scoped Secret with kubectl
|
||||
|
||||
Project scoped secrets work by creating the original secret on the management cluster in what's known as the "Project Backing Namespace". Rancher stores important project related information in this namespace. You can find it in the `status.backingNamespace` field in the project CRD, or by doing `kubectl get projects -A` in the management cluster.
|
||||
|
||||
In order for the secret to be acknowledged by Rancher as a project scoped secret, it also needs the label `management.cattle.io/project-scoped-secret: <projectID>`.
|
||||
|
||||
Example yaml:
|
||||
|
||||
```
|
||||
apiVersion: v1
|
||||
data:
|
||||
key: ZG9n
|
||||
kind: Secret
|
||||
metadata:
|
||||
labels:
|
||||
management.cattle.io/project-scoped-secret: p-vwxyz
|
||||
name: test-secret
|
||||
namespace: c-abc123-p-vwxyz
|
||||
type: Opaque
|
||||
```
|
||||
|
||||
In the above YAML, the namespace is the backing namespace of project `p-vwxyz` and the project scoped secret label references the projectID. When applied to the management cluster, all namespaces within the project `p-vwxyz` contain a copy of `test-secret`.
|
||||
|
||||
## What's Next?
|
||||
|
||||
|
||||
-43
@@ -1,43 +0,0 @@
|
||||
---
|
||||
title: Adding a Pod Security Policy
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/manage-clusters/add-a-pod-security-policy"/>
|
||||
</head>
|
||||
|
||||
:::note Prerequisite:
|
||||
|
||||
The options below are available only for clusters that are [launched using RKE.](../launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md)
|
||||
|
||||
:::
|
||||
|
||||
When your cluster is running pods with security-sensitive configurations, assign it a [pod security policy](../authentication-permissions-and-global-configuration/create-pod-security-policies.md), which is a set of rules that monitors the conditions and settings in your pods. If a pod doesn't meet the rules specified in your policy, the policy stops it from running.
|
||||
|
||||
You can assign a pod security policy when you provision a cluster. However, if you need to relax or restrict security for your pods later, you can update the policy while editing your cluster.
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Go to the cluster to which you want to apply a pod security policy and click **⋮ > Edit Config**.
|
||||
1. From **Pod Security Policy Support**, select **Enabled**.
|
||||
|
||||
:::note
|
||||
|
||||
This option is only available for clusters [provisioned by RKE](../launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md).
|
||||
|
||||
:::
|
||||
|
||||
4. From the **Default Pod Security Policy** drop-down, select the policy you want to apply to the cluster.
|
||||
|
||||
Rancher ships with [policies](../authentication-permissions-and-global-configuration/create-pod-security-policies.md#default-psps) of `restricted` and `unrestricted`, although you can [create custom policies](../authentication-permissions-and-global-configuration/create-pod-security-policies.md#creating-psps) as well.
|
||||
|
||||
5. Click **Save**.
|
||||
|
||||
**Result:** The pod security policy is applied to the cluster and any projects within the cluster.
|
||||
|
||||
:::note
|
||||
|
||||
Workloads already running before assignment of a pod security policy are grandfathered in. Even if they don't meet your pod security policy, workloads running before assignment of the policy continue to run.
|
||||
|
||||
To check if a running workload passes your pod security policy, clone or upgrade it.
|
||||
|
||||
:::
|
||||
-29
@@ -1,29 +0,0 @@
|
||||
---
|
||||
title: Assigning Pod Security Policies
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/manage-clusters/assign-pod-security-policies"/>
|
||||
</head>
|
||||
|
||||
_Pod Security Policies_ are objects that control security-sensitive aspects of pod specification (like root privileges).
|
||||
|
||||
## Adding a Default Pod Security Policy
|
||||
|
||||
When you create a new cluster with RKE, you can configure it to apply a PSP immediately. As you create the cluster, use the **Cluster Options** to enable a PSP. The PSP assigned to the cluster will be the default PSP for projects within the cluster.
|
||||
|
||||
:::note Prerequisite:
|
||||
|
||||
Create a Pod Security Policy within Rancher. Before you can assign a default PSP to a new cluster, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies](../authentication-permissions-and-global-configuration/create-pod-security-policies.md).
|
||||
|
||||
:::
|
||||
|
||||
:::note
|
||||
|
||||
For security purposes, we recommend assigning a PSP as you create your clusters.
|
||||
|
||||
:::
|
||||
|
||||
To enable a default Pod Security Policy, set the **Pod Security Policy Support** option to **Enabled**, and then make a selection from the **Default Pod Security Policy** drop-down.
|
||||
|
||||
When the cluster finishes provisioning, the PSP you selected is applied to all projects within the cluster.
|
||||
+6
-17
@@ -126,12 +126,11 @@ Rancher extends Kubernetes to allow the application of [Pod Security Policies](h
|
||||
|
||||
This section describes how to create a new project with a name and with optional pod security policy, members, and resource quotas.
|
||||
|
||||
1. [Name a new project.](#1-name-a-new-project)
|
||||
2. [Optional: Select a pod security policy.](#2-optional-select-a-pod-security-policy)
|
||||
3. [Recommended: Add project members.](#3-recommended-add-project-members)
|
||||
4. [Optional: Add resource quotas.](#4-optional-add-resource-quotas)
|
||||
1. [Name a new project.](#name-a-new-project)
|
||||
1. [Recommended: Add project members.](#recommended-add-project-members)
|
||||
1. [Optional: Add resource quotas.](#optional-add-resource-quotas)
|
||||
|
||||
### 1. Name a New Project
|
||||
### Name a New Project
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, go to the cluster you want to project in and click **Explore**.
|
||||
@@ -139,17 +138,7 @@ This section describes how to create a new project with a name and with optional
|
||||
1. Click **Create Project**.
|
||||
1. Enter a **Project Name**.
|
||||
|
||||
### 2. Optional: Select a Pod Security Policy
|
||||
|
||||
This option is only available if you've already created a Pod Security Policy. For instruction, see [Creating Pod Security Policies](../authentication-permissions-and-global-configuration/create-pod-security-policies.md).
|
||||
|
||||
Assigning a PSP to a project will:
|
||||
|
||||
- Override the cluster's default PSP.
|
||||
- Apply the PSP to the project.
|
||||
- Apply the PSP to any namespaces you add to the project later.
|
||||
|
||||
### 3. Recommended: Add Project Members
|
||||
### Recommended: Add Project Members
|
||||
|
||||
Use the **Members** section to provide other users with project access and roles.
|
||||
|
||||
@@ -179,7 +168,7 @@ To add members:
|
||||
:::
|
||||
1. In the **Project Permissions** section, choose a role. For more information, refer to the [documentation on project roles.](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md)
|
||||
|
||||
### 4. Optional: Add Resource Quotas
|
||||
### Optional: Add Resource Quotas
|
||||
|
||||
Resource quotas limit the resources that a project (and its namespaces) can consume. For more information, see [Resource Quotas](../../advanced-user-guides/manage-projects/manage-project-resource-quotas/manage-project-resource-quotas.md).
|
||||
|
||||
|
||||
Reference in New Issue
Block a user