Compare commits

...
Author SHA1 Message Date
Lucas Saintarbor 20fab76cfc Update CVE pages (#2174) 2026-01-29 15:43:33 -08:00
a94f94128a Merge release v2.13.2 to main (#2164)
* Sync changes from main to v2.13.2 (#2156)

* Fixed links to images

* Added documentation for using the keywords option in Chart.yaml

* Sync Product PR #587 (Add ec2:DescribeAvailabilityZones to control plane and etcd/worker permissions)

* Revert image link change, it would break the docs website

* Fixed some typos and backported docs

---------

Co-authored-by: mschroeder-fzj <m.schroeder@fz-juelich.de>
Co-authored-by: Billy Tat <btat@suse.com>
Co-authored-by: Petr Kovar <petr.kovar@suse.com>

* v2.13.2 - Rancher Manager Release Maintenance (#2160)

* Update the versions table

* Update the Rancher:webhook version mapping table

* Update the CSP adapter compatibility matrix

* Update the deprecated features table

* Update release date (#2171)

---------

Co-authored-by: mschroeder-fzj <m.schroeder@fz-juelich.de>
Co-authored-by: Billy Tat <btat@suse.com>
Co-authored-by: Petr Kovar <petr.kovar@suse.com>
2026-01-29 12:58:11 -08:00
5b60dca51d Merge release v2.12.6 to main (#2163)
* Sync changes from main to v2.12.6 (#2155)

* Fixed links to images

* Added documentation for using the keywords option in Chart.yaml

* Sync Product PR #587 (Add ec2:DescribeAvailabilityZones to control plane and etcd/worker permissions)

* Revert image link change, it would break the docs website

* Fixed some typos and backported docs

---------

Co-authored-by: mschroeder-fzj <m.schroeder@fz-juelich.de>
Co-authored-by: Billy Tat <btat@suse.com>
Co-authored-by: Petr Kovar <petr.kovar@suse.com>

* v2.12.6 - Rancher Manager Release Maintenance (#2159)

* Update the versions table

* Update the Rancher:webhook version mapping table

* Update the CSP adapter compatibility matrix

* Update the deprecated features table

* Update release date (#2170)

---------

Co-authored-by: mschroeder-fzj <m.schroeder@fz-juelich.de>
Co-authored-by: Billy Tat <btat@suse.com>
Co-authored-by: Petr Kovar <petr.kovar@suse.com>
2026-01-29 12:57:59 -08:00
78f538b5c3 Merge release v2.11.10 to main (#2162)
* Sync changes from main to v2.11.10 (#2154)

* Fixed links to images

* Added documentation for using the keywords option in Chart.yaml

* Sync Product PR #587 (Add ec2:DescribeAvailabilityZones to control plane and etcd/worker permissions)

* Revert image link change, it would break the docs website

* Fixed some typos and backported docs

---------

Co-authored-by: mschroeder-fzj <m.schroeder@fz-juelich.de>
Co-authored-by: Billy Tat <btat@suse.com>
Co-authored-by: Petr Kovar <petr.kovar@suse.com>

* v2.11.10 - Rancher Manager Release Maintenance (#2158)

* Update the versions table

* Update the Rancher:webhook version mapping table

* Update the CSP adapter compatibility matrix

* Update the deprecated features table

* Update release date (#2169)

---------

Co-authored-by: mschroeder-fzj <m.schroeder@fz-juelich.de>
Co-authored-by: Billy Tat <btat@suse.com>
Co-authored-by: Petr Kovar <petr.kovar@suse.com>
2026-01-29 12:57:48 -08:00
b6a5fcc2af Merge release v2.10.11 to main (#2173)
* Sync changes from main to v2.10.11 (#2153)

* Fixed links to images

* Added documentation for using the keywords option in Chart.yaml

* Sync Product PR #587 (Add ec2:DescribeAvailabilityZones to control plane and etcd/worker permissions)

* Revert image link change, it would break the docs website

* Fixed some typos and backported docs

---------

Co-authored-by: mschroeder-fzj <m.schroeder@fz-juelich.de>
Co-authored-by: Billy Tat <btat@suse.com>
Co-authored-by: Petr Kovar <petr.kovar@suse.com>

* v2.10.11 - Rancher Manager Release Maintenance (#2157)

* Update the Rancher:webhook version mapping table

* Update the CNI popularity table

* Update the versions table

* Update the CSP adapter compatibility matrix

* Update the deprecated features table

* Update release date (#2168)

---------

Co-authored-by: Lucas Saintarbor <lucas.saintarbor@suse.com>
Co-authored-by: mschroeder-fzj <m.schroeder@fz-juelich.de>
Co-authored-by: Petr Kovar <petr.kovar@suse.com>
2026-01-29 12:57:36 -08:00
Petr Kovar ab234cc365 Merge pull request #2113 from mschroeder-fzj/main
Creating Apps: Added doc for `keywords`
2026-01-27 16:26:47 +01:00
Marcel Schröder 6dc122f0f9 Fixed some typos and backported docs 2026-01-26 07:27:35 +01:00
Marcel Schröder 2c2d1fd70c Revert image link change, it would break the docs website 2026-01-26 07:14:59 +01:00
mschroeder-fzj 385a493e52 Merge branch 'rancher:main' into main 2026-01-26 07:03:54 +01:00
Billy Tat d870a1a12a Merge pull request #2148 from btat/product-sync/pr587-ec2-permissions
Sync Product PR #587 (Add ec2:DescribeAvailabilityZones to control plane and etcd/worker permissions)
2026-01-23 09:48:39 -08:00
Petr Kovar 3d9908ed90 Merge branch 'main' into main 2026-01-20 16:26:50 +01:00
Billy Tat be7c002fc6 Merge pull request #2150 from rancher/revert-2146-add-fossa-workflow
Revert "Add FOSSA scanning workflow"
2026-01-16 13:45:09 -08:00
Billy Tat c5aac3c2ea Revert "Add FOSSA scanning workflow" 2026-01-16 13:10:12 -08:00
Billy Tat 2a925479f5 Sync Product PR #587 (Add ec2:DescribeAvailabilityZones to control plane and etcd/worker permissions) 2026-01-15 16:14:25 -08:00
Sunil Singh 3db5dcfe5b Merge pull request #2146 from macedogm/add-fossa-workflow
Add FOSSA scanning workflow
2026-01-14 08:34:53 -08:00
Guilherme Macedo 493918ef4b Add FOSSA scanning workflow
Signed-off-by: Guilherme Macedo <guilherme@gmacedo.com>
2026-01-13 23:08:44 -03:00
Billy Tat b9dc7cf45f Merge pull request #2117 from axeal/patch-2
Clarify JSON array format for OIDC groups and full_group_path claims
2026-01-13 15:56:16 -08:00
Billy Tat 50a89fceea Apply to other versions 2026-01-13 15:22:44 -08:00
Alex Seymour c13e9c7023 Clarify JSON array format for OIDC groups and full_group_path claims
Clarify JSON array format for OIDC groups and full_group_path claims, after a recent case where an issue occurred as a result of the groups claim formatted as a comma-separated string
2026-01-13 15:15:41 -08:00
Billy Tat 86ce745693 Merge pull request #2139 from btat/copyright
Bump copyright year
2026-01-12 16:24:10 -08:00
Billy Tat ea4b542e49 Bump copyright year 2026-01-12 15:02:56 -08:00
mschroeder-fzj 5519e07a14 Merge branch 'rancher:main' into main 2026-01-12 09:29:20 +01:00
Petr Kovar 607605ef8c Merge pull request #2119 from rancher/copilot/update-deprecation-policy-links
Fix deprecated deprecation policy link in FAQ
2026-01-08 20:35:04 +01:00
Petr Kovar 6c6d269350 Merge branch 'main' into copilot/update-deprecation-policy-links 2026-01-08 20:00:00 +01:00
mschroeder-fzj 4bb5fd9918 Merge branch 'rancher:main' into main 2026-01-05 11:42:24 +01:00
Billy Tat 1db0a99873 Merge pull request #2133 from btat/fix-checkmark
Fix checkmark entity
2025-12-30 09:21:16 -08:00
Billy Tat 613ac34951 Fix checkmark entity 2025-12-30 08:29:25 -08:00
Billy Tat 8d0683cf27 Merge pull request #2130 from jmeza-xyz/etcd-tuning-fix-typo
[docs] etcd tuning fix typo etcd-args
2025-12-19 16:18:50 -08:00
Sunil Singh 8c8388e576 Merge pull request #2131 from sunilarjun/v2.13.1-registry-note
Adding admonition for registry issue v2.13.1
2025-12-19 15:13:48 -08:00
Sunil Singh 8b903fb7e6 Adding admonition for registry issue v2.13.1
Signed-off-by: Sunil Singh <sunil.singh@suse.com>
2025-12-19 14:37:40 -08:00
Meza e4ef173aef [docs] etcd tuning fix typos etcd-args
Signed-off-by: Meza <meza-xyz@proton.me>
2025-12-19 15:39:32 -05:00
Meza 941e23dbc5 [docs] Update etcd tuning with incorrect RKE1 references (#2128)
* [docs] Update etcd tuning with incorrect RKE1 references

Signed-off-by: Meza <meza-xyz@proton.me>

* Update versioned 2.12/2.13 and zh docs

Signed-off-by: Meza <meza-xyz@proton.me>

* Updated zh current doc

Signed-off-by: Meza <meza-xyz@proton.me>

---------

Signed-off-by: Meza <meza-xyz@proton.me>
2025-12-19 10:21:40 -08:00
Sunil Singh 50de72dac8 Merge pull request #2127 from rancher/v2.13.1
Merge release v2.13.1 into main
2025-12-18 19:28:07 -08:00
Sunil Singh bd5ce6a698 Merge pull request #2126 from rancher/v2.12.5
Merge release v2.12.5 into main
2025-12-18 19:27:48 -08:00
Sunil Singh 6b578c03b8 Merge pull request #2125 from rancher/v2.11.9
Merge release v2.11.9 into main
2025-12-18 19:27:32 -08:00
Petr Kovar 3e84995a70 Merge pull request #2123 from pmkovar/v2.11.9-maintenance
v2.11.9 - Rancher Manager Release Maintenance
2025-12-18 18:03:09 +01:00
Petr Kovar 73eba84c8f Merge pull request #2122 from pmkovar/v2.12.5-maintenance
v2.12.5 - Rancher Manager Release Maintenance
2025-12-18 18:02:29 +01:00
Petr Kovar 83169414e0 Merge pull request #2121 from pmkovar/v2.13.1-maintenance
v2.13.1 - Rancher Manager Release Maintenance
2025-12-18 18:01:58 +01:00
Petr Kovar 59c6d18303 Apply suggestions from code review 2025-12-18 16:19:48 +01:00
Petr Kovar cc971f12cd Apply suggestions from code review 2025-12-18 16:18:45 +01:00
Petr Kovar 56217388e0 Apply suggestions from code review 2025-12-18 16:17:39 +01:00
Petr Kovar 4038b6b6a0 Update _cni-popularity.md 2025-12-16 20:13:07 +01:00
Petr Kovar f3ebddde6e v2.11.9 - Rancher Manager Release Maintenance
Helps #2106.
2025-12-16 19:35:49 +01:00
Petr Kovar 8dc10af3d1 v2.12.5 - Rancher Manager Release Maintenance
Helps #2107.
2025-12-16 19:22:53 +01:00
Petr Kovar 8a705b1d66 v2.13.1 - Rancher Manager Release Maintenance
Helps #2108.
2025-12-16 17:44:38 +01:00
Silvio Moioli 7aabf39e2c Merge branch 'main' into copilot/update-deprecation-policy-links 2025-12-16 08:57:52 +01:00
Jonathan Crowther 033a6ecb52 Make the projects workflow page reference the backingNamespace field (#2075)
* Make the projects workflow page reference the backingNamespace field

* Add suggestions

* Fix typo
2025-12-15 12:56:35 -08:00
copilot-swe-agent[bot]andmoio d5155ccdee Update deprecation policy links to SUSE Rancher Prime page
Co-authored-by: moio <250541+moio@users.noreply.github.com>
2025-12-12 09:29:25 +00:00
copilot-swe-agent[bot] 8e43347812 Initial plan 2025-12-12 09:25:21 +00:00
mschroeder-fzj d8c3493599 Merge branch 'rancher:main' into main 2025-12-09 08:14:00 +01:00
Billy Tat d69bad7fd4 Merge pull request #2114 from btat/self-ref-link
Remove self-referencing link
2025-12-03 09:09:46 -08:00
Billy Tat cb8c124163 Remove self-referencing link 2025-11-28 16:38:25 -08:00
mschroeder-fzj 3eb8905153 Added documentation for using the keywords option in Chart.yaml 2025-11-27 09:36:51 +01:00
mschroeder-fzj 66a6f2019d Fixed links to images 2025-11-27 09:36:16 +01:00
Jake Hyde abf80148ac Add docs for tls-additional (#1981)
* Add docs for tls-additional

* Address review comments

* Add tls-additional docs to previous versions
2025-11-26 15:15:30 -08:00
Meza 49fa9264c4 Fix broken indentation in api workflow docs (#2110)
Signed-off-by: Meza <meza-xyz@proton.me>
2025-11-26 11:32:19 -08:00
+4 24fc5a657c Merge release v2.13.0 to main (#2091)
* Sync main to v2.13.0 (#2065)

* It's bad form to ask users to pass something they just curled from the internet directly to sh

Updated the instructions for uninstalling the rancher-system-agent to use a temporary script file instead of piping directly to sh.

* doc(rancher-security): improve structure and content to latest, v2.13-preview and v2.12 (#2024)

- add Rancher Kubernetes Distributions (K3s/RKE2) Self-Assessment and Hardening Guide section
- add kubernetes cluster security best practices link to rancher-security section
- add k3s-selinux and update selinux-rpm details
- remove rhel/centos 7 support

Signed-off-by: Andy Pitcher <andy.pitcher@suse.com>

* Updating across supported versions and translations.

Signed-off-by: Sunil Singh <sunil.singh@suse.com>

---------

Signed-off-by: Andy Pitcher <andy.pitcher@suse.com>
Signed-off-by: Sunil Singh <sunil.singh@suse.com>
Co-authored-by: Tejeev <tj@rancher.com>
Co-authored-by: Andy Pitcher <andy.pitcher@suse.com>
Co-authored-by: Sunil Singh <sunil.singh@suse.com>

* Update roletemplate aggregation doc and version information

* Add versioned docs

* Remove ext token and kubeconfig feature flag sections and document bearer Token

* Update corresponding v2.13 pages

* update doc for pni in gke

* Adding reverted session idle information from PR 1653

Signed-off-by: Sunil Singh <sunil.singh@suse.com>

* [2.13.0] Add versions table entry

* [2.13.0] Add webhook version

* [2.13.0] Add CSP Adapter version

* [2.13.0] Add deprecated feature table entry

* [2.13.0] Update CNI popularity stats

* Update GKE Cluster Configuration for Project Network Isolation instructions

* Fix link and port to 2.13

* [2.13.0] Add Swagger JSON

* [v2.13.0] Add info about Azure AD Roles claims (#2079)

* Add info about Azure AD roles claims compatibility

* Apply suggestions from code review

Co-authored-by: Sunil Singh <sunil.singh@suse.com>

* Add suggestions to v2.13

---------

Co-authored-by: Sunil Singh <sunil.singh@suse.com>

* [2.13.0] Remove preview designation

* user public api docs (#2069)

* user public api docs

* Apply suggestions from code review

Co-authored-by: Andreas Kupries <akupries@suse.com>

* Apply suggestions from code review

Co-authored-by: Peter Matseykanets <pmatseykanets@gmail.com>

* explain plaintext is never stored

* add users 2.13 versioned docs

* remove extra ```

* Apply suggestions from code review

Co-authored-by: Lucas Saintarbor <lucas.saintarbor@suse.com>

* add space before code block

---------

Co-authored-by: Andreas Kupries <akupries@suse.com>
Co-authored-by: Peter Matseykanets <pmatseykanets@gmail.com>
Co-authored-by: Lucas Saintarbor <lucas.saintarbor@suse.com>

* support IPv6 (#2041)

* [v2.13.0] Add Configure GitHub App page (#2081)

* Add Configure GitHub App page

* Apply suggestions from code review

Co-authored-by: Billy Tat <btat@suse.com>

* Fix header/GH URL & add suggestions to v2.13

* Apply suggestions from code review

Co-authored-by: Petr Kovar <pknbe@volny.cz>

* Apply suggestions from code review to v2.13

* Add note describing why to use Installation ID

* Apply suggestions from code review

Co-authored-by: Billy Tat <btat@suse.com>

---------

Co-authored-by: Billy Tat <btat@suse.com>
Co-authored-by: Petr Kovar <pknbe@volny.cz>

* [v2.13.0] Add info about Generic OIDC Custom Mapping (#2080)

* Add info about Generic OIDC Custom Mapping

* Apply suggestions from code review

Co-authored-by: Sunil Singh <sunil.singh@suse.com>
Co-authored-by: Billy Tat <btat@suse.com>

* Apply suggestions from code review

Co-authored-by: Sunil Singh <sunil.singh@suse.com>
Co-authored-by: Billy Tat <btat@suse.com>

* Add suggestions to v2.13

* Remove repetitive statement in intro

* Move Prereq intro/note to appropriate section

* Fix formatting, UI typo, add Custom Claims section under Configuration Reference section

* Add section about how a custom groups claim works / note about search limitations for groups in RBAC

---------

Co-authored-by: Sunil Singh <sunil.singh@suse.com>
Co-authored-by: Billy Tat <btat@suse.com>

* [v2.13.0] Add info about OIDC SLO support (#2086)

* Add shared file covering OIDC SLO support to OIDC auth pages

* Ad How to get the End Session Endpoint steps

* Add generic curl exampleto retrieve end_session_endpoint

* [2.13.0] Bump release date

---------

Signed-off-by: Andy Pitcher <andy.pitcher@suse.com>
Signed-off-by: Sunil Singh <sunil.singh@suse.com>
Co-authored-by: Lucas Saintarbor <lucas.saintarbor@suse.com>
Co-authored-by: Tejeev <tj@rancher.com>
Co-authored-by: Andy Pitcher <andy.pitcher@suse.com>
Co-authored-by: Sunil Singh <sunil.singh@suse.com>
Co-authored-by: Jonathan Crowther <jonathan.crowther@suse.com>
Co-authored-by: Peter Matseykanets <peter.matseykanets@suse.com>
Co-authored-by: Petr Kovar <petr.kovar@suse.com>
Co-authored-by: Krunal Hingu <krunal.hingu222@gmail.com>
Co-authored-by: Raul Cabello Martin <raul.cabello@suse.com>
Co-authored-by: Andreas Kupries <akupries@suse.com>
Co-authored-by: Peter Matseykanets <pmatseykanets@gmail.com>
Co-authored-by: Jack Luo <jiaqi.luo@suse.com>
Co-authored-by: Petr Kovar <pknbe@volny.cz>
2025-11-25 10:51:39 -08:00
Billy TatandLucas Saintarbor 94197793cb Merge release v2.12.4 to main (#2090)
* [2.12.4] Add versions table entry

* [2.12.4] Bump webhook table entry

* [2.12.4] Add deprecated feature table entry

* [2.12.4] Add CSP Adapter table entry

* Fix version availability - no longer has Community

Co-authored-by: Lucas Saintarbor <lucas.saintarbor@suse.com>

---------

Co-authored-by: Lucas Saintarbor <lucas.saintarbor@suse.com>
2025-11-24 17:43:12 -08:00
Billy Tat 28fa33e752 Merge pull request #2089 from rancher/v2.11.8
Merge release v2.11.8 to main
2025-11-24 17:04:13 -08:00
Petr Kovar b3c79206b3 Merge pull request #1953 from OdedNeuhaus/patch-1
Scale down the original Rancher server
2025-11-24 19:56:49 +01:00
Billy Tat 81f32d6a4c Merge pull request #2083 from btat/v2.11.8-maintenance
v2.11.8 maintenance tasks
2025-11-19 15:00:33 -08:00
Billy Tat ccdc8cecfa Merge pull request #2072 from pmkovar/backport_docs.sh
Add backport_docs.sh
2025-11-19 14:45:13 -08:00
Billy TatandLucas Saintarbor ea88c5ed74 Fix version typo
Co-authored-by: Lucas Saintarbor <lucas.saintarbor@suse.com>
2025-11-19 07:59:10 -08:00
Billy Tat f10c1c630a [2.11.8] Add CSP Adapter table entry 2025-11-18 17:12:21 -08:00
Billy Tat efd1a027cc [2.11.8] Add deprecated feature table entry 2025-11-18 17:12:21 -08:00
Billy Tat 592c6e02cb [2.11.8] Bump webhook version 2025-11-18 17:12:16 -08:00
Billy Tat 2ca8417958 [2.11.8] Add versions table entry 2025-11-18 15:54:11 -08:00
Petr Kovar 6e2f0ddfc0 Add backport_docs.sh
A script to backport changes (added, modified, and removed files)
from 'docs/' and 'sidebars.js' to their versioned counterparts.
2025-11-11 17:23:07 +01:00
Petr Kovar 4372563bb6 Merge pull request #2055 from masap/fix-2054
Fix difference beteween `psa-config-templates.md` and `psa-restricted-exemptions.md`
2025-11-10 19:31:08 +01:00
Petr Kovar c899b6563b Backport changes 2025-11-10 19:09:24 +01:00
Petr Kovar ce6faea156 Merge branch 'main' into patch-1 2025-11-10 19:08:11 +01:00
Gabriel Blais-DuchesneandLucas Saintarbor 764dbfd2e2 Fix v1.29 in-tree provider usage instructions for Azure (#2033)
* Update azure.md for in-tree cloud providers in v1.29

Correct 'DisableKubeletCloudCredentialProvider' feature gate name to 'DisableKubeletCloudCredentialProviders'. Add both feature gates in the argument for Kubelet, Controller Manager and API Server since both are required in all of these components in v1.29. Also added the Cloud Provider Integration changes blog post for more details along with an example of the argument.

* Add v1.29 Azure in-tree provider details on versioned docs compatible with v1.29

* Apply new link to upstream documentation

Apply new link to upstream documentation for the Azure in-tree cloud providers.

Co-authored-by: Lucas Saintarbor <lucas.saintarbor@suse.com>

* Added Azure in-tree provider corrections to 2.13 docs

---------

Co-authored-by: Lucas Saintarbor <lucas.saintarbor@suse.com>
2025-11-07 15:21:49 -08:00
Petr Kovar 0167f01846 Merge branch 'main' into fix-2054 2025-11-05 18:49:57 +01:00
Sunil Singh 53df2febeb Merge pull request #2052 from Tejeev/patch-6
It's bad form to ask users to pass something they just curled from th…
2025-11-03 15:44:23 -08:00
Sunil Singh 2a36becbeb Updating across supported versions and translations.
Signed-off-by: Sunil Singh <sunil.singh@suse.com>
2025-11-03 15:11:31 -08:00
Andy Pitcher dae5fda314 doc(rancher-security): improve structure and content to latest, v2.13-preview and v2.12 (#2024)
- add Rancher Kubernetes Distributions (K3s/RKE2) Self-Assessment and Hardening Guide section
- add kubernetes cluster security best practices link to rancher-security section
- add k3s-selinux and update selinux-rpm details
- remove rhel/centos 7 support

Signed-off-by: Andy Pitcher <andy.pitcher@suse.com>
2025-10-31 09:25:39 -07:00
Masashi Honma 85eada02ef Fix difference beteween psa-config-templates.md and psa-restricted-exemptions.md
Fixes #2054.

Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
2025-10-29 17:12:48 +09:00
Billy Tat 56deac4918 Merge pull request #2053 from btat/v2.13-preview
Add v2.13 preview docs
2025-10-27 15:37:47 -07:00
Billy Tat 51a03551a5 Add v2.13 preview docs 2025-10-24 16:06:44 -07:00
Tejeev adb2726735 It's bad form to ask users to pass something they just curled from the internet directly to sh
Updated the instructions for uninstalling the rancher-system-agent to use a temporary script file instead of piping directly to sh.
2025-10-24 16:26:42 -06:00
Petr Kovar 7d899ad89e Merge branch 'main' into patch-1 2025-09-29 22:11:54 +02:00
Oded Neuhaus 73363534e8 Merge branch 'main' into patch-1 2025-08-21 23:31:41 +03:00
Oded NeuhausandPetr Kovar 73a2dc4671 Update docs/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md
Co-authored-by: Petr Kovar <pknbe@volny.cz>
2025-08-21 23:31:17 +03:00
Oded NeuhausandPetr Kovar b43b19fda2 Update docs/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md
Co-authored-by: Petr Kovar <pknbe@volny.cz>
2025-08-21 23:31:03 +03:00
OdedNeuhaus 5046e36283 Update migrate-rancher-to-new-cluster.md
I was migrating my Rancher instance to a new cluster running RKE2 (the original local cluster was running RKE1),
if followed the steps as described in https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster

I found out that after i made the change on my DNS server - all the clusters that were registrated to my original Rancher server - were stuck on updating in the new Rancher server.

I figured out that the cattle-cluster-agents were still communicating with the old Rancher server, and had to be restarted, or fail their connection with it - in order to make them communicate with the new Rancher server.

I assume that more Rancher users can experience this problem, and this add to the Rancher migration guide will make their migrating operation easier.
2025-08-11 20:20:22 +03:00
1030 changed files with 104650 additions and 961 deletions
+1 -1
View File
@@ -93,7 +93,7 @@ Subsequent executions will check for updated dependencies, if there are none, it
License
=======
Copyright (c) 2014-2025 [SUSE, LLC.](https://www.suse.com/)
Copyright (c) 2014-2026 [SUSE, LLC.](https://www.suse.com/)
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
@@ -37,8 +37,7 @@ apiVersion: management.cattle.io/v3
kind: Project
metadata:
annotations:
field.cattle.io/creatorId:
user-id
field.cattle.io/creatorId: user-id
generateName: p-
namespace: c-m-abcde
spec:
@@ -37,8 +37,7 @@ apiVersion: management.cattle.io/v3
kind: Project
metadata:
annotations:
field.cattle.io/creatorId:
user-id
field.cattle.io/creatorId: user-id
generateName: p-
namespace: c-m-abcde
spec:
+320
View File
@@ -0,0 +1,320 @@
#!/bin/bash
# backport_docs.sh
#
# A script to backport changes (added, modified, and removed files)
# from 'docs/' and 'sidebars.js' to their versioned counterparts.
# --- Configuration ---
DOCS_DIR="docs"
VERSIONED_DIR="versioned_docs"
SIDEBARS_SOURCE_FILE="sidebars.js"
SIDEBARS_VERSIONED_DIR="versioned_sidebars"
# --- Colors ---
GREEN="\033[0;32m"
RED="\033[0;31m"
YELLOW="\033[0;33m"
BLUE="\033[0;34m"
RESET="\033[0m"
# --- Help Message ---
usage() {
echo -e "${GREEN}Usage:${RESET} $0 [version1] [version2] ..."
echo
echo -e "${YELLOW}Description:${RESET}"
echo " Backports changes (added, modified, removed) from the '$DOCS_DIR/' directory"
echo " and modifications from '$SIDEBARS_SOURCE_FILE' to specified versioned directories."
echo
echo -e "${YELLOW}Arguments:${RESET}"
echo " [version] (Optional) One or more specific versions to backport to."
echo " If no versions are provided, the script attempts to backport"
echo " to all valid versions found in '$VERSIONED_DIR/'."
echo
echo -e "${YELLOW}Options:${RESET}"
echo " -h, --help Show this help message."
echo
echo -e "${YELLOW}Example (all versions):${RESET}"
echo " $0"
echo
echo -e "${YELLOW}Example (specific versions):${RESET}"
echo " $0 version-2.12 version-2.13"
}
# --- Argument Parsing ---
if [[ "$1" == "-h" || "$1" == "--help" ]]; then
usage
exit 0
fi
TARGET_VERSIONS=("$@")
# --- Sanity Checks ---
if [ ! -d "$DOCS_DIR" ]; then
echo -e "${RED}Error:${RESET} Directory '$DOCS_DIR' not found."
echo "Please run this script from the repository root."
exit 1
fi
if [ ! -d "$VERSIONED_DIR" ]; then
echo -e "${RED}Error:${RESET} Directory '$VERSIONED_DIR' not found."
echo "Please run this script from the repository root."
exit 1
fi
if [ ! -f "$SIDEBARS_SOURCE_FILE" ]; then
echo -e "${RED}Error:${RESET} Source file '$SIDEBARS_SOURCE_FILE' not found."
echo "Please run this script from the repository root."
exit 1
fi
if [ ! -d "$SIDEBARS_VERSIONED_DIR" ]; then
echo -e "${RED}Error:${RESET} Directory '$SIDEBARS_VERSIONED_DIR' not found."
echo "Please run this script from the repository root."
exit 1
fi
# --- Validate Provided Versions ---
# This block only runs if arguments were passed
if [ ${#TARGET_VERSIONS[@]} -gt 0 ]; then
echo -e "${BLUE}Validating provided versions...${RESET}"
for version in "${TARGET_VERSIONS[@]}"; do
# Fail if the argument looks like an option (starts with -)
if [[ "$version" == -* ]]; then
echo -e "${RED}Error:${RESET} Unknown option '$version'."
echo "Use -h or --help for usage."
exit 1
fi
if [ ! -d "$VERSIONED_DIR/$version" ]; then
echo -e "${RED}Error:${RESET} Provided version '$version' is not a valid directory under '$VERSIONED_DIR/'."
exit 1
fi
done
echo -e "${GREEN}All provided versions are valid.${RESET}"
echo # Newline
fi
# --- Find Target Versions (if not specified) ---
# This block only runs if NO arguments were passed
if [ ${#TARGET_VERSIONS[@]} -eq 0 ]; then
echo -e "${BLUE}No versions specified. Detecting all valid versions in '$VERSIONED_DIR'...${RESET}"
# Find all subdirectories
for dir in "$VERSIONED_DIR"/*/; do
# Check if the directory exists and is a directory
if [ -d "$dir" ]; then
# Check if the directory contains any file *other* than notice.md
# We use -print -quit to stop find immediately after the first match
if find "$dir" -type f -not -name "notice.md" -print -quit | grep -q .; then
# It's a valid version, add its basename
TARGET_VERSIONS+=("$(basename "$dir")")
fi
fi
done
fi
if [ ${#TARGET_VERSIONS[@]} -eq 0 ]; then
echo -e "${RED}Error:${RESET} No target versions found or specified."
exit 1
fi
echo -e "${GREEN}Target versions:${RESET} ${TARGET_VERSIONS[*]}"
echo # Newline
# --- Find Files to Backport (Docs) ---
echo -e "${BLUE}Finding modified/new/removed files in '$DOCS_DIR'...${RESET}"
# Find staged (cached) and unstaged (HEAD) changes (Added, Modified, or Deleted)
FILES_TO_BACKPORT=$( (git diff --name-only --diff-filter=AMD HEAD -- "$DOCS_DIR"; \
git diff --name-only --diff-filter=AMD --cached -- "$DOCS_DIR") \
| sort -u)
if [ -z "$FILES_TO_BACKPORT" ]; then
echo -e "${GREEN}No modified, new, or removed files found in '$DOCS_DIR'. Nothing to do.${RESET}"
else
echo -e "${GREEN}Files to backport:${RESET}"
echo -e "${FILES_TO_BACKPORT}"
echo # Newline
# --- Main Logic (Docs) ---
echo -e "${BLUE}Starting backport process for docs...${RESET}"
# Use 'read' to handle file paths
echo "$FILES_TO_BACKPORT" | while IFS= read -r file; do
if [ -z "$file" ]; then # Skip empty lines
continue
fi
echo -e "${YELLOW}Processing file:${RESET} $file"
# Get the relative path inside 'docs/'
# e.g., 'docs/guides/intro.md' -> 'guides/intro.md'
REL_PATH="${file#$DOCS_DIR/}"
if [ "$REL_PATH" == "$file" ]; then
echo -e " ${RED}Error:${RESET} Could not determine relative path for '$file'. Skipping."
continue
fi
# Check if the file exists in the source.
# If it does, it's ADDED or MODIFIED.
# If it doesn't, it's DELETED.
if [ -f "$file" ]; then
# --- LOGIC FOR ADDED/MODIFIED FILES ---
PATCH_DATA_STAGED=$(git diff --cached -- "$file")
PATCH_DATA_UNSTAGED=$(git diff -- "$file")
# Loop through each target version
for version in "${TARGET_VERSIONS[@]}"; do
TARGET_FILE="$VERSIONED_DIR/$version/$REL_PATH"
TARGET_DIR=$(dirname "$TARGET_FILE")
# Check if the target *versioned file* exists
if [ ! -f "$TARGET_FILE" ]; then
# File doesn't exist in the versioned directory.
# This is a NEW file. Copy it directly.
echo -e " ${BLUE}Backporting as new file to version:${RESET} $version"
# Ensure target directory exists
mkdir -p "$TARGET_DIR"
if [ $? -ne 0 ]; then
echo -e " ${RED}Error:${RESET} Could not create directory '$TARGET_DIR'. Skipping."
continue
fi
# Copy the new file
cp "$file" "$TARGET_FILE"
if [ $? -eq 0 ]; then
echo -e " ${GREEN}Copied:${RESET} $file -> $TARGET_FILE"
else
echo -e " ${RED}Error:${RESET} Failed to copy '$file' to '$TARGET_FILE'."
fi
else
# File *does* exist. Patch it using the deltas.
echo -e " ${BLUE}Backporting changes to version:${RESET} $version"
patch_applied=false
patch_failed=false
if [ -n "$PATCH_DATA_STAGED" ]; then
echo "$PATCH_DATA_STAGED" | patch --no-backup "$TARGET_FILE" - > /dev/null 2>&1
if [ $? -eq 0 ]; then
echo -e " ${GREEN}Patched (staged):${RESET} $TARGET_FILE"
patch_applied=true
else
echo -e " ${RED}Error (staged):${RESET} Failed to patch '$TARGET_FILE'."
patch_failed=true
fi
fi
if [ -n "$PATCH_DATA_UNSTAGED" ]; then
echo "$PATCH_DATA_UNSTAGED" | patch --no-backup "$TARGET_FILE" - > /dev/null 2>&1
if [ $? -eq 0 ]; then
echo -e " ${GREEN}Patched (unstaged):${RESET} $TARGET_FILE"
patch_applied=true
else
echo -e " ${RED}Error (unstaged):${RESET} Failed to patch '$TARGET_FILE'."
patch_failed=true
fi
fi
if [ "$patch_failed" = true ]; then
echo -e " ${YELLOW}Tip:${RESET} This file may have diverged. Please review manually."
elif [ "$patch_applied" = false ]; then
echo -e " ${GREEN}Skipped:${RESET} $TARGET_FILE (already in sync)"
fi
fi
done # end version loop
else
# --- LOGIC FOR DELETED FILES ---
echo -e " ${BLUE}File was deleted. Propagating deletion...${RESET}"
# Loop through each target version
for version in "${TARGET_VERSIONS[@]}"; do
TARGET_FILE="$VERSIONED_DIR/$version/$REL_PATH"
if [ -f "$TARGET_FILE" ]; then
rm "$TARGET_FILE"
if [ $? -eq 0 ]; then
echo -e " ${GREEN}Deleted:${RESET} $TARGET_FILE"
else
echo -e " ${RED}Error:${RESET} Failed to delete '$TARGET_FILE'."
fi
else
echo -e " ${GREEN}Skipped:${RESET} $TARGET_FILE (already deleted)"
fi
done # end version loop
fi # end add/modify/delete check
echo # Add a newline for readability
done # end file loop
fi
echo # Newline
# --- Main Logic (Sidebars) ---
echo -e "${BLUE}Checking for sidebars changes...${RESET}"
# Check for staged or unstaged MODIFICATIONS to the source sidebars file
# We only care about modifications (M), not additions or deletions.
SIDEBARS_CHANGED=$( (git diff --name-only --diff-filter=M HEAD -- "$SIDEBARS_SOURCE_FILE"; \
git diff --name-only --diff-filter=M --cached -- "$SIDEBARS_SOURCE_FILE") \
| sort -u)
if [ -z "$SIDEBARS_CHANGED" ]; then
echo -e "${GREEN}No modifications found in '$SIDEBARS_SOURCE_FILE'. Skipping sidebars backport.${RESET}"
else
echo -e "${YELLOW}Processing file:${RESET} $SIDEBARS_SOURCE_FILE"
# Get the patch data for STAGED changes (vs. HEAD)
PATCH_DATA_STAGED=$(git diff --cached -- "$SIDEBARS_SOURCE_FILE")
# Get the patch data for UNSTAGED changes (vs. Index)
PATCH_DATA_UNSTAGED=$(git diff -- "$SIDEBARS_SOURCE_FILE")
for version in "${TARGET_VERSIONS[@]}"; do
# The $version variable already contains "version-X.Y"
TARGET_FILE="$SIDEBARS_VERSIONED_DIR/${version}-sidebars.json"
# Check if the corresponding versioned sidebars file exists
if [ ! -f "$TARGET_FILE" ]; then
echo -e " ${YELLOW}Skipped:${RESET} $TARGET_FILE (not found)"
continue
fi
echo -e " ${BLUE}Backporting changes to:${RESET} $TARGET_FILE"
patch_applied=false
patch_failed=false
if [ -n "$PATCH_DATA_STAGED" ]; then
echo "$PATCH_DATA_STAGED" | patch --no-backup "$TARGET_FILE" - > /dev/null 2>&1
if [ $? -eq 0 ]; then
echo -e " ${GREEN}Patched (staged):${RESET} $TARGET_FILE"
patch_applied=true
else
echo -e " ${RED}Error (staged):${RESET} Failed to patch '$TARGET_FILE'."
patch_failed=true
fi
fi
if [ -n "$PATCH_DATA_UNSTAGED" ]; then
echo "$PATCH_DATA_UNSTAGED" | patch --no-backup "$TARGET_FILE" - > /dev/null 2>&1
if [ $? -eq 0 ]; then
echo -e " ${GREEN}Patched (unstaged):${RESET} $TARGET_FILE"
patch_applied=true
else
echo -e " ${RED}Error (unstaged):${RESET} Failed to patch '$TARGET_FILE'."
patch_failed=true
fi
fi
if [ "$patch_failed" = true ]; then
echo -e " ${YELLOW}Tip:${RESET} This file may have diverged. Please review manually."
elif [ "$patch_applied" = false ]; then
echo -e " ${GREEN}Skipped:${RESET} $TARGET_FILE (already in sync)"
fi
echo # Add a newline
done # end version loop
fi
echo # Newline
echo -e "${GREEN}Backport complete.${RESET}"
+1 -1
View File
@@ -15,4 +15,4 @@ At this time, not all Rancher resources are available through the Rancher Kubern
import ApiDocMdx from '@theme/ApiDocMdx';
<ApiDocMdx id="rancher-api-v2-12" />
<ApiDocMdx id="rancher-api-v2-13" />
+12 -6
View File
@@ -60,17 +60,23 @@ This feature affects all tokens which include, but are not limited to, the follo
These global settings affect Rancher token behavior.
| Setting | Description |
| ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes) | TTL in minutes on a user auth session token. |
| [`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) | Default TTL applied to all kubeconfig tokens except for tokens [generated by Rancher CLI](#disable-tokens-in-generated-kubeconfigs). |
| [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes) | Max TTL for all tokens except those controlled by [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes). |
| [`kubeconfig-generate-token`](#kubeconfig-generate-token) | If true, automatically generate tokens when a user downloads a kubeconfig. |
| Setting | Description |
| ------- | ----------- |
| [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes) | TTL in minutes on a user auth session token. |
| [`auth-user-session-idle-ttl-minutes`](#auth-user-session-idle-ttl-minutes) | TTL in minutes on a user auth session token, without user activity. |
| [`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) | Default TTL applied to all kubeconfig tokens except for tokens [generated by Rancher CLI](#disable-tokens-in-generated-kubeconfigs). |
| [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes) | Max TTL for all tokens except those controlled by [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes). |
| [`kubeconfig-generate-token`](#kubeconfig-generate-token) | If true, automatically generate tokens when a user downloads a kubeconfig. |
### auth-user-session-ttl-minutes
Time to live (TTL) duration in minutes, used to determine when a user auth session token expires. When expired, the user must log in and obtain a new token. This setting is not affected by [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes). Session tokens are created when a user logs into Rancher.
### auth-user-session-idle-ttl-minutes
Time to live (TTL) without user activity for login sessions tokens, in minutes.
By default, `auth-user-session-idle-ttl-minutes` is set to the same value as [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes) (for backward compatibility). It must never exceed the value of `auth-user-session-ttl-minutes`.
### kubeconfig-default-token-ttl-minutes
Time to live (TTL) duration in minutes, used to determine when a kubeconfig token expires. When the token is expired, the API rejects the token. This setting can't be larger than [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes). This setting applies to tokens generated in a requested kubeconfig file, except for tokens [generated by Rancher CLI](#disable-tokens-in-generated-kubeconfigs). As of Rancher v2.8, the default duration is `43200`, which means that tokens expire in 30 days.
-8
View File
@@ -20,14 +20,6 @@ To get a description of the fields and structure of the Kubeconfig resource, run
kubectl explain kubeconfigs.ext.cattle.io
```
## Feature Flag
The Kubeconfigs Public API is available since Rancher v2.12.0 and is enabled by default. It can be disabled by setting the `ext-kubeconfigs` feature flag to `false`.
```sh
kubectl patch feature ext-kubeconfigs -p '{"spec":{"value":false}}'
```
## Creating a Kubeconfig
Only a **valid and active** Rancher user can create a Kubeconfig. For example, trying to create a Kubeconfig using a `system:admin` service account will lead to an error:
+21 -12
View File
@@ -25,11 +25,15 @@ spec:
EOF
```
Use `metadata.generateName` to ensure a unique project ID, but note that `kubectl apply` does not work with `metadata.generateName`, so `kubectl create` must be used instead.
When creating a new project, you have two primary options for setting the name:
- **Automatic Generation:** Use `metadata.generateName` to ensure a unique project ID. However, note that you must use `kubectl create` (instead of `kubectl apply`) with this option, as `kubectl apply` does not support it.
- **Manual Naming:** You can explicitly set the project ID using `metadata.name`. If a project with that exact name already exists, the name request is denied.
The display name seen in the UI is set by `spec.displayName`. If `spec.displayName` is not provided, the field `metadata.name` is used instead.
Set `metadata.namespace` and `spec.clusterName` to the ID for the cluster the project belongs to.
If you create a project through a cluster member account, you must include the annotation, `field.cattle.io/creatorId`, and set it to the cluster member account's user ID.
If you create a project through a cluster member account and want that account to be able to access the project, you must include the annotation `field.cattle.io/creatorId`, and set it to the cluster member account's user ID.
```bash
kubectl create -f - <<EOF
@@ -37,8 +41,7 @@ apiVersion: management.cattle.io/v3
kind: Project
metadata:
annotations:
field.cattle.io/creatorId:
user-id
field.cattle.io/creatorId: user-id
generateName: p-
namespace: c-m-abcde
spec:
@@ -47,7 +50,7 @@ spec:
EOF
```
Setting the `field.cattle.io/creatorId` field allows the cluster member account to see project resources with the `get` command and view the project in the Rancher UI. Cluster owner and admin accounts don't need to set this annotation to perform these tasks.
Setting the `field.cattle.io/creatorId` field creates a `ProjectRoleTemplateBinding` that grants the specified user the ability to see project resources with the `get` command and view the project in the Rancher UI. Cluster owner and admin accounts don't need to set this annotation to perform these tasks.
Setting the `field.cattle.io/creator-principal-name` annotation to the user's principal preserves it in a projectroletemplatebinding automatically created for the project owner.
@@ -98,9 +101,13 @@ spec:
EOF
```
### Backing Namespace
After creating the project, the field `status.backingNamespace` gets populated. This represents the namespace in the management cluster that is created to manage project related resources. Examples of resources stored in the backing namespace are [project scoped secrets](../../how-to-guides/new-user-guides/kubernetes-resources-setup/secrets.md#creating-secrets-in-projects) and [project role template bindings](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-roles).
## Adding a Member to a Project
Look up the project ID to specify the `metadata.namespace` field and `projectName` field values.
Look up the project's [backing namespace](#backing-namespace) to specify the `metadata.namespace` field value and look up the project's ID to specify the `projectName` field value.
```bash
kubectl --namespace c-m-abcde get projects
@@ -120,7 +127,7 @@ apiVersion: management.cattle.io/v3
kind: ProjectRoleTemplateBinding
metadata:
generateName: prtb-
namespace: p-vwxyz
namespace: c-m-abcde-p-vwxyz
projectName: c-m-abcde:p-vwxyz
roleTemplateName: project-member
userPrincipalName: keycloak_user://user
@@ -146,16 +153,16 @@ Create a projectroletemplatebinding for each role you want to assign to the proj
## Listing Project Members
Look up the project ID:
Look up the project backing namespace:
```bash
kubectl --namespace c-m-abcde get projects
```
to list projectroletemplatebindings in the project's namespace:
To list projectroletemplatebindings in the project's backing namespace:
```bash
kubectl --namespace p-vwxyz get projectroletemplatebindings
kubectl --namespace c-m-abcde-p-vwxyz get projectroletemplatebindings
```
## Deleting a Member From a Project
@@ -165,14 +172,14 @@ Lookup the projectroletemplatebinding IDs containing the member in the project's
Delete the projectroletemplatebinding from the project's namespace:
```bash
kubectl --namespace p-vwxyz delete projectroletemplatebindings prtb-qx874 prtb-7zw7s
kubectl --namespace c-m-abcde-p-vwxyz delete projectroletemplatebindings prtb-qx874 prtb-7zw7s
```
## Creating a Namespace in a Project
The Project resource resides in the management cluster, even if the Project is for a managed cluster. The namespaces under the project reside in the managed cluster.
On the management cluster, look up the project ID for the cluster you are administrating since it generated using `metadata.generateName`:
On the management cluster, look up the project ID for the cluster you are administrating if generated using `metadata.generateName`:
```bash
kubectl --namespace c-m-abcde get projects
@@ -208,3 +215,5 @@ kubectl --namespace c-m-abcde delete project p-vwxyz
```
Note that this command doesn't delete the namespaces and resources that formerly belonged to the project.
It does delete all project role template bindings for the projects, so recreating the project will not restore members added to the project, and you have to add users as members again.
+2 -8
View File
@@ -20,20 +20,14 @@ To get a description of the fields and structure of the Token resource, run:
kubectl explain tokens.ext.cattle.io
```
## Feature Flag
The Tokens Public API is available for Rancher v2.12.0 and later, and is enabled by default. You can disable the Tokens Public API by setting the `ext-tokens` feature flag to `false` as shown in the example `kubectl` command below:
```sh
kubectl patch feature ext-tokens -p '{"spec":{"value":false}}'
```
## Creating a Token
:::caution
The Token value is only returned once in the `status.value` field.
:::
Since Rancher v2.13.0 the `status.bearerToken` now contains a fully formed and ready-to-use Bearer token that can be used to authenticate to [Rancher API](../v3-rancher-api-guide.md).
Only a **valid and active** Rancher user can create a Token. Otherwise, you will get an error displayed (`Error from server (Forbidden)...`) when attempting to create a Token.
```bash
+187
View File
@@ -0,0 +1,187 @@
---
title: Users
---
## User Resource
The `User` resource (users.management.cattle.io) represents a user account in Rancher.
To get a description of the fields and structure of the `User` resource, run:
```sh
kubectl explain users.management.cattle.io
```
## Creating a User
Creating a local user is a two-step process: you must create the `User` resource, then provide a password via a Kubernetes `Secret`.
Only a user with sufficient permissions can create a `User` resource.
```bash
kubectl create -f -<<EOF
apiVersion: management.cattle.io/v3
kind: User
metadata:
name: testuser
displayName: "Test User"
username: "testuser"
EOF
```
The user's password must be provided in a `Secret` object within the `cattle-local-user-passwords` namespace. The Rancher webhook will automatically hash the password and update the `Secret`.
:::important
Important: The `Secret` must have the same name as the metadata.name (and username) of the `User` resource.
:::
```bash
kubectl create -f -<<EOF
apiVersion: v1
kind: Secret
metadata:
name: testuser
namespace: cattle-local-user-passwords
type: Opaque
stringData:
password: Pass1234567!
EOF
```
After the plaintext password is submitted, the Rancher-Webhook automatically hashes it, replacing the content of the `Secret`, ensuring that the plaintext password is never stored:
```yaml
apiVersion: v1
data:
password: 1c1Y4CdjlehGWFz26F414x2qoj4gch5L5OXsx35MAa8=
salt: m8Co+CfMDo5XwVl0FqYzGcRIOTgRrwFSqW8yurh5DcE=
kind: Secret
metadata:
annotations:
cattle.io/password-hash: pbkdf2sha3512
name: testuser
namespace: cattle-local-user-passwords
ownerReferences:
- apiVersion: management.cattle.io/v3
kind: User
name: testuser
uid: 663ffb4f-8178-46c8-85a3-337f4d5cbc2e
uid: bade9f0a-b06f-4a77-9a39-4284dc2349c5
type: Opaque
```
## Updating User's Password
To change a user's password, use the `PasswordChangeRequest` resource, which handles secure password updates.
```yaml
kubectl create -f -<<EOF
apiVersion: ext.cattle.io/v1
kind: PasswordChangeRequest
spec:
userID: "testuser"
currentPassword: "Pass1234567!"
newPassword: "NewPass1234567!"
EOF
```
## Listing Users
List all `User` resources in the cluster:
```sh
kubectl get users
NAME AGE
testuser 3m54s
user-4n5ws 12m
```
## Viewing a User
View a specific `User` resource by name:
```sh
kubectl get user testuser
NAME AGE
testuser 3m54s
```
## Deleting a User
Deleting a user will automatically delete the corresponding password `Secret`.
```sh
kubectl delete user testuser
user.management.cattle.io "testuser" deleted
```
## Get a Current User's Information
A client uses the `SelfUser` resource to retrieve information about the currently authenticated user without knowing their ID. The user ID is returned in the `.status.userID` field.
```bash
kubectl create -o jsonpath='{.status.userID}' -f -<<EOF
apiVersion: ext.cattle.io/v1
kind: SelfUser
EOF
testuser
```
## Refreshing a User's Group Membership
Updates to user group memberships are triggered by the `GroupMembershipRefreshRequest` resource.
:::note
Group membership is only supported for external authentication providers.
:::
### For a Single User
```bash
kubectl create -o jsonpath='{.status}' -f -<<EOF
apiVersion: ext.cattle.io/v1
kind: GroupMembershipRefreshRequest
spec:
userId: testuser
EOF
{
"conditions": [
{
"lastTransitionTime": "2025-11-10T12:01:03Z",
"message": "",
"reason": "",
"status": "True",
"type": "UserRefreshInitiated"
}
],
"summary": "Completed"
}
```
### For All Users
```bash
kubectl create -o jsonpath='{.status}' -f -<<EOF
apiVersion: ext.cattle.io/v1
kind: GroupMembershipRefreshRequest
spec:
userId: "*"
EOF
{
"conditions": [
{
"lastTransitionTime": "2025-11-10T12:01:59Z",
"message": "",
"reason": "",
"status": "True",
"type": "UserRefreshInitiated"
}
],
"summary": "Completed"
}
```
+4 -5
View File
@@ -8,7 +8,7 @@ title: Deprecated Features in Rancher
## What is Rancher's deprecation policy?
We have published our official deprecation policy in the support [terms of service](https://rancher.com/support-maintenance-terms).
The community version of Rancher follows the same deprecation policy as Rancher Prime. The official deprecation policy is documented in the [Rancher Prime Deprecation Policy](https://www.suse.com/support/rancher-prime/#Rancher-Prime-Deprecation-Policy).
## Where can I find out which features have been deprecated in Rancher?
@@ -16,10 +16,9 @@ Rancher will publish deprecated features as part of the [release notes](https://
| Patch Version | Release Date |
|---------------|---------------|
| [2.12.3](https://github.com/rancher/rancher/releases/tag/v2.12.3) | October 23, 2025 |
| [2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2) | September 25, 2025 |
| [2.12.1](https://github.com/rancher/rancher/releases/tag/v2.12.1) | August 28, 2025 |
| [2.12.0](https://github.com/rancher/rancher/releases/tag/v2.12.0) | July 30, 2025 |
| [2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2) | January 29, 2026 |
| [2.13.1](https://github.com/rancher/rancher/releases/tag/v2.13.1) | December 18, 2025 |
| [2.13.0](https://github.com/rancher/rancher/releases/tag/v2.13.0) | November 25, 2025 |
## What can I expect when a feature is marked for deprecation?
@@ -50,6 +50,38 @@ The following CLI tools are required for setting up the Kubernetes cluster. Plea
## Install the Rancher Helm Chart
:::important
**Important:** In Rancher Community v2.13.1 if your registry configuration is one of the following you may see Rancher generate the `cattle-cluster-agent` image with an incorrect `docker.io` path segment:
- Environments where a **cluster-scoped container registry** is configured for system images.
- Environments where a **global `system-default-registry`** is configured (e.g. airgap setups), even if no cluster-scoped registry is set.
**Workaround for Affected Setups:** As a workaround, override the `cattle-cluster-agent` image via the `CATTLE_AGENT_IMAGE` environment variable. This value must **not** contain any registry prefix (Rancher will handle that automatically). It should be set only to the repository and tag, for example:`rancher/rancher-agent:v2.13.1`
**Helm `install` example:**
```bash
helm install rancher rancher-latest/rancher \
...
--set extraEnv[0].name=CATTLE_AGENT_IMAGE \
--set extraEnv[0].value=rancher/rancher-agent:v2.13.1
```
**Helm `upgrade` example:**
```bash
helm upgrade rancher rancher-latest/rancher \
...
--set extraEnv[0].name=CATTLE_AGENT_IMAGE \
--set extraEnv[0].value=rancher/rancher-agent:v2.13.1
```
**Important Upgrade Note:**
The `CATTLE_AGENT_IMAGE` override is intended only as a temporary workaround for the affected configurations. Once a Rancher version is available that corrects this behavior, the `CATTLE_AGENT_IMAGE` override should be **removed** from Helm values, so that Rancher can resume managing the agent image normally and automatically track future image and tag changes. See [#53187](https://github.com/rancher/rancher/issues/53187#issuecomment-3676484603) for further information.
:::
Rancher is installed using the [Helm](https://helm.sh/) package manager for Kubernetes. Helm charts provide templating syntax for Kubernetes YAML manifest documents. With Helm, we can create configurable deployments instead of just using static files.
For systems without direct internet access, see [Air Gap: Kubernetes install](../other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md).
@@ -28,6 +28,38 @@ Note that upgrades _to_ or _from_ any chart in the [rancher-alpha repository](..
### Helm Version
:::important
**Important:** In Rancher Community v2.13.1 if your registry configuration is one of the following you may see Rancher generate the `cattle-cluster-agent` image with an incorrect `docker.io` path segment:
- Environments where a **cluster-scoped container registry** is configured for system images.
- Environments where a **global `system-default-registry`** is configured (e.g. airgap setups), even if no cluster-scoped registry is set.
**Workaround for Affected Setups:** As a workaround, override the `cattle-cluster-agent` image via the `CATTLE_AGENT_IMAGE` environment variable. This value must **not** contain any registry prefix (Rancher will handle that automatically). It should be set only to the repository and tag, for example:`rancher/rancher-agent:v2.13.1`
**Helm `install` example:**
```bash
helm install rancher rancher-latest/rancher \
...
--set extraEnv[0].name=CATTLE_AGENT_IMAGE \
--set extraEnv[0].value=rancher/rancher-agent:v2.13.1
```
**Helm `upgrade` example:**
```bash
helm upgrade rancher rancher-latest/rancher \
...
--set extraEnv[0].name=CATTLE_AGENT_IMAGE \
--set extraEnv[0].value=rancher/rancher-agent:v2.13.1
```
**Important Upgrade Note:**
The `CATTLE_AGENT_IMAGE` override is intended only as a temporary workaround for the affected configurations. Once a Rancher version is available that corrects this behavior, the `CATTLE_AGENT_IMAGE` override should be **removed** from Helm values, so that Rancher can resume managing the agent image normally and automatically track future image and tag changes. See [#53187](https://github.com/rancher/rancher/issues/53187#issuecomment-3676484603) for further information.
:::
The upgrade instructions assume you are using Helm 3.
<DeprecationHelm2 />
@@ -18,7 +18,7 @@ Some feature flags require a restart of the Rancher container. Features that req
The following is a list of feature flags available in Rancher. If you've upgraded from a previous Rancher version, you may see additional flags in the Rancher UI, such as `proxy` or `dashboard` (both [discontinued](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.5/reference-guides/installation-references/feature-flags.md)):
- `aggregated-roletemplates`: Use cluster role aggregation architecture for RoleTemplates, ProjectRoleTemplateBindings, and ClusterRoleTemplateBindings. See [Cluster Role Aggregation](../../../how-to-guides/advanced-user-guides/enable-experimental-features/cluster-role-aggregation.md) for more information.
- `aggregated-roletemplates`: Use cluster role aggregation architecture for RoleTemplates, ProjectRoleTemplateBindings, and ClusterRoleTemplateBindings. See [RoleTemplate Aggregation](../../../how-to-guides/advanced-user-guides/enable-experimental-features/role-template-aggregation.md) for more information.
- `clean-stale-secrets`: Removes stale secrets from the `cattle-impersonation-system` namespace. This slowly cleans up old secrets which are no longer being used by the impersonation system.
- `continuous-delivery`: Allows Fleet GitOps to be disabled separately from Fleet. See [Continuous Delivery.](../../../how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery.md) for more information.
- `fleet`: The Rancher provisioning framework in v2.6 and later requires Fleet. The flag will be automatically enabled when you upgrade, even if you disabled this flag in an earlier version of Rancher. See [Continuous Delivery with Fleet](../../../integrations-in-rancher/fleet/fleet.md) for more information.
@@ -61,7 +61,7 @@ The following table shows the availability and default values for some feature f
| Feature Flag Name | Default Value | Status | Available As Of | Additional Information |
| ----------------------------- | ------------- | ------------ | --------------- | ---------------------- |
| `aggregated-roletemplates` | `Disabled` | Highly experimental | v2.11.0 | This flag value is locked on install and can't be changed. |
| `aggregated-roletemplates` | `Disabled` | Experimental | v2.11.0 | This flag value is locked on install and can't be changed. |
| `clean-stale-secrets` | `Active` | GA | v2.10.2 | |
| `continuous-delivery` | `Active` | GA | v2.6.0 | |
| `external-rules` | v2.7.14: `Disabled`, v2.8.5: `Active` | Removed | v2.7.14, v2.8.5 | This flag affected [external `RoleTemplate` behavior](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#external-roletemplate-behavior). It is removed in Rancher v2.9.0 and later as the behavior is enabled by default. |
@@ -6,4 +6,4 @@ title: Installation References
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/installation-references"/>
</head>
Please see the following reference guides for other installation resources: [Rancher Helm chart options](helm-chart-options.md), [TLS settings](tls-settings.md), and [feature flags](feature-flags.md).
Please see the following reference guides for other installation resources: [Rancher Helm chart options](helm-chart-options.md), [TLS settings](tls-settings.md), and [feature flags](feature-flags.md).
@@ -25,10 +25,16 @@ Rancher needs to be installed on a supported Kubernetes version. Consult the [Ra
Regardless of version and distribution, the Kubernetes cluster must have the aggregation API layer properly configured to support the [extension API](../../../api/extension-apiserver.md) used by Rancher.
### Install Rancher on a Hardened Kubernetes cluster
### Install Rancher on a Hardened Kubernetes Cluster
If you install Rancher on a hardened Kubernetes cluster, check the [Exempting Required Rancher Namespaces](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md#exempting-required-rancher-namespaces) section for detailed requirements.
### Install Rancher on an IPv6-only or Dual-stack Kubernetes Cluster
You can deploy Rancher on an IPv6-only or dual-stack Kubernetes cluster.
For details on Rancher’s IPv6-only and dual-stack support, see the [IPv4/IPv6 Dual-stack](../../../reference-guides/dual-stack.md) page.
## Operating Systems and Container Runtime Requirements
All supported operating systems are 64-bit x86. Rancher should work with any modern Linux distribution.
@@ -238,21 +238,23 @@ In these cases, you have to explicitly allow this traffic in your host firewall,
When using the [AWS EC2 node driver](../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md) to provision cluster nodes in Rancher, you can choose to let Rancher create a security group called `rancher-nodes`. The following rules are automatically added to this security group.
| Type | Protocol | Port Range | Source/Destination | Rule Type |
| Type | Protocol | Port Range | Source/Destination | Rule Type |
|-----------------|:--------:|:-----------:|------------------------|:---------:|
| SSH | TCP | 22 | 0.0.0.0/0 | Inbound |
| HTTP | TCP | 80 | 0.0.0.0/0 | Inbound |
| Custom TCP Rule | TCP | 443 | 0.0.0.0/0 | Inbound |
| Custom TCP Rule | TCP | 2376 | 0.0.0.0/0 | Inbound |
| Custom TCP Rule | TCP | 2379-2380 | sg-xxx (rancher-nodes) | Inbound |
| Custom UDP Rule | UDP | 4789 | sg-xxx (rancher-nodes) | Inbound |
| Custom TCP Rule | TCP | 6443 | 0.0.0.0/0 | Inbound |
| Custom UDP Rule | UDP | 8472 | sg-xxx (rancher-nodes) | Inbound |
| Custom TCP Rule | TCP | 10250-10252 | sg-xxx (rancher-nodes) | Inbound |
| Custom TCP Rule | TCP | 10256 | sg-xxx (rancher-nodes) | Inbound |
| Custom TCP Rule | TCP | 30000-32767 | 0.0.0.0/0 | Inbound |
| Custom UDP Rule | UDP | 30000-32767 | 0.0.0.0/0 | Inbound |
| All traffic | All | All | 0.0.0.0/0 | Outbound |
| SSH | TCP | 22 | 0.0.0.0/0 and ::/0 | Inbound |
| HTTP | TCP | 80 | 0.0.0.0/0 and ::/0 | Inbound |
| Custom TCP Rule | TCP | 443 | 0.0.0.0/0 and ::/0 | Inbound |
| Custom TCP Rule | TCP | 2376 | 0.0.0.0/0 and ::/0 | Inbound |
| Custom TCP Rule | TCP | 6443 | 0.0.0.0/0 and ::/0 | Inbound |
| Custom TCP Rule | TCP | 179 | sg-xxx (rancher-nodes) | Inbound |
| Custom TCP Rule | TCP | 9345 | sg-xxx (rancher-nodes) | Inbound |
| Custom TCP Rule | TCP | 2379-2380 | sg-xxx (rancher-nodes) | Inbound |
| Custom TCP Rule | TCP | 10250-10252 | sg-xxx (rancher-nodes) | Inbound |
| Custom TCP Rule | TCP | 10256 | sg-xxx (rancher-nodes) | Inbound |
| Custom UDP Rule | UDP | 4789 | sg-xxx (rancher-nodes) | Inbound |
| Custom UDP Rule | UDP | 8472 | sg-xxx (rancher-nodes) | Inbound |
| Custom TCP Rule | TCP | 30000-32767 | 0.0.0.0/0 and ::/0 | Inbound |
| Custom UDP Rule | UDP | 30000-32767 | 0.0.0.0/0 and ::/0 | Inbound |
| All traffic | All | All | 0.0.0.0/0 and ::/0 | Outbound |
### Opening SUSE Linux Ports
@@ -42,8 +42,24 @@ kubectl -n cattle-system create secret generic tls-ca \
The configured `tls-ca` secret is retrieved when Rancher starts. On a running Rancher installation the updated CA will take effect after new Rancher pods are started.
The certificate chain must be properly formatted, or components may fail to download resources from the Rancher server.
:::
## Adding Additional CA Certificates
If you are using a node driver that makes API requests with a different CA than the one configured for Rancher, you can add additional root certificates and certificate chains.
Create a unique file ending in `.pem` for each certificate that is required, and use kubectl to create the
`tls-additional` secret in the `cattle-system` namespace.
```console
kubectl -n cattle-system create secret generic tls-additional \
--from-file=cacerts1.pem=cacerts1.pem --from-file=cacerts2.pem=cacerts2.pem
```
Rancher mounts these CA root certificates and certificate chains into the node driver pod during provisioning.
## Updating a Private CA Certificate
Follow the steps on [this page](update-rancher-certificate.md) to update the SSL certificate of the ingress in a Rancher [high availability Kubernetes installation](../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md) or to switch from the default self-signed certificate to a custom certificate.
@@ -1,19 +0,0 @@
---
title: ClusterRole Aggregation
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-experimental-features/cluster-role-aggregation"/>
</head>
:::caution
ClusterRole aggregation is a highly experimental feature that changes the RBAC architecture used for RoleTemplates, ClusterRoleTemplateBindings and ProjectRoleTemplateBindings. **It is not supported for production environments**. This feature is meant exclusively for internal testing in v2.11 and v2.12. It is expected to be available as a beta for users in v2.13.
:::
ClusterRole aggregation implements RoleTemplates, ClusterRoleTemplateBindings and ProjectRoleTemplateBindings using the Kubernetes feature [Aggregated ClusterRoles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles). The new architecture results in a net reduction in RBAC objects (Roles, RoleBindings, ClusterRoles and ClusterRoleBindings) both in the Rancher cluster and the downstream clusters.
| Environment Variable Key | Default Value | Description |
| --- | --- | --- |
| `aggregated-roletemplates` | `false` | [Experimental] Make RoleTemplates use aggregation for generated RBAC roles. |
The value of this feature flag is locked on installation, which shows up in the UI as a lock symbol beside the feature flag. That means the feature can only be set on the first ever installation of Rancher. After that, attempting to modify the value will be denied.
@@ -0,0 +1,21 @@
---
title: RoleTemplate Aggregation
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-experimental-features/role-template-aggregation"/>
</head>
:::caution
RoleTemplate aggregation is an experimental feature in v2.13 that changes the RBAC architecture used for RoleTemplates, ClusterRoleTemplateBindings and ProjectRoleTemplateBindings. **It is not supported for production environments**. Breaking changes may occur between v2.13 and v2.14.
:::
RoleTemplate aggregation implements RoleTemplates, ClusterRoleTemplateBindings and ProjectRoleTemplateBindings using the Kubernetes feature [Aggregated ClusterRoles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles). The new architecture results in a net reduction in RBAC objects (Roles, RoleBindings, ClusterRoles and ClusterRoleBindings) both in the Rancher cluster and the downstream clusters.
For more information on how the feature can improve scalability and performance, please see the [Rancher Blog post](https://www.suse.com/c/rancher_blog/fewer-bindings-more-power-ranchers-rbac-boost-for-enhanced-performance-and-scalability/).
| Environment Variable Key | Default Value | Description |
| --- | --- | --- |
| `aggregated-roletemplates` | `false` | [Beta] Make RoleTemplates use aggregation for generated RBAC roles. |
The value of this feature flag is locked on installation, which shows up in the UI as a lock symbol beside the feature flag. That means the feature can only be set on the first ever installation of Rancher. After that, attempting to modify the value will be denied.
@@ -15,10 +15,8 @@ The etcd data set is automatically cleaned up on a five-minute interval by Kuber
```yaml
# RKE2/K3s config.yaml
---
services:
etcd:
extra_args:
quota-backend-bytes: 5368709120
etcd-arg:
- "quota-backend-bytes=5368709120"
```
## Scaling etcd Disk Performance
@@ -32,12 +30,7 @@ To implement this solution in an RKE2/K3s cluster, the `/var/lib/etcd/data` and
```yaml
# RKE2/K3s config.yaml
---
services:
etcd:
extra_args:
data-dir: '/var/lib/rancher/etcd/data/'
wal-dir: '/var/lib/rancher/etcd/wal/wal_dir'
extra_binds:
- '/var/lib/etcd/data:/var/lib/rancher/etcd/data'
- '/var/lib/etcd/wal:/var/lib/rancher/etcd/wal'
etcd-arg:
- "data-dir=/var/lib/etcd/data"
- "wal-dir=/var/lib/etcd/wal"
```
@@ -58,3 +58,7 @@ if the user has not yet logged in to Rancher. However, if the user has previousl
### 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.
## Configuring OIDC Single Logout (SLO)
<ConfigureSLOOidc />
@@ -363,3 +363,22 @@ Since the filter prevents Rancher from seeing that the user belongs to an exclud
>- If you don't wish to upgrade to v2.7.0+ after the Azure AD Graph API is retired, you'll need to either:
- Use the built-in Rancher auth or
- Use another third-party auth system and set that up in Rancher. Please see the [authentication docs](authentication-config.md) to learn how to configure other open authentication providers.
## Azure AD Roles Claims
Rancher supports the Roles claim provided by the Azure AD OIDC provider token, allowing for complete delegation of Role-Based Access Control (RBAC) to Azure AD. Previously, Rancher only processed the `Groups` claim to determine a user's `group` membership. This enhancement extends the logic to also include the Roles claim within the user's OIDC token.
By including the Roles claim, administrators can:
- Define specific high-level roles in Azure AD.
- Bind these Azure AD Roles directly to ProjectRoles or ClusterRoles within Rancher.
- Centralize and fully delegate access control decisions to the external OIDC provider.
For example, consider the following role structure in Azure AD:
| Azure AD Role Name | Members |
|--------------------|----------------|
| project-alpha-dev | User A, User C |
User A logs into Rancher via Azure AD. The OIDC token includes a Roles claim, [`project-alpha-dev`]. The Rancher logic processes the token, and the internal list of `groups`/roles for User A which includes `project-alpha-dev`. An administrator has created a Project Role Binding that maps the Azure AD Role `project-alpha-dev` to the Project Role `Dev Member` for Project Alpha. User A is automatically granted the `Dev Member` role in Project Alpha.
@@ -7,60 +7,75 @@ description: Create an OpenID Connect (OIDC) client and configure Rancher to wor
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-generic-oidc"/>
</head>
If your organization uses an OIDC provider for user authentication, you can configure Rancher to allow login using Identity Provider (IdP) credentials. Rancher supports integration with the OpenID Connect (OIDC) protocol and the SAML protocol. Both implementations are functionally equivalent when used with Rancher. The following instructions describe how to configure Rancher to work using the OIDC protocol.
Generic OpenID Connect (OIDC) allows users to sign in to Rancher using their credentials from their existing account at an OIDC Identity Provider (IdP). Rancher supports integration with the OIDC protocol and the SAML protocol. Both implementations are functionally equivalent when used with Rancher. The following instructions describe how to create an OIDC client and configure Rancher to work with your authentication provider. Users can then sign into Rancher using their login from the OIDC IdP.
## Prerequisites
- In Rancher:
- Generic OIDC is disabled.
### Identity Provider
In Rancher, Generic OIDC is disabled.
:::note
Consult the documentation for your specific IdP to complete the listed prerequisites.
:::
- In your IdP:
- Create a new client with the settings below:
#### OIDC Client
In your IdP, create a new client with the settings below:
Setting | Value
------------|------------
`Client ID` | <CLIENT_ID> (e.g. `rancher`)
`Name` | <CLIENT_NAME> (e.g. `rancher`)
`Client Protocol` | `openid-connect`
`Access Type` | `confidential`
`Valid Redirect URI` | `https://yourRancherHostURL/verify-auth`
In the new OIDC client, create mappers to expose the user's fields.
:::note
The `groups` and `full_group_path` claims generated by the Groups and Group Path mappers, which you create within the OIDC client in your Identity Provider, should be JSON arrays, e.g. `"groups":["admins","devs","qa"]` and `"full_group_path":["/admins","/devs","/qa"]`.
:::
1. Create a new `Groups Mapper` with the settings below:
Setting | Value
------------|------------
`Client ID` | <CLIENT_ID> (e.g. `rancher`)
`Name` | <CLIENT_NAME> (e.g. `rancher`)
`Client Protocol` | `openid-connect`
`Access Type` | `confidential`
`Valid Redirect URI` | `https://yourRancherHostURL/verify-auth`
`Name` | `Groups Mapper`
`Mapper Type` | `Group Membership`
`Token Claim Name` | `groups`
`Add to ID token` | `OFF`
`Add to access token` | `OFF`
`Add to user info` | `ON`
- In the new OIDC client, create mappers to expose the users fields.
- Create a new Groups Mapper with the settings below:
1. Create a new `Client Audience` with the settings below:
Setting | Value
------------|------------
`Name` | `Groups Mapper`
`Mapper Type` | `Group Membership`
`Token Claim Name` | `groups`
`Add to ID token` | `OFF`
`Add to access token` | `OFF`
`Add to user info` | `ON`
Setting | Value
------------|------------
`Name` | `Client Audience`
`Mapper Type` | `Audience`
`Included Client Audience` | `CLIENT_NAME`
`Add to access token` | `ON`
- Create a new Client Audience with the settings below:
1. Create a new `Groups Path` with the settings below.
Setting | Value
------------|------------
`Name` | `Client Audience`
`Mapper Type` | `Audience`
`Included Client Audience` | <CLIENT_NAME>
`Add to access token` | `ON`
Setting | Value
------------|------------
`Name` | `Group Path`
`Mapper Type` | `Group Membership`
`Token Claim Name` | `full_group_path`
`Full group path` | `ON`
`Add to user info` | `ON`
- Create a new "Groups Path" with the settings below.
:::warning
Setting | Value
------------|------------
`Name` | `Group Path`
`Mapper Type` | `Group Membership`
`Token Claim Name` | `full_group_path`
`Full group path` | `ON`
`Add to user info` | `ON`
Rancher uses the value received in the "sub" claim to form the PrincipalID which is the unique identifier in Rancher. It is important to make this a value that is unique and immutable.
- Important: Rancher will use the value received in the "sub" claim to form the PrincipalID which is the unique identifier in Rancher. It is important to make this a value that will be unique and immutable.
:::
## Configuring Generic OIDC in Rancher
@@ -80,7 +95,31 @@ Consult the documentation for your specific IdP to complete the listed prerequis
**Result:** Rancher is configured to work with your provider using the OIDC protocol. Your users can now sign into Rancher using their IdP logins.
## Configuration Reference
### Custom Claim Mapping
Custom claim mapping within the Generic OIDC configuration is supported for `name`, `email` and `groups` claims. This allows you to manually map these OIDC claims when your IdP doesn't use standard names in tokens.
#### How a Custom Groups Claim Works
A custom groups claim influences how user groups work:
- If both the standard OIDC `groups` claim and the custom groups claim are present in the user's token, the custom claim supplements the list of groups provided by the standard claim.
- If there is no standard groups claim in the token, the groups listed in the custom claim will form the user's only groups.
:::note
There is no search functionality available for groups sourced from a custom claim. To assign a role to one of these groups, you must manually enter the group's exact name into the RBAC field.
:::
#### Configuring Custom Claims
When on the **Configure an OIDC account** form:
1. Select **Add custom claims**.
1. Add your custom `name`, `email` or `groups` claims to the appropriate **Custom Claims** field.
For example, if your IdP sends `groups` in a claim called `custom_roles`, enter `custom_roles` into the **Custom Groups Claim** field. Rancher then supplements the standard OIDC `groups` claim or looks for that specific claim when processing the user's token.
### Configuration Reference
| Field | Description |
| ------------------------- |----------------------------------------------------------------------------------------------------------------------------------------------------|
@@ -91,6 +130,15 @@ Consult the documentation for your specific IdP to complete the listed prerequis
| Rancher URL | The URL for your Rancher Server. |
| Issuer | The URL of your IdP. If your provider has discovery enabled, Rancher uses the Issuer URL to fetch all of the required URLs. |
| Auth Endpoint | The URL where users are redirected to authenticate. |
#### Custom Claims
| Custom Claim Field | Default OIDC Claim | Custom Claim Description |
| ------------- | ------------------ | ------------------------ |
| Custom Name Claim | `name` | The name of the claim in the OIDC token that contains the user's full name or display name. |
| Custom Email Claim | `email` | The name of the claim in the OIDC token that contains the user's email address. |
| Custom Groups Claim | `groups` | The name of the claim in the OIDC token that contains the user's group memberships (used for RBAC). |
## Troubleshooting
If you are experiencing issues while testing the connection to the OIDC server, first double-check the configuration options of your OIDC client. You can also inspect the Rancher logs to help pinpoint what's causing issues. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging](../../../../faq/technical-items.md#how-can-i-enable-debug-logging) in this documentation.
@@ -108,3 +156,7 @@ If the `Issuer` and `Auth Endpoint` are generated incorrectly, open the **Config
### Error: "Invalid grant_type"
In some cases, the "Invalid grant_type" error message may be misleading and is actually caused by setting the `Valid Redirect URI` incorrectly.
## Configuring OIDC Single Logout (SLO)
<ConfigureSLOOidc />
@@ -0,0 +1,84 @@
---
title: Configure GitHub App
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-github-app"/>
</head>
In environments using GitHub, you can configure the new GitHub App authentication provider in Rancher, which allows users to authenticate against a GitHub Organization account using a dedicated [GitHub App](https://docs.github.com/en/apps/overview). This new provider runs alongside the existing standard GitHub authentication provider, offering increased security and better management of permissions based on GitHub Organization teams.
## Prerequisites
:::warning
The GitHub App authentication provider only works with [GitHub Organization accounts](https://docs.github.com/en/get-started/learning-about-github/types-of-github-accounts#organization-accounts). It does not function with individual [GitHub User accounts](https://docs.github.com/en/get-started/learning-about-github/types-of-github-accounts#user-accounts).
:::
Before configuring the provider in Rancher, you must first create a GitHub App for your organization, generate a client secret for your GitHub App and generate a private key for your GitHub App. Refer to [Registering a GitHub App](https://docs.github.com/en/apps/creating-github-apps/registering-a-github-app/registering-a-github-app) for details.
### Create GitHub App
1. Open your [GitHub organization settings](https://github.com/settings/organizations).
1. To the right of the organization, select **Settings**.
1. In the left sidebar, click **Developer settings** > **GitHub Apps**.
1. Click **New Github App**.
1. Fill in the GitHub App configuration form with these values:
- **GitHub App name**: Anything you like, e.g. `My Rancher`.
- **Application description**: Optional, can be left blank.
- **Homepage URL**: `https://localhost:8443`.
- **Callback URL**: `https://localhost:8443/verify-auth`.
1. Select **Create Github App**.
### Generate a Client Secret
Generate a [client secret](https://docs.github.com/en/rest/authentication/authenticating-to-the-rest-api#using-basic-authentication) on the settings page for your app.
1. Go to your GitHub App.
1. Next to **Client Secrets**, select **Generate a new client secret**.
### Generate a Private Key
Generate a [private key](https://docs.github.com/en/enterprise-server/apps/creating-github-apps/authenticating-with-a-github-app/managing-private-keys-for-github-apps#generating-private-keys) on the settings page for your app.
1. Go to your GitHub App.
1. Next to **Private Keys**, click **Generate a private key**.
## GitHub App Auth Provider Configuration
To set up the GitHub App Auth Provider in Rancher, follow these steps:
1. Navigate to the **Users & Authentication** section in the Rancher UI.
1. Select **Auth Providers**.
1. Select the **GitHub App** tile.
1. Gather and enter the details of your GitHub App into the configuration form fields.
| Field Name | Description |
| ---------- | ----------- |
| **Client ID** (Required) | The client ID of your GitHub App. |
| **Client Secret** (Required) | The client secret of your GitHub App. |
| **GitHub App ID** (Required) | The numeric ID associated with your GitHub App. |
| **Installation ID** (Optional) | If you want to restrict authentication to a single installation of the App, provide its specific numeric Installation ID. |
| **Private Key** (Required) | The contents of the Private Key file (in PEM format) generated by GitHub for your App. |
:::note
A GitHub App can be installed across multiple Organizations, and each installation has a unique Installation ID. If you want to restrict authentication to a single App installation and GitHub Organization, provide the Installation ID during configuration. If you do not provide an Installation ID, the user's permissions are aggregated across all installations.
:::
1. Select **Enable**. Rancher attempts to validate the credentials and, upon success, activates the GitHub App provider.
After it is enabled, users logging in via the GitHub App provider are automatically identified and you can leverage your GitHub Organization's teams and users to configure Role-Based Access Control (RBAC) and to assign permissions to projects and clusters.
:::note
Ensure that the users and teams you intend to use for authorization exist within the GitHub organization managed by the App.
:::
- **Users**: Individual GitHub users who are members of the GitHub Organization where the App is installed can log in.
- **Groups**: GitHub Organization teams are mapped to Rancher Groups, allowing you to assign entire teams permissions within Rancher projects and clusters.
@@ -203,3 +203,7 @@ To resolve this, you can either:
3. Save your changes.
2. Reconfigure your Keycloak OIDC setup using a user that is assigned to at least one group in Keycloak.
## Configuring OIDC Single Logout (SLO)
<ConfigureSLOOidc />
@@ -197,3 +197,32 @@ helm install rancher rancher-latest/rancher -n cattle-system -f rancher-values.y
After migration completes, update your DNS records and any load balancers, so that traffic is routed correctly to the migrated cluster. Remember that you must use the same hostname that was set as the server URL in the original cluster.
Full instructions on how to redirect traffic to the migrated cluster differ based on your specific environment. Refer to your hosting provider's documentation for more details.
### 6. Scale Down the Original Rancher Instance
After redirecting traffic to the new Rancher environment, **scale the original Rancher instance to 0 replicas** so it no longer contacts your managed clusters.
Leaving the old server up can cause agents to keep contacting the original `server-url`, which often leaves clusters stuck in **Updating** in the new environment.
```bash
kubectl scale deployment rancher -n cattle-system --replicas=0
```
If you originally ran Rancher in Docker:
```bash
docker stop <original-rancher-container>
```
:::note
If you wish to keep the original Rancher environment running, you can also restart the cattle-cluster-agent pods on each cluster connected to your Rancher environment.
```bash
kubectl rollout restart deployment cattle-cluster-agent -n cattle-system
```
This triggers a rolling restart of the agent so it re-establishes the connection to the new Rancher environment.
:::
@@ -66,7 +66,8 @@ Before you create your own custom catalog, you should have a basic understanding
![values.yaml](/img/helm-app-2.6.png)
### Chart.yaml annotations
### Chart.yaml
#### Annotations
Rancher supports additional annotations that you can add to the `Chart.yaml` file. These annotations allow you to define application dependencies or configure additional UI defaults:
@@ -76,10 +77,14 @@ Rancher supports additional annotations that you can add to the `Chart.yaml` fil
| catalog.cattle.io/display-name | A display name that should be displayed in the App Marketplace instead of the chart name | Display Name of Chart |
| catalog.cattle.io/namespace | A fixed namespace where the chart should be deployed in. If set, this can't be changed by the user | fixed-namespace |
| catalog.cattle.io/release-name | A fixed release name for the Helm installation. If set, this can't be changed by the user | fixed-release-name |
| catalog.cattle.io/requests-cpu | Total amount of CPU that should be unreserverd in the cluster. If less CPU is available, a warning will be shown | 2000m |
| catalog.cattle.io/requests-memory | Total amount of memory that should be unreserverd in the cluster. If less memory is available, a warning will be shown | 2Gi |
| catalog.cattle.io/requests-cpu | Total amount of CPU that should be unreserved in the cluster. If less CPU is available, a warning will be shown | 2000m |
| catalog.cattle.io/requests-memory | Total amount of memory that should be unreserved in the cluster. If less memory is available, a warning will be shown | 2Gi |
| catalog.cattle.io/os | Restricts the OS where this chart can be installed. Possible values: `linux`, `windows`. Default: no restriction | linux |
### Keywords
With the `keywords` option in the `Chart.yaml` file it is possible to provide a list of categories for sorting your application in the Rancher UI, like `infrastructure`, `monitoring` and more.
### questions.yml
Inside the `questions.yml`, most of the content will be around the questions to ask the end user, but there are some additional fields that can be set in this file.
@@ -120,6 +120,18 @@ For a breakdown of the port requirements for etcd nodes, controlplane nodes, and
Details on which ports are used in each situation are found under [Downstream Cluster Port Requirements](../../../getting-started/installation-and-upgrade/installation-requirements/port-requirements.md#downstream-kubernetes-cluster-nodes).
### IPv6 Address Requirements
Rancher supports clusters configured with IPv4-only, IPv6-only, or dual-stack networking.
You must provision each node with at least one valid IPv4 address, one IPv6 address, or both, according to the cluster networking configuration.
For IPv6-only environments, ensure you correctly configure the operating system and that the `/etc/hosts` file includes a valid localhost entry, for example:
```
::1 localhost
```
:::caution
You should never register a node with the same hostname or IP address as an existing node. Doing so causes RKE to prevent the node from joining, and provisioning to hang. This can occur for both node driver and custom clusters. If a node must reuse a hostname or IP of an existing node, you must set the `hostname_override` [RKE option](https://rke.docs.rancher.com/config-options/nodes#overriding-the-hostname) before registering the node, so that it can join correctly.
@@ -54,6 +54,7 @@ IAM Policy for nodes with the `controlplane` role:
"autoscaling:DescribeTags",
"ec2:DescribeInstances",
"ec2:DescribeRegions",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeRouteTables",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
@@ -123,6 +124,7 @@ IAM policy for nodes with the `etcd` or `worker` role:
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeRegions",
"ec2:DescribeAvailabilityZones",
"ecr:GetAuthorizationToken",
"ecr:BatchCheckLayerAvailability",
"ecr:GetDownloadUrlForLayer",
@@ -299,7 +301,7 @@ rancher_kubernetes_engine_config:
useInstanceMetadataHostname: true
```
You must not enable `useInstanceMetadataHostname` when setting custom values for `hostname-override` for custom clusters. When you create a [custom cluster](../../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/use-existing-nodes.md), add [`--node-name`](../../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options.md) to the `docker run` node registration command to set `hostname-override` — for example, `"$(hostname -f)"`. This can be done manually or by using **Show Advanced Options** in the Rancher UI to add **Node Name**.
You must not enable `useInstanceMetadataHostname` when setting custom values for `hostname-override` for custom clusters. When you create a [custom cluster](../../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/use-existing-nodes.md), add `--node-name` to the `docker run` node registration command to set `hostname-override` — for example, `"$(hostname -f)"`. This can be done manually or by using **Show Advanced Options** in the Rancher UI to add **Node Name**.
2. Select the cloud provider.
@@ -12,7 +12,7 @@ In Kubernetes 1.30 and later, you must use an out-of-tree Azure cloud provider.
You can also [migrate from an in-tree to an out-of-tree Azure cloud provider](../migrate-to-an-out-of-tree-cloud-provider/migrate-to-out-of-tree-azure.md) on Kubernetes 1.29 and earlier. All existing clusters must migrate prior to upgrading to v1.30 in order to stay functional.
Starting with Kubernetes 1.29, in-tree cloud providers have been disabled. You must disable `DisableCloudProviders` and `DisableKubeletCloudCredentialProvider` to use the in-tree Azure cloud provider. You can do this by setting `feature-gates=DisableCloudProviders=false` as an additional argument for the cluster's Kubelet, Controller Manager, and API Server in the advanced cluster configuration. Additionally, set `DisableKubeletCloudCredentialProvider=false` in the Kubelet's arguments to enable in-tree functionality for authenticating to Azure container registries for image pull credentials. See [upstream docs](https://github.com/kubernetes/kubernetes/pull/117503) for more details.
Starting with Kubernetes 1.29, in-tree cloud providers have been disabled. You must set `DisableCloudProviders` and `DisableKubeletCloudCredentialProviders` feature gates to `false` to use the in-tree Azure cloud provider. You can do this by setting `feature-gates=DisableCloudProviders=false,DisableKubeletCloudCredentialProviders=false` as an additional argument for the cluster's Kubelet, Controller Manager, and API Server in the advanced cluster configuration. Setting `DisableKubeletCloudCredentialProviders=false` in the Kubelet, Controller Manager, and API Server arguments enables in-tree functionality for authenticating to Azure container registries for image pull credentials. See the [Kubernetes 1.29: Mandala release notes](https://kubernetes.io/blog/2023/12/13/kubernetes-v1-29-release/#in-tree-cloud-provider-integration-removal) and this [blog post](https://kubernetes.io/blog/2023/12/14/cloud-provider-integration-changes/#continue-using-in-tree-provider-code) for more details.
Starting with Kubernetes version 1.26, in-tree persistent volume types `kubernetes.io/azure-disk` and `kubernetes.io/azure-file` are deprecated and will no longer be supported. For new clusters, [install the CSI drivers](#installing-csi-drivers), or migrate to the corresponding CSI drivers `disk.csi.azure.com` and `file.csi.azure.com` by following the [upstream migration documentation](https://learn.microsoft.com/en-us/azure/aks/csi-migrate-in-tree-volumes).
:::
@@ -103,11 +103,11 @@ The `worker` nodes, which is where your workloads will be deployed on, will typi
We recommend the minimum three-node architecture listed in the table below, but you can always add more Linux and Windows workers to scale up your cluster for redundancy:
| Node | Operating System | Kubernetes Cluster Role(s) | Purpose |
| ------ | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| Node 1 | Linux (Ubuntu Server 18.04 recommended) | Control plane, etcd, worker | Manage the Kubernetes cluster |
| Node 2 | Linux (Ubuntu Server 18.04 recommended) | Worker | Support the Rancher Cluster agent, Metrics server, DNS, and Ingress for the cluster |
| Node 3 | Windows (Windows Server core version 1809 or above) | Worker | Run your Windows containers |
| Node | Operating System | Kubernetes Cluster Role(s) | Purpose |
|--------|----------------------------------------------------------------------------------------|-----------------------------|-------------------------------------------------------------------------------------|
| Node 1 | Linux (Ubuntu Server 18.04 recommended) | Control plane, etcd, worker | Manage the Kubernetes cluster |
| Node 2 | Linux (Ubuntu Server 18.04 recommended) | Worker | Support the Rancher Cluster agent, Metrics server, DNS, and Ingress for the cluster |
| Node 3 | Windows (Windows Server core version 1809 or above required, version 2022 recommended) | Worker | Run your Windows containers |
### Container Requirements
@@ -126,8 +126,6 @@ If you are using the GCE (Google Compute Engine) cloud provider, you must do the
This tutorial describes how to create a Rancher-provisioned cluster with the three nodes in the [recommended architecture.](#recommended-architecture)
When you provision a cluster with Rancher on existing nodes, you add nodes to the cluster by installing the [Rancher agent](../../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options.md) on each one. To create or edit your cluster from the Rancher UI, run the **Registration Command** on each server to add it to your cluster.
To set up a cluster with support for Windows nodes and containers, you will need to complete the tasks below.
### 1. Provision Hosts
@@ -142,15 +140,15 @@ Your hosts can be:
You will provision three nodes:
- One Linux node, which manages the Kubernetes control plane and stores your `etcd`
- One Linux node, which manages the Kubernetes control plane, stores your `etcd`, and optionally be a worker node
- A second Linux node, which will be another worker node
- The Windows node, which will run your Windows containers as a worker node
| Node | Operating System |
| ------ | ------------------------------------------------------------ |
| Node 1 | Linux (Ubuntu Server 18.04 recommended) |
| Node 2 | Linux (Ubuntu Server 18.04 recommended) |
| Node 3 | Windows (Windows Server core version 1809 or above required) |
| Node | Operating System |
|--------|----------------------------------------------------------------------------------------|
| Node 1 | Linux (Ubuntu Server 18.04 recommended) |
| Node 2 | Linux (Ubuntu Server 18.04 recommended) |
| Node 3 | Windows (Windows Server core version 1809 or above required, version 2022 recommended) |
If your nodes are hosted by a **Cloud Provider** and you want automation support such as loadbalancers or persistent storage devices, your nodes have additional configuration requirements. For details, see [Selecting Cloud Providers.](../set-up-cloud-providers/set-up-cloud-providers.md)
@@ -164,11 +162,11 @@ The instructions for creating a Windows cluster on existing nodes are very simil
1. Enter a name for your cluster in the **Cluster Name** field.
1. In the **Kubernetes Version** dropdown menu, select a supported Kubernetes version.
1. In the **Container Network** field, select either **Calico** or **Flannel**.
1. Click **Next**.
1. Click **Create**.
### 3. Add Nodes to the Cluster
This section describes how to register your Linux and Worker nodes to your cluster. You will run a command on each node, which will install the Rancher agent and allow Rancher to manage each node.
This section describes how to register your Linux and Worker nodes to your cluster. You will run a command on each node, which will install the rancher system agent and allow Rancher to manage each node.
#### Add Linux Master Node
@@ -177,23 +175,18 @@ In this section, we fill out a form on the Rancher UI to get a custom command to
The first node in your cluster should be a Linux host that has both the **Control Plane** and **etcd** roles. At a minimum, both of these roles must be enabled for this node, and this node must be added to your cluster before you can add Windows hosts.
1. After cluster creation, navigate to the **Registration** tab.
1. In **Step 1** under the **Node Role** section, select at least **etcd** and **Control Plane**. We recommend selecting all three.
1. Optional: If you click **Show advanced options,** you can customize the settings for the [Rancher agent](../../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options.md) and [node labels.](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
1. In **Step 1** under the **Node Role** section, select all three roles. Although you can choose only the **etcd** and **Control Plane** roles, we recommend selecting all three.
1. Optional: If you click **Show Advanced**, you can configure additional settings such as specifying the IP address(es), overriding the node hostname, or adding [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) or [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to the node.
1. In **Step 2**, under the **Registration** section, copy the command displayed on the screen to your clipboard.
1. SSH into your Linux host and run the command that you copied to your clipboard.
**Result:**
**Results:**
Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
Your cluster is created and assigned a state of **Updating**. Rancher is standing up your cluster.
You can access your cluster after its state is updated to **Active**.
It may take a few minutes for the node to register and appear under the **Machines** tab.
**Active** clusters are assigned two Projects:
- `Default`, containing the `default` namespace
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
It may take a few minutes for the node to be registered in your cluster.
You’ll be able to access the cluster once its state changes to **Active**.
#### Add Linux Worker Node
@@ -203,11 +196,13 @@ After the initial provisioning of your cluster, your cluster only has a single L
1. After cluster creation, navigate to the **Registration** tab.
1. In **Step 1** under the **Node Role** section, select **Worker**.
1. Optional: If you click **Show advanced options,** you can customize the settings for the [Rancher agent](../../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options.md) and [node labels.](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
1. Optional: If you click **Show Advanced**, you can configure additional settings such as specifying the IP address(es), overriding the node hostname, or to add [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) or [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to the node.
1. In **Step 2**, under the **Registration** section, copy the command displayed on the screen to your clipboard.
1. SSH into your Linux host and run the command that you copied to your clipboard.
**Result:** The **Worker** role is installed on your Linux host, and the node registers with Rancher. It may take a few minutes for the node to be registered in your cluster.
**Results:**
The **Worker** role is installed on your Linux host, and the node registers with Rancher. It may take a few minutes for the node to be registered in your cluster.
:::note
@@ -216,7 +211,7 @@ Taints on Linux Worker Nodes
For each Linux worker node added into the cluster, the following taints will be added to Linux worker node. By adding this taint to the Linux worker node, any workloads added to the Windows cluster will be automatically scheduled to the Windows worker node. If you want to schedule workloads specifically onto the Linux worker node, you will need to add tolerations to those workloads.
| Taint Key | Taint Value | Taint Effect |
| -------------- | ----------- | ------------ |
|----------------|-------------|--------------|
| `cattle.io/os` | `linux` | `NoSchedule` |
:::
@@ -231,12 +226,16 @@ The registration command to add the Windows workers only appears after the clust
1. After cluster creation, navigate to the **Registration** tab.
1. In **Step 1** under the **Node Role** section, select **Worker**.
1. Optional: If you click **Show advanced options,** you can customize the settings for the [Rancher agent](../../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options.md) and [node labels.](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
1. Optional: If you click **Show Advanced**, you can configure additional settings such as specifying the IP address(es), overriding the node hostname, or adding [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) or [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to the node.
1. In **Step 2**, under the **Registration** section, copy the command for Windows workers displayed on the screen to your clipboard.
1. Log in to your Windows host using your preferred tool, such as [Microsoft Remote Desktop](https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-clients). Run the command copied to your clipboard in the **Command Prompt (CMD)**.
1. Log in to your Windows host using your preferred tool, such as [Microsoft Remote Desktop](https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-clients). Run the command copied to your clipboard in the **PowerShell Console** as an Administrator.
1. Optional: Repeat these instructions if you want to add more Windows nodes to your cluster.
**Result:** The **Worker** role is installed on your Windows host, and the node registers with Rancher. It may take a few minutes for the node to be registered in your cluster. You now have a Windows Kubernetes cluster.
**Results:**
The **Worker** role is installed on your Windows host, and the node registers with Rancher. It may take a few minutes for the node to be registered in your cluster.
You now have a Windows Kubernetes cluster.
### Optional Next Steps
@@ -20,7 +20,8 @@ Then you will create an EC2 cluster in Rancher, and when configuring the new clu
- [Example IAM Policy](#example-iam-policy)
- [Example IAM Policy with PassRole](#example-iam-policy-with-passrole) (needed if you want to use [Kubernetes Cloud Provider](../../kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/set-up-cloud-providers.md) or want to pass an IAM Profile to an instance)
- [Example IAM Policy to allow encrypted EBS volumes](#example-iam-policy-to-allow-encrypted-ebs-volumes)
- **IAM Policy added as Permission** to the user. See [Amazon Documentation: Adding Permissions to a User (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) how to attach it to an user.
- **IAM Policy added as Permission** to the user. See [Amazon Documentation: Adding Permissions to a User (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) how to attach it to a user.
- **IPv4-only or IPv6-only or dual-stack subnet and/or VPC** where nodes can be provisioned and assigned IPv4 and/or IPv6 addresses. See [Amazon Documentation: IPv6 support for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html).
## Creating an EC2 Cluster
@@ -141,7 +141,8 @@ You need to remove the following components from Rancher-provisioned RKE2 nodes:
To remove the rancher-system-agent, run the [system-agent-uninstall.sh](https://github.com/rancher/system-agent/blob/main/system-agent-uninstall.sh) script:
```
curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh | sudo sh
curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh > system-agent-uninstall.sh
sudo sh system-agent-uninstall.sh
```
### Removing RKE2
@@ -165,7 +166,8 @@ You need to remove the following components from Rancher-provisioned K3s nodes:
To remove the rancher-system-agent, run the [system-agent-uninstall.sh](https://github.com/rancher/system-agent/blob/main/system-agent-uninstall.sh) script:
```
curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh | sudo sh
curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh > system-agent-uninstall.sh
sudo sh system-agent-uninstall.sh
```
### Removing K3s
@@ -13,7 +13,7 @@ A project is a group of namespaces, and it is a concept introduced by Rancher. P
:::note
Projects are de-emphasized on the UI because it is not required to create Kubernetes resources within a project scope. However, resources such as [Secrets](../../new-user-guides/kubernetes-resources-setup/secrets.md#creating-secrets-in-projects) can still be created in a project scope if the legacy feature flag is enabled.
Projects are de-emphasized on the UI because it is not required to create Kubernetes resources within a project scope. However, resources such as [Secrets](../../new-user-guides/kubernetes-resources-setup/secrets.md#creating-secrets-in-projects) can still be created in a project scope.
:::
@@ -196,3 +196,7 @@ To add a resource quota,
1. Select **Delete**.
When you delete a project, any namespaces that were formerly associated with the project will remain on the cluster. You can find these namespaces in the Rancher UI, in the **Not in a Project** tab of the **Projects/Namespaces** page. You can reassign these namespaces to a project by [moving](../manage-namespaces.md#moving-namespaces-to-another-project) them.
## Further Reading
You can create projects and project members more programmatically via the [Public API](../../../api/quickstart.md). See the [project workflow doc](../../../api/workflows/projects.md) for more information.
@@ -19,10 +19,9 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
| Rancher Version | Adapter Version |
|-----------------|------------------|
| v2.12.3 | 107.0.0+up7.0.0 |
| v2.12.2 | 107.0.0+up7.0.0 |
| v2.12.1 | 107.0.0+up7.0.0 |
| v2.12.0 | 107.0.0+up7.0.0 |
| v2.13.2 | 108.0.0+up8.0.0 |
| v2.13.1 | 108.0.0+up8.0.0 |
| v2.13.0 | 108.0.0+up8.0.0 |
### 1. Gain Access to the Local Cluster
@@ -80,3 +80,18 @@ Use [Instance Metadata Service Version 2 (IMDSv2)](https://docs.aws.amazon.com/A
Add metadata using [tags](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) to categorize resources.
### IPv6 Address Count
Specify how many IPv6 addresses to assign to the instance’s network interface.
### IPv6 Address Only
Enable this option if the instance should use IPv6 exclusively. IPv6-only VPCs or subnets require this. When enabled, the instance will have IPv6 as its sole address, and the IPv6 Address Count must be greater than zero.
### HTTP Protocol IPv6
Enable or disable IPv6 endpoints for the instance metadata service.
### Enable Primary IPv6
Enable this option to designate the first assigned IPv6 address as the primary address. This ensures a consistent, non-changing IPv6 address for the instance. It does not control whether IPv6 addresses are assigned.
@@ -28,6 +28,8 @@ Enable the DigitalOcean agent for additional [monitoring](https://docs.digitaloc
Enable IPv6 for Droplets.
For more information, refer to the [Digital Ocean IPv6 documentation](https://docs.digitalocean.com/products/networking/ipv6).
### Private Networking
Enable private networking for Droplets.
@@ -71,7 +71,7 @@ Tags is a list of _network tags_, which can be used to associate preexisting Fir
### Labels
A comma seperated list of custom labels to be attached to all VMs within a given machine pool. Unlike Tags, Labels do not influence networking behavior and only serve to organize cloud resources.
A comma separated list of custom labels to be attached to all VMs within a given machine pool. Unlike Tags, Labels do not influence networking behavior and only serve to organize cloud resources.
## Advanced Options
@@ -6,4 +6,4 @@ title: Machine Configuration
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/downstream-cluster-configuration/machine-configuration"/>
</head>
Machine configuration is the arrangement of resources assigned to a virtual machine. Please see the docs for [Amazon EC2](amazon-ec2.md), [DigitalOcean](digitalocean.md), and [Azure](azure.md) to learn more.
Machine configuration is the arrangement of resources assigned to a virtual machine. Please see the docs for [Amazon EC2](amazon-ec2.md), [DigitalOcean](digitalocean.md), [Google GCE](google-gce.md), and [Azure](azure.md) to learn more.
@@ -6,4 +6,6 @@ title: Node Template Configuration
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration"/>
</head>
<EOLRKE1Warning />
To learn about node template config, refer to [EC2 Node Template Configuration](amazon-ec2.md), [DigitalOcean Node Template Configuration](digitalocean.md), [Azure Node Template Configuration](azure.md), [vSphere Node Template Configuration](vsphere.md), and [Nutanix Node Template Configuration](nutanix.md).
@@ -63,7 +63,15 @@ Enable network policy enforcement on the cluster. A network policy defines the l
_Mutable: yes_
choose whether to enable or disable inter-project communication. Note that enabling Project Network Isolation will automatically enable Network Policy and Network Policy Config, but not vice versa.
Choose whether to enable or disable inter-project communication.
#### Imported Clusters
For imported clusters, Project Network Isolation (PNI) requires Kubernetes Network Policy to be enabled on the cluster beforehand.
For clusters created by Rancher, Rancher enables Kubernetes Network Policy automatically.
1. In GKE, enable Network Policy at the cluster level. Refer to the [official GKE guide](https://cloud.google.com/kubernetes-engine/docs/how-to/network-policy) for instructions.
1. After enabling Network Policy, import the cluster into Rancher and enable PNI for project-level isolation.
### Node Ipv4 CIDR Block
@@ -13,7 +13,7 @@ This section covers the configuration options that are available in Rancher for
You can configure the Kubernetes options one of two ways:
- [Rancher UI](#configuration-options-in-the-rancher-ui): Use the Rancher UI to select options that are commonly customized when setting up a Kubernetes cluster.
- [Cluster Config File](#cluster-config-file-reference): Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create a K3s config file. Using a config file allows you to set any of the [options](https://rancher.com/docs/k3s/latest/en/installation/install-options/) available in an K3s installation.
- [Cluster Config File](#cluster-config-file-reference): Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create a K3s config file. Using a config file lets you set any of the [options](https://rancher.com/docs/k3s/latest/en/installation/install-options/) available during a K3s installation.
## Editing Clusters in the Rancher UI
@@ -32,7 +32,7 @@ To edit your cluster,
### Editing Clusters in YAML
For a complete reference of configurable options for K3s clusters in YAML, see the [K3s documentation.](https://rancher.com/docs/k3s/latest/en/installation/install-options/)
For a complete reference of configurable options for K3s clusters in YAML, see the [K3s documentation](https://docs.k3s.io/installation/configuration).
To edit your cluster with YAML:
@@ -48,7 +48,8 @@ This subsection covers generic machine pool configurations. For specific infrast
- [Azure](../downstream-cluster-configuration/machine-configuration/azure.md)
- [DigitalOcean](../downstream-cluster-configuration/machine-configuration/digitalocean.md)
- [EC2](../downstream-cluster-configuration/machine-configuration/amazon-ec2.md)
- [Amazon EC2](../downstream-cluster-configuration/machine-configuration/amazon-ec2.md)
- [Google GCE](../downstream-cluster-configuration/machine-configuration/google-gce.md)
##### Pool Name
@@ -86,9 +87,9 @@ Add [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-tolerat
#### Basics
##### Kubernetes Version
The version of Kubernetes installed on your cluster nodes. Rancher packages its own version of Kubernetes based on [hyperkube](https://github.com/rancher/hyperkube).
The version of Kubernetes installed on your cluster nodes.
For more detail, see [Upgrading Kubernetes](../../../getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md).
For details on upgrading or rolling back Kubernetes, refer to [this guide](../../../getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md).
##### Pod Security Admission Configuration Template
@@ -108,7 +109,7 @@ Option to enable or disable [SELinux](https://rancher.com/docs/k3s/latest/en/adv
##### CoreDNS
By default, [CoreDNS](https://coredns.io/) is installed as the default DNS provider. If CoreDNS is not installed, an alternate DNS provider must be installed yourself. Refer to the [K3s documentation](https://rancher.com/docs/k3s/latest/en/networking/#coredns) for details..
By default, [CoreDNS](https://coredns.io/) is installed as the default DNS provider. If CoreDNS is not installed, an alternate DNS provider must be installed yourself. Refer to the [K3s documentation](https://rancher.com/docs/k3s/latest/en/networking/#coredns) for details.
##### Klipper Service LB
@@ -148,15 +149,49 @@ Option to choose whether to expose etcd metrics to the public or only within the
##### Cluster CIDR
IPv4/IPv6 network CIDRs to use for pod IPs (default: 10.42.0.0/16).
IPv4/IPv6 network CIDRs to use for pod IPs (default: `10.42.0.0/16`).
Example values:
- IPv4-only: `10.42.0.0/16`
- IPv6-only: `2001:cafe:42::/56`
- Dual-stack: `10.42.0.0/16,2001:cafe:42::/56`
For additional requirements and limitations related to dual-stack or IPv6-only networking, see the following resources:
- [K3s documentation: Dual-stack (IPv4 + IPv6) Networking](https://docs.k3s.io/networking/basic-network-options#dual-stack-ipv4--ipv6-networking)
- [K3s documentation: Single-stack IPv6 Networking](https://docs.k3s.io/networking/basic-network-options#single-stack-ipv6-networking)
:::caution
You must configure the Service CIDR when you first create the cluster. You cannot enable the Service CIDR on an existing cluster after it starts.
:::
##### Service CIDR
IPv4/IPv6 network CIDRs to use for service IPs (default: 10.43.0.0/16).
IPv4/IPv6 network CIDRs to use for service IPs (default: `10.43.0.0/16`).
Example values:
- IPv4-only: `10.43.0.0/16`
- IPv6-only: `2001:cafe:43::/112`
- Dual-stack: `10.43.0.0/16,2001:cafe:43::/112`
For additional requirements and limitations related to dual-stack or IPv6-only networking, see the following resources:
- [K3s documentation: Dual-stack (IPv4 + IPv6) Networking](https://docs.k3s.io/networking/basic-network-options#dual-stack-ipv4--ipv6-networking)
- [K3s documentation: Single-stack IPv6 Networking](https://docs.k3s.io/networking/basic-network-options#single-stack-ipv6-networking)
:::caution
You must configure the Service CIDR when you first create the cluster. You cannot enable the Service CIDR on an existing cluster after it starts.
:::
##### Cluster DNS
IPv4 Cluster IP for coredns service. Should be in your service-cidr range (default: 10.43.0.10).
IPv4 Cluster IP for coredns service. Should be in your service-cidr range (default: `10.43.0.10`).
##### Cluster Domain
@@ -168,11 +203,11 @@ Option to change the range of ports that can be used for [NodePort services](htt
##### Truncate Hostnames
Option to truncate hostnames to 15 characters or less. You can only set this field during the initial creation of the cluster. You can't enable or disable the 15 character limit after cluster creation.
Option to truncate hostnames to 15 characters or fewer. You can only set this field during the initial creation of the cluster. You can't enable or disable the 15-character limit after cluster creation.
This setting only affects machine-provisioned clusters. Since custom clusters set hostnames during their own node creation process, which occurs outside of Rancher, this field doesn't restrict custom cluster hostname length.
Truncating hostnames in a cluster improves compatibility with Windows-based systems. Although Kubernetes allows hostnames up to 63 characters in length, systems that use NetBIOS restrict hostnames to 15 characters or less.
Truncating hostnames in a cluster improves compatibility with Windows-based systems. Although Kubernetes allows hostnames up to 63 characters in length, systems that use NetBIOS restrict hostnames to 15 characters or fewer.
##### TLS Alternate Names
@@ -186,6 +221,33 @@ For more detail on how an authorized cluster endpoint works and why it is used,
We recommend using a load balancer with the authorized cluster endpoint. For details, refer to the [recommended architecture section.](../../rancher-manager-architecture/architecture-recommendations.md#architecture-for-an-authorized-cluster-endpoint-ace)
##### Stack Preference
Choose the networking stack for the cluster. This option affects:
- The address used for health and readiness probes of components such as Calico, etcd, kube-apiserver, kube-scheduler, kube-controller-manager, and kubelet.
- The server URL in the `authentication-token-webhook-config-file` for the Authorized Cluster Endpoint.
- The `advertise-client-urls` setting for etcd during snapshot restoration.
Options are `ipv4`, `ipv6`, `dual`:
- When set to `ipv4`, the cluster uses `127.0.0.1`
- When set to `ipv6`, the cluster uses `[::1]`
- When set to `dual`, the cluster uses `localhost`
The stack preference must match the cluster’s networking configuration:
- Set to `ipv4` for IPv4-only clusters
- Set to `ipv6` for IPv6-only clusters
- Set to `dual` for dual-stack clusters
:::caution
Ensuring the loopback address configuration is correct is critical for successful cluster provisioning.
For more information, refer to the [Node Requirements](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md) page.
:::
#### Registries
Select the image repository to pull Rancher images from. For more details and configuration options, see the [K3s documentation](https://rancher.com/docs/k3s/latest/en/installation/private-registry/).
@@ -32,7 +32,7 @@ To edit your cluster,
### Editing Clusters in YAML
For a complete reference of configurable options for K3s clusters in YAML, see the [K3s documentation.](https://rancher.com/docs/k3s/latest/en/installation/install-options/)
For a complete reference of configurable options for RKE2 clusters in YAML, see the [RKE2 documentation](https://docs.rke2.io/install/configuration).
To edit your cluster in YAML:
@@ -48,7 +48,8 @@ This subsection covers generic machine pool configurations. For specific infrast
- [Azure](../downstream-cluster-configuration/machine-configuration/azure.md)
- [DigitalOcean](../downstream-cluster-configuration/machine-configuration/digitalocean.md)
- [EC2](../downstream-cluster-configuration/machine-configuration/amazon-ec2.md)
- [Amazon EC2](../downstream-cluster-configuration/machine-configuration/amazon-ec2.md)
- [Google GCE](../downstream-cluster-configuration/machine-configuration/google-gce.md)
##### Pool Name
@@ -86,9 +87,9 @@ Add [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-tolerat
#### Basics
##### Kubernetes Version
The version of Kubernetes installed on your cluster nodes. Rancher packages its own version of Kubernetes based on [hyperkube](https://github.com/rancher/hyperkube).
The version of Kubernetes installed on your cluster nodes.
For more detail, see [Upgrading Kubernetes](../../../getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md).
For details on upgrading or rolling back Kubernetes, refer to [this guide](../../../getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md).
##### Container Network Provider
@@ -105,20 +106,19 @@ Out of the box, Rancher is compatible with the following network providers:
- [Canal](https://github.com/projectcalico/canal)
- [Cilium](https://cilium.io/)*
- [Calico](https://docs.projectcalico.org/v3.11/introduction/)
- [Flannel](https://github.com/flannel-io/flannel)
- [Multus](https://github.com/k8snetworkplumbingwg/multus-cni)
\* When using [project network isolation](#project-network-isolation) in the [Cilium CNI](../../../faq/container-network-interface-providers.md#cilium), it is possible to enable cross-node ingress routing. Click the [CNI provider docs](../../../faq/container-network-interface-providers.md#ingress-routing-across-nodes-in-cilium) to learn more.
For more details on the different networking providers and how to configure them, please view our [RKE2 documentation](https://docs.rke2.io/install/network_options).
For more details on the different networking providers and how to configure them, please view our [RKE2 documentation](https://docs.rke2.io/networking/basic_network_options).
###### Dual-stack Networking
[Dual-stack](https://docs.rke2.io/install/network_options#dual-stack-configuration) networking is supported for all CNI providers. To configure RKE2 in dual-stack mode, set valid IPv4/IPv6 CIDRs for your [Cluster CIDR](#cluster-cidr) and/or [Service CIDR](#service-cidr).
###### Dual-stack Additional Configuration
:::caution
When using `cilium` or `multus,cilium` as your container network interface provider, ensure the **Enable IPv6 Support** option is also enabled.
:::
##### Cloud Provider
You can configure a [Kubernetes cloud provider](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/set-up-cloud-providers.md). If you want to use dynamically provisioned [volumes and storage](../../../how-to-guides/new-user-guides/manage-clusters/create-kubernetes-persistent-storage/create-kubernetes-persistent-storage.md) in Kubernetes, typically you must select the specific cloud provider in order to use it. For example, if you want to use Amazon EBS, you would need to select the `aws` cloud provider.
@@ -181,27 +181,62 @@ Option to choose whether to expose etcd metrics to the public or only within the
##### Cluster CIDR
IPv4 and/or IPv6 network CIDRs to use for pod IPs (default: 10.42.0.0/16).
IPv4 and/or IPv6 network CIDRs to use for pod IPs (default: `10.42.0.0/16`).
###### Dual-stack Networking
Example values:
To configure [dual-stack](https://docs.rke2.io/install/network_options#dual-stack-configuration) mode, enter a valid IPv4/IPv6 CIDR. For example `10.42.0.0/16,2001:cafe:42:0::/56`.
- IPv4-only: `10.42.0.0/16`
- IPv6-only: `2001:cafe:42::/56`
- Dual-stack: `10.42.0.0/16,2001:cafe:42::/56`
[Additional configuration](#dual-stack-additional-configuration) is required when using `cilium` or `multus,cilium` as your [container network](#container-network-provider) interface provider.
For additional requirements and limitations related to dual-stack or IPv6-only networking, see the following resources:
- [RKE2 documentation: Dual-stack configuration](https://docs.rke2.io/networking/basic_network_options#dual-stack-configuration)
- [RKE2 documentation: IPv6-only setup](https://docs.rke2.io/networking/basic_network_options#ipv6-setup)
:::caution
You must configure the Service CIDR when you first create the cluster. You cannot enable the Service CIDR on an existing cluster after it starts.
:::
:::caution
When using `cilium` or `multus,cilium` as your container network interface provider, ensure the **Enable IPv6 Support** option is also enabled.
:::
##### Service CIDR
IPv4/IPv6 network CIDRs to use for service IPs (default: 10.43.0.0/16).
IPv4/IPv6 network CIDRs to use for service IPs (default: `10.43.0.0/16`).
###### Dual-stack Networking
Example values:
To configure [dual-stack](https://docs.rke2.io/install/network_options#dual-stack-configuration) mode, enter a valid IPv4/IPv6 CIDR. For example `10.42.0.0/16,2001:cafe:42:0::/56`.
- IPv4-only: `10.43.0.0/16`
- IPv6-only: `2001:cafe:43::/112`
- Dual-stack: `10.43.0.0/16,2001:cafe:43::/112`
[Additional configuration](#dual-stack-additional-configuration) is required when using `cilium ` or `multus,cilium` as your [container network](#container-network-provider) interface provider.
For additional requirements and limitations related to dual-stack or IPv6-only networking, see the following resources:
- [RKE2 documentation: Dual-stack configuration](https://docs.rke2.io/networking/basic_network_options#dual-stack-configuration)
- [RKE2 documentation: IPv6-only setup](https://docs.rke2.io/networking/basic_network_options#ipv6-setup)
:::caution
You must configure the Service CIDR when you first create the cluster. You cannot enable the Service CIDR on an existing cluster after it starts.
:::
:::caution
When using `cilium` or `multus,cilium` as your container network interface provider, ensure the **Enable IPv6 Support** option is also enabled.
:::
##### Cluster DNS
IPv4 Cluster IP for coredns service. Should be in your service-cidr range (default: 10.43.0.10).
IPv4 Cluster IP for coredns service. Should be in your service-cidr range (default: `10.43.0.10`).
##### Cluster Domain
@@ -213,11 +248,11 @@ Option to change the range of ports that can be used for [NodePort services](htt
##### Truncate Hostnames
Option to truncate hostnames to 15 characters or less. You can only set this field during the initial creation of the cluster. You can't enable or disable the 15 character limit after cluster creation.
Option to truncate hostnames to 15 characters or fewer. You can only set this field during the initial creation of the cluster. You can't enable or disable the 15-character limit after cluster creation.
This setting only affects machine-provisioned clusters. Since custom clusters set hostnames during their own node creation process, which occurs outside of Rancher, this field doesn't restrict custom cluster hostname length.
Truncating hostnames in a cluster improves compatibility with Windows-based systems. Although Kubernetes allows hostnames up to 63 characters in length, systems that use NetBIOS restrict hostnames to 15 characters or less.
Truncating hostnames in a cluster improves compatibility with Windows-based systems. Although Kubernetes allows hostnames up to 63 characters in length, systems that use NetBIOS restrict hostnames to 15 characters or fewer.
##### TLS Alternate Names
@@ -233,6 +268,33 @@ For more detail on how an authorized cluster endpoint works and why it is used,
We recommend using a load balancer with the authorized cluster endpoint. For details, refer to the [recommended architecture section.](../../rancher-manager-architecture/architecture-recommendations.md#architecture-for-an-authorized-cluster-endpoint-ace)
##### Stack Preference
Choose the networking stack for the cluster. This option affects:
- The address used for health and readiness probes of components such as Calico, etcd, kube-apiserver, kube-scheduler, kube-controller-manager, and kubelet.
- The server URL in the `authentication-token-webhook-config-file` for the Authorized Cluster Endpoint.
- The `advertise-client-urls` setting for etcd during snapshot restoration.
Options are `ipv4`, `ipv6`, `dual`:
- When set to `ipv4`, the cluster uses `127.0.0.1`
- When set to `ipv6`, the cluster uses `[::1]`
- When set to `dual`, the cluster uses `localhost`
The stack preference must match the cluster’s networking configuration:
- Set to `ipv4` for IPv4-only clusters
- Set to `ipv6` for IPv6-only clusters
- Set to `dual` for dual-stack clusters
:::caution
Ensuring the loopback address configuration is correct is critical for successful cluster provisioning.
For more information, refer to the [Node Requirements](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md) page.
:::
#### Registries
Select the image repository to pull Rancher images from. For more details and configuration options, see the [RKE2 documentation](https://docs.rke2.io/install/private_registry).
@@ -1,57 +0,0 @@
---
title: Rancher Agent Options
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options"/>
</head>
Rancher deploys an agent on each node to communicate with the node. This pages describes the options that can be passed to the agent. To use these options, you will need to [create a cluster with custom nodes](use-existing-nodes.md) and add the options to the generated `docker run` command when adding a node.
For an overview of how Rancher communicates with downstream clusters using node agents, refer to the [architecture section.](../../../rancher-manager-architecture/communicating-with-downstream-user-clusters.md#3-node-agents)
## General options
| Parameter | Environment variable | Description |
| ---------- | -------------------- | ----------- |
| `--server` | `CATTLE_SERVER` | The configured Rancher `server-url` setting which the agent connects to |
| `--token` | `CATTLE_TOKEN` | Token that is needed to register the node in Rancher |
| `--ca-checksum` | `CATTLE_CA_CHECKSUM` | The SHA256 checksum of the configured Rancher `cacerts` setting to validate |
| `--node-name` | `CATTLE_NODE_NAME` | Override the hostname that is used to register the node (defaults to `hostname -s`) |
| `--label` | `CATTLE_NODE_LABEL` | Add node labels to the node. For multiple labels, pass additional `--label` options. (`--label key=value`) |
| `--taints` | `CATTLE_NODE_TAINTS` | Add node taints to the node. For multiple taints, pass additional `--taints` options. (`--taints key=value:effect`) |
## Role options
| Parameter | Environment variable | Description |
| ---------- | -------------------- | ----------- |
| `--all-roles` | `ALL=true` | Apply all roles (`etcd`,`controlplane`,`worker`) to the node |
| `--etcd` | `ETCD=true` | Apply the role `etcd` to the node |
| `--controlplane` | `CONTROL=true` | Apply the role `controlplane` to the node |
| `--worker` | `WORKER=true` | Apply the role `worker` to the node |
## IP address options
| Parameter | Environment variable | Description |
| ---------- | -------------------- | ----------- |
| `--address` | `CATTLE_ADDRESS` | The IP address the node will be registered with (defaults to the IP used to reach `8.8.8.8`) |
| `--internal-address` | `CATTLE_INTERNAL_ADDRESS` | The IP address used for inter-host communication on a private network |
### Dynamic IP address options
For automation purposes, you can't have a specific IP address in a command as it has to be generic to be used for every node. For this, we have dynamic IP address options. They are used as a value to the existing IP address options. This is supported for `--address` and `--internal-address`.
| Value | Example | Description |
| ---------- | -------------------- | ----------- |
| Interface name | `--address eth0` | The first configured IP address will be retrieved from the given interface |
| `ipify` | `--address ipify` | Value retrieved from `https://api.ipify.org` will be used |
| `awslocal` | `--address awslocal` | Value retrieved from `http://169.254.169.254/latest/meta-data/local-ipv4` will be used |
| `awspublic` | `--address awspublic` | Value retrieved from `http://169.254.169.254/latest/meta-data/public-ipv4` will be used |
| `doprivate` | `--address doprivate` | Value retrieved from `http://169.254.169.254/metadata/v1/interfaces/private/0/ipv4/address` will be used |
| `dopublic` | `--address dopublic` | Value retrieved from `http://169.254.169.254/metadata/v1/interfaces/public/0/ipv4/address` will be used |
| `azprivate` | `--address azprivate` | Value retrieved from `http://169.254.169.254/metadata/instance/network/interface/0/ipv4/ipAddress/0/privateIpAddress?api-version=2017-08-01&format=text` will be used |
| `azpublic` | `--address azpublic` | Value retrieved from `http://169.254.169.254/metadata/instance/network/interface/0/ipv4/ipAddress/0/publicIpAddress?api-version=2017-08-01&format=text` will be used |
| `gceinternal` | `--address gceinternal` | Value retrieved from `http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/ip` will be used |
| `gceexternal` | `--address gceexternal` | Value retrieved from `http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/access-configs/0/external-ip` will be used |
| `packetlocal` | `--address packetlocal` | Value retrieved from `https://metadata.packet.net/2009-04-04/meta-data/local-ipv4` will be used |
| `packetpublic` | `--address packetlocal` | Value retrieved from `https://metadata.packet.net/2009-04-04/meta-data/public-ipv4` will be used |
@@ -9,7 +9,7 @@ description: To create a cluster with custom nodes, you’ll need to access serv
When you create a custom cluster, Rancher can use RKE2/K3s to create a Kubernetes cluster in on-prem bare-metal servers, on-prem virtual machines, or in any node hosted by an infrastructure provider.
To use this option you'll need access to servers you intend to use in your Kubernetes cluster. Provision each server according to the [requirements](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md), which includes some hardware specifications and Docker. After you install Docker on each server, you willl also run the command provided in the Rancher UI on each server to turn each one into a Kubernetes node.
To use this option, you need access to the servers that will be part of your Kubernetes cluster. Provision each server according to the [requirements](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md). Then, run the command provided in the Rancher UI on each server to convert it into a Kubernetes node.
This section describes how to set up a custom cluster.
@@ -33,7 +33,15 @@ If you want to reuse a node from a previous custom cluster, [clean the node](../
Provision the host according to the [installation requirements](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md) and the [checklist for production-ready clusters.](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/checklist-for-production-ready-clusters/checklist-for-production-ready-clusters.md)
If you're using Amazon EC2 as your host and want to use the [dual-stack](https://kubernetes.io/docs/concepts/services-networking/dual-stack/) feature, there are additional [requirements](https://rancher.com/docs/rke//latest/en/config-options/dual-stack#requirements) when provisioning the host.
:::note IPv6-only cluster
For an IPv6-only cluster, ensure that your operating system correctly configures the `/etc/hosts` file.
```
::1 localhost
```
:::
### 2. Create the Custom Cluster
@@ -41,39 +49,43 @@ If you're using Amazon EC2 as your host and want to use the [dual-stack](https:/
1. On the **Clusters** page, click **Create**.
1. Click **Custom**.
1. Enter a **Cluster Name**.
1. Use **Cluster Configuration** section to choose the version of Kubernetes, what network provider will be used and if you want to enable project network isolation. To see more cluster options, click on **Show advanced options**.
1. Use the **Cluster Configuration** section to set up the cluster. For more information, see [RKE2 Cluster Configuration Reference](../rke2-cluster-configuration.md) and [K3s Cluster Configuration Reference](../k3s-cluster-configuration.md).
:::note Using Windows nodes as Kubernetes workers?
:::note Windows nodes
- See [Enable the Windows Support Option](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/use-windows-clusters/use-windows-clusters.md).
- The only Network Provider available for clusters with Windows support is Flannel.
To learn more about using Windows nodes as Kubernetes workers, see [Launching Kubernetes on Windows Clusters](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/use-windows-clusters/use-windows-clusters.md).
:::
:::
:::note Dual-stack on Amazon EC2:
1. Click **Create**.
If you're using Amazon EC2 as your host and want to use the [dual-stack](https://kubernetes.io/docs/concepts/services-networking/dual-stack/) feature, there are additional [requirements](https://rancher.com/docs/rke//latest/en/config-options/dual-stack#requirements) when configuring RKE.
**Result:** The UI redirects to the **Registration** page, where you can generate the registration command for your nodes.
:::
1. From **Node Role**, select the roles you want a cluster node to fill. You must provision at least one node for each role: etcd, worker, and control plane. A custom cluster requires all three roles to finish provisioning. For more information on roles, see [Roles for Nodes in Kubernetes Clusters](../../../kubernetes-concepts.md#roles-for-nodes-in-kubernetes-clusters).
6. Click **Next**.
:::note Bare-Metal Server
4. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
If you plan to dedicate bare-metal servers to each role, you must provision a bare-metal server for each role (i.e., provision multiple bare-metal servers).
7. From **Node Role**, choose the roles that you want filled by a cluster node. You must provision at least one node for each role: `etcd`, `worker`, and `control plane`. All three roles are required for a custom cluster to finish provisioning. For more information on roles, see [this section.](../../../kubernetes-concepts.md#roles-for-nodes-in-kubernetes-clusters)
:::note
:::note
1. **Optional**: Click **Show Advanced** to configure additional settings such as specifying the IP address(es), overriding the node hostname, or adding [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) or [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to the node
- Using Windows nodes as Kubernetes workers? See [this section](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/use-windows-clusters/use-windows-clusters.md).
- Bare-Metal Server Reminder: If you plan on dedicating bare-metal servers to each role, you must provision a bare-metal server for each role (i.e. provision multiple bare-metal servers).
:::note
:::
The **Node Public IP** and **Node Private IP** fields can accept either a single address or a comma-separated list of addresses (for example: `10.0.0.5,2001:db8::1`).
8. **Optional**: Click **[Show advanced options](rancher-agent-options.md)** to specify IP address(es) to use when registering the node, override the hostname of the node, or to add [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) or [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to the node.
:::
9. Copy the command displayed on screen to your clipboard.
:::note Ipv6-only or Dual-stack Cluster
10. Log in to your Linux host using your preferred shell, such as PuTTy or a remote Terminal connection. Run the command copied to your clipboard.
In both IPv6-only and dual-stack clusters, you should specify the node’s **IPv6 address** as the **Node Private IP**.
:::
1. Copy the command displayed on screen to your clipboard.
1. Log in to your Linux host using your preferred shell, such as PuTTy or a remote Terminal connection. Run the command copied to your clipboard.
:::note
@@ -81,11 +93,9 @@ Repeat steps 7-10 if you want to dedicate specific hosts to specific node roles.
:::
11. When you finish running the command(s) on your Linux host(s), click **Done**.
**Result:**
Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
The cluster is created and transitions to the **Updating** state while Rancher initializes and provisions cluster components.
You can access your cluster after its state is updated to **Active**.
+122
View File
@@ -0,0 +1,122 @@
---
title: IPv4/IPv6 Dual-stack
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/dual-stack/"/>
</head>
Kubernetes supports IPv4-only, IPv6-only, and dual-stack networking configurations.
For more details, refer to the official [Kubernetes documentation](https://kubernetes.io/docs/concepts/services-networking/dual-stack/).
## Installing Rancher on IPv6-Only or Dual-Stack Clusters
Rancher can run on clusters using:
- IPv4-only
- IPv6-only
- Dual-stack (IPv4 + IPv6)
When you install Rancher on an **IPv6-only cluster**, it can communicate externally **only over IPv6**. This means it can provision:
- IPv6-only clusters
- Dual-stack clusters
_(IPv4-only downstream clusters are not possible in this case)_
When you install Rancher on a **dual-stack cluster**, it can communicate over both IPv4 and IPv6, and can therefore provision:
- IPv4-only clusters
- IPv6-only clusters
- Dual-stack clusters
For installation steps, see the guide: **[Installing and Upgrading Rancher](../getting-started/installation-and-upgrade/installation-and-upgrade.md)**.
### Requirement for the Rancher Server URL
When provisioning IPv6-only downstream clusters, the **Rancher Server URL must be reachable over IPv6** because downstream nodes connect back to the Rancher server using IPv6.
## Provisioning IPv6-Only or Dual-Stack Clusters
You can provision RKE2 and K3s **Node driver** (machine pools) or **Custom cluster** (existing hosts) clusters using IPv4-only, IPv6-only, or dual-stack networking.
### Network Configuration
To enable IPv6-only or dual-stack networking, you must configure:
- Cluster CIDR
- Service CIDR
- Stack Preference
Configuration references:
- [K3s Cluster Configuration Reference](cluster-configuration/rancher-server-configuration/k3s-cluster-configuration.md)
- [RKE2 Cluster Configuration Reference](cluster-configuration/rancher-server-configuration/rke2-cluster-configuration.md)
### Support for Windows
Kubernetes on Windows:
| Feature | Support Status |
|---------------------|-------------------------------|
| IPv6-only clusters | Not supported |
| Dual-stack clusters | Supported |
| Services | Limited to a single IP family |
For more information, see the [Kubernetes Documentation](https://kubernetes.io/docs/concepts/services-networking/dual-stack/#windows-support).
K3s does **not** support Windows ([FAQ](https://docs.k3s.io/faq#does-k3s-support-windows))
RKE2 supports Windows, but requires using either `Calico` or `Flannel` as the CNI.
Note that Windows installations of RKE2 do not support dual-stack clusters using BGP.
For more details, see [RKE2 Network Options](https://docs.rke2.io/networking/basic_network_options).
### Provisioning Node Driver Clusters
Rancher currently supports assigning IPv6 addresses in **node driver** clusters with:
- [Amazon EC2](../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md)
- [DigitalOcean](../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-a-digitalocean-cluster.md)
Support for additional providers will be introduced in future releases.
:::note DigitalOcean Limitation
Creating an **IPv6-only cluster** using the DigitalOcean node driver is currently **not supported**.
For more details, please see [rancher/rancher#52523](https://github.com/rancher/rancher/issues/52523#issuecomment-3457803572).
:::
#### Infrastructure Requirements
Cluster nodes must meet the requirements listed in the [Node Requirements for Rancher Managed Clusters](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md).
Machine pool configuration guides:
- [Amazon EC2 Configuration](cluster-configuration/downstream-cluster-configuration/machine-configuration/amazon-ec2.md)
- [DigitalOcean Configuration](cluster-configuration/downstream-cluster-configuration/machine-configuration/digitalocean.md)
### Provisioning Custom Clusters
To provision on your own nodes, follow the instructions in [Provision Kubernetes on Existing Nodes](cluster-configuration/rancher-server-configuration/use-existing-nodes/use-existing-nodes.md).
:::note
- **Node Public IP** and **Node Private IP** fields accept IPv4, IPv6, or both (comma-separated).
> Example: `10.0.0.5,2001:db8::1`
- In **IPv6-only** and **dual-stack** clusters, specify the node’s **IPv6 address** as the **Private IP**.
:::
#### Infrastructure Requirements
Infrastructure requirements are the same as above for node-driver clusters.
## Other Limitations
### GitHub.com
GitHub.com does **not** support IPv6. As a result:
- Any application repositories ( `ClusterRepo.catalog.cattle.io/v1` CR) hosted on GitHub.com will **not be reachable** from IPv6-only clusters.
- Similarly, any **non-builtin node drivers** hosted on GitHub.com will also **not be accessible** in IPv6-only environments.
@@ -1,15 +0,0 @@
---
title: Kubernetes Security Best Practices
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/kubernetes-security-best-practices"/>
</head>
## Restricting Cloud Metadata API Access
Cloud providers such as AWS, Azure, DigitalOcean or GCP often expose metadata services locally to instances. By default, this endpoint is accessible by pods running on a cloud instance, including pods in hosted Kubernetes providers such as EKS, AKS, DigitalOcean Kubernetes or GKE, and can contain cloud credentials for that node, provisioning data such as kubelet credentials, or other sensitive data. To mitigate this risk when running on a cloud platform, follow the [Kubernetes security recommendations](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/#restricting-cloud-metadata-api-access): limit permissions given to instance credentials, use network policies to restrict pod access to the metadata API, and avoid using provisioning data to deliver secrets.
It is advised to consult your cloud provider's security best practices for further recommendations and specific details on how to restrict access to cloud instance metadata API.
Further references: MITRE ATT&CK knowledge base on - [Unsecured Credentials: Cloud Instance Metadata API](https://attack.mitre.org/techniques/T1552/005/).
@@ -55,6 +55,7 @@ plugins:
cert-manager,
cis-operator-system,
fleet-default,
fleet-local,
ingress-nginx,
istio-system,
kube-node-lease,
@@ -63,5 +64,6 @@ plugins:
longhorn-system,
rancher-alerting-drivers,
security-scan,
sr-operator-system,
tigera-operator]
```
@@ -41,9 +41,7 @@ For details, refer to the section on [security scans](../../how-to-guides/advanc
`
## 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.
We provide two RPMs (Red Hat packages) that enable Rancher products to function properly on SELinux-enforcing hosts: `rancher-selinux` and `rke2-selinux`. For details, see [this page](selinux-rpm/selinux-rpm.md).
We provide three RPMs (RPM Package Manager) that enable Rancher products to function properly on SELinux-enforcing hosts: `rancher-selinux`, `rke2-selinux` and `k3s-selinux`. For details, see [this page](selinux-rpm/selinux-rpm.md).
## Rancher Hardening Guide
@@ -80,8 +78,39 @@ Rancher is committed to informing the community of security issues in our produc
## Kubernetes Security Best Practices
For recommendations on securing your Kubernetes cluster, refer to the [Kubernetes Security Best Practices](kubernetes-security-best-practices.md) guide.
For recommendations on securing your Kubernetes cluster, refer to the [Kubernetes Cluster Security Best Practices](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/) guide.
## Rancher Security Best Practices
For recommendations on securing your Rancher Manager deployments, refer to the [Rancher Security Best Practices](rancher-security-best-practices.md) guide.
## Rancher Kubernetes Distributions (K3s/RKE2) Self-Assessment and Hardening Guides
Rancher uses the following Kubernetes distributions:
- [**RKE2**](https://docs.rke2.io/) is a fully conformant Kubernetes distribution that focuses on security and compliance within the U.S. Federal Government sector.
- [**K3s**](https://docs.k3s.io/) is a fully conformant, lightweight Kubernetes distribution. It is easy to install, with half the memory requirement of upstream Kubernetes, all in a binary of less than 100 MB.
To harden a Kubernetes cluster that's running a distribution other than those listed, refer to your Kubernetes provider's docs.
### Hardening Guides and Benchmark Versions
Each self-assessment guide is accompanied by a hardening guide. These guides were tested alongside the listed Rancher releases. Each self-assessment guide was tested on a specific Kubernetes version and CIS benchmark version. If a CIS benchmark has not been validated for your Kubernetes version, you can use the existing guides until a guide for your version is added.
### RKE2 Guides
| Type | Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guide |
|------|--------------------|-----------------------|-----------------------|------------------|
| Standalone RKE2 | Kubernetes v1.26 | CIS v1.8 | [Link](https://docs.rke2.io/security/cis_self_assessment18) | [Link](https://docs.rke2.io/security/hardening_guide) |
| Standalone RKE2 | Kubernetes v1.27 | CIS v1.9 | [Link](https://docs.rke2.io/security/cis_self_assessment19) | [Link](https://docs.rke2.io/security/hardening_guide) |
| Standalone RKE2 | Kubernetes v1.28 | CIS v1.10 | [Link](https://docs.rke2.io/security/cis_self_assessment110) | [Link](https://docs.rke2.io/security/hardening_guide) |
| Standalone RKE2 | Kubernetes v1.29 and above | CIS v1.11 | [Link](https://docs.rke2.io/security/cis_self_assessment111) | [Link](https://docs.rke2.io/security/hardening_guide) |
### K3s Guides
| Type | Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guide |
|------|--------------------|-----------------------|-----------------------|------------------|
| Standalone K3s | Kubernetes v1.26 | CIS v1.8 | [Link](https://docs.k3s.io/security/self-assessment-1.8) | [Link](https://docs.k3s.io/security/hardening-guide) |
| Standalone K3s | Kubernetes v1.27 | CIS v1.9 | [Link](https://docs.k3s.io/security/self-assessment-1.9) | [Link](https://docs.k3s.io/security/hardening-guide) |
| Standalone K3s | Kubernetes v1.28 | CIS v1.10 | [Link](https://docs.k3s.io/security/self-assessment-1.10) | [Link](https://docs.k3s.io/security/hardening-guide) |
| Standalone K3s | Kubernetes v1.29 and above | CIS v1.11 | [Link](https://docs.k3s.io/security/self-assessment-1.11) | [Link](https://docs.k3s.io/security/hardening-guide) |
@@ -10,6 +10,8 @@ Rancher is committed to informing the community of security issues in our produc
| ID | Description | Date | Resolution |
|----|-------------|------|------------|
| [CVE-2025-62879](https://github.com/rancher/backup-restore-operator/security/advisories/GHSA-wj3p-5h3x-c74q) | Rancher now provides new versions of the Rancher Backup chart which prevent the leak of secret S3 credentials via the Rancher Backup pod log. For more information. | 29 Jan 2026 | Rancher [v2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2), [v2.12.6](https://github.com/rancher/rancher/releases/tag/v2.12.6), [v2.11.10](https://github.com/rancher/rancher/releases/tag/v2.11.10), and [v2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) |
| [CVE-2025-67601](https://github.com/rancher/rancher/security/advisories/GHSA-mc24-7m59-4q5p) | Rancher now removes the ability to fetch CA certificates stored in Rancher’s setting `cacerts` when using the `login` command. For more information. | 29 Jan 2026 | Rancher [v2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2), [v2.12.6](https://github.com/rancher/rancher/releases/tag/v2.12.6), [v2.11.10](https://github.com/rancher/rancher/releases/tag/v2.11.10), and [v2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) |
| [CVE-2023-32199](https://github.com/rancher/rancher/security/advisories/GHSA-j4vr-pcmw-hx59) | Rancher now removes the corresponding ClusterRoleBindings whenever the admin GlobalRole or its GlobalRoleBindings are deleted. Previously orphaned ClusterRoleBindings were marked with the annotation `authz.cluster.cattle.io/admin-globalrole-missing=true`. | 23 Oct 2025 | Rancher [v2.12.3](https://github.com/rancher/rancher/releases/tag/v2.12.3) and [v2.11.7](https://github.com/rancher/rancher/releases/tag/v2.11.7) |
| [CVE-2024-58269](https://github.com/rancher/rancher/security/advisories/GHSA-mw39-9qc2-f7mg) | The Rancher audit log redaction process has changed to the following: <br/><br/><ul><li> It now redacts `kubectl.kubernetes.io/last-applied-configuration` annotations on both Response and Request body contents. Previously it did not redact Response body content.</li><li> It now redacts Cluster Import URLs on both Request URLs and Referer headers. Previously it did not redact Referer headers.</li></ul> | 23 Oct 2025 | Rancher [v2.12.3](https://github.com/rancher/rancher/releases/tag/v2.12.3) |
| [CVE-2024-58260](https://github.com/rancher/rancher/security/advisories/GHSA-q82v-h4rq-5c86) | Setting the username of one user as the same username of another user causes an error when either user attempts to log in. Therefore, a user with the `Manage Users` permission could potentially deny any user, including admins, from logging in. To prevent this, usernames have been made immutable once set, and it is not possible to update or create a user with a username that is already in use. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
@@ -0,0 +1,13 @@
---
title: About k3s-selinux
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/selinux-rpm/about-k3s-selinux"/>
</head>
`k3s-selinux` provides policies for K3s. It is installed automatically when the K3s installer script detects that it is running on an RPM-based distro.
The `k3s-selinux` GitHub repository is [here](https://github.com/rancher/k3s-selinux).
For more information about installing K3s on SELinux-enabled hosts, see the [K3s documentation](https://docs.k3s.io/advanced#selinux-support).
@@ -16,7 +16,7 @@ The `rancher-selinux` GitHub repository is [here.](https://github.com/rancher/ra
:::note Requirement:
The rancher-selinux RPM was tested with CentOS 7, 8 and 9.
The `rancher-selinux` RPM was tested on openSUSE Tumbleweed and RHEL-based distributions including Centos/RockyLinux 8 and 9.
:::
@@ -24,19 +24,6 @@ The rancher-selinux RPM was tested with CentOS 7, 8 and 9.
Set up the yum repo to install `rancher-selinux` directly on all hosts in the cluster.
In order to use the RPM repository, on a CentOS 7 or RHEL 7 system, run the following bash snippet:
```
# cat << EOF > /etc/yum.repos.d/rancher.repo
[rancher]
name=Rancher
baseurl=https://rpm.rancher.io/rancher/production/centos/7/noarch
enabled=1
gpgcheck=1
gpgkey=https://rpm.rancher.io/public.key
EOF
```
In order to use the RPM repository, on a CentOS 8 or RHEL 8 system, run the following bash snippet:
```
@@ -71,14 +58,14 @@ Install the RPM:
yum -y install rancher-selinux
```
## Configuring the Logging Application to Work with SELinux
## Configuring the Logging and Monitoring Applications to Work with SELinux
:::note Requirement:
Logging v2 was tested with SELinux on RHEL/CentOS 7, 8 and 9.
Logging v2 and Monitoring v2 were tested with SELinux on RHEL/CentOS 8, 9, and Tumbleweed.
:::
Applications do not automatically work once the `rancher-selinux` RPM is installed on the host. They need to be configured to run in an allowed SELinux container domain provided by the RPM.
To configure the `rancher-logging` chart to be SELinux aware, change `global.seLinux.enabled` to true in the `values.yaml` when installing the chart.
To configure the `rancher-logging` or the `rancher-monitoring` chart to be SELinux aware, change `global.seLinux.enabled` to true in the `values.yaml` when installing the charts.
@@ -10,11 +10,14 @@ title: SELinux RPM
Developed by Red Hat, it is an implementation of mandatory access controls (MAC) on Linux. Mandatory access controls allow an administrator of a system to define how applications and users can access different resources such as files, devices, networks and inter-process communication. SELinux also enhances security by making an OS restrictive by default.
After being historically used by government agencies, SELinux is now industry standard and is enabled by default on CentOS 7 and 8. To check whether SELinux is enabled and enforcing on your system, use `getenforce`:
After being historically used by government agencies, SELinux is now an industry standard and enabled by default on SUSE distributions such as SUSE Linux Enterprise 16, openSUSE distributions such as openSUSE Tumbleweed, and RHEL-based OS such as Rocky Linux. To check whether SELinux is enabled and enforced on your system, use `getenforce`:
```
# getenforce
Enforcing
```
We provide two RPMs (Red Hat packages) that enable Rancher products to function properly on SELinux-enforcing hosts: [`rancher-selinux`](about-rancher-selinux.md) and [`rke2-selinux`](about-rke2-selinux.md).
We provide three RPMs (RPM Package Manager) that enable Rancher products to function properly on SELinux-enforcing hosts:
- [`rancher-selinux`](about-rancher-selinux.md)
- [`rke2-selinux`](about-rke2-selinux.md)
- [`k3s-selinux`](about-k3s-selinux.md)
+3 -4
View File
@@ -20,10 +20,9 @@ Each Rancher version is designed to be compatible with a single version of the w
| Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
|-----------------|-----------------|-----------------------|---------------------------|
| v2.12.3 | v0.8.3 | &check; | &check; |
| v2.12.2 | v0.8.2 | &check; | &check; |
| v2.12.1 | v0.8.1 | &check; | &check; |
| v2.12.0 | v0.8.0 | &cross; | &check; |
| v2.13.2 | v0.9.2 | &check; | &check; |
| v2.13.1 | v0.9.1 | &check; | &check; |
| v2.13.0 | v0.9.0 | &cross; | &check; |
## Why Do We Need It?
+11 -1
View File
@@ -184,7 +184,12 @@ module.exports = {
current: {
label: "Latest",
},
'2.12': {
"2.13": {
label: "v2.13",
path: "v2.13",
banner: 'none'
},
"2.12": {
label: "v2.12",
path: "v2.12",
banner: "none"
@@ -251,6 +256,11 @@ module.exports = {
{
// Plugin Options for loading OpenAPI files
specs: [
{
id: "rancher-api-v2-13",
spec: "openapi/swagger-v2.13.json",
// route: '/api/',
},
{
id: "rancher-api-v2-12",
spec: "openapi/swagger-v2.12.json",
@@ -14,4 +14,4 @@ title: API 参考
import ApiDocMdx from '@theme/ApiDocMdx';
<ApiDocMdx id="rancher-api-v2-12" />
<ApiDocMdx id="rancher-api-v2-13" />
@@ -63,6 +63,7 @@ title: API 令牌
| 设置 | 描述 |
| ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes) | 用户认证会话令牌的 TTL(单位:分钟)。 |
| [`auth-user-session-idle-ttl-minutes`](#auth-user-session-idle-ttl-minutes) | TTL in minutes on a user auth session token, without user activity. |
| [`kubeconfig-default-token-TTL-minutes`](#kubeconfig-default-token-ttl-minutes) | 默认 TTL,应用于所有 kubeconfig 令牌(除了[由 Rancher CLI 生成的令牌](#在生成的-kubeconfig-中禁用令牌))。**此设置从 2.6.6 版本开始引入。** |
| [`kubeconfig-token-ttl-minutes`](#kubeconfig-token-ttl-minutes) | 在 CLI 中生成的令牌 TTL。**自 2.6.6 起已弃用,并将在 2.8.0 中删除**。请知悉,`kubeconfig-default-token-TTL-minutes` 将用于所有 kubeconfig 令牌。 |
| [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes) | 除了由 [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes) 控制的令牌外,所有令牌的最大 TTL。 |
@@ -71,6 +72,11 @@ title: API 令牌
### auth-user-session-ttl-minutes
存活时间(TTL)(单位:分钟),用于确定用户身份验证会话令牌的到期时间。过期后,用户将需要登录并获取新令牌。此设置不受 [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes) 的影响。会话令牌是在用户登录 Rancher 时创建的。
### auth-user-session-idle-ttl-minutes
Time to live (TTL) without user activity for login sessions tokens, in minutes.
By default, `auth-user-session-idle-ttl-minutes` is set to the same value as [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes) (for backward compatibility). It must never exceed the value of `auth-user-session-ttl-minutes`.
### kubeconfig-default-token-TTL-minutes
存活时间(TTL)(单位:分钟),用于确定 kubeconfig 令牌的到期时间。令牌过期后,API 将拒绝令牌。此设置的值不能大于 [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes) 的值。此设置适用于在请求的 kubeconfig 文件中生成的令牌,不包括[由 Rancher CLI 生成的](#在生成的-kubeconfig-中禁用令牌)令牌。
**此设置从 2.6.6 版本开始引入**。
@@ -37,8 +37,7 @@ apiVersion: management.cattle.io/v3
kind: Project
metadata:
annotations:
field.cattle.io/creatorId:
user-id
field.cattle.io/creatorId: user-id
generateName: p-
namespace: c-m-abcde
spec:
@@ -16,10 +16,9 @@ Rancher 将在 GitHub 上发布的 Rancher 的[发版说明](https://github.com/
| Patch 版本 | 发布时间 |
| ----------------------------------------------------------------- | ------------------ |
| [2.12.3](https://github.com/rancher/rancher/releases/tag/v2.12.3) | 2025 年 10 月 23 日 |
| [2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2) | 2025 年 9 月 25 日 |
| [2.12.1](https://github.com/rancher/rancher/releases/tag/v2.12.1) | 2025 年 8 月 28 日 |
| [2.12.0](https://github.com/rancher/rancher/releases/tag/v2.12.0) | 2025 年 7 月 30 日 |
| [2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2) | 2026 年 01 月 29 日 |
| [2.13.1](https://github.com/rancher/rancher/releases/tag/v2.13.1) | 2025 年 12 月 18 日 |
| [2.13.0](https://github.com/rancher/rancher/releases/tag/v2.13.0) | 2025 年 11 月 25 日 |
## 当一个功能被标记为弃用我可以得到什么样的预期?
@@ -11,10 +11,8 @@ Kubernetes 每隔五分钟会自动清理 etcd 数据集。在某些情况下(
```yaml
# RKE2/K3s config.yaml
---
services:
etcd:
extra_args:
quota-backend-bytes: 5368709120
etcd-arg:
- "quota-backend-bytes=5368709120"
```
## 扩展 etcd 磁盘性能
@@ -28,12 +26,7 @@ services:
```yaml
# RKE2/K3s config.yaml
---
services:
etcd:
extra_args:
data-dir: '/var/lib/rancher/etcd/data/'
wal-dir: '/var/lib/rancher/etcd/wal/wal_dir'
extra_binds:
- '/var/lib/etcd/data:/var/lib/rancher/etcd/data'
- '/var/lib/etcd/wal:/var/lib/rancher/etcd/wal'
etcd-arg:
- "data-dir=/var/lib/etcd/data"
- "wal-dir=/var/lib/etcd/wal"
```
@@ -36,71 +36,72 @@ weight: 1
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"autoscaling:DescribeAutoScalingGroups",
"autoscaling:DescribeLaunchConfigurations",
"autoscaling:DescribeTags",
"ec2:DescribeInstances",
"ec2:DescribeRegions",
"ec2:DescribeRouteTables",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVolumes",
"ec2:CreateSecurityGroup",
"ec2:CreateTags",
"ec2:CreateVolume",
"ec2:ModifyInstanceAttribute",
"ec2:ModifyVolume",
"ec2:AttachVolume",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateRoute",
"ec2:DeleteRoute",
"ec2:DeleteSecurityGroup",
"ec2:DeleteVolume",
"ec2:DetachVolume",
"ec2:RevokeSecurityGroupIngress",
"ec2:DescribeVpcs",
"elasticloadbalancing:AddTags",
"elasticloadbalancing:AttachLoadBalancerToSubnets",
"elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
"elasticloadbalancing:CreateLoadBalancer",
"elasticloadbalancing:CreateLoadBalancerPolicy",
"elasticloadbalancing:CreateLoadBalancerListeners",
"elasticloadbalancing:ConfigureHealthCheck",
"elasticloadbalancing:DeleteLoadBalancer",
"elasticloadbalancing:DeleteLoadBalancerListeners",
"elasticloadbalancing:DescribeLoadBalancers",
"elasticloadbalancing:DescribeLoadBalancerAttributes",
"elasticloadbalancing:DetachLoadBalancerFromSubnets",
"elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
"elasticloadbalancing:ModifyLoadBalancerAttributes",
"elasticloadbalancing:RegisterInstancesWithLoadBalancer",
"elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer",
"elasticloadbalancing:AddTags",
"elasticloadbalancing:CreateListener",
"elasticloadbalancing:CreateTargetGroup",
"elasticloadbalancing:DeleteListener",
"elasticloadbalancing:DeleteTargetGroup",
"elasticloadbalancing:DescribeListeners",
"elasticloadbalancing:DescribeLoadBalancerPolicies",
"elasticloadbalancing:DescribeTargetGroups",
"elasticloadbalancing:DescribeTargetHealth",
"elasticloadbalancing:ModifyListener",
"elasticloadbalancing:ModifyTargetGroup",
"elasticloadbalancing:RegisterTargets",
"elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
"iam:CreateServiceLinkedRole",
"kms:DescribeKey"
],
"Resource": [
"*"
]
}
]
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"autoscaling:DescribeAutoScalingGroups",
"autoscaling:DescribeLaunchConfigurations",
"autoscaling:DescribeTags",
"ec2:DescribeInstances",
"ec2:DescribeRegions",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeRouteTables",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVolumes",
"ec2:CreateSecurityGroup",
"ec2:CreateTags",
"ec2:CreateVolume",
"ec2:ModifyInstanceAttribute",
"ec2:ModifyVolume",
"ec2:AttachVolume",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateRoute",
"ec2:DeleteRoute",
"ec2:DeleteSecurityGroup",
"ec2:DeleteVolume",
"ec2:DetachVolume",
"ec2:RevokeSecurityGroupIngress",
"ec2:DescribeVpcs",
"elasticloadbalancing:AddTags",
"elasticloadbalancing:AttachLoadBalancerToSubnets",
"elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
"elasticloadbalancing:CreateLoadBalancer",
"elasticloadbalancing:CreateLoadBalancerPolicy",
"elasticloadbalancing:CreateLoadBalancerListeners",
"elasticloadbalancing:ConfigureHealthCheck",
"elasticloadbalancing:DeleteLoadBalancer",
"elasticloadbalancing:DeleteLoadBalancerListeners",
"elasticloadbalancing:DescribeLoadBalancers",
"elasticloadbalancing:DescribeLoadBalancerAttributes",
"elasticloadbalancing:DetachLoadBalancerFromSubnets",
"elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
"elasticloadbalancing:ModifyLoadBalancerAttributes",
"elasticloadbalancing:RegisterInstancesWithLoadBalancer",
"elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer",
"elasticloadbalancing:AddTags",
"elasticloadbalancing:CreateListener",
"elasticloadbalancing:CreateTargetGroup",
"elasticloadbalancing:DeleteListener",
"elasticloadbalancing:DeleteTargetGroup",
"elasticloadbalancing:DescribeListeners",
"elasticloadbalancing:DescribeLoadBalancerPolicies",
"elasticloadbalancing:DescribeTargetGroups",
"elasticloadbalancing:DescribeTargetHealth",
"elasticloadbalancing:ModifyListener",
"elasticloadbalancing:ModifyTargetGroup",
"elasticloadbalancing:RegisterTargets",
"elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
"iam:CreateServiceLinkedRole",
"kms:DescribeKey"
],
"Resource": [
"*"
]
}
]
}
```
@@ -108,24 +109,25 @@ weight: 1
```json
{
"Version": "2012-10-17",
"Statement": [
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeRegions",
"ecr:GetAuthorizationToken",
"ecr:BatchCheckLayerAvailability",
"ecr:GetDownloadUrlForLayer",
"ecr:GetRepositoryPolicy",
"ecr:DescribeRepositories",
"ecr:ListImages",
"ecr:BatchGetImage"
],
"Resource": "*"
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeRegions",
"ec2:DescribeAvailabilityZones",
"ecr:GetAuthorizationToken",
"ecr:BatchCheckLayerAvailability",
"ecr:GetDownloadUrlForLayer",
"ecr:GetRepositoryPolicy",
"ecr:DescribeRepositories",
"ecr:ListImages",
"ecr:BatchGetImage"
],
"Resource": "*"
}
]
]
}
```
@@ -137,7 +137,8 @@ For instructions on cleaning nodes in RKE2 clusters that weren't deployed by Ran
要删除 rancher-system-agent,请运行 [system-agent-uninstall.sh](https://github.com/rancher/system-agent/blob/main/system-agent-uninstall.sh) 脚本:
```
curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh | sudo sh
curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh > system-agent-uninstall.sh
sudo sh system-agent-uninstall.sh
```
### 删除 RKE2
@@ -161,7 +162,8 @@ sudo rke2-uninstall.sh
要删除 rancher-system-agent,请运行 [system-agent-uninstall.sh](https://github.com/rancher/system-agent/blob/main/system-agent-uninstall.sh) 脚本:
```
curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh | sudo sh
curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh > system-agent-uninstall.sh
sudo sh system-agent-uninstall.sh
```
### 删除 K3s
@@ -14,11 +14,10 @@ title: 安装 Adapter
:::
| Rancher 版本 | Adapter 版本 |
|-----------------|:----------------:|
| v2.12.3 | 107.0.0+up7.0.0 |
| v2.12.2 | 107.0.0+up7.0.0 |
| v2.12.1 | 107.0.0+up7.0.0 |
| v2.12.0 | 107.0.0+up7.0.0 |
|-----------------|------------------|
| v2.13.2 | 108.0.0+up8.0.0 |
| v2.13.1 | 108.0.0+up8.0.0 |
| v2.13.0 | 108.0.0+up8.0.0 |
## 1. 获取对 Local 集群的访问权限
@@ -10,6 +10,8 @@ Rancher 致力于向社区披露我们产品的安全问题。我们会针对已
| ID | 描述 | 日期 | 解决 |
|----|-------------|------|------------|
| [CVE-2025-62879](https://github.com/rancher/backup-restore-operator/security/advisories/GHSA-wj3p-5h3x-c74q) | Rancher now provides new versions of the Rancher Backup chart which prevent the leak of secret S3 credentials via the Rancher Backup pod log. For more information. | 29 Jan 2026 | Rancher [v2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2), [v2.12.6](https://github.com/rancher/rancher/releases/tag/v2.12.6), [v2.11.10](https://github.com/rancher/rancher/releases/tag/v2.11.10), and [v2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) |
| [CVE-2025-67601](https://github.com/rancher/rancher/security/advisories/GHSA-mc24-7m59-4q5p) | Rancher now removes the ability to fetch CA certificates stored in Rancher’s setting `cacerts` when using the `login` command. For more information. | 29 Jan 2026 | Rancher [v2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2), [v2.12.6](https://github.com/rancher/rancher/releases/tag/v2.12.6), [v2.11.10](https://github.com/rancher/rancher/releases/tag/v2.11.10), and [v2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) |
| [CVE-2023-32199](https://github.com/rancher/rancher/security/advisories/GHSA-j4vr-pcmw-hx59) | Rancher now removes the corresponding ClusterRoleBindings whenever the admin GlobalRole or its GlobalRoleBindings are deleted. Previously orphaned ClusterRoleBindings were marked with the annotation `authz.cluster.cattle.io/admin-globalrole-missing=true`. | 23 Oct 2025 | Rancher [v2.12.3](https://github.com/rancher/rancher/releases/tag/v2.12.3) and [v2.11.7](https://github.com/rancher/rancher/releases/tag/v2.11.7) |
| [CVE-2024-58269](https://github.com/rancher/rancher/security/advisories/GHSA-mw39-9qc2-f7mg) | The Rancher audit log redaction process has changed to the following: <br/><br/><ul><li> It now redacts `kubectl.kubernetes.io/last-applied-configuration` annotations on both Response and Request body contents. Previously it did not redact Response body content.</li><li> It now redacts Cluster Import URLs on both Request URLs and Referer headers. Previously it did not redact Referer headers.</li></ul> | 23 Oct 2025 | Rancher [v2.12.3](https://github.com/rancher/rancher/releases/tag/v2.12.3) |
| [CVE-2024-58260](https://github.com/rancher/rancher/security/advisories/GHSA-q82v-h4rq-5c86) | Setting the username of one user as the same username of another user causes an error when either user attempts to log in. Therefore, a user with the `Manage Users` permission could potentially deny any user, including admins, from logging in. To prevent this, usernames have been made immutable once set, and it is not possible to update or create a user with a username that is already in use. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
@@ -20,10 +20,9 @@ Rancher 将 Rancher-Webhook 作为单独的 deployment 和服务部署在 local
| Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
|-----------------|-----------------|-----------------------|---------------------------|
| v2.12.3 | v0.8.3 | &check; | &check; |
| v2.12.2 | v0.8.2 | &check; | &check; |
| v2.12.1 | v0.8.1 | &check; | &check; |
| v2.12.0 | v0.8.0 | &cross; | &check; |
| v2.13.2 | v0.9.2 | &check; | &check; |
| v2.13.1 | v0.9.1 | &check; | &check; |
| v2.13.0 | v0.9.0 | &cross; | &check; |
## 为什么我们需要它?
@@ -37,8 +37,7 @@ apiVersion: management.cattle.io/v3
kind: Project
metadata:
annotations:
field.cattle.io/creatorId:
user-id
field.cattle.io/creatorId: user-id
generateName: p-
namespace: c-m-abcde
spec:
@@ -16,6 +16,7 @@ Rancher 将在 GitHub 上发布的 Rancher 的[发版说明](https://github.com/
| Patch 版本 | 发布时间 |
| --------------------------------------------------------------- | -------------------- |
| [2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) | 2026 年 01 月 29 日 |
| [2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10) | 2025 年 9 月 25 日 |
| [2.10.9](https://github.com/rancher/rancher/releases/tag/v2.10.9) | 2025 年 8 月 27 日 |
| [2.10.8](https://github.com/rancher/rancher/releases/tag/v2.10.8) | 2025 年 7 月 30 日 |
@@ -36,71 +36,72 @@ weight: 1
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"autoscaling:DescribeAutoScalingGroups",
"autoscaling:DescribeLaunchConfigurations",
"autoscaling:DescribeTags",
"ec2:DescribeInstances",
"ec2:DescribeRegions",
"ec2:DescribeRouteTables",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVolumes",
"ec2:CreateSecurityGroup",
"ec2:CreateTags",
"ec2:CreateVolume",
"ec2:ModifyInstanceAttribute",
"ec2:ModifyVolume",
"ec2:AttachVolume",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateRoute",
"ec2:DeleteRoute",
"ec2:DeleteSecurityGroup",
"ec2:DeleteVolume",
"ec2:DetachVolume",
"ec2:RevokeSecurityGroupIngress",
"ec2:DescribeVpcs",
"elasticloadbalancing:AddTags",
"elasticloadbalancing:AttachLoadBalancerToSubnets",
"elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
"elasticloadbalancing:CreateLoadBalancer",
"elasticloadbalancing:CreateLoadBalancerPolicy",
"elasticloadbalancing:CreateLoadBalancerListeners",
"elasticloadbalancing:ConfigureHealthCheck",
"elasticloadbalancing:DeleteLoadBalancer",
"elasticloadbalancing:DeleteLoadBalancerListeners",
"elasticloadbalancing:DescribeLoadBalancers",
"elasticloadbalancing:DescribeLoadBalancerAttributes",
"elasticloadbalancing:DetachLoadBalancerFromSubnets",
"elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
"elasticloadbalancing:ModifyLoadBalancerAttributes",
"elasticloadbalancing:RegisterInstancesWithLoadBalancer",
"elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer",
"elasticloadbalancing:AddTags",
"elasticloadbalancing:CreateListener",
"elasticloadbalancing:CreateTargetGroup",
"elasticloadbalancing:DeleteListener",
"elasticloadbalancing:DeleteTargetGroup",
"elasticloadbalancing:DescribeListeners",
"elasticloadbalancing:DescribeLoadBalancerPolicies",
"elasticloadbalancing:DescribeTargetGroups",
"elasticloadbalancing:DescribeTargetHealth",
"elasticloadbalancing:ModifyListener",
"elasticloadbalancing:ModifyTargetGroup",
"elasticloadbalancing:RegisterTargets",
"elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
"iam:CreateServiceLinkedRole",
"kms:DescribeKey"
],
"Resource": [
"*"
]
}
]
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"autoscaling:DescribeAutoScalingGroups",
"autoscaling:DescribeLaunchConfigurations",
"autoscaling:DescribeTags",
"ec2:DescribeInstances",
"ec2:DescribeRegions",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeRouteTables",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVolumes",
"ec2:CreateSecurityGroup",
"ec2:CreateTags",
"ec2:CreateVolume",
"ec2:ModifyInstanceAttribute",
"ec2:ModifyVolume",
"ec2:AttachVolume",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateRoute",
"ec2:DeleteRoute",
"ec2:DeleteSecurityGroup",
"ec2:DeleteVolume",
"ec2:DetachVolume",
"ec2:RevokeSecurityGroupIngress",
"ec2:DescribeVpcs",
"elasticloadbalancing:AddTags",
"elasticloadbalancing:AttachLoadBalancerToSubnets",
"elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
"elasticloadbalancing:CreateLoadBalancer",
"elasticloadbalancing:CreateLoadBalancerPolicy",
"elasticloadbalancing:CreateLoadBalancerListeners",
"elasticloadbalancing:ConfigureHealthCheck",
"elasticloadbalancing:DeleteLoadBalancer",
"elasticloadbalancing:DeleteLoadBalancerListeners",
"elasticloadbalancing:DescribeLoadBalancers",
"elasticloadbalancing:DescribeLoadBalancerAttributes",
"elasticloadbalancing:DetachLoadBalancerFromSubnets",
"elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
"elasticloadbalancing:ModifyLoadBalancerAttributes",
"elasticloadbalancing:RegisterInstancesWithLoadBalancer",
"elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer",
"elasticloadbalancing:AddTags",
"elasticloadbalancing:CreateListener",
"elasticloadbalancing:CreateTargetGroup",
"elasticloadbalancing:DeleteListener",
"elasticloadbalancing:DeleteTargetGroup",
"elasticloadbalancing:DescribeListeners",
"elasticloadbalancing:DescribeLoadBalancerPolicies",
"elasticloadbalancing:DescribeTargetGroups",
"elasticloadbalancing:DescribeTargetHealth",
"elasticloadbalancing:ModifyListener",
"elasticloadbalancing:ModifyTargetGroup",
"elasticloadbalancing:RegisterTargets",
"elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
"iam:CreateServiceLinkedRole",
"kms:DescribeKey"
],
"Resource": [
"*"
]
}
]
}
```
@@ -108,24 +109,25 @@ weight: 1
```json
{
"Version": "2012-10-17",
"Statement": [
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeRegions",
"ecr:GetAuthorizationToken",
"ecr:BatchCheckLayerAvailability",
"ecr:GetDownloadUrlForLayer",
"ecr:GetRepositoryPolicy",
"ecr:DescribeRepositories",
"ecr:ListImages",
"ecr:BatchGetImage"
],
"Resource": "*"
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeRegions",
"ec2:DescribeAvailabilityZones",
"ecr:GetAuthorizationToken",
"ecr:BatchCheckLayerAvailability",
"ecr:GetDownloadUrlForLayer",
"ecr:GetRepositoryPolicy",
"ecr:DescribeRepositories",
"ecr:ListImages",
"ecr:BatchGetImage"
],
"Resource": "*"
}
]
]
}
```
@@ -196,7 +196,8 @@ For instructions on cleaning nodes in RKE2 clusters that weren't deployed by Ran
要删除 rancher-system-agent,请运行 [system-agent-uninstall.sh](https://github.com/rancher/system-agent/blob/main/system-agent-uninstall.sh) 脚本:
```
curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh | sudo sh
curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh > system-agent-uninstall.sh
sudo sh system-agent-uninstall.sh
```
### 删除 RKE2
@@ -220,7 +221,8 @@ sudo rke2-uninstall.sh
要删除 rancher-system-agent,请运行 [system-agent-uninstall.sh](https://github.com/rancher/system-agent/blob/main/system-agent-uninstall.sh) 脚本:
```
curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh | sudo sh
curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh > system-agent-uninstall.sh
sudo sh system-agent-uninstall.sh
```
### 删除 K3s
@@ -14,7 +14,8 @@ title: 安装 Adapter
:::
| Rancher 版本 | Adapter 版本 |
|-----------------|:---------------:|
|-----------------|:----------------:|
| v2.10.11 | v105.0.0+up5.0.1 |
| v2.10.10 | v105.0.0+up5.0.1 |
| v2.10.9 | v105.0.0+up5.0.1 |
| v2.10.8 | v105.0.0+up5.0.1 |
@@ -10,6 +10,8 @@ Rancher 致力于向社区披露我们产品的安全问题。我们会针对已
| ID | 描述 | 日期 | 解决 |
|----|-------------|------|------------|
| [CVE-2025-62879](https://github.com/rancher/backup-restore-operator/security/advisories/GHSA-wj3p-5h3x-c74q) | Rancher now provides new versions of the Rancher Backup chart which prevent the leak of secret S3 credentials via the Rancher Backup pod log. For more information. | 29 Jan 2026 | Rancher [v2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2), [v2.12.6](https://github.com/rancher/rancher/releases/tag/v2.12.6), [v2.11.10](https://github.com/rancher/rancher/releases/tag/v2.11.10), and [v2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) |
| [CVE-2025-67601](https://github.com/rancher/rancher/security/advisories/GHSA-mc24-7m59-4q5p) | Rancher now removes the ability to fetch CA certificates stored in Rancher’s setting `cacerts` when using the `login` command. For more information. | 29 Jan 2026 | Rancher [v2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2), [v2.12.6](https://github.com/rancher/rancher/releases/tag/v2.12.6), [v2.11.10](https://github.com/rancher/rancher/releases/tag/v2.11.10), and [v2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) |
| [CVE-2024-58260](https://github.com/rancher/rancher/security/advisories/GHSA-q82v-h4rq-5c86) | Setting the username of one user as the same username of another user causes an error when either user attempts to log in. Therefore, a user with the `Manage Users` permission could potentially deny any user, including admins, from logging in. To prevent this, usernames have been made immutable once set, and it is not possible to update or create a user with a username that is already in use. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
| [CVE-2024-58267](https://github.com/rancher/rancher/security/advisories/GHSA-v3vj-5868-2ch2) | The Rancher CLI is modified to print the `requestId` more visibly than as part of the login URL. It also adds a `cli=true` origin marker to the URL. The dashboard is modified to recognize the presence of the `requestId` and uses that to show a warning message to the user, asking for verification that they initiated a CLI login with the related Id. The non-presence of the origin marker enables the dashboard to distinguish between the modified CLI and older CLI’s, and adjust the message accordingly. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
| [CVE-2025-54468](https://github.com/rancher/rancher/security/advisories/GHSA-mjcp-rj3c-36fr) | `Impersonate-*` headers are removed for requests made through the `/meta/proxy` Rancher endpoint (e.g. when cloud credentials are being created) as the headers may contain identifiable and/or sensitive information. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
@@ -20,6 +20,7 @@ Rancher 将 Rancher-Webhook 作为单独的 deployment 和服务部署在 local
| Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
| --------------- | --------------- | --------------------- | ------------------------- |
| v2.10.11 | v0.6.12 | &check; | &cross; |
| v2.10.10 | v0.6.11 | &check; | &cross; |
| v2.10.9 | v0.6.10 | &check; | &cross; |
| v2.10.8 | v0.6.9 | &check; | &cross; |
@@ -37,8 +37,7 @@ apiVersion: management.cattle.io/v3
kind: Project
metadata:
annotations:
field.cattle.io/creatorId:
user-id
field.cattle.io/creatorId: user-id
generateName: p-
namespace: c-m-abcde
spec:
@@ -16,6 +16,9 @@ Rancher 将在 GitHub 上发布的 Rancher 的[发版说明](https://github.com/
| Patch 版本 | 发布时间 |
| --------------------------------------------------------------- | ------------------ |
| [2.11.10](https://github.com/rancher/rancher/releases/tag/v2.11.10) | 2026 年 01 月 29 日 |
| [2.11.9](https://github.com/rancher/rancher/releases/tag/v2.11.9) | 2025 年 12 月 18 日 |
| [2.11.8](https://github.com/rancher/rancher/releases/tag/v2.11.8) | 2025 年 11 月 24 日 |
| [2.11.7](https://github.com/rancher/rancher/releases/tag/v2.11.7) | 2025 年 10 月 23 日 |
| [2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6) | 2025 年 9 月 25 日 |
| [2.11.5](https://github.com/rancher/rancher/releases/tag/v2.11.5) | 2025 年 8 月 28 日 |
@@ -36,71 +36,72 @@ weight: 1
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"autoscaling:DescribeAutoScalingGroups",
"autoscaling:DescribeLaunchConfigurations",
"autoscaling:DescribeTags",
"ec2:DescribeInstances",
"ec2:DescribeRegions",
"ec2:DescribeRouteTables",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVolumes",
"ec2:CreateSecurityGroup",
"ec2:CreateTags",
"ec2:CreateVolume",
"ec2:ModifyInstanceAttribute",
"ec2:ModifyVolume",
"ec2:AttachVolume",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateRoute",
"ec2:DeleteRoute",
"ec2:DeleteSecurityGroup",
"ec2:DeleteVolume",
"ec2:DetachVolume",
"ec2:RevokeSecurityGroupIngress",
"ec2:DescribeVpcs",
"elasticloadbalancing:AddTags",
"elasticloadbalancing:AttachLoadBalancerToSubnets",
"elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
"elasticloadbalancing:CreateLoadBalancer",
"elasticloadbalancing:CreateLoadBalancerPolicy",
"elasticloadbalancing:CreateLoadBalancerListeners",
"elasticloadbalancing:ConfigureHealthCheck",
"elasticloadbalancing:DeleteLoadBalancer",
"elasticloadbalancing:DeleteLoadBalancerListeners",
"elasticloadbalancing:DescribeLoadBalancers",
"elasticloadbalancing:DescribeLoadBalancerAttributes",
"elasticloadbalancing:DetachLoadBalancerFromSubnets",
"elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
"elasticloadbalancing:ModifyLoadBalancerAttributes",
"elasticloadbalancing:RegisterInstancesWithLoadBalancer",
"elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer",
"elasticloadbalancing:AddTags",
"elasticloadbalancing:CreateListener",
"elasticloadbalancing:CreateTargetGroup",
"elasticloadbalancing:DeleteListener",
"elasticloadbalancing:DeleteTargetGroup",
"elasticloadbalancing:DescribeListeners",
"elasticloadbalancing:DescribeLoadBalancerPolicies",
"elasticloadbalancing:DescribeTargetGroups",
"elasticloadbalancing:DescribeTargetHealth",
"elasticloadbalancing:ModifyListener",
"elasticloadbalancing:ModifyTargetGroup",
"elasticloadbalancing:RegisterTargets",
"elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
"iam:CreateServiceLinkedRole",
"kms:DescribeKey"
],
"Resource": [
"*"
]
}
]
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"autoscaling:DescribeAutoScalingGroups",
"autoscaling:DescribeLaunchConfigurations",
"autoscaling:DescribeTags",
"ec2:DescribeInstances",
"ec2:DescribeRegions",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeRouteTables",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVolumes",
"ec2:CreateSecurityGroup",
"ec2:CreateTags",
"ec2:CreateVolume",
"ec2:ModifyInstanceAttribute",
"ec2:ModifyVolume",
"ec2:AttachVolume",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateRoute",
"ec2:DeleteRoute",
"ec2:DeleteSecurityGroup",
"ec2:DeleteVolume",
"ec2:DetachVolume",
"ec2:RevokeSecurityGroupIngress",
"ec2:DescribeVpcs",
"elasticloadbalancing:AddTags",
"elasticloadbalancing:AttachLoadBalancerToSubnets",
"elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
"elasticloadbalancing:CreateLoadBalancer",
"elasticloadbalancing:CreateLoadBalancerPolicy",
"elasticloadbalancing:CreateLoadBalancerListeners",
"elasticloadbalancing:ConfigureHealthCheck",
"elasticloadbalancing:DeleteLoadBalancer",
"elasticloadbalancing:DeleteLoadBalancerListeners",
"elasticloadbalancing:DescribeLoadBalancers",
"elasticloadbalancing:DescribeLoadBalancerAttributes",
"elasticloadbalancing:DetachLoadBalancerFromSubnets",
"elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
"elasticloadbalancing:ModifyLoadBalancerAttributes",
"elasticloadbalancing:RegisterInstancesWithLoadBalancer",
"elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer",
"elasticloadbalancing:AddTags",
"elasticloadbalancing:CreateListener",
"elasticloadbalancing:CreateTargetGroup",
"elasticloadbalancing:DeleteListener",
"elasticloadbalancing:DeleteTargetGroup",
"elasticloadbalancing:DescribeListeners",
"elasticloadbalancing:DescribeLoadBalancerPolicies",
"elasticloadbalancing:DescribeTargetGroups",
"elasticloadbalancing:DescribeTargetHealth",
"elasticloadbalancing:ModifyListener",
"elasticloadbalancing:ModifyTargetGroup",
"elasticloadbalancing:RegisterTargets",
"elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
"iam:CreateServiceLinkedRole",
"kms:DescribeKey"
],
"Resource": [
"*"
]
}
]
}
```
@@ -108,24 +109,25 @@ weight: 1
```json
{
"Version": "2012-10-17",
"Statement": [
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeRegions",
"ecr:GetAuthorizationToken",
"ecr:BatchCheckLayerAvailability",
"ecr:GetDownloadUrlForLayer",
"ecr:GetRepositoryPolicy",
"ecr:DescribeRepositories",
"ecr:ListImages",
"ecr:BatchGetImage"
],
"Resource": "*"
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeRegions",
"ec2:DescribeAvailabilityZones",
"ecr:GetAuthorizationToken",
"ecr:BatchCheckLayerAvailability",
"ecr:GetDownloadUrlForLayer",
"ecr:GetRepositoryPolicy",
"ecr:DescribeRepositories",
"ecr:ListImages",
"ecr:BatchGetImage"
],
"Resource": "*"
}
]
]
}
```
@@ -196,7 +196,8 @@ For instructions on cleaning nodes in RKE2 clusters that weren't deployed by Ran
要删除 rancher-system-agent,请运行 [system-agent-uninstall.sh](https://github.com/rancher/system-agent/blob/main/system-agent-uninstall.sh) 脚本:
```
curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh | sudo sh
curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh > system-agent-uninstall.sh
sudo sh system-agent-uninstall.sh
```
### 删除 RKE2
@@ -220,7 +221,8 @@ sudo rke2-uninstall.sh
要删除 rancher-system-agent,请运行 [system-agent-uninstall.sh](https://github.com/rancher/system-agent/blob/main/system-agent-uninstall.sh) 脚本:
```
curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh | sudo sh
curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh > system-agent-uninstall.sh
sudo sh system-agent-uninstall.sh
```
### 删除 K3s
@@ -15,6 +15,9 @@ title: 安装 Adapter
| Rancher 版本 | Adapter 版本 |
|-----------------|:----------------:|
| v2.11.10 | v106.0.0+up6.0.0 |
| v2.11.9 | v106.0.0+up6.0.0 |
| v2.11.8 | v106.0.0+up6.0.0 |
| v2.11.7 | v106.0.0+up6.0.0 |
| v2.11.6 | v106.0.0+up6.0.0 |
| v2.11.5 | v106.0.0+up6.0.0 |
@@ -10,6 +10,8 @@ Rancher 致力于向社区披露我们产品的安全问题。我们会针对已
| ID | 描述 | 日期 | 解决 |
|----|-------------|------|------------|
| [CVE-2025-62879](https://github.com/rancher/backup-restore-operator/security/advisories/GHSA-wj3p-5h3x-c74q) | Rancher now provides new versions of the Rancher Backup chart which prevent the leak of secret S3 credentials via the Rancher Backup pod log. For more information. | 29 Jan 2026 | Rancher [v2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2), [v2.12.6](https://github.com/rancher/rancher/releases/tag/v2.12.6), [v2.11.10](https://github.com/rancher/rancher/releases/tag/v2.11.10), and [v2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) |
| [CVE-2025-67601](https://github.com/rancher/rancher/security/advisories/GHSA-mc24-7m59-4q5p) | Rancher now removes the ability to fetch CA certificates stored in Rancher’s setting `cacerts` when using the `login` command. For more information. | 29 Jan 2026 | Rancher [v2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2), [v2.12.6](https://github.com/rancher/rancher/releases/tag/v2.12.6), [v2.11.10](https://github.com/rancher/rancher/releases/tag/v2.11.10), and [v2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) |
| [CVE-2023-32199](https://github.com/rancher/rancher/security/advisories/GHSA-j4vr-pcmw-hx59) | Rancher now removes the corresponding ClusterRoleBindings whenever the admin GlobalRole or its GlobalRoleBindings are deleted. Previously orphaned ClusterRoleBindings were marked with the annotation `authz.cluster.cattle.io/admin-globalrole-missing=true`. | 23 Oct 2025 | Rancher [v2.12.3](https://github.com/rancher/rancher/releases/tag/v2.12.3) and [v2.11.7](https://github.com/rancher/rancher/releases/tag/v2.11.7) |
| [CVE-2024-58260](https://github.com/rancher/rancher/security/advisories/GHSA-q82v-h4rq-5c86) | Setting the username of one user as the same username of another user causes an error when either user attempts to log in. Therefore, a user with the `Manage Users` permission could potentially deny any user, including admins, from logging in. To prevent this, usernames have been made immutable once set, and it is not possible to update or create a user with a username that is already in use. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
| [CVE-2024-58267](https://github.com/rancher/rancher/security/advisories/GHSA-v3vj-5868-2ch2) | The Rancher CLI is modified to print the `requestId` more visibly than as part of the login URL. It also adds a `cli=true` origin marker to the URL. The dashboard is modified to recognize the presence of the `requestId` and uses that to show a warning message to the user, asking for verification that they initiated a CLI login with the related Id. The non-presence of the origin marker enables the dashboard to distinguish between the modified CLI and older CLI’s, and adjust the message accordingly. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
@@ -20,6 +20,9 @@ Rancher 将 Rancher-Webhook 作为单独的 deployment 和服务部署在 local
| Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
|-----------------|-----------------|-----------------------|---------------------------|
| v2.11.10 | v0.7.8 | &check; | &cross; |
| v2.11.9 | v0.7.8 | &check; | &cross; |
| v2.11.8 | v0.7.8 | &check; | &cross; |
| v2.11.7 | v0.7.7 | &check; | &cross; |
| v2.11.6 | v0.7.6 | &check; | &cross; |
| v2.11.5 | v0.7.5 | &check; | &cross; |
@@ -37,8 +37,7 @@ apiVersion: management.cattle.io/v3
kind: Project
metadata:
annotations:
field.cattle.io/creatorId:
user-id
field.cattle.io/creatorId: user-id
generateName: p-
namespace: c-m-abcde
spec:
@@ -16,6 +16,9 @@ Rancher 将在 GitHub 上发布的 Rancher 的[发版说明](https://github.com/
| Patch 版本 | 发布时间 |
| ----------------------------------------------------------------- | ------------------ |
| [2.12.6](https://github.com/rancher/rancher/releases/tag/v2.12.6) | 2026 年 01 月 29 日 |
| [2.12.5](https://github.com/rancher/rancher/releases/tag/v2.12.5) | 2025 年 12 月 18 日 |
| [2.12.4](https://github.com/rancher/rancher/releases/tag/v2.12.4) | 2025 年 11 月 24 日 |
| [2.12.3](https://github.com/rancher/rancher/releases/tag/v2.12.3) | 2025 年 10 月 23 日 |
| [2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2) | 2025 年 9 月 25 日 |
| [2.12.1](https://github.com/rancher/rancher/releases/tag/v2.12.1) | 2025 年 8 月 28 日 |
@@ -11,10 +11,8 @@ Kubernetes 每隔五分钟会自动清理 etcd 数据集。在某些情况下(
```yaml
# RKE2/K3s config.yaml
---
services:
etcd:
extra_args:
quota-backend-bytes: 5368709120
etcd-arg:
- "quota-backend-bytes=5368709120"
```
## 扩展 etcd 磁盘性能
@@ -28,12 +26,7 @@ services:
```yaml
# RKE2/K3s config.yaml
---
services:
etcd:
extra_args:
data-dir: '/var/lib/rancher/etcd/data/'
wal-dir: '/var/lib/rancher/etcd/wal/wal_dir'
extra_binds:
- '/var/lib/etcd/data:/var/lib/rancher/etcd/data'
- '/var/lib/etcd/wal:/var/lib/rancher/etcd/wal'
etcd-arg:
- "data-dir=/var/lib/etcd/data"
- "wal-dir=/var/lib/etcd/wal"
```
@@ -36,71 +36,72 @@ weight: 1
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"autoscaling:DescribeAutoScalingGroups",
"autoscaling:DescribeLaunchConfigurations",
"autoscaling:DescribeTags",
"ec2:DescribeInstances",
"ec2:DescribeRegions",
"ec2:DescribeRouteTables",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVolumes",
"ec2:CreateSecurityGroup",
"ec2:CreateTags",
"ec2:CreateVolume",
"ec2:ModifyInstanceAttribute",
"ec2:ModifyVolume",
"ec2:AttachVolume",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateRoute",
"ec2:DeleteRoute",
"ec2:DeleteSecurityGroup",
"ec2:DeleteVolume",
"ec2:DetachVolume",
"ec2:RevokeSecurityGroupIngress",
"ec2:DescribeVpcs",
"elasticloadbalancing:AddTags",
"elasticloadbalancing:AttachLoadBalancerToSubnets",
"elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
"elasticloadbalancing:CreateLoadBalancer",
"elasticloadbalancing:CreateLoadBalancerPolicy",
"elasticloadbalancing:CreateLoadBalancerListeners",
"elasticloadbalancing:ConfigureHealthCheck",
"elasticloadbalancing:DeleteLoadBalancer",
"elasticloadbalancing:DeleteLoadBalancerListeners",
"elasticloadbalancing:DescribeLoadBalancers",
"elasticloadbalancing:DescribeLoadBalancerAttributes",
"elasticloadbalancing:DetachLoadBalancerFromSubnets",
"elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
"elasticloadbalancing:ModifyLoadBalancerAttributes",
"elasticloadbalancing:RegisterInstancesWithLoadBalancer",
"elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer",
"elasticloadbalancing:AddTags",
"elasticloadbalancing:CreateListener",
"elasticloadbalancing:CreateTargetGroup",
"elasticloadbalancing:DeleteListener",
"elasticloadbalancing:DeleteTargetGroup",
"elasticloadbalancing:DescribeListeners",
"elasticloadbalancing:DescribeLoadBalancerPolicies",
"elasticloadbalancing:DescribeTargetGroups",
"elasticloadbalancing:DescribeTargetHealth",
"elasticloadbalancing:ModifyListener",
"elasticloadbalancing:ModifyTargetGroup",
"elasticloadbalancing:RegisterTargets",
"elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
"iam:CreateServiceLinkedRole",
"kms:DescribeKey"
],
"Resource": [
"*"
]
}
]
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"autoscaling:DescribeAutoScalingGroups",
"autoscaling:DescribeLaunchConfigurations",
"autoscaling:DescribeTags",
"ec2:DescribeInstances",
"ec2:DescribeRegions",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeRouteTables",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVolumes",
"ec2:CreateSecurityGroup",
"ec2:CreateTags",
"ec2:CreateVolume",
"ec2:ModifyInstanceAttribute",
"ec2:ModifyVolume",
"ec2:AttachVolume",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateRoute",
"ec2:DeleteRoute",
"ec2:DeleteSecurityGroup",
"ec2:DeleteVolume",
"ec2:DetachVolume",
"ec2:RevokeSecurityGroupIngress",
"ec2:DescribeVpcs",
"elasticloadbalancing:AddTags",
"elasticloadbalancing:AttachLoadBalancerToSubnets",
"elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
"elasticloadbalancing:CreateLoadBalancer",
"elasticloadbalancing:CreateLoadBalancerPolicy",
"elasticloadbalancing:CreateLoadBalancerListeners",
"elasticloadbalancing:ConfigureHealthCheck",
"elasticloadbalancing:DeleteLoadBalancer",
"elasticloadbalancing:DeleteLoadBalancerListeners",
"elasticloadbalancing:DescribeLoadBalancers",
"elasticloadbalancing:DescribeLoadBalancerAttributes",
"elasticloadbalancing:DetachLoadBalancerFromSubnets",
"elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
"elasticloadbalancing:ModifyLoadBalancerAttributes",
"elasticloadbalancing:RegisterInstancesWithLoadBalancer",
"elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer",
"elasticloadbalancing:AddTags",
"elasticloadbalancing:CreateListener",
"elasticloadbalancing:CreateTargetGroup",
"elasticloadbalancing:DeleteListener",
"elasticloadbalancing:DeleteTargetGroup",
"elasticloadbalancing:DescribeListeners",
"elasticloadbalancing:DescribeLoadBalancerPolicies",
"elasticloadbalancing:DescribeTargetGroups",
"elasticloadbalancing:DescribeTargetHealth",
"elasticloadbalancing:ModifyListener",
"elasticloadbalancing:ModifyTargetGroup",
"elasticloadbalancing:RegisterTargets",
"elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
"iam:CreateServiceLinkedRole",
"kms:DescribeKey"
],
"Resource": [
"*"
]
}
]
}
```
@@ -108,24 +109,25 @@ weight: 1
```json
{
"Version": "2012-10-17",
"Statement": [
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeRegions",
"ecr:GetAuthorizationToken",
"ecr:BatchCheckLayerAvailability",
"ecr:GetDownloadUrlForLayer",
"ecr:GetRepositoryPolicy",
"ecr:DescribeRepositories",
"ecr:ListImages",
"ecr:BatchGetImage"
],
"Resource": "*"
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeRegions",
"ec2:DescribeAvailabilityZones",
"ecr:GetAuthorizationToken",
"ecr:BatchCheckLayerAvailability",
"ecr:GetDownloadUrlForLayer",
"ecr:GetRepositoryPolicy",
"ecr:DescribeRepositories",
"ecr:ListImages",
"ecr:BatchGetImage"
],
"Resource": "*"
}
]
]
}
```
@@ -137,7 +137,8 @@ For instructions on cleaning nodes in RKE2 clusters that weren't deployed by Ran
要删除 rancher-system-agent,请运行 [system-agent-uninstall.sh](https://github.com/rancher/system-agent/blob/main/system-agent-uninstall.sh) 脚本:
```
curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh | sudo sh
curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh > system-agent-uninstall.sh
sudo sh system-agent-uninstall.sh
```
### 删除 RKE2
@@ -161,7 +162,8 @@ sudo rke2-uninstall.sh
要删除 rancher-system-agent,请运行 [system-agent-uninstall.sh](https://github.com/rancher/system-agent/blob/main/system-agent-uninstall.sh) 脚本:
```
curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh | sudo sh
curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh > system-agent-uninstall.sh
sudo sh system-agent-uninstall.sh
```
### 删除 K3s
@@ -15,6 +15,9 @@ title: 安装 Adapter
| Rancher 版本 | Adapter 版本 |
|-----------------|:----------------:|
| v2.12.6 | 107.0.0+up7.0.0 |
| v2.12.5 | 107.0.0+up7.0.0 |
| v2.12.4 | 107.0.0+up7.0.0 |
| v2.12.3 | 107.0.0+up7.0.0 |
| v2.12.2 | 107.0.0+up7.0.0 |
| v2.12.1 | 107.0.0+up7.0.0 |
@@ -10,6 +10,8 @@ Rancher 致力于向社区披露我们产品的安全问题。我们会针对已
| ID | 描述 | 日期 | 解决 |
|----|-------------|------|------------|
| [CVE-2025-62879](https://github.com/rancher/backup-restore-operator/security/advisories/GHSA-wj3p-5h3x-c74q) | Rancher now provides new versions of the Rancher Backup chart which prevent the leak of secret S3 credentials via the Rancher Backup pod log. For more information. | 29 Jan 2026 | Rancher [v2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2), [v2.12.6](https://github.com/rancher/rancher/releases/tag/v2.12.6), [v2.11.10](https://github.com/rancher/rancher/releases/tag/v2.11.10), and [v2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) |
| [CVE-2025-67601](https://github.com/rancher/rancher/security/advisories/GHSA-mc24-7m59-4q5p) | Rancher now removes the ability to fetch CA certificates stored in Rancher’s setting `cacerts` when using the `login` command. For more information. | 29 Jan 2026 | Rancher [v2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.2), [v2.12.6](https://github.com/rancher/rancher/releases/tag/v2.12.6), [v2.11.10](https://github.com/rancher/rancher/releases/tag/v2.11.10), and [v2.10.11](https://github.com/rancher/rancher/releases/tag/v2.10.11) |
| [CVE-2023-32199](https://github.com/rancher/rancher/security/advisories/GHSA-j4vr-pcmw-hx59) | Rancher now removes the corresponding ClusterRoleBindings whenever the admin GlobalRole or its GlobalRoleBindings are deleted. Previously orphaned ClusterRoleBindings were marked with the annotation `authz.cluster.cattle.io/admin-globalrole-missing=true`. | 23 Oct 2025 | Rancher [v2.12.3](https://github.com/rancher/rancher/releases/tag/v2.12.3) and [v2.11.7](https://github.com/rancher/rancher/releases/tag/v2.11.7) |
| [CVE-2024-58269](https://github.com/rancher/rancher/security/advisories/GHSA-mw39-9qc2-f7mg) | The Rancher audit log redaction process has changed to the following: <br/><br/><ul><li> It now redacts `kubectl.kubernetes.io/last-applied-configuration` annotations on both Response and Request body contents. Previously it did not redact Response body content.</li><li> It now redacts Cluster Import URLs on both Request URLs and Referer headers. Previously it did not redact Referer headers.</li></ul> | 23 Oct 2025 | Rancher [v2.12.3](https://github.com/rancher/rancher/releases/tag/v2.12.3) |
| [CVE-2024-58260](https://github.com/rancher/rancher/security/advisories/GHSA-q82v-h4rq-5c86) | Setting the username of one user as the same username of another user causes an error when either user attempts to log in. Therefore, a user with the `Manage Users` permission could potentially deny any user, including admins, from logging in. To prevent this, usernames have been made immutable once set, and it is not possible to update or create a user with a username that is already in use. | 25 Sep 2025 | Rancher [v2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2), [v2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6), [v2.10.10](https://github.com/rancher/rancher/releases/tag/v2.10.10), and [v2.9.12](https://github.com/rancher/rancher/releases/tag/v2.9.12) |
@@ -20,6 +20,9 @@ Rancher 将 Rancher-Webhook 作为单独的 deployment 和服务部署在 local
| Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
|-----------------|-----------------|-----------------------|---------------------------|
| v2.12.6 | v0.8.5 | &check; | &cross; |
| v2.12.5 | v0.8.4 | &check; | &cross; |
| v2.12.4 | v0.8.4 | &check; | &cross; |
| v2.12.3 | v0.8.3 | &check; | &check; |
| v2.12.2 | v0.8.2 | &check; | &check; |
| v2.12.1 | v0.8.1 | &check; | &check; |
@@ -0,0 +1,17 @@
---
title: API 参考
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/api/api-reference"/>
</head>
:::note
目前,并非所有的 Rancher 资源都可以通过 Rancher Kubernetes API 操作。
:::
import ApiDocMdx from '@theme/ApiDocMdx';
<ApiDocMdx id="rancher-api-v2-13" />
@@ -0,0 +1,93 @@
---
title: API 令牌
---
默认情况下,某些集群级别的 API 令牌是使用无限期 TTL(`ttl=0`)生成的。换言之,除非你让令牌失效,否则 `ttl=0` 的 API 令牌永远不会过期。令牌不会因为更改密码而失效。
要停用 API 令牌,你可以删除令牌或停用用户账号。
## 删除令牌
要删除令牌:
1. 转到 `https://<Rancher-Server-IP>/v3/tokens`,在 Rancher API 视图中查看包含所有令牌的列表。
1. 通过 ID 访问要删除的令牌。例如,`https://<Rancher-Server-IP>/v3/tokens/kubectl-shell-user-vqkqt`。
1. 单击**删除**。
以下是使用 `ttl=0` 生成的完整令牌列表:
| 令牌 | 描述 |
| ----------------- | -------------------------------------------------------------------------------------- |
| `kubeconfig-*` | Kubeconfig 令牌 |
| `kubectl-shell-*` | 在浏览器中访问 `kubectl` shell |
| `agent-*` | Agent deployment 令牌 |
| `compose-token-*` | compose 令牌 |
| `helm-token-*` | Helm Chart deployment 令牌 |
| `telemetry-*` | 遥测令牌 |
| `drain-node-*` | 用于清空的令牌(由于没有原生 Kubernetes API,我们使用 `kubectl` 来清空) |
## 在 Kubeconfig 令牌上设置 TTL
管理员可以在 Kubeconfig 令牌上设置全局存活时间 (time-to-live,TTL)。如需更改默认 kubeconfig TTL,你可以导航到全局设置并将 [`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) 设置为所需的持续时间(单位:分钟)。[`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) 的默认值为 0,表示令牌永不过期。
:::note
除了由 CLI 创建的用于[生成 kubeconfig 令牌](#在生成的-kubeconfig-中禁用令牌)的令牌之外,所有 kubeconfig 令牌都使用此设置。
:::
## 在生成的 Kubeconfig 中禁用令牌
1. 将 `kubeconfig-generate-token` 设置为 `false`。此设置让 Rancher 不再在用户单击下载 kubeconfig 文件时自动生成令牌。如果停用此设置,生成的 kubeconfig 将引用 [Rancher CLI](../reference-guides/cli-with-rancher/kubectl-utility.md#使用-kubectl-和-kubeconfig-令牌进行-ttl-认证) 来检索集群的短期令牌。当这个 kubeconfig 在客户端(例如 `kubectl`)中使用时,你需要安装 Rancher CLI 来完成登录请求。
2. 将 `kubeconfig-token-ttl-minutes` 设置为所需的时长(单位:分钟)。`kubeconfig-token-ttl-minutes` 默认设置为 960(即 16 小时)。
## 令牌哈希
你可以启用令牌哈希,令牌将使用 SHA256 算法进行单向哈希。这是一个不可逆的操作,一旦启用,此功能将无法禁用。在启用功能或在测试环境中评估之前,建议你先进行备份。
要启用令牌哈希,请参阅[本节](../how-to-guides/advanced-user-guides/enable-experimental-features/enable-experimental-features.md)。
此功能将影响所有令牌,包括但不限于以下内容:
- Kubeconfig 令牌
- 持有者令牌 API 密钥/调用
- 内部操作使用的令牌
## 令牌设置
以下全局设置会影响 Rancher 令牌的行为:
| 设置 | 描述 |
| ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes) | 用户认证会话令牌的 TTL(单位:分钟)。 |
| [`auth-user-session-idle-ttl-minutes`](#auth-user-session-idle-ttl-minutes) | TTL in minutes on a user auth session token, without user activity. |
| [`kubeconfig-default-token-TTL-minutes`](#kubeconfig-default-token-ttl-minutes) | 默认 TTL,应用于所有 kubeconfig 令牌(除了[由 Rancher CLI 生成的令牌](#在生成的-kubeconfig-中禁用令牌))。**此设置从 2.6.6 版本开始引入。** |
| [`kubeconfig-token-ttl-minutes`](#kubeconfig-token-ttl-minutes) | 在 CLI 中生成的令牌 TTL。**自 2.6.6 起已弃用,并将在 2.8.0 中删除**。请知悉,`kubeconfig-default-token-TTL-minutes` 将用于所有 kubeconfig 令牌。 |
| [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes) | 除了由 [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes) 控制的令牌外,所有令牌的最大 TTL。 |
| [`kubeconfig-generate-token`](#kubeconfig-generate-token) | 如果为 true,则在用户下载 kubeconfig 时自动生成令牌。 |
### auth-user-session-ttl-minutes
存活时间(TTL)(单位:分钟),用于确定用户身份验证会话令牌的到期时间。过期后,用户将需要登录并获取新令牌。此设置不受 [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes) 的影响。会话令牌是在用户登录 Rancher 时创建的。
### auth-user-session-idle-ttl-minutes
Time to live (TTL) without user activity for login sessions tokens, in minutes.
By default, `auth-user-session-idle-ttl-minutes` is set to the same value as [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes) (for backward compatibility). It must never exceed the value of `auth-user-session-ttl-minutes`.
### kubeconfig-default-token-TTL-minutes
存活时间(TTL)(单位:分钟),用于确定 kubeconfig 令牌的到期时间。令牌过期后,API 将拒绝令牌。此设置的值不能大于 [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes) 的值。此设置适用于在请求的 kubeconfig 文件中生成的令牌,不包括[由 Rancher CLI 生成的](#在生成的-kubeconfig-中禁用令牌)令牌。
**此设置从 2.6.6 版本开始引入**。
### kubeconfig-token-ttl-minutes
存活时间(TTL)(单位:分钟),用于确定由 CLI 生成的 kubeconfig 令牌的到期时间。当 [`kubeconfig-generate-token`](#kubeconfig-generate-token) 设为 false 时,则由 CLI 生成令牌。令牌过期后,API 将拒绝令牌。此设置的值不能大于 [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes) 的值。
**自版本 2.6.6 起已弃用,并将在 2.8.0 中删除。请知悉,此设置将被 [`kubeconfig-default-token-TTL-minutes`](#kubeconfig-default-token-ttl-minutes) 的值替换**。
### auth-token-max-ttl-minutes
身份验证令牌的最大生存时间 (TTL)(单位:分钟)。如果用户尝试创建一个 TTL 大于 `auth-token-max-ttl-minutes` 的令牌,Rancher 会将令牌 TTL 设置为 `auth-token-max-ttl-minutes` 的值。身份验证令牌是为验证 API 请求而创建的。
**2.6.6 版本更改:适用于所有 kubeconfig 令牌和 API 令牌。**
### kubeconfig-generate-token
如果设置为 true,则通过 UI 请求的 kubeconfig 将包含一个有效的令牌。如果设置为 false,kubeconfig 将包含一个使用 Rancher CLI 提示用户登录的命令。然后,[CLI 将为用户检索和缓存令牌](../reference-guides/cli-with-rancher/kubectl-utility.md#使用-kubectl-和-kubeconfig-令牌进行-ttl-认证)。
@@ -0,0 +1,152 @@
---
title: API 快速入门指南
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/api/quickstart"/>
</head>
你可以通过 Kubernetes API 访问 Rancher 的资源。本指南将帮助你以 Rancher 用户的身份开始使用此 API。
1. 在左上角,点击 **☰ > 全局设置**.
2. 找到 `server-url` 字段并复制其地址。
3. [创建](../reference-guides/user-settings/api-keys.md#创建-api-密钥)一个没有作用域的 Rancher API 密钥。
:::danger
没有作用域的 Rancher API 密钥授予用户可以访问的所有资源的无限制的访问权限。为防止未经授权的使用,此密钥应安全存储并经常轮换。
:::
4. 创建一个 `kubeconfig.yaml` 文件,将 `$SERVER_URL` 替换成上面从全局设置中复制的地址,并且将 `$API_KEY` 替换为上面创建的 Rancher API 密钥:
```yaml
apiVersion: v1
kind: Config
clusters:
- name: "rancher"
cluster:
server: "$SERVER_URL"
users:
- name: "rancher"
user:
token: "$API_KEY"
contexts:
- name: "rancher"
context:
user: "rancher"
cluster: "rancher"
current-context: "rancher"
```
你可以使用任何兼容的工具来引用这个文件,例如 kubectl 或 [client-go](https://github.com/kubernetes/client-go)。快速演示内容请参阅 [kubectl 示例](#api-kubectl-示例)
更多有关处理更复杂证书的设置信息,请参阅[指定 CA 证书](#指定-ca-证书)。
更多关于可用的 kubeconfig 选项,请参阅[上游文档](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)。
## API kubectl 示例
在此示例中,我们将展示如何使用 kubectl 创建一个项目,然后删除它。关于其他可用的 Rancher 资源列表,请参阅 [API 参考](./api-reference.mdx)。
:::note
目前,并非所有的 Rancher 资源都可以通过 Rancher Kubernetes API 操作。
:::
1. 将 KUBECONFIG 环境变量设置为刚才创建的 kubeconfig 文件:
```bash
export KUBECONFIG=$(pwd)/kubeconfig.yaml
```
2. 使用 `kubectl explain` 查看项目的可用字段,或者复杂资源的子字段:
```bash
kubectl explain projects
kubectl explain projects.spec
```
不是所有的资源都有详细的输出。
3. 在名称为 `project.yaml` 的文件中添加以下内容:
```yaml
apiVersion: management.cattle.io/v3
kind: Project
metadata:
# name 应在每个集群的所有项目中都是唯一的
name: p-abc123
# generateName 可以替代 `name` 来随机生成一个名称
# generateName: p-
# namespace 应与 spec.ClusterName 匹配
namespace: local
spec:
# clusterName 应与目标集群的 `metadata.Name` 匹配
clusterName: local
description: Example Project
# displayName 是人类可读的名称并且从 UI 中显示
displayName: Example
```
4. 创建项目:
```bash
kubectl create -f project.yaml
```
5. 删除项目:
项目删除的方式取决于项目名称的创建方式。
**A. 如果在创建项目时使用 `name`**:
```bash
kubectl delete -f project.yaml
```
**B. 如果你使用 `generateName`**:
将 `$PROJECT_NAME` 替换为 kubectl 创建项目后随机生成的项目名称。
```bash
kubectl delete project $PROJECT_NAME -n local
```
## 指定 CA 证书
为确保你的工具能够识别 Rancher 的 CA 证书,大多数设置都需要对上述模板进行额外修改。
1. 在左上角点击 **☰ > 全局设置**.
2. 查找并复制 `ca-certs` 字段中的值。
3. 将复制的值保存在名称为 `rancher.crt` 的文件中。
:::note
如果你的 Rancher 实例由其他服务代理,你必须提取该服务正在使用的证书,并将其添加到 kubeconfig 文件中,如步骤 5 所示。
:::
4. 以下命令会将 `rancher.crt` 转换为 base64 输出,除去所有换行符,并使用证书内容更新 kubeconfig 中的 cluster 选项,然后删除 `rancher.crt` 文件:
```bash
export KUBECONFIG=$PATH_TO_RANCHER_KUBECONFIG
kubectl config set clusters.rancher.certificate-authority-data $(cat rancher.crt | base64 -i - | tr -d '\n')
rm rancher.crt
```
5. (可选项)如果你使用不受系统信任的自签名证书,则可以通过 kubectl 在 kubeconfig 中设置不安全选项:
:::danger
此选项不应该在生产环境中使用,因为它存在安全风险。
:::
```bash
export KUBECONFIG=$PATH_TO_RANCHER_KUBECONFIG
kubectl config set clusters.rancher.insecure-skip-tls-verify true
```
如果你的 Rancher 实例由其他服务代理,你必须提取该服务正在使用的证书,并如上面演示的方法,将其添加到 kubeconfig 文件中。
@@ -0,0 +1,93 @@
---
title: API
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/about-the-api"/>
</head>
## 如何使用 API
API 有自己的用户界面,你可以从 Web 浏览器访问它。这是查看资源、执行操作以及查看等效 cURL 或 HTTP 请求和响应的一种简单的方法。要访问它:
<Tabs>
<TabItem value="Rancher v2.6.4+">
1. 单击右上角的用户头像。
1. 单击**账号 & API 密钥**。
1. 在 **API 密钥**下,找到 **API 端点**字段并单击链接。该链接类似于 `https://<RANCHER_FQDN>/v3`,其中 `<RANCHER_FQDN>` 是 Rancher deployment 的完全限定域名。
</TabItem>
<TabItem value="Rancher 版本低于 v2.6.4">
转到位于 `https://<RANCHER_FQDN>/v3` 的 URL 端点,其中 `<RANCHER_FQDN>` 是你的 Rancher deployment 的完全限定域名。
</TabItem>
</Tabs>
## 认证
API 请求必须包含认证信息。认证是通过 [API 密钥](../reference-guides/user-settings/api-keys.md)使用 HTTP 基本认证完成的。API 密钥可以创建新集群并通过 `/v3/clusters/` 访问多个集群。[集群和项目角色](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md)会应用于这些键,并限制账号可以查看的集群和项目以及可以执行的操作。
默认情况下,某些集群级别的 API 令牌是使用无限期 TTL(`ttl=0`)生成的。换言之,除非你让令牌失效,否则 `ttl=0` 的 API 令牌永远不会过期。有关如何使 API 令牌失效的详细信息,请参阅 [API 令牌](api-tokens.md)。
## 发出请求
该 API 通常是 RESTful 的,但是还具有多种功能。这些功能可以使客户端发现所有内容,因此可以编写通用客户端,而不必为每种资源编写特定代码。有关通用 API 规范的详细信息,请参阅[此处](https://github.com/rancher/api-spec/blob/master/specification.md)。
- 每种类型都有一个 Schema,这个 Schema 描述了以下内容:
- 用于获取此类资源集合的 URL
- 资源可以具有的每个字段及其类型、基本验证规则、是必填还是可选字段等
- 在此类资源上可以执行的每个操作,以及它们的输入和输出(也作为 schema)
- 允许过滤的每个字段
- 集合本身或集合中的单个资源可以使用的 HTTP 操作方法
- 因此,你可以只加载 schema 列表并了解 API 的所有信息。实际上,这是 API 的 UI 工作方式,它不包含特定于 Rancher 本身的代码。每个 HTTP 响应中的 `X-Api-Schemas` 标头都会发送获取 Schemas 的 URL。你可以按照每个 schema 上的 `collection` 链接了解要在哪里列出资源,并在返回资源中的其他 `links` 中获取其他信息。
- 在实践中,你可能只想构造 URL 字符串。我们强烈建议将此限制为在顶层列出的集合 (`/v3/<type>`),或获取特定资源 (`/v3/<type>/<id>`)。除此之外的任何内容都可能在将来的版本中发生更改。
- 资源之间相互之间有联系,称为链接(links)。每个资源都包含一个 `links` 映射,其中包含链接名称和用于检索该信息的 URL。同样,你应该 `GET` 资源并遵循 `links` 映射中的 URL,而不是自己构造这些字符串。
- 大多数资源都有操作(action),表示可以执行某个操作或改变资源的状态。要使用操作,请将 HTTP `POST` 请求发送到 `actions` 映射中你想要的操作的 URL。某些操作需要输入或生成输出,请参阅每种类型的独立文档或 schema 以获取具体信息。
- 要编辑资源,请将 HTTP `PUT` 请求发送到资源上的 `links.update` 链接,其中包含要更改的字段。如果链接丢失,则你无权更新资源。未知字段和不可编辑的字段将被忽略。
- 要删除资源,请将 HTTP `DELETE` 请求发送到资源上的 `links.remove` 链接。如果链接丢失,则你无权更新资源。
- 要创建新资源,HTTP `POST` 到 schema(即 `/v3/<type>`)中的集合 URL。
## 过滤
你可以使用 HTTP 查询参数的公共字段在服务器端过滤大多数集合。`filters` 映射显示了可以过滤的字段,以及过滤后的值在你发起的请求中是什么。API UI 具有设置过滤和显示适当请求的控件。对于简单的 "equals" 匹配,它只是 `field=value`。你可以将修饰符添加到字段名称,例如 `field_gt=42` 表示“字段大于 42”。详情请参阅 [API 规范](https://github.com/rancher/api-spec/blob/master/specification.md#filtering)。
## 排序
你可以使用 HTTP 查询参数的公共字段在服务器端排序大多数集合。`sortLinks` 映射显示了可用的排序,以及用于获取遵循该排序的集合的 URL。它还包括当前响排序依据的信息(如果指定)。
## 分页
默认情况下,API 响应以每页 100 个资源的限制进行分页。你可以通过 `limit` 查询参数进行更改,最大为 1000,例如 `/v3/pods?limit=1000`。集合响应中的 `pagination` 映射能让你知道你是否拥有完整的结果集,如果没有,则会指向下一页的链接。
## 捕获 Rancher API 调用
You can use browser developer tools to capture how the v3 API is called. For example, you could follow these steps to use the Chrome developer tools to get the API call for provisioning a Rancher Kubernetes distribution cluster:
1. 在 Rancher UI 中,转到**集群管理**并单击**创建**。
1. 单击某个集群类型。此示例使用 Digital Ocean。
1. 使用集群名称和节点模板填写表单,但不要单击**创建**。
1. 在创建集群之前,你需要打开开发人员工具才能看到正在记录的 API 调用。要打开工具,右键单击 Rancher UI,然后单击**检查**。
1. 在开发者工具中,单击 **Network** 选项卡。
1. 在 **Network** 选项卡上,确保选择了 **Fetch/XHR**。
1. 在 Rancher UI 中,单击**创建**。在开发者工具中,你应该会看到一个名为 `cluster?_replace=true` 的新网络请求。
1. 右键单击 `cluster?_replace=true` 并单击**复制 > 复制为 cURL**。
1. 将结果粘贴到文本编辑器中。你将能够看到 POST 请求,包括被发送到的 URL、所有标头以及请求的完整正文。此命令可用于从命令行创建集群。请注意,请求包含凭证,因此请将请求存储在安全的地方。
### 启用在 API 中查看
你还可以查看针对各自集群和资源捕获的 Rancher API 调用。 默认情况下不启用此功能。 要启用它:
1. 单击 UI 右上角的 **用户图标**,然后从下拉菜单中选择 **偏好设置**
1. 在**高级功能**部分下,单击**启用"在 API 中查看"**
选中后,**在 API 中查看**链接现在将显示在 UI 资源页面上的 **⋮** 子菜单下。
@@ -0,0 +1,134 @@
---
title: 项目
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/api/workflows/projects"/>
</head>
## 创建项目
项目资源只能在管理集群上创建,请参考下文了解如何[在管理集群中的项目下创建命名空间](#在项目中创建命名空间)
### 创建一个基本项目
```bash
kubectl create -f - <<EOF
apiVersion: management.cattle.io/v3
kind: Project
metadata:
generateName: p-
namespace: c-m-abcde
spec:
clusterName: c-m-abcde
displayName: myproject
EOF
```
使用 `metadata.generateName` 来确保一个唯一的项目 ID,但是需要注意 `kubectl apply` 不能与 `metadata.generateName` 一起使用,因此必须使用 `kubectl create` 来替代。
将 `metadata.namespace` 和 `spec.clusterName` 设置为项目所属的集群 ID。
如果你通过集群成员账户创建项目,则必须包含注释 `field.cattle.io/creatorId`,并将注释值设置为集群成员账号的用户 ID。
```bash
kubectl create -f - <<EOF
apiVersion: management.cattle.io/v3
kind: Project
metadata:
annotations:
field.cattle.io/creatorId: user-id
generateName: p-
namespace: c-m-abcde
spec:
clusterName: c-m-abcde
displayName: myproject
EOF
```
设置 `field.cattle.io/creatorId` 字段允许集群成员账户通过 `get` 命令查看项目资源,并可以在 Rancher UI 中查看项目。集群所有者和管理员账号不需要设置此注释。
### 创建一个具有 Resource Quota 的项目
请查看 [Kubernetes Resource Quota](https://kubernetes.io/docs/concepts/policy/resource-quotas/)。
```bash
kubectl create -f - <<EOF
apiVersion: management.cattle.io/v3
kind: Project
metadata:
generateName: p-
namespace: c-m-abcde
spec:
clusterName: c-m-abcde
displayName: myproject
resourceQuota:
limit:
limitsCpu: 1000m
namespaceDefaultResourceQuota:
limit:
limitsCpu: 50m
EOF
```
### 创建一个具有 Container Limit Ranges 的项目
请查看 [Kubernetes Limit Ranges](https://kubernetes.io/docs/concepts/policy/limit-range/)。
```bash
kubectl create -f - <<EOF
apiVersion: management.cattle.io/v3
kind: Project
metadata:
generateName: p-
namespace: c-m-abcde
spec:
clusterName: c-m-abcde
displayName: myproject
containerDefaultResourceLimit:
limitsCpu: 100m
limitsMemory: 100Mi
requestsCpu: 50m
requestsMemory: 50Mi
```
## 在项目中创建命名空间
项目资源保存在管理集群中,即使该项目使用于托管集群也是如此。项目下的命名空间保存在托管集群中。
在管理集群上查找你正在管理的集群的项目 ID,因为它是使用 `metadata.generateName` 生成的:
```bash
kubectl --namespace c-m-abcde get projects
```
在托管集群上,使用项目注释创建命名空间:
```bash
kubectl apply -f - <<EOF
apiVersion: v1
kind: Namespace
metadata:
name: mynamespace
annotations:
field.cattle.io/projectId: c-m-abcde:p-vwxyz
EOF
```
注意格式:`<cluster ID>:<project ID>`
## 删除项目
在集群命名空间中查找要删除的项目:
```bash
kubectl --namespace c-m-abcde get projects
```
删除集群命名空间下的项目:
```bash
kubectl --namespace c-m-abcde delete project p-vwxyz
```
请注意此命令不会删除以前属于该项目的命名空间和资源。
@@ -0,0 +1,114 @@
---
title: 参与 Rancher 社区贡献
---
本文介绍了 Rancher 仓库和 Rancher 文档、如何构建 Rancher 仓库以及提交 issue 时要包含哪些信息。
有关如何为 Rancher 项目开发做出贡献的更多详细信息,请参阅 [Rancher Developer Wiki](https://github.com/rancher/rancher/wiki)。Wiki 包含以下主题的资源:
- 如何搭建 Rancher 开发环境并运行测试
- Issue 在开发生命周期中的典型流程
- 编码指南和开发最佳实践
- 调试和故障排除
- 开发 Rancher API
在 Rancher Users Slack 上,开发者的频道是 **#developer**。
## Rancher 文档
如果你对此网站上的文档有建议,请在主 [Rancher 文档](https://github.com/rancher/rancher-docs)仓库中[提交 issue](https://github.com/rancher/rancher-docs/issues/new/choose)。此仓库包含 Rancher v2.0 及更高版本的文档。
有关贡献和构建 Rancher v2.x 文档仓库的更多详细信息,请参阅 [Rancher 文档 README](https://github.com/rancher/rancher-docs#readme)。
有关 Rancher v1.6 及更早版本的文档,请参阅 [Rancher 1.x docs](https://github.com/rancher/rancher.github.io) 仓库,其中包含 https://rancher.com/docs/rancher/v1.6/en/ 的源文件。
## Rancher 仓库
所有仓库都位于我们的主要 GitHub 组织内。Rancher 使用了很多仓库,以下是部分主要仓库的描述:
| 仓库 | URL | 描述 |
-----------|-----|-------------
| Rancher | https://github.com/rancher/rancher | Rancher 2.x 的主要源码仓库。 |
| Types | https://github.com/rancher/types | 包含 Rancher 2.x 的所有 API 类型的仓库。 |
| API Framework | https://github.com/rancher/norman | API 框架,用于构建由 Kubernetes 自定义资源支持的 Rancher 风格的 API。 |
| User Interface | https://github.com/rancher/dashboard/ | Dashboard UI 源码仓库。 |
| (Rancher) Docker Machine | https://github.com/rancher/machine | 使用主机驱动时使用的 Docker Machine 二进制文件的源码仓库。这是 `docker/machine` 仓库的一个 fork。 |
| machine-package | https://github.com/rancher/machine-package | 用于构建 Rancher Docker Machine 二进制文件。 |
| kontainer-engine | https://github.com/rancher/kontainer-engine | kontainer-engine 的源码仓库,它是配置托管 Kubernetes 集群的工具。 |
| CLI | https://github.com/rancher/cli | Rancher 2.x 中使用的 Rancher CLI 的源码仓库。 |
| (Rancher) Helm repository | https://github.com/rancher/helm | 打包的 Helm 二进制文件的源码仓库。这是 `helm/helm` 仓库的一个 fork。 |
| Telemetry repository | https://github.com/rancher/telemetry | Telemetry 二进制文件的源码仓库。 |
| loglevel repository | https://github.com/rancher/loglevel | loglevel 二进制文件的源码仓库,用于动态更改日志级别。 |
要查看 Rancher 使用的所有库/项目,请查看 `rancher/rancher` 仓库中的 [`go.mod` 文件](https://github.com/rancher/rancher/blob/master/go.mod)。
![Rancher diagram](/img/ranchercomponentsdiagram-2.6.svg)<br/>
<sup>用于配置/管理 Kubernetes 集群的 Rancher 组件。</sup>
### 构建 Rancher 仓库
每个仓库都应该有一个 Makefile,并且可以使用 `make` 命令进行构建。`make` 目标基于仓库中 `/scripts` 目录中的脚本,每个目标都使用 [Dapper](https://github.com/rancher/dapper) 在孤立的环境中运行。`Dockerfile.dapper` 将用于此操作,它包含了所需的所有构建工具。
默认目标是 `ci`,它将运行 `./scripts/validate`、`./scripts/build`、`./scripts/test ` 和 `./scripts/package`。生成的二进制文件将在 `./build/bin` 中,通常也打包在 Docker 镜像中。
### Rancher Bug、Issue 或疑问
如果你发现任何 bug 或问题,由于有人可能遇到过同样的问题,或者我们已经正在寻找解决方案,因此请先在[已报告 issue](https://github.com/rancher/rancher/issues) 中搜索。
如果找不到与你的问题相关的内容,请通过[提出 issue](https://github.com/rancher/rancher/issues/new) 与我们联系。与 Rancher 相关的仓库有很多,但请将 issue 提交到 Rancher 仓库中,这样能确保我们能看到这些 issue。如果你想就一个用例提出问题或询问其他用户,你可以在 [Rancher 论坛](https://forums.rancher.com)上发帖。
#### 提交 Issue 的检查清单
提交问题时请遵循此清单,以便我们调查和解决问题。如果你能提供更多信息,我们就可以使用更多数据来确定导致问题的原因或发现更多相关的内容。
:::note
如果数据量很大,请使用 [GitHub Gist](https://gist.github.com/) 或类似工具,并在 issue 中链接你创建的资源。
:::
:::note 重要提示:
请删除所有敏感数据。
:::
- **资源**:请尽量详细地提供所使用的资源。导致问题的原因可能很多,因此请尽量提供更多细节来帮助我们确定根本原因。下面是一些参考示例:
- **主机**:主机的规格(例如 CPU/内存/磁盘),运行在什么云厂商上,使用的 Amazon Machine Image,使用的 DigitalOcean droplet,配置的镜像(复现时用于重新构建或使用)。
- **操作系统**:使用的是什么操作系统。在此处提供详细信息,例如 `cat /etc/os-release` 的输出(确切的操作系统版本)和 `uname -r` 的输出(确切的内核)。
- **Docker**:使用的 Docker 版本以及安装的方法。Docker 的大部分详情都可以在 `docker version` 和 `docker info` 的输出中找到。
- **环境**:是否使用了代理,是否使用可信的 CA/自签名证书,是否使用了外部负载均衡器。
- **Rancher**:使用的 Rancher 版本,可以在 UI 左下角或者从主机运行的 image 标签中获取。
- **集群**:创建了什么样的集群,如何创建的,在创建时指定了什么参数。
- **复现 issue 的步骤**:尽量详细地说明你是如何触发所报告的情况的。这有助于复现你的情况。
- 提供从创建到你报告的情况使用的手动步骤或自动化脚本。
- **日志**:提供使用资源的数据/日志。
- Rancher
- Docker 安装
```
docker logs \
--timestamps \
$(docker ps | grep -E "rancher/rancher:|rancher/rancher " | awk '{ print $1 }')
```
- 使用 `kubectl` 的 Kubernetes 安装
:::note
确保你配置了正确的 kubeconfig(例如,如果 Rancher 安装在 Kubernetes 集群上,则 `export KUBECONFIG=$PWD/kube_config_cluster.yml`)或通过 UI 使用了嵌入式 kubectl。
:::
```
kubectl -n cattle-system \
logs \
-l app=rancher \
--timestamps=true
```
- 系统日志记录(可能不存在,取决于操作系统)
- `/var/log/messages`
- `/var/log/syslog`
- `/var/log/kern.log`
- Docker Daemon 日志记录(可能并不全部存在,取决于操作系统)
- `/var/log/docker.log`
- **指标**:如果你遇到性能问题,请提供尽可能多的指标数据(文件或屏幕截图)来帮助我们确定问题。如果你遇到主机相关的问题,你可以提供 `top`、`free -m`、`df` 的输出,这些输出会显示进程/内存/磁盘的使用情况。
@@ -0,0 +1,169 @@
---
title: CNI 网络插件
description: 了解容器网络接口 (CNI)、Rancher 提供的 CNI 网络插件、提供商的功能,以及如何选择网络提供商
---
## 什么是 CNI?
CNI(容器网络接口)是一个[云原生计算基金会项目](https://cncf.io/),它包含了一些规范和库,用于编写在 Linux 容器中配置网络接口的一系列插件。CNI 只关注容器的网络连接,并在容器被删除时移除所分配的资源。
Kubernetes 使用 CNI 作为网络提供商和 Kubernetes Pod 网络之间的接口。
![CNI Logo](/img/cni-logo.png)
有关更多信息,请访问 [CNI GitHub 项目](https://github.com/containernetworking/cni)。
## CNI 使用了哪些网络模型?
CNI 网络插件使用封装网络模型(例如 Virtual Extensible Lan,缩写是 [VXLAN](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#vxlan))或非封装网络模型(例如 Border Gateway Protocol,缩写是 [BGP](https://en.wikipedia.org/wiki/Border_Gateway_Protocol))来实现网络结构。
### 什么是封装网络?
此网络模型提供了一个逻辑二层(L2)网络,该网络封装在跨 Kubernetes 集群节点的现有三层(L3)网络拓扑上。使用此模型,你可以为容器提供一个隔离的 L2 网络,而无需分发路由。封装网络带来了少量的处理开销以及由于覆盖封装生成 IP header 造成的 IP 包大小增加。封装信息由 Kubernetes worker 之间的 UDP 端口分发,交换如何访问 MAC 地址的网络控制平面信息。此类网络模型中常用的封装是 VXLAN、Internet 协议安全性 (IPSec) 和 IP-in-IP。
简单来说,这种网络模型在 Kubernetes worker 之间生成了一种扩展网桥,其中连接了 pod。
如果你偏向使用扩展 L2 网桥,则可以选择此网络模型。此网络模型对 Kubernetes worker 的 L3 网络延迟很敏感。如果数据中心位于不同的地理位置,请确保它们之间的延迟较低,以避免最终的网络分段。
使用这种网络模型的 CNI 网络插件包括 Flannel、Canal、Weave 和 Cilium。默认情况下,Calico 不会使用此模型,但你可以对其进行配置。
![封装网络](/img/encapsulated-network.png)
### 什么是非封装网络?
该网络模型提供了一个 L3 网络,用于在容器之间路由数据包。此模型不会生成隔离的 L2 网络,也不会产生开销。这些好处的代价是,Kubernetes worker 必须管理所需的所有路由分发。该网络模型不使用 IP header 进行封装,而是使用 Kubernetes Worker 之间的网络协议来分发路由信息以实现 Pod 连接,例如 [BGP](https://en.wikipedia.org/wiki/Border_Gateway_Protocol)。
简而言之,这种网络模型在 Kubernetes worker 之间生成了一种扩展网络路由器,提供了如何连接 Pod 的信息。
如果你偏向使用 L3 网络,则可以选择此网络模型。此模型在操作系统级别为 Kubernetes Worker 动态更新路由。对延迟较不敏感。
使用这种网络模型的 CNI 网络插件包括 Calico 和 Cilium。Cilium 可以使用此模型进行配置,即使这不是默认模式。
![非封装网络](/img/unencapsulated-network.png)
## Rancher 提供哪些 CNI 插件?
### RKE2 Kubernetes 集群
Rancher 开箱即用地为 RKE2 Kubernetes 集群提供了几个 CNI 网络插件,分别是 Canal、Calico 和 Cilium。
如果你使用 Rancher 创建新的 Kubernetes 集群,你可以选择你的 CNI 网络插件。
#### Calico
![Calico Logo](/img/calico-logo.png)
Calico 在云上的 Kubernetes 集群中启用网络和网络策略。默认情况下,Calico 使用纯净、未封装的 IP 网络结构和策略引擎为 Kubernetes 工作负载提供网络。工作负载能够使用 BGP 在云上和本地进行通信。
Calico 还提供了一种无状态的 IP-in-IP 或 VXLAN 封装模式。如果需要,你可以使用它。Calico 还支持策略隔离,让你使用高级 ingress 和 egress 策略保护和管理 Kubernetes 工作负载。
如果使用 BGP,Kubernetes Worker 需要打开 TCP 端口 `179`,如果使用 VXLAN 封装,则需要打开 UDP 端口 `4789`。另外,使用 Typha 时需要 TCP 端口 `5473`。有关详细信息,请参阅[下游集群的端口要求](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#网络要求)。
:::note 重要提示:
在 Rancher 2.6.3 中,Calico 探测到在安装 RKE2 时 Windows 节点会失败。<b>请注意,此问题已在 v2.6.4 中解决。</b>
- 要解决此问题,请先导航到 `https://<rancherserverurl>/v3/settings/windows-rke2-install-script`。
- 在那里,将当前设置 `https://raw.githubusercontent.com/rancher/wins/v0.1.3/install.ps1` 更改为新设置 `https://raw.githubusercontent .com/rancher/rke2/master/windows/rke2-install.ps1`。
:::
![Calico Diagram](/img/calico-diagram.svg)
有关详细信息,请参阅以下页面:
- [Project Calico 官方网站](https://www.projectcalico.org/)
- [Calico 项目 GitHub 页面](https://github.com/projectcalico/calico)
#### Canal
![Canal Logo](/img/canal-logo.png)
Canal 是一个 CNI 网络插件,它很好地结合了 Flannel 和 Calico 的优点。它让你轻松地将 Calico 和 Flannel 网络部署为统一的网络解决方案,将 Calico 的网络策略执行与 Calico(未封装)和 Flannel(封装)丰富的网络连接选项结合起来。
Canal 是 Rancher 默认的 CNI 网络插件,并采用了 Flannel 和 VXLAN 封装。
Kubernetes Worker 需要打开 UDP 端口 `8472` (VXLAN) 和 TCP 端口 `9099`(健康检查)。如果使用 Wireguard,则需要打开 UDP 端口 `51820` 和 `51821`。有关详细信息,请参阅[下游集群的端口要求](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md)。
![](/img/canal-diagram.png)
有关详细信息,请参阅 [Canal GitHub 页面](https://github.com/projectcalico/canal)
#### Cilium
![Cilium Logo](/img/cilium-logo.png)
Cilium 在 Kubernetes 中启用网络和网络策略(L3、L4 和 L7)。默认情况下,Cilium 使用 eBPF 技术在节点内部路由数据包,并使用 VXLAN 将数据包发送到其他节点。你也可以配置非封装的技术。
Cilium 推荐大于 5.2 的内核版本,从而充分利用 eBPF 的能力。Kubernetes worker 需要打开 TCP 端口 `8472`(VXLAN)和 TCP 端口 `4240`(健康检查)。此外,还必须为健康检查启用 ICMP 8/0。有关详细信息,请查看 [Cilium 系统要求](https://docs.cilium.io/en/latest/operations/system_requirements/#firewall-requirements)。
##### Cilium 中跨节点的 Ingress 路由
<br/>
默认情况下,Cilium 不允许 Pod 与其他节点上的 Pod 通信。要解决此问题,请启用 Ingress Controller 以使用 “CiliumNetworkPolicy” 进行跨节点路由请求。
选择 Cilium CNI 并为新集群启用项目网络隔离后,配置如下:
```
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: hn-nodes
namespace: default
spec:
endpointSelector: {}
ingress:
- fromEntities:
- remote-node
```
## 各个网络插件的 CNI 功能
下表总结了 Rancher 中每个 CNI 网络插件支持的不同功能:
| 提供商 | 网络模型 | 路线分发 | 网络策略 | 网格 | 外部数据存储 | 加密 | Ingress/Egress 策略 |
| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
| Canal | 封装 (VXLAN) | 否 | 是 | 否 | K8s API | 是 | 是 |
| Flannel | 封装 (VXLAN) | 否 | 否 | 否 | K8s API | 是 | 否 |
| Calico | 封装(VXLAN,IPIP)或未封装 | 是 | 是 | 是 | Etcd 和 K8s API | 是 | 是 |
| Weave | 封装 | 是 | 是 | 是 | 否 | 是 | 是 |
| Cilium | 封装 (VXLAN) | 是 | 是 | 是 | Etcd 和 K8s API | 是 | 是 |
- 网络模型:封装或未封装。如需更多信息,请参阅 [CNI 中使用的网络模型](#cni-使用了哪些网络模型)。
- 路由分发:一种外部网关协议,用于在互联网上交换路由和可达性信息。BGP 可以帮助进行跨集群 pod 之间的网络。此功能对于未封装的 CNI 网络插件是必须的,并且通常由 BGP 完成。如果你想构建跨网段拆分的集群,路由分发是一个很好的功能。
- 网络策略:Kubernetes 提供了强制执行规则的功能,这些规则决定了哪些 service 可以使用网络策略进行相互通信。这是从 Kubernetes 1.7 起稳定的功能,可以与某些网络插件一起使用。
- 网格:允许在不同的 Kubernetes 集群间进行 service 之间的网络通信。
- 外部数据存储:具有此功能的 CNI 网络插件需要一个外部数据存储来存储数据。
- 加密:允许加密和安全的网络控制和数据平面。
- Ingress/Egress 策略:允许你管理 Kubernetes 和非 Kubernetes 通信的路由控制。
## CNI 社区人气
下表总结了不同的 GitHub 指标,让你了解每个项目的受欢迎程度和活动。数据收集于 2022 年 1 月。
| 提供商 | 项目 | Stars | Forks | Contributors |
| ---- | ---- | ---- | ---- | ---- |
| Canal | https://github.com/projectcalico/canal | 679 | 100 | 21 |
| Flannel | https://github.com/flannel-io/flannel | 7k | 2.5k | 185 |
| Calico | https://github.com/projectcalico/calico | 3.1k | 741 | 224 |
| Weave | https://github.com/weaveworks/weave/ | 6.2k | 635 | 84 |
| Cilium | https://github.com/cilium/cilium | 10.6k | 1.3k | 352 |
<br/>
## 使用哪个 CNI 插件?
这取决于你的项目需求。各个提供商都有不同的功能和选项。没有一个提供商可以满足所有用户的需求。
Canal 是默认的 CNI 网络插件。对于大多数用例,我们推荐你使用它。它使用 Flannel 为容器提供封装网络,同时添加 Calico 网络策略,可以在网络方面提供项目/命名空间隔离。
## 如何配置 CNI 网络插件?
如需了解如何为你的集群配置网络插件,请参阅[集群选项](../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md)。有关更高级的配置选项,请参阅有关使用[配置文件](../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#rke-集群配置文件参考)和[网络插件](https://rancher.com/docs/rke/latest/en/config-options/add-ons/network-plugins/)选项来配置集群的说明。
@@ -0,0 +1,25 @@
---
title: Rancher 中已弃用的功能
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/faq/deprecated-features"/>
</head>
## Rancher 的弃用策略是什么?
我们已经在支持的[服务条款](https://rancher.com/support-maintenance-terms)中发布了官方的弃用策略。
## 在哪里可以了解 Rancher 中已弃用哪些功能?
Rancher 将在 GitHub 上发布的 Rancher 的[发版说明](https://github.com/rancher/rancher/releases)中发布已弃用的功能。有关已弃用的功能,请参阅以下的补丁版本:
| Patch 版本 | 发布时间 |
| ----------------------------------------------------------------- | ------------------ |
| [2.13.2](https://github.com/rancher/rancher/releases/tag/v2.13.1) | 2026 年 01 月 29 日 |
| [2.13.1](https://github.com/rancher/rancher/releases/tag/v2.13.1) | 2025 年 12 月 18 日 |
| [2.13.0](https://github.com/rancher/rancher/releases/tag/v2.13.0) | 2025 年 11 月 25 日 |
## 当一个功能被标记为弃用我可以得到什么样的预期?
当功能被标记为“已弃用”时,它依然可用并得到支持,允许按照常规的流程进行升级。一旦升级完成,用户/管理员应开始计划在升级到标记为已移除的版本之前放弃使用已弃用的功能。对于新的部署,建议不要使用已弃用的功能。
@@ -0,0 +1,51 @@
---
title: 一般常见问题解答
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/faq/general-faq"/>
</head>
本文包含了用户常见的 Rancher 2.x 问题。
有关常见技术问题,请参阅[常见技术问题解答](technical-items.md)。
## Rancher 2.x 支持 Docker Swarm 和 Mesos 作为环境类型吗?
如果你在 Rancher 2.x 中创建环境,Swarm 和 Mesos 将不再是可选的标准选项。但是,Swarm 和 Mesos 还能继续作为可以部署的商店应用程序。这是一个艰难的决定,但这是大势所趋。比如说,15,000 多个集群可能只有大约 200 个在运行 Swarm。
## 是否可以使用 Rancher 2.x 管理 Azure Kubernetes 服务?
是的。请参阅我们的[集群管理](../how-to-guides/new-user-guides/manage-clusters/manage-clusters.md)指南,了解 AKS 上可用的 Rancher 功能,以及相关的 [AKS 的文档](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-aks.md)
## Rancher 是否支持 Windows?
Rancher 支持 Windows Server 1809 容器。有关如何使用 Windows Worker 节点设置集群的详细信息,请参阅[为 Windows 配置自定义集群](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/use-windows-clusters/use-windows-clusters.md)。
## Rancher 是否支持 Istio?
Rancher 支持 [Istio](../integrations-in-rancher/istio/istio.md)。
## Rancher 2.x 是否支持使用 Hashicorp 的 Vault 来存储密文?
密文管理已在我们的 roadmap 上,但我们尚未将该功能分配给特定版本。
## Rancher 2.x 是否也支持 RKT 容器?
目前,我们只支持 Docker。
## Rancher 2.x 是否支持将 Calico、Contiv、Contrail、Flannel、Weave net 等网络插件用于嵌入和已注册的 Kubernetes?
Rancher 开箱即用地为 Kubernetes 集群提供了几个 CNI 网络插件,分别是 Canal、Flannel、Calico 和 Weave。有关官方支持的详细信息,请参阅 [Rancher 支持矩阵](https://rancher.com/support-maintenance-terms/)。
## Rancher 是否计划支持 Traefik?
目前,我们不打算提供嵌入式 Traefik 支持,但我们仍在探索负载均衡方案。
## 我可以将 OpenShift Kubernetes 集群导入 2.x 吗?
我们的目标是运行任何上游 Kubernetes 集群。因此,Rancher 2.x 应该可以与 OpenShift 一起使用,但我们尚未对此进行测试。
## Rancher 会集成 Longhorn 吗?
是的。Longhorn 已集成到 Rancher 2.5+ 中。
@@ -0,0 +1,23 @@
---
title: 安装和配置 kubectl
---
`kubectl` 是一个 CLI 工具,用于运行 Kubernetes 集群相关的命令。Rancher 2.x 中的许多维护和管理任务都需要它。
## 安装
请参阅 [kubectl 安装](https://kubernetes.io/docs/tasks/tools/install-kubectl/)将 kubectl 安装到你的操作系统上。
## 配置
When you create a Kubernetes cluster with RKE2/K3s, the Kubeconfig file is stored at `/etc/rancher/rke2/rke2.yaml` or `/etc/rancher/k3s/k3s.yaml` depending on your chosen distribution. These files are used to configure access to the Kubernetes cluster.
使用 `kubectl` 测试你的连接性,并查看你是否可以获取节点列表:
```shell
kubectl get nodes
NAME STATUS ROLES AGE VERSION
165.227.114.63 Ready controlplane,etcd,worker 11m v1.10.1
165.227.116.167 Ready controlplane,etcd,worker 11m v1.10.1
165.227.127.226 Ready controlplane,etcd,worker 11m v1.10.1
```
@@ -0,0 +1,60 @@
---
title: 卸载 Rancher
---
本文介绍了如果你不再需要 Rancher、不想再由 Rancher 管理集群、或想删除 Rancher Server 需要怎么做。
## 如果 Rancher Server 被删除,下游集群中的工作负载会怎样?
如果 Rancher 删除了或无法恢复,Rancher 管理的下游 Kubernetes 集群中的所有工作负载将继续正常运行。
## 如果删除了 Rancher Server,该如何访问下游集群?
如果删除了 Rancher,访问下游集群的方式取决于集群的类型和集群的创建方式。总而言之:
- **Registered/Imported clusters:** The cluster will be unaffected and you can access the cluster using the same methods that you did before the cluster was registered into Rancher.
- **托管的 Kubernetes 集群**:如果你在 Kubernetes 云提供商(例如 EKS、GKE 或 AKS)中创建集群,你可以继续使用提供商的云凭证来管理集群。
- **Rancher provisioned clusters:** To access an [RKE2/K3s cluster](../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) the cluster must have the [authorized cluster endpoint](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) enabled, and you must have already downloaded the cluster's kubeconfig file from the Rancher UI. With this endpoint, you can access your cluster with kubectl directly instead of communicating through the Rancher server's [authentication proxy.](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#1-the-authentication-proxy) For instructions on how to configure kubectl to use the authorized cluster endpoint, refer to the section about directly accessing clusters with [kubectl and the kubeconfig file.](../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) These clusters will use a snapshot of the authentication as it was configured when Rancher was removed.
## 如果我不想再使用 Rancher 了该怎么做?
:::note
之前推荐的 [System Tools](../reference-guides/system-tools.md) 自 2022 年 6 月起已弃用。
:::
如果你[在 Kubernetes 集群上安装了 Rancher](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md),你可以使用 [Rancher Cleanup](https://github.com/rancher/rancher-cleanup) 工具删除 Rancher。
在高可用 (HA) 模式下卸载 Rancher 还将删除所有 `helm-operation-*` Pod 和以下应用程序:
- fleet
- fleet-agent
- rancher-operator
- rancher-webhook
自定义资源 (CRD) 和自定义命名空间仍需要手动删除。
如果你在 Docker 中安装 Rancher,则可以通过删除运行 Rancher 的单个 Docker 容器来卸载 Rancher。
移除 Rancher 不会影响导入的集群。有关其他集群类型,请参考[移除 Rancher 后访问下游集群](#如果删除了-rancher-server该如何访问下游集群)。
## 如果我不想 Rancher 管理我的注册集群该怎么办?
如果你在 Rancher UI 中删除了已注册的集群,则该集群将与 Rancher 分离,集群不会发生改变,你可以使用注册集群之前的方法访问该集群。
要分离集群:
1. 在左上角,单击 **☰ > 集群管理**。
2. 转到要与 Rancher 分离的已注册集群,然后单击 **⋮ > 删除**。
3. 单击**删除**。
**结果**:注册的集群已与 Rancher 分离,并在 Rancher 外正常运行。
## What if I don't want my hosted Kubernetes cluster managed by Rancher?
目前,我们没有将这些集群从 Rancher 中分离出来的功能。在这种情况下,“分离”指的是将 Rancher 组件移除出集群,并独立于 Rancher 管理对集群的访问。
[此 issue](https://github.com/rancher/rancher/issues/25234) 跟踪了在没有 Rancher 的情况下管理这些集群的功能。
有关如何在删除 Rancher Server 后访问集群的更多信息,请参阅[本节](#如果删除了-rancher-server该如何访问下游集群)。
@@ -0,0 +1,14 @@
---
title: 安全
---
**是否有强化指南?**
强化指南现在位于[安全](../reference-guides/rancher-security/rancher-security.md)部分。
<br/>
**Rancher Kubernetes 集群 CIS Benchmark 测试的结果是什么?**
我们已经针对强化的 Rancher Kubernetes 集群运行了 CIS Kubernetes Benchmark 测试。你可以在[安全](../reference-guides/rancher-security/rancher-security.md)中找到该评估的结果。

Some files were not shown because too many files have changed in this diff Show More