mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-29 06:29:34 +00:00
Compare commits
57
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
a192d4c204 | ||
|
|
c0bb462495 | ||
|
|
b0d5bf7f17 | ||
|
|
ff9e2a1102 | ||
|
|
b9a23c4350 | ||
|
|
9fd94c4750 | ||
|
|
2a02e2bc0c | ||
|
|
278e55bc61 | ||
|
|
d935632f57 | ||
|
|
d23d6f0cb7 | ||
|
|
61f5a02048 | ||
|
|
ca3001912d | ||
|
|
e363836980 | ||
|
|
db108776a3 | ||
|
|
34c873ece2 | ||
|
|
56d09d63f1 | ||
|
|
6abbf96143 | ||
|
|
80dd010452 | ||
|
|
83aa9da938 | ||
|
|
b34027c28a | ||
|
|
17486fb91f | ||
|
|
bdd6116c6b | ||
|
|
92216252ef | ||
|
|
4878cf5a9c | ||
|
|
124b0d1823 | ||
|
|
d853433d1d | ||
|
|
29ae56f5b7 | ||
|
|
1d696bac8e | ||
|
|
0272c007cb | ||
|
|
ccfe370188 | ||
|
|
b641c16125 | ||
|
|
ca818e70af | ||
|
|
eeddf866f7 | ||
|
|
f0ae84ea56 | ||
|
|
690a8ceab6 | ||
|
|
21de5f1f58 | ||
|
|
2ce9276086 | ||
|
|
50ccf01498 | ||
|
|
595dd80222 | ||
|
|
07b47e82d8 | ||
|
|
d12531819a | ||
|
|
38204c2ae5 | ||
|
|
8e10fcd952 | ||
|
|
91d9e2b81d | ||
|
|
57d019e486 | ||
|
|
48c191e1b6 | ||
|
|
7838a690ed | ||
|
|
5f0c5857f8 | ||
|
|
0ab15d2315 | ||
|
|
834cd145ab | ||
|
|
f21edef534 | ||
|
|
8bf8fef3ba | ||
|
|
0b1a9b0d35 | ||
|
|
a387de4bfa | ||
|
|
6eed0e9140 | ||
|
|
8a0c297a24 | ||
|
|
4174a58070 |
Submodule .github/styles/suse-vale-styleguide updated: fba9687e7d...61aa791cfb
-2
@@ -23,7 +23,5 @@ For information on how Rancher works, regardless of the installation method, ref
|
||||
- The Ingress controller will redirect HTTP to HTTPS and terminate SSL/TLS on port TCP/443.
|
||||
- The Ingress controller will forward traffic to port TCP/80 on the pod in the Rancher deployment.
|
||||
|
||||
<figcaption>Kubernetes Rancher install with layer 4 load balancer, depicting SSL termination at ingress controllers</figcaption>
|
||||
|
||||

|
||||
<sup>Kubernetes Rancher install with Layer 4 load balancer (TCP), depicting SSL termination at ingress controllers</sup>
|
||||
|
||||
@@ -30,7 +30,6 @@ The following is a complete list of tokens generated with `ttl=0`:
|
||||
| `agent-*` | Token for agent deployment |
|
||||
| `compose-token-*` | Token for compose |
|
||||
| `helm-token-*` | Token for Helm chart deployment |
|
||||
| `telemetry-*` | Telemetry token |
|
||||
| `drain-node-*` | Token for drain (Rancher uses `kubectl` for drain because there is no native Kubernetes API). |
|
||||
|
||||
## Setting TTL on Kubeconfig Tokens
|
||||
|
||||
@@ -42,7 +42,6 @@ kontainer-engine | https://github.com/rancher/kontainer-engine | This repository
|
||||
RKE repository | https://github.com/rancher/rke | This repository is the source of Rancher Kubernetes Engine, the tool to provision Kubernetes clusters on any machine.
|
||||
CLI | https://github.com/rancher/cli | This repository is the source code for the Rancher CLI used in Rancher 2.x.
|
||||
(Rancher) Helm repository | https://github.com/rancher/helm | This repository is the source of the packaged Helm binary. This is a fork of the `helm/helm` repository.
|
||||
Telemetry repository | https://github.com/rancher/telemetry | This repository is the source for the Telemetry binary.
|
||||
loglevel repository | https://github.com/rancher/loglevel | This repository is the source of the loglevel binary, used to dynamically change log levels.
|
||||
|
||||
To see all libraries/projects used in Rancher, see the [`go.mod` file](https://github.com/rancher/rancher/blob/master/go.mod) in the `rancher/rancher` repository.
|
||||
|
||||
@@ -16,6 +16,7 @@ Rancher will publish deprecated features as part of the [release notes](https://
|
||||
|
||||
| Patch Version | Release Date |
|
||||
|---------------|---------------|
|
||||
| [2.10.1](https://github.com/rancher/rancher/releases/tag/v2.10.1) | Dec 19, 2024 |
|
||||
| [2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) | Nov 18, 2024 |
|
||||
|
||||
## What can I expect when a feature is marked for deprecation?
|
||||
|
||||
@@ -1,35 +0,0 @@
|
||||
---
|
||||
title: Telemetry FAQ
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/telemetry"/>
|
||||
</head>
|
||||
|
||||
## What is Telemetry?
|
||||
|
||||
Telemetry collects aggregate information about the size of Rancher installations, versions of components used, and which features are used. This information is used by Rancher Labs to help make the product better and is not shared with third-parties.
|
||||
|
||||
## What information is collected?
|
||||
|
||||
No specific identifying information like usernames, passwords, or the names or addresses of user resources will ever be collected.
|
||||
|
||||
The primary things collected include:
|
||||
|
||||
- Aggregate counts (smallest, average, largest, total) of nodes per-cluster and their size (e.g. CPU cores & RAM).
|
||||
- Aggregate counts of logical resources like Clusters, Projects, Namespaces, and Pods.
|
||||
- Counts of what driver was used to deploy clusters and nodes (e.g. GKE vs EC2 vs Imported vs Custom).
|
||||
- Versions of Kubernetes components, Operating Systems and Docker that are deployed on nodes.
|
||||
- Whether some optional components are enabled or not (e.g. which auth providers are used).
|
||||
- The image name & version of Rancher that is running.
|
||||
- A unique randomly-generated identifier for this installation.
|
||||
|
||||
## Can I see the information that is being sent?
|
||||
|
||||
If Telemetry is enabled, you can go to `https://<your rancher server>/v1-telemetry` in your installation to see the current data.
|
||||
|
||||
If Telemetry is not enabled, the process that collects the data is not running, so there is nothing being collected to look at.
|
||||
|
||||
## How do I turn it on or off?
|
||||
|
||||
After initial setup, an administrator can go to the `Settings` page in the `Global` section of the UI and click Edit to change the `telemetry-opt` setting to either `in` or `out`.
|
||||
-7
@@ -142,10 +142,3 @@ docker run -d --restart=unless-stopped \
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
:::note
|
||||
|
||||
If you don't intend to send telemetry data, opt out [telemetry](../../../../faq/telemetry.md) during the initial login.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
-6
@@ -234,13 +234,7 @@ If you are using a Private CA signed cert, add `--set privateCA=true` following
|
||||
--set useBundledSystemChart=true # Use the packaged Rancher system charts
|
||||
```
|
||||
|
||||
|
||||
The installation is complete.
|
||||
:::caution
|
||||
|
||||
If you don't intend to send telemetry data, opt out [telemetry](../../../../faq/telemetry.md) during the initial login. Leaving this active in an air-gapped environment can cause issues if the sockets cannot be opened successfully.
|
||||
|
||||
:::
|
||||
|
||||
## Additional Resources
|
||||
|
||||
|
||||
-6
@@ -95,12 +95,6 @@ kubectl rollout status deployment -n cattle-system rancher
|
||||
|
||||
You can now navigate to `https://rancher.example.com` and start using Rancher.
|
||||
|
||||
:::caution
|
||||
|
||||
If you don't intend to send telemetry data, opt out [telemetry](../../../../faq/telemetry.md) during the initial login. Leaving this active in an air-gapped environment can cause issues if the sockets cannot be opened successfully.
|
||||
|
||||
:::
|
||||
|
||||
### Additional Resources
|
||||
|
||||
These resources could be helpful when installing Rancher:
|
||||
|
||||
-2
@@ -23,7 +23,5 @@ For information on how Rancher works, regardless of the installation method, ref
|
||||
- The Ingress controller will redirect HTTP to HTTPS and terminate SSL/TLS on port TCP/443.
|
||||
- The Ingress controller will forward traffic to port TCP/80 on the pod in the Rancher deployment.
|
||||
|
||||
<figcaption>Kubernetes Rancher install with layer 4 load balancer, depicting SSL termination at ingress controllers</figcaption>
|
||||
|
||||

|
||||
<sup>Kubernetes Rancher install with Layer 4 load balancer (TCP), depicting SSL termination at ingress controllers</sup>
|
||||
|
||||
+137
-187
@@ -93,7 +93,7 @@ This [tutorial](https://aws.amazon.com/blogs/opensource/managing-eks-clusters-ra
|
||||
|
||||
## Minimum EKS Permissions
|
||||
|
||||
These are the minimum set of permissions necessary to access the full functionality of Rancher's EKS driver. You'll need additional permissions for Rancher to provision the `Service Role` and `VPC` resources. If you create these resources **before** you create the cluster, they'll be available when you configure the cluster.
|
||||
These are the minimum set of permissions necessary to access the full functionality of Rancher's EKS driver. These permissions allow Rancher to create the Service Role and Virtual Private Cloud (VPC) resources on the users' behalf, if necessary.
|
||||
|
||||
:::note
|
||||
In EKS v1.23 and above, you must use the out-of-tree drivers for EBS-backed volumes. You need [specific permissions](#ebs-csi-driver-addon-permissions) to enable this add-on.
|
||||
@@ -101,133 +101,66 @@ In EKS v1.23 and above, you must use the out-of-tree drivers for EBS-backed volu
|
||||
|
||||
Resource | Description
|
||||
---------|------------
|
||||
Service Role | Provides permissions that allow Kubernetes to manage resources on your behalf. Rancher can create the service role with the following [Service Role Permissions](#service-role-permissions).
|
||||
VPC | Provides isolated network resources utilised by EKS and worker nodes. Rancher can create the VPC resources with the following [VPC Permissions](#vpc-permissions).
|
||||
EBS CSI Driver add-on | Provides permissions that allow Kubernetes to interact with EBS and configure the cluster to enable the add-on (required for EKS v1.23 and above). Rancher can install the add-on with the following [EBS CSI Driver addon Permissions](#ebs-csi-driver-addon-permissions).
|
||||
|
||||
|
||||
Resource targeting uses `*` as the ARN of many of the resources created cannot be known before creating the EKS cluster in Rancher.
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "EC2Permissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:RunInstances",
|
||||
"ec2:RevokeSecurityGroupIngress",
|
||||
"ec2:RevokeSecurityGroupEgress",
|
||||
"ec2:DescribeInstanceTypes",
|
||||
"ec2:DescribeRegions",
|
||||
"ec2:DescribeVpcs",
|
||||
"ec2:DescribeTags",
|
||||
"ec2:DescribeSubnets",
|
||||
"ec2:DescribeSecurityGroups",
|
||||
"ec2:DescribeRouteTables",
|
||||
"ec2:DescribeLaunchTemplateVersions",
|
||||
"ec2:DescribeLaunchTemplates",
|
||||
"ec2:DescribeKeyPairs",
|
||||
"ec2:DescribeInternetGateways",
|
||||
"ec2:DescribeImages",
|
||||
"ec2:DescribeAvailabilityZones",
|
||||
"ec2:DescribeAccountAttributes",
|
||||
"ec2:DeleteTags",
|
||||
"ec2:DeleteLaunchTemplateVersions",
|
||||
"ec2:DeleteLaunchTemplate",
|
||||
"ec2:DeleteSecurityGroup",
|
||||
"ec2:DeleteKeyPair",
|
||||
"ec2:CreateTags",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateLaunchTemplateVersion",
|
||||
"ec2:CreateLaunchTemplate",
|
||||
"ec2:CreateKeyPair",
|
||||
"ec2:AuthorizeSecurityGroupIngress",
|
||||
"ec2:AuthorizeSecurityGroupEgress"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "CloudFormationPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"cloudformation:ListStacks",
|
||||
"cloudformation:ListStackResources",
|
||||
"cloudformation:DescribeStacks",
|
||||
"cloudformation:DescribeStackResources",
|
||||
"cloudformation:DescribeStackResource",
|
||||
"cloudformation:DeleteStack",
|
||||
"cloudformation:CreateStackSet",
|
||||
"cloudformation:CreateStack"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "IAMPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"iam:PassRole",
|
||||
"iam:ListRoles",
|
||||
"iam:ListRoleTags",
|
||||
"iam:ListInstanceProfilesForRole",
|
||||
"iam:ListInstanceProfiles",
|
||||
"iam:ListAttachedRolePolicies",
|
||||
"iam:GetRole",
|
||||
"iam:GetInstanceProfile",
|
||||
"iam:DetachRolePolicy",
|
||||
"iam:DeleteRole",
|
||||
"iam:CreateRole",
|
||||
"iam:AttachRolePolicy"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "KMSPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": "kms:ListKeys",
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "EKSPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"eks:UpdateNodegroupVersion",
|
||||
"eks:UpdateNodegroupConfig",
|
||||
"eks:UpdateClusterVersion",
|
||||
"eks:UpdateClusterConfig",
|
||||
"eks:UntagResource",
|
||||
"eks:TagResource",
|
||||
"eks:ListUpdates",
|
||||
"eks:ListTagsForResource",
|
||||
"eks:ListNodegroups",
|
||||
"eks:ListFargateProfiles",
|
||||
"eks:ListClusters",
|
||||
"eks:DescribeUpdate",
|
||||
"eks:DescribeNodegroup",
|
||||
"eks:DescribeFargateProfile",
|
||||
"eks:DescribeCluster",
|
||||
"eks:DeleteNodegroup",
|
||||
"eks:DeleteFargateProfile",
|
||||
"eks:DeleteCluster",
|
||||
"eks:CreateNodegroup",
|
||||
"eks:CreateFargateProfile",
|
||||
"eks:CreateCluster"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Service Role Permissions
|
||||
|
||||
These are permissions that are needed during EKS cluster creation, so Rancher can create a service role on the users' behalf.
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "EC2Permissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:AuthorizeSecurityGroupEgress",
|
||||
"ec2:AuthorizeSecurityGroupIngress",
|
||||
"ec2:CreateKeyPair",
|
||||
"ec2:CreateLaunchTemplate",
|
||||
"ec2:CreateLaunchTemplateVersion",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateTags",
|
||||
"ec2:DeleteKeyPair",
|
||||
"ec2:DeleteLaunchTemplate",
|
||||
"ec2:DeleteLaunchTemplateVersions",
|
||||
"ec2:DeleteSecurityGroup",
|
||||
"ec2:DeleteTags",
|
||||
"ec2:DescribeAccountAttributes",
|
||||
"ec2:DescribeAvailabilityZones",
|
||||
"ec2:DescribeImages",
|
||||
"ec2:DescribeInternetGateways",
|
||||
"ec2:DescribeInstanceTypes",
|
||||
"ec2:DescribeKeyPairs",
|
||||
"ec2:DescribeLaunchTemplateVersions",
|
||||
"ec2:DescribeLaunchTemplates",
|
||||
"ec2:DescribeRegions",
|
||||
"ec2:DescribeRouteTables",
|
||||
"ec2:DescribeSecurityGroups",
|
||||
"ec2:DescribeSubnets",
|
||||
"ec2:DescribeTags",
|
||||
"ec2:DescribeVpcs",
|
||||
"ec2:RevokeSecurityGroupEgress",
|
||||
"ec2:RevokeSecurityGroupIngress",
|
||||
"ec2:RunInstances"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "CloudFormationPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"cloudformation:CreateStack",
|
||||
"cloudformation:CreateStackSet",
|
||||
"cloudformation:DeleteStack",
|
||||
"cloudformation:DescribeStackResource",
|
||||
"cloudformation:DescribeStackResources",
|
||||
"cloudformation:DescribeStacks",
|
||||
"cloudformation:ListStackResources",
|
||||
"cloudformation:ListStacks"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "IAMPermissions",
|
||||
"Effect": "Allow",
|
||||
@@ -248,7 +181,70 @@ These are permissions that are needed during EKS cluster creation, so Rancher ca
|
||||
"iam:ListRoles",
|
||||
"iam:ListRoleTags",
|
||||
"iam:PassRole",
|
||||
"iam:RemoveRoleFromInstanceProfile"
|
||||
"iam:RemoveRoleFromInstanceProfile",
|
||||
"iam:TagRole"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "KMSPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": "kms:ListKeys",
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "EKSPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"eks:CreateCluster",
|
||||
"eks:CreateFargateProfile",
|
||||
"eks:CreateNodegroup",
|
||||
"eks:DeleteCluster",
|
||||
"eks:DeleteFargateProfile",
|
||||
"eks:DeleteNodegroup",
|
||||
"eks:DescribeAddon",
|
||||
"eks:DescribeCluster",
|
||||
"eks:DescribeFargateProfile",
|
||||
"eks:DescribeNodegroup",
|
||||
"eks:DescribeUpdate",
|
||||
"eks:ListClusters",
|
||||
"eks:ListFargateProfiles",
|
||||
"eks:ListNodegroups",
|
||||
"eks:ListTagsForResource",
|
||||
"eks:ListUpdates",
|
||||
"eks:TagResource",
|
||||
"eks:UntagResource",
|
||||
"eks:UpdateClusterConfig",
|
||||
"eks:UpdateClusterVersion",
|
||||
"eks:UpdateNodegroupConfig",
|
||||
"eks:UpdateNodegroupVersion"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "VPCPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:AssociateRouteTable",
|
||||
"ec2:AttachInternetGateway",
|
||||
"ec2:CreateInternetGateway",
|
||||
"ec2:CreateRoute",
|
||||
"ec2:CreateRouteTable",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateSubnet",
|
||||
"ec2:CreateVpc",
|
||||
"ec2:DeleteInternetGateway",
|
||||
"ec2:DeleteRoute",
|
||||
"ec2:DeleteRouteTable",
|
||||
"ec2:DeleteSubnet",
|
||||
"ec2:DeleteTags",
|
||||
"ec2:DeleteVpc",
|
||||
"ec2:DescribeVpcs",
|
||||
"ec2:DetachInternetGateway",
|
||||
"ec2:DisassociateRouteTable",
|
||||
"ec2:ModifySubnetAttribute",
|
||||
"ec2:ModifyVpcAttribute",
|
||||
"ec2:ReplaceRoute"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
@@ -281,79 +277,33 @@ arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
|
||||
arn:aws:iam::aws:policy/AmazonEKSServicePolicy
|
||||
```
|
||||
|
||||
### VPC Permissions
|
||||
|
||||
These are permissions that are needed by Rancher to create a Virtual Private Cloud (VPC) and associated resources.
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "VPCPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:ReplaceRoute",
|
||||
"ec2:ModifyVpcAttribute",
|
||||
"ec2:ModifySubnetAttribute",
|
||||
"ec2:DisassociateRouteTable",
|
||||
"ec2:DetachInternetGateway",
|
||||
"ec2:DescribeVpcs",
|
||||
"ec2:DeleteVpc",
|
||||
"ec2:DeleteTags",
|
||||
"ec2:DeleteSubnet",
|
||||
"ec2:DeleteRouteTable",
|
||||
"ec2:DeleteRoute",
|
||||
"ec2:DeleteInternetGateway",
|
||||
"ec2:CreateVpc",
|
||||
"ec2:CreateSubnet",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateRouteTable",
|
||||
"ec2:CreateRoute",
|
||||
"ec2:CreateInternetGateway",
|
||||
"ec2:AttachInternetGateway",
|
||||
"ec2:AssociateRouteTable"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### EBS CSI Driver addon Permissions
|
||||
|
||||
The following are the required permissions for installing the Amazon EBS CSI Driver add-on.
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"iam:GetRole",
|
||||
"eks:DescribeAddonConfiguration",
|
||||
"eks:UpdateAddon",
|
||||
"eks:ListAddons",
|
||||
"iam:CreateRole",
|
||||
"iam:AttachRolePolicy",
|
||||
"eks:DescribeAddon",
|
||||
"iam:CreateOpenIDConnectProvider",
|
||||
"iam:PassRole",
|
||||
"eks:DescribeIdentityProviderConfig",
|
||||
"eks:DeleteAddon",
|
||||
"iam:ListOpenIDConnectProviders",
|
||||
"iam:ListAttachedRolePolicies",
|
||||
"eks:CreateAddon",
|
||||
"eks:DescribeCluster",
|
||||
"eks:DescribeAddonVersions",
|
||||
"sts:AssumeRoleWithWebIdentity",
|
||||
"eks:AssociateIdentityProviderConfig",
|
||||
"eks:ListIdentityProviderConfigs"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"eks:AssociateIdentityProviderConfig",
|
||||
"eks:CreateAddon",
|
||||
"eks:DeleteAddon",
|
||||
"eks:DescribeAddonConfiguration",
|
||||
"eks:DescribeAddonVersions",
|
||||
"eks:DescribeIdentityProviderConfig",
|
||||
"eks:ListAddons",
|
||||
"eks:ListIdentityProviderConfigs",
|
||||
"eks:UpdateAddon",
|
||||
"iam:CreateOpenIDConnectProvider",
|
||||
"iam:ListOpenIDConnectProviders",
|
||||
"sts:AssumeRoleWithWebIdentity"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
+1
@@ -19,6 +19,7 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
|
||||
|
||||
| Rancher Version | Adapter Version |
|
||||
|-----------------|------------------|
|
||||
| v2.10.1 | v105.0.0+up5.0.1 |
|
||||
| v2.10.0 | v105.0.0+up5.0.1 |
|
||||
|
||||
### 1. Gain Access to the Local Cluster
|
||||
|
||||
@@ -6,10 +6,13 @@ title: Overview
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/fleet/overview"/>
|
||||
</head>
|
||||
|
||||
Continuous Delivery with Fleet is GitOps at scale. Fleet is designed to manage up to a million clusters. It’s also lightweight enough that it works great for a [single cluster](https://fleet.rancher.io/installation#default-install) too, but it really shines when you get to a [large scale](https://fleet.rancher.io/installation#configuration-for-multi-cluster). By large scale we mean either a lot of clusters, a lot of deployments, or a lot of teams in a single organization.
|
||||
## What is Continuous Delivery with Fleet?
|
||||
|
||||
Fleet is a separate project from Rancher, and can be installed on any Kubernetes cluster with Helm.
|
||||
Continuous Delivery is Rancher's GitOps functionality, which is provided via integration with Fleet.
|
||||
|
||||
- *Cluster engine*: Fleet is a container management and deployment engine designed to offer users more control on the local cluster and constant monitoring through GitOps. Fleet focuses not only on the ability to scale, but it also gives users a high degree of control and visibility to monitor exactly what is installed on the cluster.
|
||||
|
||||
- *Deployment management*: Fleet can manage deployments from git of raw Kubernetes YAML, Helm charts, Kustomize, or any combination of the three. Regardless of the source, all resources are dynamically turned into Helm charts, and Helm is used as the engine to deploy all resources in the cluster. As a result, users can enjoy a high degree of control, consistency, and auditability of their clusters.
|
||||
|
||||
## Architecture
|
||||
|
||||
|
||||
@@ -61,9 +61,6 @@ Once Prometheus determines that an alert needs to be fired, alerts are forwarded
|
||||
|
||||
- Routes and receivers are also stored in the Kubernetes API via the Alertmanager Secret. When the Secret is updated, Alertmanager is also updated automatically. Note that routing occurs via labels only (not via annotations, etc.).
|
||||
|
||||
<figcaption>How data flows through the monitoring application:</figcaption>
|
||||
|
||||
|
||||
## 2. How Prometheus Works
|
||||
|
||||
### Storing Time Series Data
|
||||
|
||||
+1
-1
@@ -139,5 +139,5 @@ At high scale, Rancher transfers more data from the upstream cluster to UI compo
|
||||
For best performance, ensure that the host running the hardware meets these requirements:
|
||||
- 2020 i5 10th generation Intel (4 cores) or equivalent
|
||||
- 8 GB RAM
|
||||
- Total network bandwith to the upstream cluster: 72 Mb/s (equivalent to a single 802.11n Wi-Fi 4 link stream, ~8 MB/s http download throughput)
|
||||
- Total network bandwidth to the upstream cluster: 72 Mb/s (equivalent to a single 802.11n Wi-Fi 4 link stream, ~8 MB/s http download throughput)
|
||||
- Round-trip time (ping time) from browser to upstream cluster: 150 ms or less
|
||||
|
||||
@@ -10,6 +10,10 @@ Rancher is committed to informing the community of security issues in our produc
|
||||
|
||||
| ID | Description | Date | Resolution |
|
||||
|----|-------------|------|------------|
|
||||
[CVE-2024-52282](https://github.com/rancher/rancher/security/advisories/GHSA-9c5p-35gj-jqp4) | A medium severity vulnerability was discovered within Rancher Manager whereby applications installed via Rancher Manager Apps Catalog store their Helm values directly into the Apps Custom Resource Definition, resulting in any users with GET access to it to be able to read any sensitive information that are contained within the Apps’ values. Additionally, the same information leaks into auditing logs when the audit level is set to equal or above 2. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 19 Nov 2024 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.8.10](https://github.com/rancher/rancher/releases/tag/v2.8.10). |
|
||||
[CVE-2024-22036](https://github.com/rancher/rancher/security/advisories/GHSA-h99m-6755-rgwc) | A critical severity vulnerability was discovered within Rancher where a cluster or node driver can be used to escape the `chroot` jail and gain root access to the Rancher container itself. In production environments, further privilege escalation is possible based on living off the land within the Rancher container itself. For test and development environments, based on a –privileged Docker container, it is possible to escape the Docker container and gain execution access on the host system. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3), [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) and [v2.7.16](https://github.com/rancher/rancher/releases/tag/v2.7.16) |
|
||||
[CVE-2023-32197](https://github.com/rancher/rancher/security/advisories/GHSA-7h8m-pvw3-5gh4) | A critical severity vulnerability was discovered whereby Rancher Manager deployments containing Windows nodes have weak Access Control Lists (ACL), allowing `BUILTIN\Users` or `NT AUTHORITY\Authenticated Users` to view or edit sensitive files which could lead to privilege escalation. This vulnerability is exclusive to deployments that contain Windows nodes. Linux-only environments are not affected by it. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) |
|
||||
[CVE-2022-45157](https://github.com/rancher/rancher/security/advisories/GHSA-xj7w-r753-vj8v) | A critical severity vulnerability was discovered in the way that Rancher stores vSphere's CPI (Cloud Provider Interface) and CSI (Container Storage Interface) credentials used to deploy clusters through the vSphere cloud provider. This issue leads to the vSphere CPI and CSI passwords being stored in a plaintext object inside Rancher. This vulnerability is only applicable to users that deploy clusters in vSphere environments. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) |
|
||||
[CVE-2024-22030](https://github.com/rancher/rancher/security/advisories/GHSA-h4h5-9833-v2p4) | A high severity vulnerability was discovered in Rancher's agents that under very specific circumstances allows a malicious actor to take over existing Rancher nodes. The attacker needs to have control of an expired domain or execute a DNS spoofing/hijacking attack against the domain in order to exploit this vulnerability. The targeted domain is the one used as the Rancher URL (the `server-url` of the Rancher cluster). | 19 Sep 2024 | Rancher [v2.9.2](https://github.com/rancher/rancher/releases/tag/v2.9.2), [v2.8.8](https://github.com/rancher/rancher/releases/tag/v2.8.8) and [v2.7.15](https://github.com/rancher/rancher/releases/tag/v2.7.15) |
|
||||
| [CVE-2024-22032](https://github.com/rancher/rancher/security/advisories/GHSA-q6c7-56cq-g2wm) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where custom secrets encryption configurations are stored in plaintext under the clusters `AppliedSpec`. This also causes clusters to continuously reconcile, as the `AppliedSpec` would never match the desired cluster `Spec`. The stored information contains the encryption configuration for secrets within etcd, and could potentially expose sensitive data if the etcd database was exposed directly. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
| [CVE-2023-32196](https://github.com/rancher/rancher/security/advisories/GHSA-64jq-m7rq-768h) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where the webhook rule resolver ignores rules from a `ClusterRole` for an external `RoleTemplate` set with `.context=project` or `.context=""`. This allows a user to create an external `ClusterRole` with `.context=project` or `.context=""`, depending on the use of the new feature flag `external-rules` and backing `ClusterRole`. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
|
||||
@@ -20,6 +20,7 @@ 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.10.1 | v0.6.2 | ✓ | ✓ |
|
||||
| v2.10.0 | v0.6.1 | ✗ | ✓ |
|
||||
|
||||
## Why Do We Need It?
|
||||
|
||||
@@ -185,9 +185,9 @@ module.exports = {
|
||||
label: 'Latest',
|
||||
},
|
||||
'2.10': {
|
||||
label: 'v2.10 (Preview)',
|
||||
label: 'v2.10',
|
||||
path: 'v2.10',
|
||||
banner: 'unreleased'
|
||||
banner: 'none'
|
||||
},
|
||||
2.9: {
|
||||
label: 'v2.9',
|
||||
@@ -202,12 +202,10 @@ module.exports = {
|
||||
2.7: {
|
||||
label: 'v2.7',
|
||||
path: 'v2.7',
|
||||
banner: 'none'
|
||||
},
|
||||
2.6: {
|
||||
label: 'v2.6',
|
||||
path: 'v2.6',
|
||||
banner: 'none'
|
||||
},
|
||||
2.5: {
|
||||
label: 'v2.5',
|
||||
|
||||
-2
@@ -19,7 +19,5 @@ Rancher Server 的数据存储在 etcd 中。etcd 数据库可以在所有三个
|
||||
- Ingress Controller 会把 HTTP 重定向到 HTTPS,在 TCP/443 端口终结 SSL/TLS。
|
||||
- Ingress Controller 会把流量转发到 Rancher deployment 的 Pod 上的 TCP/80 端口。
|
||||
|
||||
<figcaption>使用 4 层负载均衡器在 Kubernetes 集群中安装 Rancher:Ingress Controller 的 SSL 终止:</figcaption>
|
||||
|
||||

|
||||
<sup>使用 4 层负载均衡器在 Kubernetes 集群中安装 Rancher:Ingress Controller 的 SSL 终止</sup>
|
||||
|
||||
-3
@@ -56,9 +56,6 @@ PrometheusRule 用于定义指标或时间序列数据库查询触发告警的
|
||||
|
||||
- 路由和接收器也通过 Alertmanager Secret 存储在 Kubernetes API 中。当 Secret 更新时,Alertmanager 也会自动更新。请注意,路由仅通过标签发生(而不是通过注释等)。
|
||||
|
||||
<figcaption>数据如何流经 Monitoring 应用程序</figcaption>
|
||||
|
||||
|
||||
## 2. Prometheus 的工作原理
|
||||
|
||||
### 存储时间序列数据
|
||||
|
||||
-2
@@ -19,7 +19,5 @@ Rancher Server 的数据存储在 etcd 中。etcd 数据库可以在所有三个
|
||||
- Ingress Controller 会把 HTTP 重定向到 HTTPS,在 TCP/443 端口终结 SSL/TLS。
|
||||
- Ingress Controller 会把流量转发到 Rancher deployment 的 Pod 上的 TCP/80 端口。
|
||||
|
||||
<figcaption>使用 4 层负载均衡器在 Kubernetes 集群中安装 Rancher:Ingress Controller 的 SSL 终止:</figcaption>
|
||||
|
||||

|
||||
<sup>使用 4 层负载均衡器在 Kubernetes 集群中安装 Rancher:Ingress Controller 的 SSL 终止</sup>
|
||||
|
||||
-3
@@ -56,9 +56,6 @@ PrometheusRule 用于定义指标或时间序列数据库查询触发告警的
|
||||
|
||||
- 路由和接收器也通过 Alertmanager Secret 存储在 Kubernetes API 中。当 Secret 更新时,Alertmanager 也会自动更新。请注意,路由仅通过标签发生(而不是通过注释等)。
|
||||
|
||||
<figcaption>数据如何流经 Monitoring 应用程序</figcaption>
|
||||
|
||||
|
||||
## 2. Prometheus 的工作原理
|
||||
|
||||
### 存储时间序列数据
|
||||
|
||||
-2
@@ -19,7 +19,5 @@ Rancher Server 的数据存储在 etcd 中。etcd 数据库可以在所有三个
|
||||
- Ingress Controller 会把 HTTP 重定向到 HTTPS,在 TCP/443 端口终结 SSL/TLS。
|
||||
- Ingress Controller 会把流量转发到 Rancher deployment 的 Pod 上的 TCP/80 端口。
|
||||
|
||||
<figcaption>使用 4 层负载均衡器在 Kubernetes 集群中安装 Rancher:Ingress Controller 的 SSL 终止:</figcaption>
|
||||
|
||||

|
||||
<sup>使用 4 层负载均衡器在 Kubernetes 集群中安装 Rancher:Ingress Controller 的 SSL 终止</sup>
|
||||
|
||||
-3
@@ -56,9 +56,6 @@ PrometheusRule 用于定义指标或时间序列数据库查询触发告警的
|
||||
|
||||
- 路由和接收器也通过 Alertmanager Secret 存储在 Kubernetes API 中。当 Secret 更新时,Alertmanager 也会自动更新。请注意,路由仅通过标签发生(而不是通过注释等)。
|
||||
|
||||
<figcaption>数据如何流经 Monitoring 应用程序</figcaption>
|
||||
|
||||
|
||||
## 2. Prometheus 的工作原理
|
||||
|
||||
### 存储时间序列数据
|
||||
|
||||
-2
@@ -19,7 +19,5 @@ Rancher Server 的数据存储在 etcd 中。etcd 数据库可以在所有三个
|
||||
- Ingress Controller 会把 HTTP 重定向到 HTTPS,在 TCP/443 端口终结 SSL/TLS。
|
||||
- Ingress Controller 会把流量转发到 Rancher deployment 的 Pod 上的 TCP/80 端口。
|
||||
|
||||
<figcaption>使用 4 层负载均衡器在 Kubernetes 集群中安装 Rancher:Ingress Controller 的 SSL 终止:</figcaption>
|
||||
|
||||

|
||||
<sup>使用 4 层负载均衡器在 Kubernetes 集群中安装 Rancher:Ingress Controller 的 SSL 终止</sup>
|
||||
|
||||
-3
@@ -56,9 +56,6 @@ PrometheusRule 用于定义指标或时间序列数据库查询触发告警的
|
||||
|
||||
- 路由和接收器也通过 Alertmanager Secret 存储在 Kubernetes API 中。当 Secret 更新时,Alertmanager 也会自动更新。请注意,路由仅通过标签发生(而不是通过注释等)。
|
||||
|
||||
<figcaption>数据如何流经 Monitoring 应用程序</figcaption>
|
||||
|
||||
|
||||
## 2. Prometheus 的工作原理
|
||||
|
||||
### 存储时间序列数据
|
||||
|
||||
-2
@@ -19,7 +19,5 @@ Rancher Server 的数据存储在 etcd 中。etcd 数据库可以在所有三个
|
||||
- Ingress Controller 会把 HTTP 重定向到 HTTPS,在 TCP/443 端口终结 SSL/TLS。
|
||||
- Ingress Controller 会把流量转发到 Rancher deployment 的 Pod 上的 TCP/80 端口。
|
||||
|
||||
<figcaption>使用 4 层负载均衡器在 Kubernetes 集群中安装 Rancher:Ingress Controller 的 SSL 终止:</figcaption>
|
||||
|
||||

|
||||
<sup>使用 4 层负载均衡器在 Kubernetes 集群中安装 Rancher:Ingress Controller 的 SSL 终止</sup>
|
||||
|
||||
-3
@@ -56,9 +56,6 @@ PrometheusRule 用于定义指标或时间序列数据库查询触发告警的
|
||||
|
||||
- 路由和接收器也通过 Alertmanager Secret 存储在 Kubernetes API 中。当 Secret 更新时,Alertmanager 也会自动更新。请注意,路由仅通过标签发生(而不是通过注释等)。
|
||||
|
||||
<figcaption>数据如何流经 Monitoring 应用程序</figcaption>
|
||||
|
||||
|
||||
## 2. Prometheus 的工作原理
|
||||
|
||||
### 存储时间序列数据
|
||||
|
||||
-2
@@ -19,7 +19,5 @@ Rancher Server 的数据存储在 etcd 中。etcd 数据库可以在所有三个
|
||||
- Ingress Controller 会把 HTTP 重定向到 HTTPS,在 TCP/443 端口终结 SSL/TLS。
|
||||
- Ingress Controller 会把流量转发到 Rancher deployment 的 Pod 上的 TCP/80 端口。
|
||||
|
||||
<figcaption>使用 4 层负载均衡器在 Kubernetes 集群中安装 Rancher:Ingress Controller 的 SSL 终止:</figcaption>
|
||||
|
||||

|
||||
<sup>使用 4 层负载均衡器在 Kubernetes 集群中安装 Rancher:Ingress Controller 的 SSL 终止</sup>
|
||||
|
||||
-3
@@ -56,9 +56,6 @@ PrometheusRule 用于定义指标或时间序列数据库查询触发告警的
|
||||
|
||||
- 路由和接收器也通过 Alertmanager Secret 存储在 Kubernetes API 中。当 Secret 更新时,Alertmanager 也会自动更新。请注意,路由仅通过标签发生(而不是通过注释等)。
|
||||
|
||||
<figcaption>数据如何流经 Monitoring 应用程序</figcaption>
|
||||
|
||||
|
||||
## 2. Prometheus 的工作原理
|
||||
|
||||
### 存储时间序列数据
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
<!-- releaseTask -->
|
||||
The following table summarizes different GitHub metrics to give you an idea of each project's popularity and activity levels. This data was collected in October 2024.
|
||||
The following table summarizes different GitHub metrics to give you an idea of each project's popularity and activity levels. This data was collected in December 2024.
|
||||
|
||||
| Provider | Project | Stars | Forks | Contributors |
|
||||
| ---- | ---- | ---- | ---- | ---- |
|
||||
| Canal | https://github.com/projectcalico/canal | 717 | 100 | 20 |
|
||||
| Flannel | https://github.com/flannel-io/flannel | 8.8k | 2.9k | 235 |
|
||||
| Calico | https://github.com/projectcalico/calico | 6.0k | 1.3k | 356 |
|
||||
| Weave | https://github.com/weaveworks/weave/ | 6.6k | 670 | 84 |
|
||||
| Cilium | https://github.com/cilium/cilium | 20.2k | 3k | 853 |
|
||||
| Canal | https://github.com/projectcalico/canal | 718 | 100 | 20 |
|
||||
| Flannel | https://github.com/flannel-io/flannel | 8.9k | 2.9k | 234 |
|
||||
| Calico | https://github.com/projectcalico/calico | 6.1k | 1.4k | 360 |
|
||||
| Weave | https://github.com/weaveworks/weave/ | 6.6k | 672 | 84 |
|
||||
| Cilium | https://github.com/cilium/cilium | 20.5k | 3k | 868 |
|
||||
|
||||
@@ -1306,7 +1306,6 @@ const sidebars = {
|
||||
"faq/dockershim",
|
||||
"faq/technical-items",
|
||||
"faq/security",
|
||||
"faq/telemetry",
|
||||
"faq/container-network-interface-providers",
|
||||
"faq/rancher-is-no-longer-needed",
|
||||
]
|
||||
|
||||
+44
-7
@@ -18,12 +18,12 @@ Here you can find links to supporting documentation for the current released ver
|
||||
<th>Community</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.10.0</b></td>
|
||||
<td><b>v2.10.1</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.10">Documentation</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.10.0">Release Notes</a></td>
|
||||
<td><center>N/A</center></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.10.1">Release Notes</a></td>
|
||||
<td><center>N/A</center></td>
|
||||
<td><center>✓</center></td>
|
||||
<td><center>✓</center></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
@@ -39,9 +39,9 @@ Here you can find links to supporting documentation for the current released ver
|
||||
<th>Community</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.9.4</b></td>
|
||||
<td><b>v2.9.5</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.9">Documentation</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.9.4">Release Notes</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.9.5">Release Notes</a></td>
|
||||
<td><center>N/A</center></td>
|
||||
<td><center>✓</center></td>
|
||||
<td><center>N/A</center></td>
|
||||
@@ -60,9 +60,9 @@ Here you can find links to supporting documentation for the current released ver
|
||||
<th>Community</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.8.10</b></td>
|
||||
<td><b>v2.8.11</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.8">Documentation</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.8.10">Release Notes</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.8.11">Release Notes</a></td>
|
||||
<td><center>N/A</center></td>
|
||||
<td><center>✓</center></td>
|
||||
<td><center>N/A</center></td>
|
||||
@@ -92,6 +92,27 @@ Here you can find links to supporting documentation for the current released ver
|
||||
|
||||
### Past Versions
|
||||
|
||||
Here you can find links to supporting documentation for previous versions of Rancher v2.10, and their availability for [Rancher Prime](/v2.10/getting-started/quick-start-guides/deploy-rancher-manager/prime) and the Community version of Rancher:
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th>Version</th>
|
||||
<th>Documentation</th>
|
||||
<th>Release Notes</th>
|
||||
<th>Support Matrix</th>
|
||||
<th>Prime</th>
|
||||
<th>Community</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.10.0</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.10">Documentation</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.10.0">Release Notes</a></td>
|
||||
<td><center>N/A</center></td>
|
||||
<td><center>N/A</center></td>
|
||||
<td><center>✓</center></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
Here you can find links to supporting documentation for previous versions of Rancher v2.9, and their availability for [Rancher Prime](/v2.9/getting-started/quick-start-guides/deploy-rancher-manager/prime) and the Community version of Rancher:
|
||||
|
||||
<table>
|
||||
@@ -103,6 +124,14 @@ Here you can find links to supporting documentation for previous versions of Ran
|
||||
<th>Prime</th>
|
||||
<th>Community</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.9.4</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.9">Documentation</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.9.4">Release Notes</a></td>
|
||||
<td><a href="https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/rancher-v2-9-4/">Support Matrix</a></td>
|
||||
<td><center>✓</center></td>
|
||||
<td><center>N/A</center></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.9.3</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.9">Documentation</a></td>
|
||||
@@ -150,6 +179,14 @@ Here you can find links to supporting documentation for previous versions of Ran
|
||||
<th>Prime</th>
|
||||
<th>Community</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.8.10</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.8">Documentation</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.8.10">Release Notes</a></td>
|
||||
<td><a href="https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/rancher-v2-8-10/">Support Matrix</a></td>
|
||||
<td><center>✓</center></td>
|
||||
<td><center>N/A</center></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.8.9</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.8">Documentation</a></td>
|
||||
|
||||
@@ -16,6 +16,7 @@ Rancher will publish deprecated features as part of the [release notes](https://
|
||||
|
||||
| Patch Version | Release Date |
|
||||
|---------------|---------------|
|
||||
| [2.10.1](https://github.com/rancher/rancher/releases/tag/v2.10.1) | Dec 19, 2024 |
|
||||
| [2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) | Nov 18, 2024 |
|
||||
|
||||
## What can I expect when a feature is marked for deprecation?
|
||||
|
||||
-2
@@ -23,7 +23,5 @@ For information on how Rancher works, regardless of the installation method, ref
|
||||
- The Ingress controller will redirect HTTP to HTTPS and terminate SSL/TLS on port TCP/443.
|
||||
- The Ingress controller will forward traffic to port TCP/80 on the pod in the Rancher deployment.
|
||||
|
||||
<figcaption>Kubernetes Rancher install with layer 4 load balancer, depicting SSL termination at ingress controllers</figcaption>
|
||||
|
||||

|
||||
<sup>Kubernetes Rancher install with Layer 4 load balancer (TCP), depicting SSL termination at ingress controllers</sup>
|
||||
|
||||
+137
-187
@@ -93,7 +93,7 @@ This [tutorial](https://aws.amazon.com/blogs/opensource/managing-eks-clusters-ra
|
||||
|
||||
## Minimum EKS Permissions
|
||||
|
||||
These are the minimum set of permissions necessary to access the full functionality of Rancher's EKS driver. You'll need additional permissions for Rancher to provision the `Service Role` and `VPC` resources. If you create these resources **before** you create the cluster, they'll be available when you configure the cluster.
|
||||
These are the minimum set of permissions necessary to access the full functionality of Rancher's EKS driver. These permissions allow Rancher to create the Service Role and Virtual Private Cloud (VPC) resources on the users' behalf, if necessary.
|
||||
|
||||
:::note
|
||||
In EKS v1.23 and above, you must use the out-of-tree drivers for EBS-backed volumes. You need [specific permissions](#ebs-csi-driver-addon-permissions) to enable this add-on.
|
||||
@@ -101,133 +101,66 @@ In EKS v1.23 and above, you must use the out-of-tree drivers for EBS-backed volu
|
||||
|
||||
Resource | Description
|
||||
---------|------------
|
||||
Service Role | Provides permissions that allow Kubernetes to manage resources on your behalf. Rancher can create the service role with the following [Service Role Permissions](#service-role-permissions).
|
||||
VPC | Provides isolated network resources utilised by EKS and worker nodes. Rancher can create the VPC resources with the following [VPC Permissions](#vpc-permissions).
|
||||
EBS CSI Driver add-on | Provides permissions that allow Kubernetes to interact with EBS and configure the cluster to enable the add-on (required for EKS v1.23 and above). Rancher can install the add-on with the following [EBS CSI Driver addon Permissions](#ebs-csi-driver-addon-permissions).
|
||||
|
||||
|
||||
Resource targeting uses `*` as the ARN of many of the resources created cannot be known before creating the EKS cluster in Rancher.
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "EC2Permissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:RunInstances",
|
||||
"ec2:RevokeSecurityGroupIngress",
|
||||
"ec2:RevokeSecurityGroupEgress",
|
||||
"ec2:DescribeInstanceTypes",
|
||||
"ec2:DescribeRegions",
|
||||
"ec2:DescribeVpcs",
|
||||
"ec2:DescribeTags",
|
||||
"ec2:DescribeSubnets",
|
||||
"ec2:DescribeSecurityGroups",
|
||||
"ec2:DescribeRouteTables",
|
||||
"ec2:DescribeLaunchTemplateVersions",
|
||||
"ec2:DescribeLaunchTemplates",
|
||||
"ec2:DescribeKeyPairs",
|
||||
"ec2:DescribeInternetGateways",
|
||||
"ec2:DescribeImages",
|
||||
"ec2:DescribeAvailabilityZones",
|
||||
"ec2:DescribeAccountAttributes",
|
||||
"ec2:DeleteTags",
|
||||
"ec2:DeleteLaunchTemplateVersions",
|
||||
"ec2:DeleteLaunchTemplate",
|
||||
"ec2:DeleteSecurityGroup",
|
||||
"ec2:DeleteKeyPair",
|
||||
"ec2:CreateTags",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateLaunchTemplateVersion",
|
||||
"ec2:CreateLaunchTemplate",
|
||||
"ec2:CreateKeyPair",
|
||||
"ec2:AuthorizeSecurityGroupIngress",
|
||||
"ec2:AuthorizeSecurityGroupEgress"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "CloudFormationPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"cloudformation:ListStacks",
|
||||
"cloudformation:ListStackResources",
|
||||
"cloudformation:DescribeStacks",
|
||||
"cloudformation:DescribeStackResources",
|
||||
"cloudformation:DescribeStackResource",
|
||||
"cloudformation:DeleteStack",
|
||||
"cloudformation:CreateStackSet",
|
||||
"cloudformation:CreateStack"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "IAMPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"iam:PassRole",
|
||||
"iam:ListRoles",
|
||||
"iam:ListRoleTags",
|
||||
"iam:ListInstanceProfilesForRole",
|
||||
"iam:ListInstanceProfiles",
|
||||
"iam:ListAttachedRolePolicies",
|
||||
"iam:GetRole",
|
||||
"iam:GetInstanceProfile",
|
||||
"iam:DetachRolePolicy",
|
||||
"iam:DeleteRole",
|
||||
"iam:CreateRole",
|
||||
"iam:AttachRolePolicy"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "KMSPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": "kms:ListKeys",
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "EKSPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"eks:UpdateNodegroupVersion",
|
||||
"eks:UpdateNodegroupConfig",
|
||||
"eks:UpdateClusterVersion",
|
||||
"eks:UpdateClusterConfig",
|
||||
"eks:UntagResource",
|
||||
"eks:TagResource",
|
||||
"eks:ListUpdates",
|
||||
"eks:ListTagsForResource",
|
||||
"eks:ListNodegroups",
|
||||
"eks:ListFargateProfiles",
|
||||
"eks:ListClusters",
|
||||
"eks:DescribeUpdate",
|
||||
"eks:DescribeNodegroup",
|
||||
"eks:DescribeFargateProfile",
|
||||
"eks:DescribeCluster",
|
||||
"eks:DeleteNodegroup",
|
||||
"eks:DeleteFargateProfile",
|
||||
"eks:DeleteCluster",
|
||||
"eks:CreateNodegroup",
|
||||
"eks:CreateFargateProfile",
|
||||
"eks:CreateCluster"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Service Role Permissions
|
||||
|
||||
These are permissions that are needed during EKS cluster creation, so Rancher can create a service role on the users' behalf.
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "EC2Permissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:AuthorizeSecurityGroupEgress",
|
||||
"ec2:AuthorizeSecurityGroupIngress",
|
||||
"ec2:CreateKeyPair",
|
||||
"ec2:CreateLaunchTemplate",
|
||||
"ec2:CreateLaunchTemplateVersion",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateTags",
|
||||
"ec2:DeleteKeyPair",
|
||||
"ec2:DeleteLaunchTemplate",
|
||||
"ec2:DeleteLaunchTemplateVersions",
|
||||
"ec2:DeleteSecurityGroup",
|
||||
"ec2:DeleteTags",
|
||||
"ec2:DescribeAccountAttributes",
|
||||
"ec2:DescribeAvailabilityZones",
|
||||
"ec2:DescribeImages",
|
||||
"ec2:DescribeInternetGateways",
|
||||
"ec2:DescribeInstanceTypes",
|
||||
"ec2:DescribeKeyPairs",
|
||||
"ec2:DescribeLaunchTemplateVersions",
|
||||
"ec2:DescribeLaunchTemplates",
|
||||
"ec2:DescribeRegions",
|
||||
"ec2:DescribeRouteTables",
|
||||
"ec2:DescribeSecurityGroups",
|
||||
"ec2:DescribeSubnets",
|
||||
"ec2:DescribeTags",
|
||||
"ec2:DescribeVpcs",
|
||||
"ec2:RevokeSecurityGroupEgress",
|
||||
"ec2:RevokeSecurityGroupIngress",
|
||||
"ec2:RunInstances"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "CloudFormationPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"cloudformation:CreateStack",
|
||||
"cloudformation:CreateStackSet",
|
||||
"cloudformation:DeleteStack",
|
||||
"cloudformation:DescribeStackResource",
|
||||
"cloudformation:DescribeStackResources",
|
||||
"cloudformation:DescribeStacks",
|
||||
"cloudformation:ListStackResources",
|
||||
"cloudformation:ListStacks"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "IAMPermissions",
|
||||
"Effect": "Allow",
|
||||
@@ -248,7 +181,70 @@ These are permissions that are needed during EKS cluster creation, so Rancher ca
|
||||
"iam:ListRoles",
|
||||
"iam:ListRoleTags",
|
||||
"iam:PassRole",
|
||||
"iam:RemoveRoleFromInstanceProfile"
|
||||
"iam:RemoveRoleFromInstanceProfile",
|
||||
"iam:TagRole"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "KMSPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": "kms:ListKeys",
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "EKSPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"eks:CreateCluster",
|
||||
"eks:CreateFargateProfile",
|
||||
"eks:CreateNodegroup",
|
||||
"eks:DeleteCluster",
|
||||
"eks:DeleteFargateProfile",
|
||||
"eks:DeleteNodegroup",
|
||||
"eks:DescribeAddon",
|
||||
"eks:DescribeCluster",
|
||||
"eks:DescribeFargateProfile",
|
||||
"eks:DescribeNodegroup",
|
||||
"eks:DescribeUpdate",
|
||||
"eks:ListClusters",
|
||||
"eks:ListFargateProfiles",
|
||||
"eks:ListNodegroups",
|
||||
"eks:ListTagsForResource",
|
||||
"eks:ListUpdates",
|
||||
"eks:TagResource",
|
||||
"eks:UntagResource",
|
||||
"eks:UpdateClusterConfig",
|
||||
"eks:UpdateClusterVersion",
|
||||
"eks:UpdateNodegroupConfig",
|
||||
"eks:UpdateNodegroupVersion"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "VPCPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:AssociateRouteTable",
|
||||
"ec2:AttachInternetGateway",
|
||||
"ec2:CreateInternetGateway",
|
||||
"ec2:CreateRoute",
|
||||
"ec2:CreateRouteTable",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateSubnet",
|
||||
"ec2:CreateVpc",
|
||||
"ec2:DeleteInternetGateway",
|
||||
"ec2:DeleteRoute",
|
||||
"ec2:DeleteRouteTable",
|
||||
"ec2:DeleteSubnet",
|
||||
"ec2:DeleteTags",
|
||||
"ec2:DeleteVpc",
|
||||
"ec2:DescribeVpcs",
|
||||
"ec2:DetachInternetGateway",
|
||||
"ec2:DisassociateRouteTable",
|
||||
"ec2:ModifySubnetAttribute",
|
||||
"ec2:ModifyVpcAttribute",
|
||||
"ec2:ReplaceRoute"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
@@ -281,79 +277,33 @@ arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
|
||||
arn:aws:iam::aws:policy/AmazonEKSServicePolicy
|
||||
```
|
||||
|
||||
### VPC Permissions
|
||||
|
||||
These are permissions that are needed by Rancher to create a Virtual Private Cloud (VPC) and associated resources.
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "VPCPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:ReplaceRoute",
|
||||
"ec2:ModifyVpcAttribute",
|
||||
"ec2:ModifySubnetAttribute",
|
||||
"ec2:DisassociateRouteTable",
|
||||
"ec2:DetachInternetGateway",
|
||||
"ec2:DescribeVpcs",
|
||||
"ec2:DeleteVpc",
|
||||
"ec2:DeleteTags",
|
||||
"ec2:DeleteSubnet",
|
||||
"ec2:DeleteRouteTable",
|
||||
"ec2:DeleteRoute",
|
||||
"ec2:DeleteInternetGateway",
|
||||
"ec2:CreateVpc",
|
||||
"ec2:CreateSubnet",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateRouteTable",
|
||||
"ec2:CreateRoute",
|
||||
"ec2:CreateInternetGateway",
|
||||
"ec2:AttachInternetGateway",
|
||||
"ec2:AssociateRouteTable"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### EBS CSI Driver addon Permissions
|
||||
|
||||
The following are the required permissions for installing the Amazon EBS CSI Driver add-on.
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"iam:GetRole",
|
||||
"eks:DescribeAddonConfiguration",
|
||||
"eks:UpdateAddon",
|
||||
"eks:ListAddons",
|
||||
"iam:CreateRole",
|
||||
"iam:AttachRolePolicy",
|
||||
"eks:DescribeAddon",
|
||||
"iam:CreateOpenIDConnectProvider",
|
||||
"iam:PassRole",
|
||||
"eks:DescribeIdentityProviderConfig",
|
||||
"eks:DeleteAddon",
|
||||
"iam:ListOpenIDConnectProviders",
|
||||
"iam:ListAttachedRolePolicies",
|
||||
"eks:CreateAddon",
|
||||
"eks:DescribeCluster",
|
||||
"eks:DescribeAddonVersions",
|
||||
"sts:AssumeRoleWithWebIdentity",
|
||||
"eks:AssociateIdentityProviderConfig",
|
||||
"eks:ListIdentityProviderConfigs"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"eks:AssociateIdentityProviderConfig",
|
||||
"eks:CreateAddon",
|
||||
"eks:DeleteAddon",
|
||||
"eks:DescribeAddonConfiguration",
|
||||
"eks:DescribeAddonVersions",
|
||||
"eks:DescribeIdentityProviderConfig",
|
||||
"eks:ListAddons",
|
||||
"eks:ListIdentityProviderConfigs",
|
||||
"eks:UpdateAddon",
|
||||
"iam:CreateOpenIDConnectProvider",
|
||||
"iam:ListOpenIDConnectProviders",
|
||||
"sts:AssumeRoleWithWebIdentity"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
+1
@@ -19,6 +19,7 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
|
||||
|
||||
| Rancher Version | Adapter Version |
|
||||
|-----------------|------------------|
|
||||
| v2.10.1 | v105.0.0+up5.0.1 |
|
||||
| v2.10.0 | v105.0.0+up5.0.1 |
|
||||
|
||||
### 1. Gain Access to the Local Cluster
|
||||
|
||||
-3
@@ -61,9 +61,6 @@ Once Prometheus determines that an alert needs to be fired, alerts are forwarded
|
||||
|
||||
- Routes and receivers are also stored in the Kubernetes API via the Alertmanager Secret. When the Secret is updated, Alertmanager is also updated automatically. Note that routing occurs via labels only (not via annotations, etc.).
|
||||
|
||||
<figcaption>How data flows through the monitoring application:</figcaption>
|
||||
|
||||
|
||||
## 2. How Prometheus Works
|
||||
|
||||
### Storing Time Series Data
|
||||
|
||||
+1
-1
@@ -139,5 +139,5 @@ At high scale, Rancher transfers more data from the upstream cluster to UI compo
|
||||
For best performance, ensure that the host running the hardware meets these requirements:
|
||||
- 2020 i5 10th generation Intel (4 cores) or equivalent
|
||||
- 8 GB RAM
|
||||
- Total network bandwith to the upstream cluster: 72 Mb/s (equivalent to a single 802.11n Wi-Fi 4 link stream, ~8 MB/s http download throughput)
|
||||
- Total network bandwidth to the upstream cluster: 72 Mb/s (equivalent to a single 802.11n Wi-Fi 4 link stream, ~8 MB/s http download throughput)
|
||||
- Round-trip time (ping time) from browser to upstream cluster: 150 ms or less
|
||||
|
||||
@@ -20,6 +20,7 @@ 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.10.1 | v0.6.2 | ✓ | ✓ |
|
||||
| v2.10.0 | v0.6.1 | ✗ | ✓ |
|
||||
|
||||
## Why Do We Need It?
|
||||
|
||||
+5
-2
@@ -8,10 +8,13 @@ title: Continuous Delivery with Fleet
|
||||
|
||||
_Available as of Rancher v2.5_
|
||||
|
||||
Continuous Delivery with Fleet is GitOps at scale. Fleet is designed to manage up to a million clusters. It’s also lightweight enough that it works great for a [single cluster](https://fleet.rancher.io/installation#default-install) too, but it really shines when you get to a [large scale](https://fleet.rancher.io/installation#configuration-for-multi-cluster). By large scale we mean either a lot of clusters, a lot of deployments, or a lot of teams in a single organization.
|
||||
## What is Continuous Delivery with Fleet?
|
||||
|
||||
Fleet is a separate project from Rancher, and can be installed on any Kubernetes cluster with Helm.
|
||||
Continuous Delivery is Rancher's GitOps functionality, which is provided via integration with Fleet.
|
||||
|
||||
- *Cluster engine*: Fleet is a container management and deployment engine designed to offer users more control on the local cluster and constant monitoring through GitOps. Fleet focuses not only on the ability to scale, but it also gives users a high degree of control and visibility to monitor exactly what is installed on the cluster.
|
||||
|
||||
- *Deployment management*: Fleet can manage deployments from git of raw Kubernetes YAML, Helm charts, Kustomize, or any combination of the three. Regardless of the source, all resources are dynamically turned into Helm charts, and Helm is used as the engine to deploy all resources in the cluster. As a result, users can enjoy a high degree of control, consistency, and auditability of their clusters.
|
||||
|
||||
## Architecture
|
||||
|
||||
|
||||
-3
@@ -61,9 +61,6 @@ Once Prometheus determines that an alert needs to be fired, alerts are forwarded
|
||||
|
||||
- Routes and receivers are also stored in the Kubernetes API via the Alertmanager Secret. When the Secret is updated, Alertmanager is also updated automatically. Note that routing occurs via labels only (not via annotations, etc.).
|
||||
|
||||
<figcaption>How data flows through the monitoring application:</figcaption>
|
||||
|
||||
|
||||
## 2. How Prometheus Works
|
||||
|
||||
### Storing Time Series Data
|
||||
|
||||
+5
-2
@@ -8,10 +8,13 @@ title: Fleet - GitOps at Scale
|
||||
|
||||
_Available as of Rancher v2.5_
|
||||
|
||||
Fleet is GitOps at scale. Fleet is designed to manage up to a million clusters. It's also lightweight enough that it works great for a [single cluster](https://fleet.rancher.io/installation#default-install) too, but it really shines when you get to a [large scale.](https://fleet.rancher.io/installation#configuration-for-multi-cluster) By large scale we mean either a lot of clusters, a lot of deployments, or a lot of teams in a single organization.
|
||||
## What is Continuous Delivery with Fleet?
|
||||
|
||||
Fleet is a separate project from Rancher, and can be installed on any Kubernetes cluster with Helm.
|
||||
Continuous Delivery is Rancher's GitOps functionality, which is provided via integration with Fleet.
|
||||
|
||||
- *Cluster engine*: Fleet is a container management and deployment engine designed to offer users more control on the local cluster and constant monitoring through GitOps. Fleet focuses not only on the ability to scale, but it also gives users a high degree of control and visibility to monitor exactly what is installed on the cluster.
|
||||
|
||||
- *Deployment management*: Fleet can manage deployments from git of raw Kubernetes YAML, Helm charts, Kustomize, or any combination of the three. Regardless of the source, all resources are dynamically turned into Helm charts, and Helm is used as the engine to deploy all resources in the cluster. As a result, users can enjoy a high degree of control, consistency, and auditability of their clusters.
|
||||
|
||||
## Architecture
|
||||
|
||||
|
||||
-2
@@ -23,7 +23,5 @@ For information on how Rancher works, regardless of the installation method, ref
|
||||
- The Ingress controller will redirect HTTP to HTTPS and terminate SSL/TLS on port TCP/443.
|
||||
- The Ingress controller will forward traffic to port TCP/80 on the pod in the Rancher deployment.
|
||||
|
||||
<figcaption>Kubernetes Rancher install with layer 4 load balancer, depicting SSL termination at ingress controllers</figcaption>
|
||||
|
||||

|
||||
<sup>Kubernetes Rancher install with Layer 4 load balancer (TCP), depicting SSL termination at ingress controllers</sup>
|
||||
|
||||
+5
-2
@@ -6,10 +6,13 @@ title: Continuous Delivery with Fleet
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet"/>
|
||||
</head>
|
||||
|
||||
Continuous Delivery with Fleet is GitOps at scale. Fleet is designed to manage up to a million clusters. It's also lightweight enough that it works great for a [single cluster](https://fleet.rancher.io/installation#default-install) too, but it really shines when you get to a [large scale.](https://fleet.rancher.io/installation#configuration-for-multi-cluster) By large scale we mean either a lot of clusters, a lot of deployments, or a lot of teams in a single organization.
|
||||
## What is Continuous Delivery with Fleet?
|
||||
|
||||
Fleet is a separate project from Rancher, and can be installed on any Kubernetes cluster with Helm.
|
||||
Continuous Delivery is Rancher's GitOps functionality, which is provided via integration with Fleet.
|
||||
|
||||
- *Cluster engine*: Fleet is a container management and deployment engine designed to offer users more control on the local cluster and constant monitoring through GitOps. Fleet focuses not only on the ability to scale, but it also gives users a high degree of control and visibility to monitor exactly what is installed on the cluster.
|
||||
|
||||
- *Deployment management*: Fleet can manage deployments from git of raw Kubernetes YAML, Helm charts, Kustomize, or any combination of the three. Regardless of the source, all resources are dynamically turned into Helm charts, and Helm is used as the engine to deploy all resources in the cluster. As a result, users can enjoy a high degree of control, consistency, and auditability of their clusters.
|
||||
|
||||
## Architecture
|
||||
|
||||
|
||||
-2
@@ -23,7 +23,5 @@ For information on how Rancher works, regardless of the installation method, ref
|
||||
- The Ingress controller will redirect HTTP to HTTPS and terminate SSL/TLS on port TCP/443.
|
||||
- The Ingress controller will forward traffic to port TCP/80 on the pod in the Rancher deployment.
|
||||
|
||||
<figcaption>Kubernetes Rancher install with layer 4 load balancer, depicting SSL termination at ingress controllers</figcaption>
|
||||
|
||||

|
||||
<sup>Kubernetes Rancher install with Layer 4 load balancer (TCP), depicting SSL termination at ingress controllers</sup>
|
||||
|
||||
+5
-2
@@ -6,10 +6,13 @@ title: Continuous Delivery with Fleet
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet"/>
|
||||
</head>
|
||||
|
||||
Continuous Delivery with Fleet is GitOps at scale. Fleet is designed to manage up to a million clusters. It’s also lightweight enough that it works great for a [single cluster](https://fleet.rancher.io/installation#default-install) too, but it really shines when you get to a [large scale](https://fleet.rancher.io/installation#configuration-for-multi-cluster). By large scale we mean either a lot of clusters, a lot of deployments, or a lot of teams in a single organization.
|
||||
## What is Continuous Delivery with Fleet?
|
||||
|
||||
Fleet is a separate project from Rancher, and can be installed on any Kubernetes cluster with Helm.
|
||||
Continuous Delivery is Rancher's GitOps functionality, which is provided via integration with Fleet.
|
||||
|
||||
- *Cluster engine*: Fleet is a container management and deployment engine designed to offer users more control on the local cluster and constant monitoring through GitOps. Fleet focuses not only on the ability to scale, but it also gives users a high degree of control and visibility to monitor exactly what is installed on the cluster.
|
||||
|
||||
- *Deployment management*: Fleet can manage deployments from git of raw Kubernetes YAML, Helm charts, Kustomize, or any combination of the three. Regardless of the source, all resources are dynamically turned into Helm charts, and Helm is used as the engine to deploy all resources in the cluster. As a result, users can enjoy a high degree of control, consistency, and auditability of their clusters.
|
||||
|
||||
## Architecture
|
||||
|
||||
|
||||
-3
@@ -61,9 +61,6 @@ Once Prometheus determines that an alert needs to be fired, alerts are forwarded
|
||||
|
||||
- Routes and receivers are also stored in the Kubernetes API via the Alertmanager Secret. When the Secret is updated, Alertmanager is also updated automatically. Note that routing occurs via labels only (not via annotations, etc.).
|
||||
|
||||
<figcaption>How data flows through the monitoring application:</figcaption>
|
||||
|
||||
|
||||
## 2. How Prometheus Works
|
||||
|
||||
### Storing Time Series Data
|
||||
|
||||
+1
-1
@@ -139,5 +139,5 @@ At high scale, Rancher transfers more data from the upstream cluster to UI compo
|
||||
For best performance, ensure that the host running the hardware meets these requirements:
|
||||
- 2020 i5 10th generation Intel (4 cores) or equivalent
|
||||
- 8 GB RAM
|
||||
- Total network bandwith to the upstream cluster: 72 Mb/s (equivalent to a single 802.11n Wi-Fi 4 link stream, ~8 MB/s http download throughput)
|
||||
- Total network bandwidth to the upstream cluster: 72 Mb/s (equivalent to a single 802.11n Wi-Fi 4 link stream, ~8 MB/s http download throughput)
|
||||
- Round-trip time (ping time) from browser to upstream cluster: 150 ms or less
|
||||
|
||||
-2
@@ -23,7 +23,5 @@ For information on how Rancher works, regardless of the installation method, ref
|
||||
- The Ingress controller will redirect HTTP to HTTPS and terminate SSL/TLS on port TCP/443.
|
||||
- The Ingress controller will forward traffic to port TCP/80 on the pod in the Rancher deployment.
|
||||
|
||||
<figcaption>Kubernetes Rancher install with layer 4 load balancer, depicting SSL termination at ingress controllers</figcaption>
|
||||
|
||||

|
||||
<sup>Kubernetes Rancher install with Layer 4 load balancer (TCP), depicting SSL termination at ingress controllers</sup>
|
||||
|
||||
+5
-2
@@ -6,10 +6,13 @@ title: Continuous Delivery with Fleet
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet"/>
|
||||
</head>
|
||||
|
||||
Continuous Delivery with Fleet is GitOps at scale. Fleet is designed to manage up to a million clusters. It’s also lightweight enough that it works great for a [single cluster](https://fleet.rancher.io/installation#default-install) too, but it really shines when you get to a [large scale](https://fleet.rancher.io/installation#configuration-for-multi-cluster). By large scale we mean either a lot of clusters, a lot of deployments, or a lot of teams in a single organization.
|
||||
## What is Continuous Delivery with Fleet?
|
||||
|
||||
Fleet is a separate project from Rancher, and can be installed on any Kubernetes cluster with Helm.
|
||||
Continuous Delivery is Rancher's GitOps functionality, which is provided via integration with Fleet.
|
||||
|
||||
- *Cluster engine*: Fleet is a container management and deployment engine designed to offer users more control on the local cluster and constant monitoring through GitOps. Fleet focuses not only on the ability to scale, but it also gives users a high degree of control and visibility to monitor exactly what is installed on the cluster.
|
||||
|
||||
- *Deployment management*: Fleet can manage deployments from git of raw Kubernetes YAML, Helm charts, Kustomize, or any combination of the three. Regardless of the source, all resources are dynamically turned into Helm charts, and Helm is used as the engine to deploy all resources in the cluster. As a result, users can enjoy a high degree of control, consistency, and auditability of their clusters.
|
||||
|
||||
## Architecture
|
||||
|
||||
|
||||
-3
@@ -61,9 +61,6 @@ Once Prometheus determines that an alert needs to be fired, alerts are forwarded
|
||||
|
||||
- Routes and receivers are also stored in the Kubernetes API via the Alertmanager Secret. When the Secret is updated, Alertmanager is also updated automatically. Note that routing occurs via labels only (not via annotations, etc.).
|
||||
|
||||
<figcaption>How data flows through the monitoring application:</figcaption>
|
||||
|
||||
|
||||
## 2. How Prometheus Works
|
||||
|
||||
### Storing Time Series Data
|
||||
|
||||
+1
-1
@@ -139,5 +139,5 @@ At high scale, Rancher transfers more data from the upstream cluster to UI compo
|
||||
For best performance, ensure that the host running the hardware meets these requirements:
|
||||
- 2020 i5 10th generation Intel (4 cores) or equivalent
|
||||
- 8 GB RAM
|
||||
- Total network bandwith to the upstream cluster: 72 Mb/s (equivalent to a single 802.11n Wi-Fi 4 link stream, ~8 MB/s http download throughput)
|
||||
- Total network bandwidth to the upstream cluster: 72 Mb/s (equivalent to a single 802.11n Wi-Fi 4 link stream, ~8 MB/s http download throughput)
|
||||
- Round-trip time (ping time) from browser to upstream cluster: 150 ms or less
|
||||
|
||||
+4
@@ -10,6 +10,10 @@ Rancher is committed to informing the community of security issues in our produc
|
||||
|
||||
| ID | Description | Date | Resolution |
|
||||
|----|-------------|------|------------|
|
||||
[CVE-2024-52282](https://github.com/rancher/rancher/security/advisories/GHSA-9c5p-35gj-jqp4) | A medium severity vulnerability was discovered within Rancher Manager whereby applications installed via Rancher Manager Apps Catalog store their Helm values directly into the Apps Custom Resource Definition, resulting in any users with GET access to it to be able to read any sensitive information that are contained within the Apps’ values. Additionally, the same information leaks into auditing logs when the audit level is set to equal or above 2. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 19 Nov 2024 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.8.10](https://github.com/rancher/rancher/releases/tag/v2.8.10). |
|
||||
[CVE-2024-22036](https://github.com/rancher/rancher/security/advisories/GHSA-h99m-6755-rgwc) | A critical severity vulnerability was discovered within Rancher where a cluster or node driver can be used to escape the `chroot` jail and gain root access to the Rancher container itself. In production environments, further privilege escalation is possible based on living off the land within the Rancher container itself. For test and development environments, based on a –privileged Docker container, it is possible to escape the Docker container and gain execution access on the host system. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3), [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) and [v2.7.16](https://github.com/rancher/rancher/releases/tag/v2.7.16) |
|
||||
[CVE-2023-32197](https://github.com/rancher/rancher/security/advisories/GHSA-7h8m-pvw3-5gh4) | A critical severity vulnerability was discovered whereby Rancher Manager deployments containing Windows nodes have weak Access Control Lists (ACL), allowing `BUILTIN\Users` or `NT AUTHORITY\Authenticated Users` to view or edit sensitive files which could lead to privilege escalation. This vulnerability is exclusive to deployments that contain Windows nodes. Linux-only environments are not affected by it. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) |
|
||||
[CVE-2022-45157](https://github.com/rancher/rancher/security/advisories/GHSA-xj7w-r753-vj8v) | A critical severity vulnerability was discovered in the way that Rancher stores vSphere's CPI (Cloud Provider Interface) and CSI (Container Storage Interface) credentials used to deploy clusters through the vSphere cloud provider. This issue leads to the vSphere CPI and CSI passwords being stored in a plaintext object inside Rancher. This vulnerability is only applicable to users that deploy clusters in vSphere environments. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) |
|
||||
[CVE-2024-22030](https://github.com/rancher/rancher/security/advisories/GHSA-h4h5-9833-v2p4) | A high severity vulnerability was discovered in Rancher's agents that under very specific circumstances allows a malicious actor to take over existing Rancher nodes. The attacker needs to have control of an expired domain or execute a DNS spoofing/hijacking attack against the domain in order to exploit this vulnerability. The targeted domain is the one used as the Rancher URL (the `server-url` of the Rancher cluster). | 19 Sep 2024 | Rancher [v2.9.2](https://github.com/rancher/rancher/releases/tag/v2.9.2), [v2.8.8](https://github.com/rancher/rancher/releases/tag/v2.8.8) and [v2.7.15](https://github.com/rancher/rancher/releases/tag/v2.7.15) |
|
||||
| [CVE-2024-22032](https://github.com/rancher/rancher/security/advisories/GHSA-q6c7-56cq-g2wm) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where custom secrets encryption configurations are stored in plaintext under the clusters `AppliedSpec`. This also causes clusters to continuously reconcile, as the `AppliedSpec` would never match the desired cluster `Spec`. The stored information contains the encryption configuration for secrets within etcd, and could potentially expose sensitive data if the etcd database was exposed directly. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
| [CVE-2023-32196](https://github.com/rancher/rancher/security/advisories/GHSA-64jq-m7rq-768h) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where the webhook rule resolver ignores rules from a `ClusterRole` for an external `RoleTemplate` set with `.context=project` or `.context=""`. This allows a user to create an external `ClusterRole` with `.context=project` or `.context=""`, depending on the use of the new feature flag `external-rules` and backing `ClusterRole`. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
|
||||
@@ -16,6 +16,7 @@ Rancher will publish deprecated features as part of the [release notes](https://
|
||||
|
||||
| Patch Version | Release Date |
|
||||
|---------------|---------------|
|
||||
| [2.8.11](https://github.com/rancher/rancher/releases/tag/v2.8.11) | Dec 18, 2024 |
|
||||
| [2.8.10](https://github.com/rancher/rancher/releases/tag/v2.8.10) | Nov 18, 2024 |
|
||||
| [2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) | Oct 24, 2024 |
|
||||
| [2.8.8](https://github.com/rancher/rancher/releases/tag/v2.8.8) | Sep 19, 2024 |
|
||||
|
||||
-2
@@ -23,7 +23,5 @@ For information on how Rancher works, regardless of the installation method, ref
|
||||
- The Ingress controller will redirect HTTP to HTTPS and terminate SSL/TLS on port TCP/443.
|
||||
- The Ingress controller will forward traffic to port TCP/80 on the pod in the Rancher deployment.
|
||||
|
||||
<figcaption>Kubernetes Rancher install with layer 4 load balancer, depicting SSL termination at ingress controllers</figcaption>
|
||||
|
||||

|
||||
<sup>Kubernetes Rancher install with Layer 4 load balancer (TCP), depicting SSL termination at ingress controllers</sup>
|
||||
|
||||
+129
-127
@@ -105,113 +105,114 @@ Resource targeting uses `*` as the ARN of many of the resources created cannot b
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "EC2Permissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:RunInstances",
|
||||
"ec2:RevokeSecurityGroupIngress",
|
||||
"ec2:RevokeSecurityGroupEgress",
|
||||
"ec2:DescribeInstanceTypes",
|
||||
"ec2:DescribeRegions",
|
||||
"ec2:DescribeVpcs",
|
||||
"ec2:DescribeTags",
|
||||
"ec2:DescribeSubnets",
|
||||
"ec2:DescribeSecurityGroups",
|
||||
"ec2:DescribeRouteTables",
|
||||
"ec2:DescribeLaunchTemplateVersions",
|
||||
"ec2:DescribeLaunchTemplates",
|
||||
"ec2:DescribeKeyPairs",
|
||||
"ec2:DescribeInternetGateways",
|
||||
"ec2:DescribeImages",
|
||||
"ec2:DescribeAvailabilityZones",
|
||||
"ec2:DescribeAccountAttributes",
|
||||
"ec2:DeleteTags",
|
||||
"ec2:DeleteLaunchTemplateVersions",
|
||||
"ec2:DeleteLaunchTemplate",
|
||||
"ec2:DeleteSecurityGroup",
|
||||
"ec2:DeleteKeyPair",
|
||||
"ec2:CreateTags",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateLaunchTemplateVersion",
|
||||
"ec2:CreateLaunchTemplate",
|
||||
"ec2:CreateKeyPair",
|
||||
"ec2:AuthorizeSecurityGroupIngress",
|
||||
"ec2:AuthorizeSecurityGroupEgress"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "CloudFormationPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"cloudformation:ListStacks",
|
||||
"cloudformation:ListStackResources",
|
||||
"cloudformation:DescribeStacks",
|
||||
"cloudformation:DescribeStackResources",
|
||||
"cloudformation:DescribeStackResource",
|
||||
"cloudformation:DeleteStack",
|
||||
"cloudformation:CreateStackSet",
|
||||
"cloudformation:CreateStack"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "IAMPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"iam:PassRole",
|
||||
"iam:ListRoles",
|
||||
"iam:ListRoleTags",
|
||||
"iam:ListInstanceProfilesForRole",
|
||||
"iam:ListInstanceProfiles",
|
||||
"iam:ListAttachedRolePolicies",
|
||||
"iam:GetRole",
|
||||
"iam:GetInstanceProfile",
|
||||
"iam:DetachRolePolicy",
|
||||
"iam:DeleteRole",
|
||||
"iam:CreateRole",
|
||||
"iam:AttachRolePolicy"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "KMSPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": "kms:ListKeys",
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "EKSPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"eks:UpdateNodegroupVersion",
|
||||
"eks:UpdateNodegroupConfig",
|
||||
"eks:UpdateClusterVersion",
|
||||
"eks:UpdateClusterConfig",
|
||||
"eks:UntagResource",
|
||||
"eks:TagResource",
|
||||
"eks:ListUpdates",
|
||||
"eks:ListTagsForResource",
|
||||
"eks:ListNodegroups",
|
||||
"eks:ListFargateProfiles",
|
||||
"eks:ListClusters",
|
||||
"eks:DescribeUpdate",
|
||||
"eks:DescribeNodegroup",
|
||||
"eks:DescribeFargateProfile",
|
||||
"eks:DescribeCluster",
|
||||
"eks:DeleteNodegroup",
|
||||
"eks:DeleteFargateProfile",
|
||||
"eks:DeleteCluster",
|
||||
"eks:CreateNodegroup",
|
||||
"eks:CreateFargateProfile",
|
||||
"eks:CreateCluster"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "EC2Permissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:AuthorizeSecurityGroupEgress",
|
||||
"ec2:AuthorizeSecurityGroupIngress",
|
||||
"ec2:CreateKeyPair",
|
||||
"ec2:CreateLaunchTemplate",
|
||||
"ec2:CreateLaunchTemplateVersion",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateTags",
|
||||
"ec2:DeleteKeyPair",
|
||||
"ec2:DeleteLaunchTemplate",
|
||||
"ec2:DeleteLaunchTemplateVersions",
|
||||
"ec2:DeleteSecurityGroup",
|
||||
"ec2:DeleteTags",
|
||||
"ec2:DescribeAccountAttributes",
|
||||
"ec2:DescribeAvailabilityZones",
|
||||
"ec2:DescribeImages",
|
||||
"ec2:DescribeInternetGateways",
|
||||
"ec2:DescribeInstanceTypes",
|
||||
"ec2:DescribeKeyPairs",
|
||||
"ec2:DescribeLaunchTemplateVersions",
|
||||
"ec2:DescribeLaunchTemplates",
|
||||
"ec2:DescribeRegions",
|
||||
"ec2:DescribeRouteTables",
|
||||
"ec2:DescribeSecurityGroups",
|
||||
"ec2:DescribeSubnets",
|
||||
"ec2:DescribeTags",
|
||||
"ec2:DescribeVpcs",
|
||||
"ec2:RevokeSecurityGroupEgress",
|
||||
"ec2:RevokeSecurityGroupIngress",
|
||||
"ec2:RunInstances"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "CloudFormationPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"cloudformation:CreateStack",
|
||||
"cloudformation:CreateStackSet",
|
||||
"cloudformation:DeleteStack",
|
||||
"cloudformation:DescribeStackResource",
|
||||
"cloudformation:DescribeStackResources",
|
||||
"cloudformation:DescribeStacks",
|
||||
"cloudformation:ListStackResources",
|
||||
"cloudformation:ListStacks"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "IAMPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"iam:AttachRolePolicy",
|
||||
"iam:CreateRole",
|
||||
"iam:DetachRolePolicy",
|
||||
"iam:DeleteRole",
|
||||
"iam:GetRole",
|
||||
"iam:GetInstanceProfile",
|
||||
"iam:ListAttachedRolePolicies",
|
||||
"iam:ListInstanceProfilesForRole",
|
||||
"iam:ListInstanceProfiles",
|
||||
"iam:ListRoles",
|
||||
"iam:ListRoleTags",
|
||||
"iam:PassRole"
|
||||
"iam:TagRole"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "KMSPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": "kms:ListKeys",
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "EKSPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"eks:CreateCluster",
|
||||
"eks:CreateFargateProfile",
|
||||
"eks:CreateNodegroup",
|
||||
"eks:DeleteCluster",
|
||||
"eks:DeleteFargateProfile",
|
||||
"eks:DeleteNodegroup",
|
||||
"eks:DescribeCluster",
|
||||
"eks:DescribeFargateProfile",
|
||||
"eks:DescribeNodegroup",
|
||||
"eks:DescribeUpdate",
|
||||
"eks:ListClusters",
|
||||
"eks:ListFargateProfiles",
|
||||
"eks:ListNodegroups",
|
||||
"eks:ListTagsForResource",
|
||||
"eks:ListUpdates",
|
||||
"eks:TagResource",
|
||||
"eks:UntagResource",
|
||||
"eks:UpdateClusterConfig",
|
||||
"eks:UpdateClusterVersion",
|
||||
"eks:UpdateNodegroupConfig",
|
||||
"eks:UpdateNodegroupVersion"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
@@ -243,7 +244,8 @@ These are permissions that are needed during EKS cluster creation, so Rancher ca
|
||||
"iam:ListRoles",
|
||||
"iam:ListRoleTags",
|
||||
"iam:PassRole",
|
||||
"iam:RemoveRoleFromInstanceProfile"
|
||||
"iam:RemoveRoleFromInstanceProfile",
|
||||
"iam:TagRole"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
@@ -288,26 +290,26 @@ These are permissions that are needed by Rancher to create a Virtual Private Clo
|
||||
"Sid": "VPCPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:ReplaceRoute",
|
||||
"ec2:ModifyVpcAttribute",
|
||||
"ec2:ModifySubnetAttribute",
|
||||
"ec2:DisassociateRouteTable",
|
||||
"ec2:DetachInternetGateway",
|
||||
"ec2:DescribeVpcs",
|
||||
"ec2:DeleteVpc",
|
||||
"ec2:DeleteTags",
|
||||
"ec2:DeleteSubnet",
|
||||
"ec2:DeleteRouteTable",
|
||||
"ec2:DeleteRoute",
|
||||
"ec2:DeleteInternetGateway",
|
||||
"ec2:CreateVpc",
|
||||
"ec2:CreateSubnet",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateRouteTable",
|
||||
"ec2:CreateRoute",
|
||||
"ec2:CreateInternetGateway",
|
||||
"ec2:AssociateRouteTable",
|
||||
"ec2:AttachInternetGateway",
|
||||
"ec2:AssociateRouteTable"
|
||||
"ec2:CreateInternetGateway",
|
||||
"ec2:CreateRoute",
|
||||
"ec2:CreateRouteTable",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateSubnet",
|
||||
"ec2:CreateVpc",
|
||||
"ec2:DeleteInternetGateway",
|
||||
"ec2:DeleteRoute",
|
||||
"ec2:DeleteRouteTable",
|
||||
"ec2:DeleteSubnet",
|
||||
"ec2:DeleteTags",
|
||||
"ec2:DeleteVpc",
|
||||
"ec2:DescribeVpcs",
|
||||
"ec2:DetachInternetGateway",
|
||||
"ec2:DisassociateRouteTable",
|
||||
"ec2:ModifySubnetAttribute",
|
||||
"ec2:ModifyVpcAttribute",
|
||||
"ec2:ReplaceRoute"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
|
||||
+1
@@ -19,6 +19,7 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
|
||||
|
||||
| Rancher Version | Adapter Version |
|
||||
|-----------------|------------------|
|
||||
| v2.8.11 | v103.0.1+up3.0.1 |
|
||||
| v2.8.10 | v103.0.1+up3.0.1 |
|
||||
| v2.8.9 | v103.0.1+up3.0.1 |
|
||||
| v2.8.8 | v103.0.1+up3.0.1 |
|
||||
|
||||
@@ -6,10 +6,13 @@ title: Overview
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/fleet/overview"/>
|
||||
</head>
|
||||
|
||||
Continuous Delivery with Fleet is GitOps at scale. Fleet is designed to manage up to a million clusters. It’s also lightweight enough that it works great for a [single cluster](https://fleet.rancher.io/installation#default-install) too, but it really shines when you get to a [large scale](https://fleet.rancher.io/installation#configuration-for-multi-cluster). By large scale we mean either a lot of clusters, a lot of deployments, or a lot of teams in a single organization.
|
||||
## What is Continuous Delivery with Fleet?
|
||||
|
||||
Fleet is a separate project from Rancher, and can be installed on any Kubernetes cluster with Helm.
|
||||
Continuous Delivery is Rancher's GitOps functionality, which is provided via integration with Fleet.
|
||||
|
||||
- *Cluster engine*: Fleet is a container management and deployment engine designed to offer users more control on the local cluster and constant monitoring through GitOps. Fleet focuses not only on the ability to scale, but it also gives users a high degree of control and visibility to monitor exactly what is installed on the cluster.
|
||||
|
||||
- *Deployment management*: Fleet can manage deployments from git of raw Kubernetes YAML, Helm charts, Kustomize, or any combination of the three. Regardless of the source, all resources are dynamically turned into Helm charts, and Helm is used as the engine to deploy all resources in the cluster. As a result, users can enjoy a high degree of control, consistency, and auditability of their clusters.
|
||||
|
||||
## Architecture
|
||||
|
||||
|
||||
-3
@@ -61,9 +61,6 @@ Once Prometheus determines that an alert needs to be fired, alerts are forwarded
|
||||
|
||||
- Routes and receivers are also stored in the Kubernetes API via the Alertmanager Secret. When the Secret is updated, Alertmanager is also updated automatically. Note that routing occurs via labels only (not via annotations, etc.).
|
||||
|
||||
<figcaption>How data flows through the monitoring application:</figcaption>
|
||||
|
||||
|
||||
## 2. How Prometheus Works
|
||||
|
||||
### Storing Time Series Data
|
||||
|
||||
+1
-1
@@ -139,5 +139,5 @@ At high scale, Rancher transfers more data from the upstream cluster to UI compo
|
||||
For best performance, ensure that the host running the hardware meets these requirements:
|
||||
- 2020 i5 10th generation Intel (4 cores) or equivalent
|
||||
- 8 GB RAM
|
||||
- Total network bandwith to the upstream cluster: 72 Mb/s (equivalent to a single 802.11n Wi-Fi 4 link stream, ~8 MB/s http download throughput)
|
||||
- Total network bandwidth to the upstream cluster: 72 Mb/s (equivalent to a single 802.11n Wi-Fi 4 link stream, ~8 MB/s http download throughput)
|
||||
- Round-trip time (ping time) from browser to upstream cluster: 150 ms or less
|
||||
|
||||
+4
@@ -10,6 +10,10 @@ Rancher is committed to informing the community of security issues in our produc
|
||||
|
||||
| ID | Description | Date | Resolution |
|
||||
|----|-------------|------|------------|
|
||||
[CVE-2024-52282](https://github.com/rancher/rancher/security/advisories/GHSA-9c5p-35gj-jqp4) | A medium severity vulnerability was discovered within Rancher Manager whereby applications installed via Rancher Manager Apps Catalog store their Helm values directly into the Apps Custom Resource Definition, resulting in any users with GET access to it to be able to read any sensitive information that are contained within the Apps’ values. Additionally, the same information leaks into auditing logs when the audit level is set to equal or above 2. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 19 Nov 2024 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.8.10](https://github.com/rancher/rancher/releases/tag/v2.8.10). |
|
||||
[CVE-2024-22036](https://github.com/rancher/rancher/security/advisories/GHSA-h99m-6755-rgwc) | A critical severity vulnerability was discovered within Rancher where a cluster or node driver can be used to escape the `chroot` jail and gain root access to the Rancher container itself. In production environments, further privilege escalation is possible based on living off the land within the Rancher container itself. For test and development environments, based on a –privileged Docker container, it is possible to escape the Docker container and gain execution access on the host system. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3), [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) and [v2.7.16](https://github.com/rancher/rancher/releases/tag/v2.7.16) |
|
||||
[CVE-2023-32197](https://github.com/rancher/rancher/security/advisories/GHSA-7h8m-pvw3-5gh4) | A critical severity vulnerability was discovered whereby Rancher Manager deployments containing Windows nodes have weak Access Control Lists (ACL), allowing `BUILTIN\Users` or `NT AUTHORITY\Authenticated Users` to view or edit sensitive files which could lead to privilege escalation. This vulnerability is exclusive to deployments that contain Windows nodes. Linux-only environments are not affected by it. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) |
|
||||
[CVE-2022-45157](https://github.com/rancher/rancher/security/advisories/GHSA-xj7w-r753-vj8v) | A critical severity vulnerability was discovered in the way that Rancher stores vSphere's CPI (Cloud Provider Interface) and CSI (Container Storage Interface) credentials used to deploy clusters through the vSphere cloud provider. This issue leads to the vSphere CPI and CSI passwords being stored in a plaintext object inside Rancher. This vulnerability is only applicable to users that deploy clusters in vSphere environments. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) |
|
||||
[CVE-2024-22030](https://github.com/rancher/rancher/security/advisories/GHSA-h4h5-9833-v2p4) | A high severity vulnerability was discovered in Rancher's agents that under very specific circumstances allows a malicious actor to take over existing Rancher nodes. The attacker needs to have control of an expired domain or execute a DNS spoofing/hijacking attack against the domain in order to exploit this vulnerability. The targeted domain is the one used as the Rancher URL (the `server-url` of the Rancher cluster). | 19 Sep 2024 | Rancher [v2.9.2](https://github.com/rancher/rancher/releases/tag/v2.9.2), [v2.8.8](https://github.com/rancher/rancher/releases/tag/v2.8.8) and [v2.7.15](https://github.com/rancher/rancher/releases/tag/v2.7.15) |
|
||||
| [CVE-2024-22032](https://github.com/rancher/rancher/security/advisories/GHSA-q6c7-56cq-g2wm) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where custom secrets encryption configurations are stored in plaintext under the clusters `AppliedSpec`. This also causes clusters to continuously reconcile, as the `AppliedSpec` would never match the desired cluster `Spec`. The stored information contains the encryption configuration for secrets within etcd, and could potentially expose sensitive data if the etcd database was exposed directly. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
| [CVE-2023-32196](https://github.com/rancher/rancher/security/advisories/GHSA-64jq-m7rq-768h) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where the webhook rule resolver ignores rules from a `ClusterRole` for an external `RoleTemplate` set with `.context=project` or `.context=""`. This allows a user to create an external `ClusterRole` with `.context=project` or `.context=""`, depending on the use of the new feature flag `external-rules` and backing `ClusterRole`. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
|
||||
@@ -20,6 +20,7 @@ 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.8.11 | v0.4.14 | ✓ | ✗ |
|
||||
| v2.8.10 | v0.4.13 | ✓ | ✗ |
|
||||
| v2.8.9 | v0.4.12 | ✓ | ✗ |
|
||||
| v2.8.8 | v0.4.11 | ✓ | ✗ |
|
||||
|
||||
@@ -16,6 +16,7 @@ Rancher will publish deprecated features as part of the [release notes](https://
|
||||
|
||||
| Patch Version | Release Date |
|
||||
|---------------|---------------|
|
||||
| [2.9.5](https://github.com/rancher/rancher/releases/tag/v2.9.5) | Dec 19, 2024 |
|
||||
| [2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) | Nov 18, 2024 |
|
||||
| [2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) | Oct 24, 2024 |
|
||||
| [2.9.2](https://github.com/rancher/rancher/releases/tag/v2.9.2) | Sep 19, 2024 |
|
||||
|
||||
-2
@@ -23,7 +23,5 @@ For information on how Rancher works, regardless of the installation method, ref
|
||||
- The Ingress controller will redirect HTTP to HTTPS and terminate SSL/TLS on port TCP/443.
|
||||
- The Ingress controller will forward traffic to port TCP/80 on the pod in the Rancher deployment.
|
||||
|
||||
<figcaption>Kubernetes Rancher install with layer 4 load balancer, depicting SSL termination at ingress controllers</figcaption>
|
||||
|
||||

|
||||
<sup>Kubernetes Rancher install with Layer 4 load balancer (TCP), depicting SSL termination at ingress controllers</sup>
|
||||
|
||||
+138
-187
@@ -93,7 +93,7 @@ This [tutorial](https://aws.amazon.com/blogs/opensource/managing-eks-clusters-ra
|
||||
|
||||
## Minimum EKS Permissions
|
||||
|
||||
These are the minimum set of permissions necessary to access the full functionality of Rancher's EKS driver. You'll need additional permissions for Rancher to provision the `Service Role` and `VPC` resources. If you create these resources **before** you create the cluster, they'll be available when you configure the cluster.
|
||||
These are the minimum set of permissions necessary to access the full functionality of Rancher's EKS driver. These permissions allow Rancher to create the Service Role and Virtual Private Cloud (VPC) resources on the users' behalf, if necessary.
|
||||
|
||||
:::note
|
||||
In EKS v1.23 and above, you must use the out-of-tree drivers for EBS-backed volumes. You need [specific permissions](#ebs-csi-driver-addon-permissions) to enable this add-on.
|
||||
@@ -101,132 +101,66 @@ In EKS v1.23 and above, you must use the out-of-tree drivers for EBS-backed volu
|
||||
|
||||
Resource | Description
|
||||
---------|------------
|
||||
Service Role | Provides permissions that allow Kubernetes to manage resources on your behalf. Rancher can create the service role with the following [Service Role Permissions](#service-role-permissions).
|
||||
VPC | Provides isolated network resources utilised by EKS and worker nodes. Rancher can create the VPC resources with the following [VPC Permissions](#vpc-permissions).
|
||||
EBS CSI Driver add-on | Provides permissions that allow Kubernetes to interact with EBS and configure the cluster to enable the add-on (required for EKS v1.23 and above). Rancher can install the add-on with the following [EBS CSI Driver addon Permissions](#ebs-csi-driver-addon-permissions).
|
||||
|
||||
|
||||
Resource targeting uses `*` as the ARN of many of the resources created cannot be known before creating the EKS cluster in Rancher.
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "EC2Permissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:RunInstances",
|
||||
"ec2:RevokeSecurityGroupIngress",
|
||||
"ec2:RevokeSecurityGroupEgress",
|
||||
"ec2:DescribeInstanceTypes",
|
||||
"ec2:DescribeRegions",
|
||||
"ec2:DescribeVpcs",
|
||||
"ec2:DescribeTags",
|
||||
"ec2:DescribeSubnets",
|
||||
"ec2:DescribeSecurityGroups",
|
||||
"ec2:DescribeRouteTables",
|
||||
"ec2:DescribeLaunchTemplateVersions",
|
||||
"ec2:DescribeLaunchTemplates",
|
||||
"ec2:DescribeKeyPairs",
|
||||
"ec2:DescribeInternetGateways",
|
||||
"ec2:DescribeImages",
|
||||
"ec2:DescribeAvailabilityZones",
|
||||
"ec2:DescribeAccountAttributes",
|
||||
"ec2:DeleteTags",
|
||||
"ec2:DeleteLaunchTemplateVersions",
|
||||
"ec2:DeleteLaunchTemplate",
|
||||
"ec2:DeleteSecurityGroup",
|
||||
"ec2:DeleteKeyPair",
|
||||
"ec2:CreateTags",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateLaunchTemplateVersion",
|
||||
"ec2:CreateLaunchTemplate",
|
||||
"ec2:CreateKeyPair",
|
||||
"ec2:AuthorizeSecurityGroupIngress",
|
||||
"ec2:AuthorizeSecurityGroupEgress"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "CloudFormationPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"cloudformation:ListStacks",
|
||||
"cloudformation:ListStackResources",
|
||||
"cloudformation:DescribeStacks",
|
||||
"cloudformation:DescribeStackResources",
|
||||
"cloudformation:DescribeStackResource",
|
||||
"cloudformation:DeleteStack",
|
||||
"cloudformation:CreateStackSet",
|
||||
"cloudformation:CreateStack"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "IAMPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"iam:PassRole",
|
||||
"iam:ListRoles",
|
||||
"iam:ListRoleTags",
|
||||
"iam:ListInstanceProfilesForRole",
|
||||
"iam:ListInstanceProfiles",
|
||||
"iam:ListAttachedRolePolicies",
|
||||
"iam:GetRole",
|
||||
"iam:GetInstanceProfile",
|
||||
"iam:DetachRolePolicy",
|
||||
"iam:DeleteRole",
|
||||
"iam:CreateRole",
|
||||
"iam:AttachRolePolicy"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "KMSPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": "kms:ListKeys",
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "EKSPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"eks:UpdateNodegroupVersion",
|
||||
"eks:UpdateNodegroupConfig",
|
||||
"eks:UpdateClusterVersion",
|
||||
"eks:UpdateClusterConfig",
|
||||
"eks:UntagResource",
|
||||
"eks:TagResource",
|
||||
"eks:ListUpdates",
|
||||
"eks:ListTagsForResource",
|
||||
"eks:ListNodegroups",
|
||||
"eks:ListFargateProfiles",
|
||||
"eks:ListClusters",
|
||||
"eks:DescribeUpdate",
|
||||
"eks:DescribeNodegroup",
|
||||
"eks:DescribeFargateProfile",
|
||||
"eks:DescribeCluster",
|
||||
"eks:DeleteNodegroup",
|
||||
"eks:DeleteFargateProfile",
|
||||
"eks:DeleteCluster",
|
||||
"eks:CreateNodegroup",
|
||||
"eks:CreateFargateProfile",
|
||||
"eks:CreateCluster"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Service Role Permissions
|
||||
|
||||
These are permissions that are needed during EKS cluster creation, so Rancher can create a service role on the users' behalf.
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "EC2Permissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:AuthorizeSecurityGroupEgress",
|
||||
"ec2:AuthorizeSecurityGroupIngress",
|
||||
"ec2:CreateKeyPair",
|
||||
"ec2:CreateLaunchTemplate",
|
||||
"ec2:CreateLaunchTemplateVersion",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateTags",
|
||||
"ec2:DeleteKeyPair",
|
||||
"ec2:DeleteLaunchTemplate",
|
||||
"ec2:DeleteLaunchTemplateVersions",
|
||||
"ec2:DeleteSecurityGroup",
|
||||
"ec2:DeleteTags",
|
||||
"ec2:DescribeAccountAttributes",
|
||||
"ec2:DescribeAvailabilityZones",
|
||||
"ec2:DescribeImages",
|
||||
"ec2:DescribeInternetGateways",
|
||||
"ec2:DescribeInstanceTypes",
|
||||
"ec2:DescribeKeyPairs",
|
||||
"ec2:DescribeLaunchTemplateVersions",
|
||||
"ec2:DescribeLaunchTemplates",
|
||||
"ec2:DescribeRegions",
|
||||
"ec2:DescribeRouteTables",
|
||||
"ec2:DescribeSecurityGroups",
|
||||
"ec2:DescribeSubnets",
|
||||
"ec2:DescribeTags",
|
||||
"ec2:DescribeVpcs",
|
||||
"ec2:RevokeSecurityGroupEgress",
|
||||
"ec2:RevokeSecurityGroupIngress",
|
||||
"ec2:RunInstances"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "CloudFormationPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"cloudformation:CreateStack",
|
||||
"cloudformation:CreateStackSet",
|
||||
"cloudformation:DeleteStack",
|
||||
"cloudformation:DescribeStackResource",
|
||||
"cloudformation:DescribeStackResources",
|
||||
"cloudformation:DescribeStacks",
|
||||
"cloudformation:ListStackResources",
|
||||
"cloudformation:ListStacks"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "IAMPermissions",
|
||||
"Effect": "Allow",
|
||||
@@ -247,7 +181,70 @@ These are permissions that are needed during EKS cluster creation, so Rancher ca
|
||||
"iam:ListRoles",
|
||||
"iam:ListRoleTags",
|
||||
"iam:PassRole",
|
||||
"iam:RemoveRoleFromInstanceProfile"
|
||||
"iam:RemoveRoleFromInstanceProfile",
|
||||
"iam:TagRole"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "KMSPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": "kms:ListKeys",
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "EKSPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"eks:CreateCluster",
|
||||
"eks:CreateFargateProfile",
|
||||
"eks:CreateNodegroup",
|
||||
"eks:DeleteCluster",
|
||||
"eks:DeleteFargateProfile",
|
||||
"eks:DeleteNodegroup",
|
||||
"eks:DescribeAddon",
|
||||
"eks:DescribeCluster",
|
||||
"eks:DescribeFargateProfile",
|
||||
"eks:DescribeNodegroup",
|
||||
"eks:DescribeUpdate",
|
||||
"eks:ListClusters",
|
||||
"eks:ListFargateProfiles",
|
||||
"eks:ListNodegroups",
|
||||
"eks:ListTagsForResource",
|
||||
"eks:ListUpdates",
|
||||
"eks:TagResource",
|
||||
"eks:UntagResource",
|
||||
"eks:UpdateClusterConfig",
|
||||
"eks:UpdateClusterVersion",
|
||||
"eks:UpdateNodegroupConfig",
|
||||
"eks:UpdateNodegroupVersion"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "VPCPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:AssociateRouteTable",
|
||||
"ec2:AttachInternetGateway",
|
||||
"ec2:CreateInternetGateway",
|
||||
"ec2:CreateRoute",
|
||||
"ec2:CreateRouteTable",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateSubnet",
|
||||
"ec2:CreateVpc",
|
||||
"ec2:DeleteInternetGateway",
|
||||
"ec2:DeleteRoute",
|
||||
"ec2:DeleteRouteTable",
|
||||
"ec2:DeleteSubnet",
|
||||
"ec2:DeleteTags",
|
||||
"ec2:DeleteVpc",
|
||||
"ec2:DescribeVpcs",
|
||||
"ec2:DetachInternetGateway",
|
||||
"ec2:DisassociateRouteTable",
|
||||
"ec2:ModifySubnetAttribute",
|
||||
"ec2:ModifyVpcAttribute",
|
||||
"ec2:ReplaceRoute"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
@@ -280,79 +277,33 @@ arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
|
||||
arn:aws:iam::aws:policy/AmazonEKSServicePolicy
|
||||
```
|
||||
|
||||
### VPC Permissions
|
||||
|
||||
These are permissions that are needed by Rancher to create a Virtual Private Cloud (VPC) and associated resources.
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "VPCPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:ReplaceRoute",
|
||||
"ec2:ModifyVpcAttribute",
|
||||
"ec2:ModifySubnetAttribute",
|
||||
"ec2:DisassociateRouteTable",
|
||||
"ec2:DetachInternetGateway",
|
||||
"ec2:DescribeVpcs",
|
||||
"ec2:DeleteVpc",
|
||||
"ec2:DeleteTags",
|
||||
"ec2:DeleteSubnet",
|
||||
"ec2:DeleteRouteTable",
|
||||
"ec2:DeleteRoute",
|
||||
"ec2:DeleteInternetGateway",
|
||||
"ec2:CreateVpc",
|
||||
"ec2:CreateSubnet",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateRouteTable",
|
||||
"ec2:CreateRoute",
|
||||
"ec2:CreateInternetGateway",
|
||||
"ec2:AttachInternetGateway",
|
||||
"ec2:AssociateRouteTable"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### EBS CSI Driver addon Permissions
|
||||
|
||||
The following are the required permissions for installing the Amazon EBS CSI Driver add-on.
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"iam:GetRole",
|
||||
"eks:DescribeAddonConfiguration",
|
||||
"eks:UpdateAddon",
|
||||
"eks:ListAddons",
|
||||
"iam:CreateRole",
|
||||
"iam:AttachRolePolicy",
|
||||
"eks:DescribeAddon",
|
||||
"iam:CreateOpenIDConnectProvider",
|
||||
"iam:PassRole",
|
||||
"eks:DescribeIdentityProviderConfig",
|
||||
"eks:DeleteAddon",
|
||||
"iam:ListOpenIDConnectProviders",
|
||||
"iam:ListAttachedRolePolicies",
|
||||
"eks:CreateAddon",
|
||||
"eks:DescribeCluster",
|
||||
"eks:DescribeAddonVersions",
|
||||
"sts:AssumeRoleWithWebIdentity",
|
||||
"eks:AssociateIdentityProviderConfig",
|
||||
"eks:ListIdentityProviderConfigs"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"eks:AssociateIdentityProviderConfig",
|
||||
"eks:CreateAddon",
|
||||
"eks:DeleteAddon",
|
||||
"eks:DescribeAddonConfiguration",
|
||||
"eks:DescribeAddonVersions",
|
||||
"eks:DescribeIdentityProviderConfig",
|
||||
"eks:ListAddons",
|
||||
"eks:ListIdentityProviderConfigs",
|
||||
"eks:UpdateAddon",
|
||||
"iam:CreateOpenIDConnectProvider",
|
||||
"iam:ListOpenIDConnectProviders",
|
||||
"sts:AssumeRoleWithWebIdentity"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
+1
@@ -19,6 +19,7 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
|
||||
|
||||
| Rancher Version | Adapter Version |
|
||||
|-----------------|------------------|
|
||||
| v2.9.5 | v104.0.0+up4.0.0 |
|
||||
| v2.9.4 | v104.0.0+up4.0.0 |
|
||||
| v2.9.3 | v104.0.0+up4.0.0 |
|
||||
| v2.9.2 | v104.0.0+up4.0.0 |
|
||||
|
||||
@@ -6,10 +6,13 @@ title: Overview
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/fleet/overview"/>
|
||||
</head>
|
||||
|
||||
Continuous Delivery with Fleet is GitOps at scale. Fleet is designed to manage up to a million clusters. It’s also lightweight enough that it works great for a [single cluster](https://fleet.rancher.io/installation#default-install) too, but it really shines when you get to a [large scale](https://fleet.rancher.io/installation#configuration-for-multi-cluster). By large scale we mean either a lot of clusters, a lot of deployments, or a lot of teams in a single organization.
|
||||
## What is Continuous Delivery with Fleet?
|
||||
|
||||
Fleet is a separate project from Rancher, and can be installed on any Kubernetes cluster with Helm.
|
||||
Continuous Delivery is Rancher's GitOps functionality, which is provided via integration with Fleet.
|
||||
|
||||
- *Cluster engine*: Fleet is a container management and deployment engine designed to offer users more control on the local cluster and constant monitoring through GitOps. Fleet focuses not only on the ability to scale, but it also gives users a high degree of control and visibility to monitor exactly what is installed on the cluster.
|
||||
|
||||
- *Deployment management*: Fleet can manage deployments from git of raw Kubernetes YAML, Helm charts, Kustomize, or any combination of the three. Regardless of the source, all resources are dynamically turned into Helm charts, and Helm is used as the engine to deploy all resources in the cluster. As a result, users can enjoy a high degree of control, consistency, and auditability of their clusters.
|
||||
|
||||
## Architecture
|
||||
|
||||
|
||||
-3
@@ -61,9 +61,6 @@ Once Prometheus determines that an alert needs to be fired, alerts are forwarded
|
||||
|
||||
- Routes and receivers are also stored in the Kubernetes API via the Alertmanager Secret. When the Secret is updated, Alertmanager is also updated automatically. Note that routing occurs via labels only (not via annotations, etc.).
|
||||
|
||||
<figcaption>How data flows through the monitoring application:</figcaption>
|
||||
|
||||
|
||||
## 2. How Prometheus Works
|
||||
|
||||
### Storing Time Series Data
|
||||
|
||||
+1
-1
@@ -139,5 +139,5 @@ At high scale, Rancher transfers more data from the upstream cluster to UI compo
|
||||
For best performance, ensure that the host running the hardware meets these requirements:
|
||||
- 2020 i5 10th generation Intel (4 cores) or equivalent
|
||||
- 8 GB RAM
|
||||
- Total network bandwith to the upstream cluster: 72 Mb/s (equivalent to a single 802.11n Wi-Fi 4 link stream, ~8 MB/s http download throughput)
|
||||
- Total network bandwidth to the upstream cluster: 72 Mb/s (equivalent to a single 802.11n Wi-Fi 4 link stream, ~8 MB/s http download throughput)
|
||||
- Round-trip time (ping time) from browser to upstream cluster: 150 ms or less
|
||||
|
||||
+4
@@ -10,6 +10,10 @@ Rancher is committed to informing the community of security issues in our produc
|
||||
|
||||
| ID | Description | Date | Resolution |
|
||||
|----|-------------|------|------------|
|
||||
[CVE-2024-52282](https://github.com/rancher/rancher/security/advisories/GHSA-9c5p-35gj-jqp4) | A medium severity vulnerability was discovered within Rancher Manager whereby applications installed via Rancher Manager Apps Catalog store their Helm values directly into the Apps Custom Resource Definition, resulting in any users with GET access to it to be able to read any sensitive information that are contained within the Apps’ values. Additionally, the same information leaks into auditing logs when the audit level is set to equal or above 2. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 19 Nov 2024 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.8.10](https://github.com/rancher/rancher/releases/tag/v2.8.10). |
|
||||
[CVE-2024-22036](https://github.com/rancher/rancher/security/advisories/GHSA-h99m-6755-rgwc) | A critical severity vulnerability was discovered within Rancher where a cluster or node driver can be used to escape the `chroot` jail and gain root access to the Rancher container itself. In production environments, further privilege escalation is possible based on living off the land within the Rancher container itself. For test and development environments, based on a –privileged Docker container, it is possible to escape the Docker container and gain execution access on the host system. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3), [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) and [v2.7.16](https://github.com/rancher/rancher/releases/tag/v2.7.16) |
|
||||
[CVE-2023-32197](https://github.com/rancher/rancher/security/advisories/GHSA-7h8m-pvw3-5gh4) | A critical severity vulnerability was discovered whereby Rancher Manager deployments containing Windows nodes have weak Access Control Lists (ACL), allowing `BUILTIN\Users` or `NT AUTHORITY\Authenticated Users` to view or edit sensitive files which could lead to privilege escalation. This vulnerability is exclusive to deployments that contain Windows nodes. Linux-only environments are not affected by it. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) |
|
||||
[CVE-2022-45157](https://github.com/rancher/rancher/security/advisories/GHSA-xj7w-r753-vj8v) | A critical severity vulnerability was discovered in the way that Rancher stores vSphere's CPI (Cloud Provider Interface) and CSI (Container Storage Interface) credentials used to deploy clusters through the vSphere cloud provider. This issue leads to the vSphere CPI and CSI passwords being stored in a plaintext object inside Rancher. This vulnerability is only applicable to users that deploy clusters in vSphere environments. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) |
|
||||
| [CVE-2024-22030](https://github.com/rancher/rancher/security/advisories/GHSA-h4h5-9833-v2p4) | A high severity vulnerability was discovered in Rancher's agents that under very specific circumstances allows a malicious actor to take over existing Rancher nodes. The attacker needs to have control of an expired domain or execute a DNS spoofing/hijacking attack against the domain in order to exploit this vulnerability. The targeted domain is the one used as the Rancher URL (the `server-url` of the Rancher cluster). | 19 Sep 2024 | Rancher [v2.9.2](https://github.com/rancher/rancher/releases/tag/v2.9.2), [v2.8.8](https://github.com/rancher/rancher/releases/tag/v2.8.8) and [v2.7.15](https://github.com/rancher/rancher/releases/tag/v2.7.15) |
|
||||
| [CVE-2023-32193](https://github.com/rancher/norman/security/advisories/GHSA-r8f4-hv23-6qp6) | An issue was discovered in Rancher versions up to and including 2.6.13, 2.7.9 and 2.8.1, where multiple Cross-Site Scripting (XSS) vulnerabilities can be exploited via the Rancher UI (Norman). | 8 Feb 2024 | Rancher [v2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2), [v2.7.10](https://github.com/rancher/rancher/releases/tag/v2.7.10) and [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
|
||||
| [CVE-2023-32192](https://github.com/rancher/apiserver/security/advisories/GHSA-833m-37f7-jq55) | An issue was discovered in Rancher versions up to and including 2.6.13, 2.7.9 and 2.8.1, where multiple Cross-Site Scripting (XSS) vulnerabilities can be exploited via the Rancher UI (Apiserver). | 8 Feb 2024 | Rancher [v2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2), [v2.7.10](https://github.com/rancher/rancher/releases/tag/v2.7.10) and [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
|
||||
|
||||
@@ -20,6 +20,7 @@ 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.9.5 | v0.5.5 | ✓ | ✗ |
|
||||
| v2.9.4 | v0.5.4 | ✓ | ✗ |
|
||||
| v2.9.3 | v0.5.3 | ✓ | ✓ |
|
||||
| v2.9.2 | v0.5.2 | ✓ | ✓ |
|
||||
|
||||
Reference in New Issue
Block a user