mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-05-04 20:23:24 +00:00
Adding preview for v2.12 Rancher documentation.
Signed-off-by: Sunil Singh <sunil.singh@suse.com>
This commit is contained in:
Sunil Singh
+55
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: Rancher 自我评估和加固指南
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/hardening-guides"/>
|
||||
</head>
|
||||
|
||||
Rancher 为每个受支持的 Rancher 版本的 Kubernetes 发行版提供了特定的安全强化指南。
|
||||
|
||||
## Rancher Kubernetes 发行版
|
||||
|
||||
Rancher 使用以下 Kubernetes 发行版：
|
||||
|
||||
- [**RKE**](https://rancher.com/docs/rke/latest/en/)（Rancher Kubernetes Engine）是经过 CNCF 认证的 Kubernetes 发行版，完全在 Docker 容器中运行。
|
||||
- [**RKE2**](https://docs.rke2.io/) 是一个完全合规的 Kubernetes 发行版，专注于安全和合规性。
|
||||
- [**K3s**](https://docs.k3s.io/) 是一个完全合规的，轻量级 Kubernetes 发行版。它易于安装，内存需求只有上游 Kubernetes 的一半，所有组件都在一个小于 100 MB 的二进制文件中。
|
||||
|
||||
要加固运行未列出的发行版的 Kubernetes 集群，请参阅 Kubernetes 提供商文档。
|
||||
|
||||
## 加固指南和 Benchmark 版本
|
||||
|
||||
每个自我评估指南都附有强化指南。这些指南与列出的 Rancher 版本一起进行了测试。每个自我评估指南都在特定的 Kubernetes 版本和 CIS Benchmark 版本上进行了测试。如果 CIS Benchmark 尚未针对你的 Kubernetes 版本进行验证，你可以使用现有指南，直到添加适合你的版本的指南。
|
||||
|
||||
### RKE 指南
|
||||
|
||||
| Kubernetes 版本 | CIS Benchmark 版本 | 自我评估指南 | 加固指南 |
|
||||
|--------------------|-----------------------|-----------------------|------------------|
|
||||
| Kubernetes v1.23 | CIS v1.23 | [链接](rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.23.md) | [链接](rke1-hardening-guide/rke1-hardening-guide.md) |
|
||||
| Kubernetes v1.24 | CIS v1.24 | [链接](rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.24-k8s-v1.24.md) | [链接](rke1-hardening-guide/rke1-hardening-guide.md) |
|
||||
| Kubernetes v1.25/v1.26/v1.27 | CIS v1.7 | [链接](rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.7-k8s-v1.25-v1.26-v1.27.md) | [链接](rke1-hardening-guide/rke1-hardening-guide.md) |
|
||||
|
||||
### RKE2 指南
|
||||
|
||||
| 类型 | Kubernetes 版本 | CIS Benchmark 版本 | 自我评估指南 | 加固指南 |
|
||||
|------|--------------------|-----------------------|-----------------------|------------------|
|
||||
| Rancher provisioned RKE2 | Kubernetes v1.23 | CIS v1.23 | [链接](rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.23-k8s-v1.23.md) | [链接](rke2-hardening-guide/rke2-hardening-guide.md) |
|
||||
| Rancher provisioned RKE2 | Kubernetes v1.24 | CIS v1.24 | [链接](rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.24-k8s-v1.24.md) | [链接](rke2-hardening-guide/rke2-hardening-guide.md) |
|
||||
| Rancher provisioned RKE2 | Kubernetes v1.25/v1.26/v1.27 | CIS v1.7 | [链接](rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.7-k8s-v1.25-v1.26-v1.27.md) | [链接](rke2-hardening-guide/rke2-hardening-guide.md) |
|
||||
| Standalone RKE2 | Kubernetes v1.25/v1.26/v1.27 | CIS v1.7 | [链接](https://docs.rke2.io/security/cis_self_assessment123) | [链接](https://docs.rke2.io/security/hardening_guide) |
|
||||
|
||||
### K3s 指南
|
||||
|
||||
| 类型 | Kubernetes 版本 | CIS Benchmark 版本 | 自我评估指南 | 加固指南 |
|
||||
|------|--------------------|-----------------------|-----------------------|------------------|
|
||||
| Rancher provisioned K3s cluster | Kubernetes v1.23 | CIS v1.23 | [链接](k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.23-k8s-v1.23.md) | [链接](k3s-hardening-guide/k3s-hardening-guide.md) |
|
||||
| Rancher provisioned K3s cluster | Kubernetes v1.24 | CIS v1.24 | [链接](k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.24-k8s-v1.24.md) | [链接](k3s-hardening-guide/k3s-hardening-guide.md) |
|
||||
| Rancher provisioned K3s cluster | Kubernetes v1.25/v1.26/v1.27 | CIS v1.7 | [链接](k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.7-k8s-v1.25-v1.26-v1.27.md) | [链接](k3s-hardening-guide/k3s-hardening-guide.md) |
|
||||
| Standalone K3s | Kubernetes v1.22 up to v1.24 | CIS v1.23 | [链接](https://docs.k3s.io/security/self-assessment-1.8) | [链接](https://docs.k3s.io/security/hardening-guide) |
|
||||
|
||||
## 在 SELinux 上使用 Rancher
|
||||
|
||||
[Security-Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) 是一个内核模块，为 Linux 添加了额外的访问控制和安全工具。SELinux 过去曾被政府机构使用，现在已成为行业标准。SELinux 在 RHEL 和 CentOS 上默认启用。
|
||||
|
||||
要将 Rancher 与 SELinux 结合使用，我们建议[安装](../selinux-rpm/about-rancher-selinux.md) `rancher-selinux`。
|
||||
+744
@@ -0,0 +1,744 @@
|
||||
---
|
||||
title: K3s 加固指南
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/hardening-guides/k3s-hardening-guide"/>
|
||||
</head>
|
||||
|
||||
本文档提供了针对生产环境的 K3s 集群进行加固的具体指导，以便在使用 Rancher 部署之前进行配置。它概述了满足信息安全中心（Center for Information Security, CIS）Kubernetes benchmark controls 所需的配置和控制。
|
||||
|
||||
:::note
|
||||
这份加固指南描述了如何确保你集群中的节点安全。我们建议你在安装 Kubernetes 之前遵循本指南。
|
||||
:::
|
||||
|
||||
此加固指南适用于 K3s 集群，并与以下版本的 CIS Kubernetes Benchmark、Kubernetes 和 Rancher 相关联：
|
||||
|
||||
| Rancher 版本 | CIS Benchmark 版本 | Kubernetes 版本 |
|
||||
|-----------------|-----------------------|------------------------------|
|
||||
| Rancher v2.7 | Benchmark v1.23 | Kubernetes v1.23 |
|
||||
| Rancher v2.7 | Benchmark v1.24 | Kubernetes v1.24 |
|
||||
| Rancher v2.7 | Benchmark v1.7 | Kubernetes v1.25 至 v1.26 |
|
||||
|
||||
:::note
|
||||
在 Benchmark v1.7 中，不再需要 `--protect-kernel-defaults` (4.2.6) 参数，并已被 CIS 删除。
|
||||
:::
|
||||
|
||||
有关如何评估加固的 K3s 集群与官方 CIS benchmark 的更多细节，请参考特定 Kubernetes 和 CIS benchmark 版本的 K3s 自我评估指南。
|
||||
|
||||
K3s 在不需要修改的情况下通过了许多 Kubernetes CIS controls，因为它默认应用了几个安全缓解措施。然而，有一些值得注意的例外情况，需要手动干预才能完全符合 CIS Benchmark 要求：
|
||||
|
||||
1. K3s 不修改主机操作系统。任何主机级别的修改都需要手动完成。
|
||||
2. 某些 CIS policy controls，例如 `NetworkPolicies` 和 `PodSecurityStandards`（在 v1.24 及更早版本中为 `PodSecurityPolicies`），会限制集群功能。
|
||||
你必须选择让 K3s 配置这些策略。在你的命令行标志或配置文件中添加相应的选项（启用准入插件），并手动应用适当的策略。
|
||||
请参阅以下详细信息。
|
||||
|
||||
CIS Benchmark 的第一部分（1.1）主要关注于 Pod manifest 的权限和所有权。由于发行版中的所有内容都打包在一个二进制文件中，因此这一部分不适用于 K3s 的核心组件。
|
||||
|
||||
## 主机级别要求
|
||||
|
||||
### 确保 `protect-kernel-defaults`已经设置
|
||||
|
||||
<Tabs groupId="k3s-version">
|
||||
<TabItem value="v1.25 及更新版本" default>
|
||||
|
||||
自 CIS benchmark 1.7 开始，不再需要`protect-kernel-defaults`。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="v1.24 及更早版本">
|
||||
|
||||
这是一个 kubelet 标志，如果所需的内核参数未设置或设置为与 kubelet 的默认值不同的值，将导致 kubelet 退出。
|
||||
|
||||
可以在 Rancher 的集群配置中设置 `protect-kernel-defaults` 标志。
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
rkeConfig:
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
protect-kernel-defaults: true
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### 设置内核参数
|
||||
|
||||
建议为集群中的所有节点类型设置以下 `sysctl` 配置。在 `/etc/sysctl.d/90-kubelet.conf` 中设置以下参数：
|
||||
|
||||
```ini
|
||||
vm.panic_on_oom=0
|
||||
vm.overcommit_memory=1
|
||||
kernel.panic=10
|
||||
kernel.panic_on_oops=1
|
||||
```
|
||||
|
||||
运行 `sudo sysctl -p /etc/sysctl.d/90-kubelet.conf` 以启用设置。
|
||||
|
||||
此配置需要在设置 kubelet 标志之前完成，否则 K3s 将无法启动。
|
||||
|
||||
## Kubernetes 运行时要求
|
||||
|
||||
CIS Benchmark 的运行时要求主要围绕 Pod 安全（通过 PSP 或 PSA）、网络策略和 API 服务器审计日志展开。
|
||||
|
||||
默认情况下，K3s 不包含任何 Pod 安全或网络策略。然而，K3s 附带一个控制器，可以强制执行你创建的任何网络策略。默认情况下，K3s 启用了 `PodSecurity` 和 `NodeRestriction` 等多个准入控制器。
|
||||
|
||||
### Pod 安全
|
||||
|
||||
<Tabs groupId="k3s-version">
|
||||
<TabItem value="v1.25 及更新版本" default>
|
||||
|
||||
K3s v1.25 及更新版本支持 [Pod 安全准入(PSA)](https://kubernetes.io/docs/concepts/security/pod-security-admission/)，用于控制 Pod 安全性。
|
||||
|
||||
你可以在 Rancher 中通过集群配置，设置 `defaultPodSecurityAdmissionConfigurationTemplateName` 字段来指定 PSA 配置：
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
defaultPodSecurityAdmissionConfigurationTemplateName: rancher-restricted
|
||||
```
|
||||
|
||||
Rancher 提供了 `rancher-restricted` 模板，用于强制执行高度限制性的 Kubernetes 上游 [`Restricted`](https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted) 配置文件，其中包含了 Pod 加固的最佳实践。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="v1.24 及更早版本">
|
||||
|
||||
K3s v1.24 及更早版本支持 [Pod 安全策略 (PSP)](https://github.com/kubernetes/website/blob/release-1.24/content/en/docs/concepts/security/pod-security-policy.md) 以控制 Pod 安全性。
|
||||
|
||||
你可以在 Rancher 中通过集群配置，传递以下标志来启用 PSPs：
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
rkeConfig:
|
||||
machineGlobalConfig:
|
||||
kube-apiserver-arg:
|
||||
- enable-admission-plugins=NodeRestriction,PodSecurityPolicy,ServiceAccount
|
||||
```
|
||||
|
||||
这会保留 `NodeRestriction` 插件并启用 `PodSecurityPolicy`。
|
||||
|
||||
启用 PSPs 后，你可以应用策略来满足 CIS Benchmark 第 5.2 节中描述的必要控制。
|
||||
|
||||
:::note
|
||||
这些是 CIS Benchmark 中的手动检查。CIS 扫描结果将标记为 `warning`，因为需要集群操作员进行手动检查。
|
||||
:::
|
||||
|
||||
以下是合规的 PSP 示例：
|
||||
|
||||
```yaml
|
||||
---
|
||||
apiVersion: policy/v1beta1
|
||||
kind: PodSecurityPolicy
|
||||
metadata:
|
||||
name: restricted-psp
|
||||
spec:
|
||||
privileged: false # CIS - 5.2.1
|
||||
allowPrivilegeEscalation: false # CIS - 5.2.5
|
||||
requiredDropCapabilities: # CIS - 5.2.7/8/9
|
||||
- ALL
|
||||
volumes:
|
||||
- 'configMap'
|
||||
- 'emptyDir'
|
||||
- 'projected'
|
||||
- 'secret'
|
||||
- 'downwardAPI'
|
||||
- 'csi'
|
||||
- 'persistentVolumeClaim'
|
||||
- 'ephemeral'
|
||||
hostNetwork: false # CIS - 5.2.4
|
||||
hostIPC: false # CIS - 5.2.3
|
||||
hostPID: false # CIS - 5.2.2
|
||||
runAsUser:
|
||||
rule: 'MustRunAsNonRoot' # CIS - 5.2.6
|
||||
seLinux:
|
||||
rule: 'RunAsAny'
|
||||
supplementalGroups:
|
||||
rule: 'MustRunAs'
|
||||
ranges:
|
||||
- min: 1
|
||||
max: 65535
|
||||
fsGroup:
|
||||
rule: 'MustRunAs'
|
||||
ranges:
|
||||
- min: 1
|
||||
max: 65535
|
||||
readOnlyRootFilesystem: false
|
||||
```
|
||||
|
||||
要使示例 PSP 生效，我们需要创建一个 `ClusterRole` 和 一个`ClusterRoleBinding`。我们还需要为需要额外权限的系统级 Pod 提供“系统无限制策略”，以及允许必要的 sysctls 来实现 ServiceLB 完整功能的额外策略。
|
||||
|
||||
```yaml
|
||||
---
|
||||
apiVersion: policy/v1beta1
|
||||
kind: PodSecurityPolicy
|
||||
metadata:
|
||||
name: restricted-psp
|
||||
spec:
|
||||
privileged: false
|
||||
allowPrivilegeEscalation: false
|
||||
requiredDropCapabilities:
|
||||
- ALL
|
||||
volumes:
|
||||
- 'configMap'
|
||||
- 'emptyDir'
|
||||
- 'projected'
|
||||
- 'secret'
|
||||
- 'downwardAPI'
|
||||
- 'csi'
|
||||
- 'persistentVolumeClaim'
|
||||
- 'ephemeral'
|
||||
hostNetwork: false
|
||||
hostIPC: false
|
||||
hostPID: false
|
||||
runAsUser:
|
||||
rule: 'MustRunAsNonRoot'
|
||||
seLinux:
|
||||
rule: 'RunAsAny'
|
||||
supplementalGroups:
|
||||
rule: 'MustRunAs'
|
||||
ranges:
|
||||
- min: 1
|
||||
max: 65535
|
||||
fsGroup:
|
||||
rule: 'MustRunAs'
|
||||
ranges:
|
||||
- min: 1
|
||||
max: 65535
|
||||
readOnlyRootFilesystem: false
|
||||
---
|
||||
apiVersion: policy/v1beta1
|
||||
kind: PodSecurityPolicy
|
||||
metadata:
|
||||
name: system-unrestricted-psp
|
||||
annotations:
|
||||
seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
|
||||
spec:
|
||||
allowPrivilegeEscalation: true
|
||||
allowedCapabilities:
|
||||
- '*'
|
||||
fsGroup:
|
||||
rule: RunAsAny
|
||||
hostIPC: true
|
||||
hostNetwork: true
|
||||
hostPID: true
|
||||
hostPorts:
|
||||
- max: 65535
|
||||
min: 0
|
||||
privileged: true
|
||||
runAsUser:
|
||||
rule: RunAsAny
|
||||
seLinux:
|
||||
rule: RunAsAny
|
||||
supplementalGroups:
|
||||
rule: RunAsAny
|
||||
volumes:
|
||||
- '*'
|
||||
---
|
||||
apiVersion: policy/v1beta1
|
||||
kind: PodSecurityPolicy
|
||||
metadata:
|
||||
name: svclb-psp
|
||||
annotations:
|
||||
seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
|
||||
spec:
|
||||
allowPrivilegeEscalation: false
|
||||
allowedCapabilities:
|
||||
- NET_ADMIN
|
||||
allowedUnsafeSysctls:
|
||||
- net.ipv4.ip_forward
|
||||
- net.ipv6.conf.all.forwarding
|
||||
fsGroup:
|
||||
rule: RunAsAny
|
||||
hostPorts:
|
||||
- max: 65535
|
||||
min: 0
|
||||
runAsUser:
|
||||
rule: RunAsAny
|
||||
seLinux:
|
||||
rule: RunAsAny
|
||||
supplementalGroups:
|
||||
rule: RunAsAny
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: psp:restricted-psp
|
||||
rules:
|
||||
- apiGroups:
|
||||
- policy
|
||||
resources:
|
||||
- podsecuritypolicies
|
||||
verbs:
|
||||
- use
|
||||
resourceNames:
|
||||
- restricted-psp
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: psp:system-unrestricted-psp
|
||||
rules:
|
||||
- apiGroups:
|
||||
- policy
|
||||
resources:
|
||||
- podsecuritypolicies
|
||||
resourceNames:
|
||||
- system-unrestricted-psp
|
||||
verbs:
|
||||
- use
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: psp:svclb-psp
|
||||
rules:
|
||||
- apiGroups:
|
||||
- policy
|
||||
resources:
|
||||
- podsecuritypolicies
|
||||
resourceNames:
|
||||
- svclb-psp
|
||||
verbs:
|
||||
- use
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: psp:svc-local-path-provisioner-psp
|
||||
rules:
|
||||
- apiGroups:
|
||||
- policy
|
||||
resources:
|
||||
- podsecuritypolicies
|
||||
resourceNames:
|
||||
- system-unrestricted-psp
|
||||
verbs:
|
||||
- use
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: psp:svc-coredns-psp
|
||||
rules:
|
||||
- apiGroups:
|
||||
- policy
|
||||
resources:
|
||||
- podsecuritypolicies
|
||||
resourceNames:
|
||||
- system-unrestricted-psp
|
||||
verbs:
|
||||
- use
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: psp:svc-cis-operator-psp
|
||||
rules:
|
||||
- apiGroups:
|
||||
- policy
|
||||
resources:
|
||||
- podsecuritypolicies
|
||||
resourceNames:
|
||||
- system-unrestricted-psp
|
||||
verbs:
|
||||
- use
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRoleBinding
|
||||
metadata:
|
||||
name: default:restricted-psp
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: psp:restricted-psp
|
||||
subjects:
|
||||
- kind: Group
|
||||
name: system:authenticated
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRoleBinding
|
||||
metadata:
|
||||
name: system-unrestricted-node-psp-rolebinding
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: psp:system-unrestricted-psp
|
||||
subjects:
|
||||
- apiGroup: rbac.authorization.k8s.io
|
||||
kind: Group
|
||||
name: system:nodes
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: RoleBinding
|
||||
metadata:
|
||||
name: system-unrestricted-svc-acct-psp-rolebinding
|
||||
namespace: kube-system
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: psp:system-unrestricted-psp
|
||||
subjects:
|
||||
- apiGroup: rbac.authorization.k8s.io
|
||||
kind: Group
|
||||
name: system:serviceaccounts
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: RoleBinding
|
||||
metadata:
|
||||
name: svclb-psp-rolebinding
|
||||
namespace: kube-system
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: psp:svclb-psp
|
||||
subjects:
|
||||
- kind: ServiceAccount
|
||||
name: svclb
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: RoleBinding
|
||||
metadata:
|
||||
name: svc-local-path-provisioner-psp-rolebinding
|
||||
namespace: kube-system
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: psp:svc-local-path-provisioner-psp
|
||||
subjects:
|
||||
- kind: ServiceAccount
|
||||
name: local-path-provisioner-service-account
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: RoleBinding
|
||||
metadata:
|
||||
name: svc-coredns-psp-rolebinding
|
||||
namespace: kube-system
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: psp:svc-coredns-psp
|
||||
subjects:
|
||||
- kind: ServiceAccount
|
||||
name: coredns
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: RoleBinding
|
||||
metadata:
|
||||
name: svc-cis-operator-psp-rolebinding
|
||||
namespace: cis-operator-system
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: psp:svc-cis-operator-psp
|
||||
subjects:
|
||||
- kind: ServiceAccount
|
||||
name: cis-operator-serviceaccount
|
||||
```
|
||||
|
||||
上述策略可以放置在 `/var/lib/rancher/k3s/server/manifests` 目录下名为 `policy.yaml` 的文件中。在启动 K3s 之前，必须创建策略文件和其目录结构。建议限制访问权限以避免泄露潜在的敏感信息。
|
||||
|
||||
```shell
|
||||
sudo mkdir -p -m 700 /var/lib/rancher/k3s/server/manifests
|
||||
```
|
||||
|
||||
:::note
|
||||
CNI、DNS 和 Ingress 等关键 Kubernetes 组件在 `kube-system` 命名空间中作为 Pod 运行。因此，这个命名空间的限制政策较少，从而使这些组件能够正常运行。
|
||||
:::
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### 网络策略
|
||||
|
||||
CIS 要求所有命名空间应用网络策略，合理限制进入命名空间和 Pod 的流量。
|
||||
|
||||
:::note
|
||||
这些是 CIS Benchmark 中的手动检查。CIS 扫描结果将标记为 `warning`，因为需要集群操作员进行手动检查。
|
||||
:::
|
||||
|
||||
网络策略可以放置在 `/var/lib/rancher/k3s/server/manifests` 目录下的 `policy.yaml` 文件中。如果该目录不是作为 PSP（如上所述）的一部分创建的，则必须首先创建该目录。
|
||||
|
||||
```shell
|
||||
sudo mkdir -p -m 700 /var/lib/rancher/k3s/server/manifests
|
||||
```
|
||||
|
||||
以下是合规的网络策略示例：
|
||||
|
||||
```yaml
|
||||
---
|
||||
kind: NetworkPolicy
|
||||
apiVersion: networking.k8s.io/v1
|
||||
metadata:
|
||||
name: intra-namespace
|
||||
namespace: kube-system
|
||||
spec:
|
||||
podSelector: {}
|
||||
ingress:
|
||||
- from:
|
||||
- namespaceSelector:
|
||||
matchLabels:
|
||||
name: kube-system
|
||||
---
|
||||
kind: NetworkPolicy
|
||||
apiVersion: networking.k8s.io/v1
|
||||
metadata:
|
||||
name: intra-namespace
|
||||
namespace: default
|
||||
spec:
|
||||
podSelector: {}
|
||||
ingress:
|
||||
- from:
|
||||
- namespaceSelector:
|
||||
matchLabels:
|
||||
name: default
|
||||
---
|
||||
kind: NetworkPolicy
|
||||
apiVersion: networking.k8s.io/v1
|
||||
metadata:
|
||||
name: intra-namespace
|
||||
namespace: kube-public
|
||||
spec:
|
||||
podSelector: {}
|
||||
ingress:
|
||||
- from:
|
||||
- namespaceSelector:
|
||||
matchLabels:
|
||||
name: kube-public
|
||||
```
|
||||
|
||||
除非特意允许，否则活动限制会阻止 DNS。以下是允许 DNS 相关流量的网络策略示例：
|
||||
|
||||
```yaml
|
||||
---
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
name: default-network-dns-policy
|
||||
namespace: <NAMESPACE>
|
||||
spec:
|
||||
ingress:
|
||||
- ports:
|
||||
- port: 53
|
||||
protocol: TCP
|
||||
- port: 53
|
||||
protocol: UDP
|
||||
podSelector:
|
||||
matchLabels:
|
||||
k8s-app: kube-dns
|
||||
policyTypes:
|
||||
- Ingress
|
||||
```
|
||||
|
||||
如果没有创建网络策略来允许访问，则默认情况下会阻止 metrics-server 和 Traefik Ingress 控制器。
|
||||
|
||||
```yaml
|
||||
---
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
name: allow-all-metrics-server
|
||||
namespace: kube-system
|
||||
spec:
|
||||
podSelector:
|
||||
matchLabels:
|
||||
k8s-app: metrics-server
|
||||
ingress:
|
||||
- {}
|
||||
policyTypes:
|
||||
- Ingress
|
||||
---
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
name: allow-all-svclbtraefik-ingress
|
||||
namespace: kube-system
|
||||
spec:
|
||||
podSelector:
|
||||
matchLabels:
|
||||
svccontroller.k3s.cattle.io/svcname: traefik
|
||||
ingress:
|
||||
- {}
|
||||
policyTypes:
|
||||
- Ingress
|
||||
---
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
name: allow-all-traefik-v121-ingress
|
||||
namespace: kube-system
|
||||
spec:
|
||||
podSelector:
|
||||
matchLabels:
|
||||
app.kubernetes.io/name: traefik
|
||||
ingress:
|
||||
- {}
|
||||
policyTypes:
|
||||
- Ingress
|
||||
```
|
||||
|
||||
:::note
|
||||
你必须像平常一样管理你创建的任何其他命名空间的网络策略。
|
||||
:::
|
||||
|
||||
### API server 审计配置
|
||||
|
||||
CIS 要求 1.2.19 至 1.2.22 与配置 API server 审核日志相关。默认情况下，K3s 不会创建日志目录和审计策略，因为每个用户的审计策略要求和环境都是特定的。
|
||||
|
||||
如果你需要日志目录，则必须在启动 K3s 之前创建它。我们建议限制访问权限以避免泄露敏感信息。
|
||||
|
||||
```bash
|
||||
sudo mkdir -p -m 700 /var/lib/rancher/k3s/server/logs
|
||||
```
|
||||
|
||||
以下是用于记录请求元数据的初始审计策略。应将策略写入到 `/var/lib/rancher/k3s/server` 目录下名为 `audit.yaml` 的文件中。有关 API server 的策略配置的详细信息，请参阅 [官方 Kubernetes 文档](https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/)。
|
||||
|
||||
```yaml
|
||||
---
|
||||
apiVersion: audit.k8s.io/v1
|
||||
kind: Policy
|
||||
rules:
|
||||
- level: Metadata
|
||||
```
|
||||
|
||||
还需要进一步配置才能通过 CIS 检查。这些在 K3s 中默认不配置，因为它们根据你的环境和需求而有所不同：
|
||||
|
||||
- 确保 `--audit-log-path` 参数已经设置。
|
||||
- 确保 `--audit-log-maxage` 参数设置为 30 或适当的值。
|
||||
- 确保 `--audit-log-maxbackup` 参数设置为 10 或适当的值。
|
||||
- 确保 `--audit-log-maxsize` 参数设置为 100 或适当的值。
|
||||
|
||||
综合起来，要启用和配置审计日志，请将以下行添加到 Rancher 的 K3s 集群配置文件中：
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
rkeConfig:
|
||||
machineGlobalConfig:
|
||||
kube-apiserver-arg:
|
||||
- audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml # CIS 3.2.1
|
||||
- audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log # CIS 1.2.18
|
||||
- audit-log-maxage=30 # CIS 1.2.19
|
||||
- audit-log-maxbackup=10 # CIS 1.2.20
|
||||
- audit-log-maxsize=100 # CIS 1.2.21
|
||||
```
|
||||
|
||||
### Controller Manager 要求
|
||||
|
||||
CIS 要求 1.3.1 检查 Controller Manager 中的垃圾收集设置。垃圾收集对于确保资源充足可用性并避免性能和可用性下降非常重要。根据你的系统资源和测试结果，选择一个适当的阈值来激活垃圾收集。
|
||||
|
||||
你可以在 Rancher 的 K3s 集群文件中设置以下配置来解决此问题。下面的值仅是一个示例，请根据当前环境设置适当的阈值。
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
rkeConfig:
|
||||
machineGlobalConfig:
|
||||
kube-controller-manager-arg:
|
||||
- terminated-pod-gc-threshold=10 # CIS 1.3.1
|
||||
```
|
||||
|
||||
### 配置 `default` Service Account
|
||||
|
||||
Kubernetes 提供了一个名为 `default` 的 service account，供集群工作负载使用，其中没有为 Pod 分配特定的 service account。当 Pod 需要从 Kubernetes API 获取访问权限时，应为该 Pod 创建一个特定的 service account，并为该 service account 授予权限。
|
||||
|
||||
对于 CIS 5.1.5，`default` service account 应配置为不提供 service account 令牌，并且不具有任何明确的权限分配。
|
||||
|
||||
可以通过在每个命名空间中将 `default` service account 的 `automountServiceAccountToken` 字段更新为 `false` 来解决此问题。
|
||||
|
||||
对于内置命名空间（`kube-system`、`kube-public`、`kube-node-lease` 和 `default`）中的 `default` service accounts，K3s 不会自动执行此操作。
|
||||
|
||||
将以下配置保存到名为 `account_update.yaml` 的文件中。
|
||||
|
||||
```yaml
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: default
|
||||
automountServiceAccountToken: false
|
||||
```
|
||||
|
||||
创建一个名为 `account_update.sh` 的 Bash 脚本文件。确保使用 `chmod +x account_update.sh` 给脚本添加可执行权限。
|
||||
|
||||
```shell
|
||||
#!/bin/bash -e
|
||||
|
||||
for namespace in $(kubectl get namespaces -A -o=jsonpath="{.items[*]['metadata.name']}"); do
|
||||
kubectl patch serviceaccount default -n ${namespace} -p "$(cat account_update.yaml)"
|
||||
done
|
||||
```
|
||||
|
||||
每次向你的集群添加新的 service account 时，运行该脚本。
|
||||
|
||||
## 加固版 K3s 模板配置参考
|
||||
|
||||
Rancher 使用以下参考模板配置，基于本指南中的每个 CIS 控件创建加固过的自定义 K3s 集群。此参考内容不包括其他必需的**集群配置**指令，这些指令因你的环境而异。
|
||||
|
||||
<Tabs groupId="k3s-version">
|
||||
<TabItem value="v1.25 及更新的版本" default>
|
||||
|
||||
```yaml
|
||||
apiVersion: provisioning.cattle.io/v1
|
||||
kind: Cluster
|
||||
metadata:
|
||||
name: # 定义集群名称
|
||||
spec:
|
||||
defaultPodSecurityAdmissionConfigurationTemplateName: rancher-restricted
|
||||
enableNetworkPolicy: true
|
||||
kubernetesVersion: # 定义 K3s 版本
|
||||
rkeConfig:
|
||||
machineGlobalConfig:
|
||||
kube-apiserver-arg:
|
||||
- enable-admission-plugins=NodeRestriction,ServiceAccount # CIS 1.2.15, 1.2.13
|
||||
- audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml # CIS 3.2.1
|
||||
- audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log # CIS 1.2.18
|
||||
- audit-log-maxage=30 # CIS 1.2.19
|
||||
- audit-log-maxbackup=10 # CIS 1.2.20
|
||||
- audit-log-maxsize=100 # CIS 1.2.21
|
||||
- request-timeout=300s # CIS 1.2.22
|
||||
- service-account-lookup=true # CIS 1.2.24
|
||||
kube-controller-manager-arg:
|
||||
- terminated-pod-gc-threshold=10 # CIS 1.3.1
|
||||
secrets-encryption: true
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
kubelet-arg:
|
||||
- make-iptables-util-chains=true # CIS 4.2.7
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="v1.24 及更早的版本">
|
||||
|
||||
```yaml
|
||||
apiVersion: provisioning.cattle.io/v1
|
||||
kind: Cluster
|
||||
metadata:
|
||||
name: # 定义集群名称
|
||||
spec:
|
||||
enableNetworkPolicy: true
|
||||
kubernetesVersion: # 定义 K3s 版本
|
||||
rkeConfig:
|
||||
machineGlobalConfig:
|
||||
kube-apiserver-arg:
|
||||
- enable-admission-plugins=NodeRestriction,PodSecurityPolicy,ServiceAccount # CIS 1.2.15, 5.2, 1.2.13
|
||||
- audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml # CIS 3.2.1
|
||||
- audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log # CIS 1.2.18
|
||||
- audit-log-maxage=30 # CIS 1.2.19
|
||||
- audit-log-maxbackup=10 # CIS 1.2.20
|
||||
- audit-log-maxsize=100 # CIS 1.2.21
|
||||
- request-timeout=300s # CIS 1.2.22
|
||||
- service-account-lookup=true # CIS 1.2.24
|
||||
kube-controller-manager-arg:
|
||||
- terminated-pod-gc-threshold=10 # CIS 1.3.1
|
||||
secrets-encryption: true
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
kubelet-arg:
|
||||
- make-iptables-util-chains=true # CIS 4.2.7
|
||||
protect-kernel-defaults: true # CIS 4.2.6
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## 结论
|
||||
|
||||
如果你按照本指南操作，由 Rancher 提供的 K3s 自定义集群将配置为通过 CIS Kubernetes Benchmark 测试。你可以查看我们的 K3s 自我评估指南，了解我们是如何验证每个 benchmarks 的，并且你可以在你的集群上执行相同的操作。
|
||||
+3152
File diff suppressed because it is too large
Load Diff
+3208
File diff suppressed because it is too large
Load Diff
+3215
File diff suppressed because it is too large
Load Diff
+517
@@ -0,0 +1,517 @@
|
||||
---
|
||||
title: RKE 加固指南
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide"/>
|
||||
</head>
|
||||
|
||||
<EOLRKE1Warning />
|
||||
|
||||
本文档提供了针对生产环境的 RKE 集群进行加固的具体指导，以便在使用 Rancher 部署之前进行配置。它概述了满足信息安全中心（Center for Information Security, CIS）Kubernetes benchmark controls 所需的配置和控制。
|
||||
|
||||
:::note
|
||||
这份加固指南描述了如何确保你集群中的节点安全。我们建议你在安装 Kubernetes 之前遵循本指南。
|
||||
:::
|
||||
|
||||
此加固指南适用于 RKE 集群，并与以下版本的 CIS Kubernetes Benchmark、Kubernetes 和 Rancher 相关联：
|
||||
|
||||
| Rancher 版本 | CIS Benchmark 版本 | Kubernetes 版本 |
|
||||
|-----------------|-----------------------|------------------------------|
|
||||
| Rancher v2.7 | Benchmark v1.23 | Kubernetes v1.23 |
|
||||
| Rancher v2.7 | Benchmark v1.24 | Kubernetes v1.24 |
|
||||
| Rancher v2.7 | Benchmark v1.7 | Kubernetes v1.25 至 v1.26 |
|
||||
|
||||
:::note
|
||||
- 在 Benchmark v1.24 及更高版本中，检查 id `4.1.7 Ensure that the certificate authorities file permissions are set to 600 or more restrictive (Automated)` 可能会失败，因为 `/etc/kubernetes/ssl/kube-ca.pem` 默认设置为 644。
|
||||
- 在 Benchmark v1.7 中，不再需要 `--protect-kernel-defaults` (`4.2.6`) 参数，并已被 CIS 删除。
|
||||
:::
|
||||
|
||||
有关如何评估加固的 RKE 集群与官方 CIS benchmark 的更多细节，请参考特定 Kubernetes 和 CIS benchmark 版本的 RKE 自我评估指南。
|
||||
|
||||
## 主机级别要求
|
||||
|
||||
### 配置 Kernel 运行时参数
|
||||
|
||||
建议对群集中的所有节点类型使用以下 `sysctl` 配置。在 `/etc/sysctl.d/90-kubelet.conf` 中设置以下参数：
|
||||
|
||||
```ini
|
||||
vm.overcommit_memory=1
|
||||
vm.panic_on_oom=0
|
||||
kernel.panic=10
|
||||
kernel.panic_on_oops=1
|
||||
```
|
||||
|
||||
运行 `sysctl -p /etc/sysctl.d/90-kubelet.conf` 以启用设置。
|
||||
|
||||
### 配置 `etcd` 用户和组
|
||||
|
||||
在安装 RKE 之前，需要设置 **etcd** 服务的用户帐户和组。
|
||||
|
||||
#### 创建 `etcd` 用户和组
|
||||
|
||||
要创建 **etcd** 用户和组，请运行以下控制台命令。
|
||||
下面的命令示例中使用 `52034` 作为 **uid** 和 **gid** 。
|
||||
任何有效且未使用的 **uid** 或 **gid** 都可以代替 `52034`。
|
||||
|
||||
```bash
|
||||
groupadd --gid 52034 etcd
|
||||
useradd --comment "etcd service account" --uid 52034 --gid 52034 etcd --shell /usr/sbin/nologin
|
||||
```
|
||||
|
||||
在通过集群配置文件 `config.yml` 部署RKE时，请更新 `etcd` 用户的 `uid` 和 `gid`：
|
||||
|
||||
```yaml
|
||||
services:
|
||||
etcd:
|
||||
gid: 52034
|
||||
uid: 52034
|
||||
```
|
||||
|
||||
## Kubernetes 运行时要求
|
||||
|
||||
### 配置 `default` Service Account
|
||||
|
||||
#### 设置 `automountServiceAccountToken` 为 `false` 用于 `default` service accounts
|
||||
|
||||
Kubernetes 提供了一个 default service account，供集群工作负载使用，其中没有为 pod 分配特定的 service account。
|
||||
如果需要从 pod 访问 Kubernetes API，则应为该 pod 创建特定的 service account，并向该 service account 授予权限。
|
||||
应配置 default service account，使其不提供 service account 令牌，并且不应具有任何明确的权限分配。
|
||||
|
||||
对于标准 RKE 安装上的每个命名空间（包括 `default` 和 `kube-system`），`default` service account 必须包含以下值：
|
||||
|
||||
```yaml
|
||||
automountServiceAccountToken: false
|
||||
```
|
||||
|
||||
将以下配置保存到名为 `account_update.yaml` 的文件中。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: default
|
||||
automountServiceAccountToken: false
|
||||
```
|
||||
|
||||
创建一个名为 `account_update.yaml` 的 bash 脚本文件。
|
||||
确保执行 `chmod +x account_update.sh` 命令，以赋予脚本执行权限。
|
||||
|
||||
```bash
|
||||
#!/bin/bash -e
|
||||
|
||||
for namespace in $(kubectl get namespaces -A -o=jsonpath="{.items[*]['metadata.name']}"); do
|
||||
kubectl patch serviceaccount default -n ${namespace} -p "$(cat account_update.yaml)"
|
||||
done
|
||||
```
|
||||
|
||||
执行此脚本将 `account_update.yaml` 配置应用到所有命名空间中的 `default` service account。
|
||||
|
||||
### 配置网络策略
|
||||
|
||||
#### 确保所有命名空间都定义了网络策略
|
||||
|
||||
在同一个 Kubernetes 集群上运行不同的应用程序会带来风险，即某个受感染的应用程序可能会攻击相邻的应用程序。为确保容器只与其预期通信的容器进行通信，网络分段至关重要。网络策略规定了哪些 Pod 可以互相通信，以及与其他网络终端通信的方式。
|
||||
|
||||
网络策略是命名空间范围的。当在特定命名空间引入网络策略时，所有未被策略允许的流量将被拒绝。然而，如果在命名空间中没有网络策略，那么所有流量将被允许进入和离开该命名空间中的 Pod。要强制执行网络策略，必须启用容器网络接口（container network interface, CNI）插件。本指南使用 [Canal](https://github.com/projectcalico/canal) 来提供策略执行。有关 CNI 提供程序的其他信息可以在[这里](https://www.suse.com/c/rancher_blog/comparing-kubernetes-cni-providers-flannel-calico-canal-and-weave/)找到。
|
||||
|
||||
一旦在集群上启用了 CNI 提供程序，就可以应用默认的网络策略。下面提供了一个 **permissive** 的示例供参考。如果你希望允许匹配某个命名空间中所有 Pod 的所有入站和出站流量（即使添加了策略导致某些 Pod 被视为”隔离”），你可以创建一个明确允许该命名空间中所有流量的策略。请将以下配置保存为 `default-allow-all.yaml`。有关网络策略的其他[文档](https://kubernetes.io/docs/concepts/services-networking/network-policies/)可以在 Kubernetes 站点上找到。
|
||||
|
||||
:::caution
|
||||
此网络策略只是一个示例，不建议用于生产用途。
|
||||
:::
|
||||
|
||||
```yaml
|
||||
---
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
name: default-allow-all
|
||||
spec:
|
||||
podSelector: {}
|
||||
ingress:
|
||||
- {}
|
||||
egress:
|
||||
- {}
|
||||
policyTypes:
|
||||
- Ingress
|
||||
- Egress
|
||||
```
|
||||
|
||||
创建一个名为 `apply_networkPolicy_to_all_ns.sh`的 Bash 脚本文件。
|
||||
|
||||
确保运行 `chmod +x apply_networkPolicy_to_all_ns.sh` 命令，以赋予脚本执行权限。
|
||||
|
||||
```bash
|
||||
#!/bin/bash -e
|
||||
|
||||
for namespace in $(kubectl get namespaces -A -o=jsonpath="{.items[*]['metadata.name']}"); do
|
||||
kubectl apply -f default-allow-all.yaml -n ${namespace}
|
||||
done
|
||||
```
|
||||
|
||||
执行此脚本以将 `default-allow-all.yaml` 配置和 **permissive** 的 `NetworkPolicy` 应用于所有命名空间。
|
||||
|
||||
## 已知限制
|
||||
|
||||
- 当注册自定义节点仅提供公共 IP 时，Rancher **exec shell** 和 **查看 pod 日志** 在加固设置中**不起作用**。 此功能需要在注册自定义节点时提供私有 IP。
|
||||
- 当根据 Rancher [提供](../../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md)的 Pod 安全策略 (Pod Security Policies, PSP) 将 `default_pod_security_policy_template_id:` 设置为 `restricted` 或 `restricted-noroot` 时，Rancher 会在 `default` service accounts 上创建 `RoleBindings` 和 `ClusterRoleBindings`。CIS 检查 5.1.5 要求除了默认角色之外，`default` service accounts 不应绑定其他角色或集群角色。此外，`default` service accounts 应配置为不提供服务账户令牌，也不具有任何明确的权限分配。
|
||||
|
||||
## 加固的 RKE `cluster.yml` 配置参考
|
||||
|
||||
参考的 `cluster.yml` 文件是由 RKE CLI 使用的，它提供了实现 RKE 加固安装所需的配置。
|
||||
RKE [文档](https://rancher.com/docs/rke/latest/en/installation/)提供了有关配置项的更多详细信息。这里参考的 `cluster.yml` 不包括必需的 `nodes` 指令，因为它取决于你的环境。在 RKE 中有关节点配置的文档可以在[这里](https://rancher.com/docs/rke/latest/en/config-options/nodes/)找到。
|
||||
|
||||
示例 `cluster.yml` 配置文件中包含了一个 Admission Configuration 策略，在 `services.kube-api.admission_configuration` 字段中指定。这个[示例](../../psa-restricted-exemptions.md)策略包含了命名空间的豁免规则，这对于在Rancher中正确运行导入的RKE集群非常必要，类似于Rancher预定义的 [`rancher-restricted`](../../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md) 策略。
|
||||
|
||||
如果你希望使用 RKE 的默认 `restricted` 策略，则将 `services.kube-api.admission_configuration` 字段留空，并将 `services.pod_security_configuration` 设置为 `restricted`。你可以在 [RKE 文档](https://rke.docs.rancher.com/config-options/services/pod-security-admission)中找到更多信息。
|
||||
|
||||
<Tabs groupId="rke1-version">
|
||||
<TabItem value="v1.25 及更新版本" default>
|
||||
|
||||
:::note
|
||||
如果你打算将一个 RKE 集群导入到 Rancher 中，请参考此[文档](../../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md)以了解如何配置 PSA 以豁免 Rancher 系统命名空间。
|
||||
:::
|
||||
|
||||
```yaml
|
||||
# 如果你打算在离线环境部署 Kubernetes，
|
||||
# 请查阅文档以了解如何配置自定义的 RKE 镜像。
|
||||
nodes: []
|
||||
kubernetes_version: # 定义 RKE 版本
|
||||
services:
|
||||
etcd:
|
||||
uid: 52034
|
||||
gid: 52034
|
||||
kube-api:
|
||||
secrets_encryption_config:
|
||||
enabled: true
|
||||
audit_log:
|
||||
enabled: true
|
||||
event_rate_limit:
|
||||
enabled: true
|
||||
# 如果你在 `admission_configuration` 中设置了自定义策略，
|
||||
# 请将 `pod_security_configuration` 字段留空。
|
||||
# 否则，将其设置为 `restricted` 以使用 RKE 预定义的受限策略，
|
||||
# 并删除 `admission_configuration` 字段中的所有内容。
|
||||
#
|
||||
# pod_security_configuration: restricted
|
||||
#
|
||||
admission_configuration:
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
kind: AdmissionConfiguration
|
||||
plugins:
|
||||
- name: PodSecurity
|
||||
configuration:
|
||||
apiVersion: pod-security.admission.config.k8s.io/v1
|
||||
kind: PodSecurityConfiguration
|
||||
defaults:
|
||||
enforce: "restricted"
|
||||
enforce-version: "latest"
|
||||
audit: "restricted"
|
||||
audit-version: "latest"
|
||||
warn: "restricted"
|
||||
warn-version: "latest"
|
||||
exemptions:
|
||||
usernames: []
|
||||
runtimeClasses: []
|
||||
namespaces: [calico-apiserver,
|
||||
calico-system,
|
||||
cattle-alerting,
|
||||
cattle-csp-adapter-system,
|
||||
cattle-elemental-system,
|
||||
cattle-epinio-system,
|
||||
cattle-externalip-system,
|
||||
cattle-fleet-local-system,
|
||||
cattle-fleet-system,
|
||||
cattle-gatekeeper-system,
|
||||
cattle-global-data,
|
||||
cattle-global-nt,
|
||||
cattle-impersonation-system,
|
||||
cattle-istio,
|
||||
cattle-istio-system,
|
||||
cattle-logging,
|
||||
cattle-logging-system,
|
||||
cattle-monitoring-system,
|
||||
cattle-neuvector-system,
|
||||
cattle-prometheus,
|
||||
cattle-provisioning-capi-system,
|
||||
cattle-resources-system,
|
||||
cattle-sriov-system,
|
||||
cattle-system,
|
||||
cattle-ui-plugin-system,
|
||||
cattle-windows-gmsa-system,
|
||||
cert-manager,
|
||||
cis-operator-system,
|
||||
fleet-default,
|
||||
ingress-nginx,
|
||||
istio-system,
|
||||
kube-node-lease,
|
||||
kube-public,
|
||||
kube-system,
|
||||
longhorn-system,
|
||||
rancher-alerting-drivers,
|
||||
security-scan,
|
||||
tigera-operator]
|
||||
kube-controller:
|
||||
extra_args:
|
||||
feature-gates: RotateKubeletServerCertificate=true
|
||||
kubelet:
|
||||
extra_args:
|
||||
feature-gates: RotateKubeletServerCertificate=true
|
||||
generate_serving_certificate: true
|
||||
addons: |
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
name: default-allow-all
|
||||
spec:
|
||||
podSelector: {}
|
||||
ingress:
|
||||
- {}
|
||||
egress:
|
||||
- {}
|
||||
policyTypes:
|
||||
- Ingress
|
||||
- Egress
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: default
|
||||
automountServiceAccountToken: false
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="v1.24 及更早版本">
|
||||
|
||||
```yaml
|
||||
# 如果你打算在离线环境部署 Kubernetes，
|
||||
# 请查阅文档以了解如何配置自定义的 RKE 镜像。
|
||||
nodes: []
|
||||
kubernetes_version: # 定义 RKE 版本
|
||||
services:
|
||||
etcd:
|
||||
uid: 52034
|
||||
gid: 52034
|
||||
kube-api:
|
||||
secrets_encryption_config:
|
||||
enabled: true
|
||||
audit_log:
|
||||
enabled: true
|
||||
event_rate_limit:
|
||||
enabled: true
|
||||
pod_security_policy: true
|
||||
kube-controller:
|
||||
extra_args:
|
||||
feature-gates: RotateKubeletServerCertificate=true
|
||||
kubelet:
|
||||
extra_args:
|
||||
feature-gates: RotateKubeletServerCertificate=true
|
||||
protect-kernel-defaults: true
|
||||
generate_serving_certificate: true
|
||||
addons: |
|
||||
# Upstream Kubernetes restricted PSP policy
|
||||
# https://github.com/kubernetes/website/blob/564baf15c102412522e9c8fc6ef2b5ff5b6e766c/content/en/examples/policy/restricted-psp.yaml
|
||||
apiVersion: policy/v1beta1
|
||||
kind: PodSecurityPolicy
|
||||
metadata:
|
||||
name: restricted-noroot
|
||||
spec:
|
||||
privileged: false
|
||||
# Required to prevent escalations to root.
|
||||
allowPrivilegeEscalation: false
|
||||
requiredDropCapabilities:
|
||||
- ALL
|
||||
# Allow core volume types.
|
||||
volumes:
|
||||
- 'configMap'
|
||||
- 'emptyDir'
|
||||
- 'projected'
|
||||
- 'secret'
|
||||
- 'downwardAPI'
|
||||
# Assume that ephemeral CSI drivers & persistentVolumes set up by the cluster admin are safe to use.
|
||||
- 'csi'
|
||||
- 'persistentVolumeClaim'
|
||||
- 'ephemeral'
|
||||
hostNetwork: false
|
||||
hostIPC: false
|
||||
hostPID: false
|
||||
runAsUser:
|
||||
# Require the container to run without root privileges.
|
||||
rule: 'MustRunAsNonRoot'
|
||||
seLinux:
|
||||
# This policy assumes the nodes are using AppArmor rather than SELinux.
|
||||
rule: 'RunAsAny'
|
||||
supplementalGroups:
|
||||
rule: 'MustRunAs'
|
||||
ranges:
|
||||
# Forbid adding the root group.
|
||||
- min: 1
|
||||
max: 65535
|
||||
fsGroup:
|
||||
rule: 'MustRunAs'
|
||||
ranges:
|
||||
# Forbid adding the root group.
|
||||
- min: 1
|
||||
max: 65535
|
||||
readOnlyRootFilesystem: false
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: psp:restricted-noroot
|
||||
rules:
|
||||
- apiGroups:
|
||||
- extensions
|
||||
resourceNames:
|
||||
- restricted-noroot
|
||||
resources:
|
||||
- podsecuritypolicies
|
||||
verbs:
|
||||
- use
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRoleBinding
|
||||
metadata:
|
||||
name: psp:restricted-noroot
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: psp:restricted-noroot
|
||||
subjects:
|
||||
- apiGroup: rbac.authorization.k8s.io
|
||||
kind: Group
|
||||
name: system:serviceaccounts
|
||||
- apiGroup: rbac.authorization.k8s.io
|
||||
kind: Group
|
||||
name: system:authenticated
|
||||
---
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
name: default-allow-all
|
||||
spec:
|
||||
podSelector: {}
|
||||
ingress:
|
||||
- {}
|
||||
egress:
|
||||
- {}
|
||||
policyTypes:
|
||||
- Ingress
|
||||
- Egress
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: default
|
||||
automountServiceAccountToken: false
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## 加固后的 RKE 集群模板配置参考
|
||||
|
||||
参考的 RKE 集群模板提供了实现 Kubernetes 加固安装所需的最低配置。RKE 模板用于提供 Kubernetes 并定义 Rancher 设置。有关安装 RKE 及其模板详情的其他信息，请参考 Rancher [文档](../../../../getting-started/installation-and-upgrade/installation-and-upgrade.md) 。
|
||||
|
||||
<Tabs groupId="rke1-version">
|
||||
<TabItem value="v1.25 及更新版本" default>
|
||||
|
||||
```yaml
|
||||
#
|
||||
# 集群配置
|
||||
#
|
||||
default_pod_security_admission_configuration_template_name: rancher-restricted
|
||||
enable_network_policy: true
|
||||
local_cluster_auth_endpoint:
|
||||
enabled: true
|
||||
name: # 定义集群名称
|
||||
|
||||
#
|
||||
# Rancher 配置
|
||||
#
|
||||
rancher_kubernetes_engine_config:
|
||||
addon_job_timeout: 45
|
||||
authentication:
|
||||
strategy: x509|webhook
|
||||
kubernetes_version: # 定义 RKE 版本
|
||||
services:
|
||||
etcd:
|
||||
uid: 52034
|
||||
gid: 52034
|
||||
kube-api:
|
||||
audit_log:
|
||||
enabled: true
|
||||
event_rate_limit:
|
||||
enabled: true
|
||||
pod_security_policy: false
|
||||
secrets_encryption_config:
|
||||
enabled: true
|
||||
kube-controller:
|
||||
extra_args:
|
||||
feature-gates: RotateKubeletServerCertificate=true
|
||||
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
|
||||
kubelet:
|
||||
extra_args:
|
||||
feature-gates: RotateKubeletServerCertificate=true
|
||||
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
|
||||
generate_serving_certificate: true
|
||||
scheduler:
|
||||
extra_args:
|
||||
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="v1.24 及更早版本">
|
||||
|
||||
```yaml
|
||||
#
|
||||
# 集群配置
|
||||
#
|
||||
default_pod_security_policy_template_id: restricted-noroot
|
||||
enable_network_policy: true
|
||||
local_cluster_auth_endpoint:
|
||||
enabled: true
|
||||
name: # 定义集群名称
|
||||
|
||||
#
|
||||
# Rancher 配置
|
||||
#
|
||||
rancher_kubernetes_engine_config:
|
||||
addon_job_timeout: 45
|
||||
authentication:
|
||||
strategy: x509|webhook
|
||||
kubernetes_version: # 定义 RKE 版本
|
||||
services:
|
||||
etcd:
|
||||
uid: 52034
|
||||
gid: 52034
|
||||
kube-api:
|
||||
audit_log:
|
||||
enabled: true
|
||||
event_rate_limit:
|
||||
enabled: true
|
||||
pod_security_policy: true
|
||||
secrets_encryption_config:
|
||||
enabled: true
|
||||
kube-controller:
|
||||
extra_args:
|
||||
feature-gates: RotateKubeletServerCertificate=true
|
||||
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
|
||||
kubelet:
|
||||
extra_args:
|
||||
feature-gates: RotateKubeletServerCertificate=true
|
||||
protect-kernel-defaults: true
|
||||
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
|
||||
generate_serving_certificate: true
|
||||
scheduler:
|
||||
extra_args:
|
||||
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## 结论
|
||||
|
||||
如果你按照本指南操作，由 Rancher 提供的 RKE 自定义集群将配置为通过 CIS Kubernetes Benchmark 测试。你可以查看我们的 RKE 自我评估指南，了解我们是如何验证每个 benchmarks 的，并且你可以在你的集群上执行相同的操作。
|
||||
+3089
File diff suppressed because one or more lines are too long
+3048
File diff suppressed because it is too large
Load Diff
+2864
File diff suppressed because it is too large
Load Diff
+273
@@ -0,0 +1,273 @@
|
||||
---
|
||||
title: RKE2 加固指南
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/hardening-guides/rke2-hardening-guide"/>
|
||||
</head>
|
||||
|
||||
本文档提供了针对生产环境的 RKE2 集群进行加固的具体指导，以便在使用 Rancher 部署之前进行配置。它概述了满足信息安全中心（Center for Information Security, CIS）Kubernetes benchmark controls 制所需的配置和控制。
|
||||
|
||||
:::note
|
||||
这份加固指南描述了如何确保你集群中的节点安全。我们建议你在安装 Kubernetes 之前遵循本指南。
|
||||
:::
|
||||
|
||||
此加固指南适用于 RKE2 集群，并与以下版本的 CIS Kubernetes Benchmark、Kubernetes 和 Rancher 相关联：
|
||||
|
||||
| Rancher 版本 | CIS Benchmark 版本 | Kubernetes 版本 |
|
||||
|-----------------|-----------------------|------------------------------|
|
||||
| Rancher v2.7 | Benchmark v1.23 | Kubernetes v1.23 |
|
||||
| Rancher v2.7 | Benchmark v1.24 | Kubernetes v1.24 |
|
||||
| Rancher v2.7 | Benchmark v1.7 | Kubernetes v1.25 至 v1.26 |
|
||||
|
||||
:::note
|
||||
- 在 Benchmark v1.24 及更高版本中，由于新的文件权限要求（600 而不是 644），一些检查 ID 可能会失败。受影响的检查 ID 包括：`1.1.1`, `1.1.3`, `1.1.5`, `1.1.7`, `1.1.13`, `1.1.15`, `1.1.17`, `4.1.3`, `4.1.5` 和 `4.1.9`。
|
||||
- 在 Benchmark v1.7 中，不再需要 `--protect-kernel-defaults` (4.2.6) 参数，并已被 CIS 删除。
|
||||
:::
|
||||
|
||||
有关如何评估加固的 RKE2 集群与官方 CIS benchmark 的更多细节，请参考特定 Kubernetes 和 CIS benchmark 版本的 RKE2 自我评估指南。
|
||||
|
||||
RKE2 在不需要修改的情况下通过了许多 Kubernetes CIS controls，因为它默认应用了几个安全缓解措施。然而，有一些值得注意的例外情况，需要手动干预才能完全符合 CIS Benchmark 要求：
|
||||
|
||||
1. RKE2 不会修改主机操作系统。因此，作为运维人员，你必须进行一些主机级别的修改。
|
||||
2. 某些 CIS controls 对于网络策略和 Pod 安全标准（或 RKE2 v1.25 之前的 Pod 安全策略 (PSP)）将限制集群的功能。你必须选择让 RKE2 为你配置这些功能。为了确保满足这些要求，可以启动 RKE2 并设置 profile 标志为 `cis-1.23`（适用于 v1.25 及更新版本）或 `cis-1.6`（适用于 v1.24 及更早版本）。
|
||||
|
||||
## 主机级别要求
|
||||
|
||||
主机级要求有两个方面：内核参数和 etcd 进程/目录配置。这些在本节中进行了概述。
|
||||
|
||||
### 确保 `protect-kernel-defaults` 已经设置
|
||||
|
||||
<Tabs groupId="k3s-version">
|
||||
<TabItem value="v1.25 及更新版本" default>
|
||||
|
||||
自 CIS benchmark 1.7 开始，不再需要`protect-kernel-defaults`。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="v1.24 及更早版本">
|
||||
|
||||
这是一个 kubelet 标志，如果所需的内核参数未设置或设置为与 kubelet 的默认值不同的值，将导致 kubelet 退出。
|
||||
|
||||
可以在 Rancher 的集群配置中设置 `protect-kernel-defaults` 标志。
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
rkeConfig:
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
protect-kernel-defaults: true
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### 设置内核参数
|
||||
|
||||
建议为集群中的所有节点类型设置以下 `sysctl` 配置。在 `/etc/sysctl.d/90-kubelet.conf` 中设置以下参数：
|
||||
|
||||
```ini
|
||||
vm.panic_on_oom=0
|
||||
vm.overcommit_memory=1
|
||||
kernel.panic=10
|
||||
kernel.panic_on_oops=1
|
||||
```
|
||||
|
||||
运行 `sudo sysctl -p /etc/sysctl.d/90-kubelet.conf` 以启用设置。
|
||||
|
||||
### 确保 etcd 配置正确
|
||||
|
||||
CIS Benchmark 要求 etcd 数据目录由 `etcd` 用户和组拥有。这意味着 etcd 进程必须以主机级别的 `etcd` 用户身份运行。为了实现这一点，在使用有效的 `cis-1.xx` 配置文件启动 RKE2 时，RKE2 会采取以下几个步骤：
|
||||
|
||||
1. 检查主机上是否存在 `etcd` 用户和组。如果不存在，则显示错误并退出。
|
||||
2. 使用 `etcd` 作为用户和组所有者创建 etcd 的数据目录。
|
||||
3. 通过适当设置 etcd 静态 Pod 的 `SecurityContext`，确保 etcd 进程以 `etcd` 用户和组的身份运行。
|
||||
|
||||
为满足上述要求，你必须执行以下操作：
|
||||
|
||||
#### 创建 etcd 用户
|
||||
|
||||
在某些 Linux 发行版中，`useradd` 命令不会创建组。下面包含了 `-U` 标志来解决这个问题。这个标志告诉 `useradd` 创建一个与用户同名的组。
|
||||
|
||||
```bash
|
||||
sudo useradd -r -c "etcd user" -s /sbin/nologin -M etcd -U
|
||||
```
|
||||
|
||||
## Kubernetes 运行时要求
|
||||
|
||||
通过 CIS Benchmark 测试的运行时要求主要集中在 Pod 安全、网络策略和内核参数上。当使用有效的 `cis-1.xx` 配置文件时，大部分都会被 RKE2 自动处理，但需要一些额外的运维人员干预是。本节概述了这些内容。
|
||||
|
||||
### Pod 安全
|
||||
|
||||
RKE2 始终以一定程度的 Pod 安全性运行。
|
||||
|
||||
<Tabs groupId="rke2-version">
|
||||
<TabItem value="v1.25 及更新版本" default>
|
||||
|
||||
在 v1.25 及更高版本中，[Pod 安全准入(PSAs)](https://kubernetes.io/docs/concepts/security/pod-security-admission/)用于保证 pod 安全。
|
||||
|
||||
以下是确保加固 RKE2 通过 Rancher 中提供的 CIS v1.23 加固配置文件 `rke2-cis-1.7-hardened` 所需的最低配置。
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
defaultPodSecurityAdmissionConfigurationTemplateName: rancher-restricted
|
||||
rkeConfig:
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
profile: cis-1.23
|
||||
```
|
||||
|
||||
当同时设置了 `defaultPodSecurityAdmissionConfigurationTemplateName` 和 `profile` 标志时，Rancher 和 RKE2 会执行以下操作：
|
||||
|
||||
1. 检查是否已满足主机级要求。如果未满足，RKE2 将以致命错误退出，并描述未满足的要求。
|
||||
2. 应用允许群集传递关联 controls 的网络策略。
|
||||
3. 配置 Pod 安全准入控制器（PSA）使用 PSA 配置模板 `rancher-restricted`，以在所有命名空间中强制执行受限模式，除了模板豁免列表中的命名空间。
|
||||
这些命名空间被豁免，以允许系统 Pod 在没有限制的情况下运行，这是集群正常运行所必需的。
|
||||
|
||||
:::note
|
||||
如果你打算将一个 RKE 集群导入到 Rancher 中，请参考[文档](../../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md)了解如何配置 PSA 以豁免 Rancher system 命名空间。
|
||||
:::
|
||||
|
||||
</TabItem>
|
||||
|
||||
<TabItem value="v1.24 及更早版本">
|
||||
|
||||
在 Kubernetes v1.24 及更早版本中，`PodSecurityPolicy` 准入控制器始终是启用的。
|
||||
|
||||
以下是确保 RKE2 加固以通过 Rancher 中提供的 CIS v1.23 加固配置文件 `rke2-cis-1.23-hardened` 所需的最低配置。
|
||||
|
||||
:::note
|
||||
在下面的示例中，配置文件设置为`cis-1.6`，这是在上游 RKE2 中定义的值，但集群实际上配置为传递 CIS v1.23 加固配置文件
|
||||
:::
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
defaultPodSecurityPolicyTemplateName: restricted-noroot
|
||||
rkeConfig:
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
profile: cis-1.6
|
||||
```
|
||||
|
||||
|
||||
当同时设置了 `defaultPodSecurityPolicyTemplateName` 和 `profile` 标志时，Rancher 和 RKE2 会执行以下操作：
|
||||
|
||||
1. 检查是否已满足主机级要求。如果未满足，RKE2 将以致命错误退出，并描述未满足的要求。
|
||||
2. 应用网络策略，以确保集群通过相关的 controls 要求。
|
||||
3. 配置运行时 Pod 安全策略，以确保集群通过相关的 controls 要求。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
:::note
|
||||
Kubernetes control plane 组件以及关键的附加组件，如 CNI、DNS 和 Ingress，都作为 `kube-system` 命名空间中的 Pod 运行。因此，这个命名空间的限制政策较少，从而使这些组件能够正常运行。
|
||||
:::
|
||||
|
||||
### 网络策略
|
||||
|
||||
当使用有效的 `cis-1.xx` 配置文件运行时，RKE2 将设置适当的 `NetworkPolicies`，以满足 Kubernetes 内置命名空间的 CIS Benchmark 要求。这些命名空间包括：`kube-system`、`kube-public`、`kube-node-lease` 和 `default`。
|
||||
|
||||
所使用的 `NetworkPolicy` 仅允许同一命名空间内的 Pod 相互通信。值得注意的例外是允许 DNS 请求进行解析。
|
||||
|
||||
:::note
|
||||
运维人员必须像管理其他命名空间一样管理额外创建的命名空间的网络策略。
|
||||
:::
|
||||
|
||||
### 配置 `default` service account
|
||||
|
||||
**将 `default` service accountsSet 的 `automountServiceAccountToken` 设置为 `false`**
|
||||
|
||||
Kubernetes 提供了一个 `default` service account，用于集群工作负载，在 pod 没有分配特定 service account 时使用。如果需要从 pod 访问 Kubernetes API，则应为该 pod 创建一个特定的 service account，并授予该 service account 权限。`default` service account 应配置为不提供 service account 令牌，并且不具有任何明确的权限分配。
|
||||
|
||||
对于标准的 RKE2 安装中的每个命名空间，包括 `default` 和 `kube-system`，`default` service account 必须包含此值：
|
||||
|
||||
```yaml
|
||||
automountServiceAccountToken: false
|
||||
```
|
||||
|
||||
对于由集群操作员创建的命名空间，可以使用以下脚本和配置文件来配置 `default` service account。
|
||||
|
||||
以下配置必须保存到一个名为 `account_update.yaml` 的文件中。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: default
|
||||
automountServiceAccountToken: false
|
||||
```
|
||||
|
||||
创建一个名为 `account_update.sh` 的 bash 脚本文件。确保运行 `sudo chmod +x account_update.sh` 命令，以便脚本具有执行权限。
|
||||
|
||||
```bash
|
||||
#!/bin/bash -e
|
||||
|
||||
for namespace in $(kubectl get namespaces -A -o=jsonpath="{.items[*]['metadata.name']}"); do
|
||||
echo -n "Patching namespace $namespace - "
|
||||
kubectl patch serviceaccount default -n ${namespace} -p "$(cat account_update.yaml)"
|
||||
done
|
||||
```
|
||||
|
||||
执行此脚本以将 `account_update.yaml` 配置应用到所有命名空间中的 `default` service account。
|
||||
|
||||
### API server 审计配置
|
||||
|
||||
CIS 要求 1.2.19 至 1.2.22 与为 API server 配置审计日志有关。当 RKE2 在设置配置文件标志的情况下启动时，它将自动在 API server 中配置加固的 `--audit-log-` 参数以通过这些 CIS 检查。
|
||||
|
||||
RKE2 的默认审计策略被配置为不记录 API server 中的请求。这样做是为了允许集群操作员灵活地定制符合其审计要求和需求的审计策略，因为这些策略是针对每个用户的环境和政策而特定的。
|
||||
|
||||
当使用 `profile` 标志启动 RKE2 时，RKE2 会创建一个默认的审计策略。该策略定义在 `/etc/rancher/rke2/audit-policy.yaml` 中。
|
||||
|
||||
```yaml
|
||||
apiVersion: audit.k8s.io/v1
|
||||
kind: Policy
|
||||
metadata:
|
||||
creationTimestamp: null
|
||||
rules:
|
||||
- level: None
|
||||
```
|
||||
|
||||
## 加固的 RKE2 模板配置参考
|
||||
|
||||
参考模板配置用于在 Rancher 中创建加固的 RKE2 自定义集群。该参考不包括其他必需的**集群配置**指令，这些指令会根据你的环境而有所不同。
|
||||
|
||||
<Tabs groupId="rke2-version">
|
||||
<TabItem value="v1.25 及更新版本" default>
|
||||
|
||||
```yaml
|
||||
apiVersion: provisioning.cattle.io/v1
|
||||
kind: Cluster
|
||||
metadata:
|
||||
name: # 定义集群名称
|
||||
spec:
|
||||
defaultPodSecurityAdmissionConfigurationTemplateName: rancher-restricted
|
||||
kubernetesVersion: # 定义 RKE2 版本
|
||||
rkeConfig:
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
profile: cis-1.23
|
||||
```
|
||||
</TabItem>
|
||||
|
||||
<TabItem value="v1.24 及更早版本">
|
||||
|
||||
```yaml
|
||||
apiVersion: provisioning.cattle.io/v1
|
||||
kind: Cluster
|
||||
metadata:
|
||||
name: # 定义集群名称
|
||||
spec:
|
||||
defaultPodSecurityPolicyTemplateName: restricted-noroot
|
||||
kubernetesVersion: # 定义 RKE2 版本
|
||||
rkeConfig:
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
profile: cis-1.6
|
||||
protect-kernel-defaults: true
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## 结论
|
||||
|
||||
如果你按照本指南操作，由 Rancher 提供的 RKE2 自定义集群将配置为通过 CIS Kubernetes Benchmark 测试。你可以查看我们的 RKE2 自我评估指南，了解我们是如何验证每个 benchmarks 的，并且你可以在你的集群上执行相同的操作。
|
||||
+3200
File diff suppressed because one or more lines are too long
+3202
File diff suppressed because one or more lines are too long
+2967
File diff suppressed because it is too large
Load Diff
+11
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: Kubernetes 安全最佳实践
|
||||
---
|
||||
|
||||
## 限制云元数据 API 访问
|
||||
|
||||
AWS、Azure、DigitalOcean 或 GCP 等云提供商通常会在本地向实例公开元数据服务。默认情况下，此端点可被运行在云实例上的 pod 访问，包括在托管的 Kubernetes（如 EKS、AKS、DigitalOcean Kubernetes 或 GKE）中的 pod，并且可以包含该节点的云凭证、配置数据（如 kubelet 凭证）以及其他敏感数据。为了降低在云平台上运行的这种风险，请遵循 [Kubernetes 安全建议](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/#restricting-cloud-metadata-api-access)，即限制授予实例凭证的权限，使用网络策略限制 pod 对元数据 API 的访问，并避免使用配置数据来传递密文。
|
||||
|
||||
建议你参阅你使用的云提供商的安全最佳实践，获取限制对云实例元数据 API 访问的建议和详情。
|
||||
|
||||
要获取更多参考资料，请参阅 MITRE ATT&CK 知识库 - [不安全凭证：云实例元数据 API](https://attack.mitre.org/techniques/T1552/005/)。
|
||||
+62
@@ -0,0 +1,62 @@
|
||||
---
|
||||
title: PodSecurityConfiguration 示例
|
||||
---
|
||||
|
||||
以下 PodSecurityConfiguration 包含了 `rancher-restricted` 集群正常运行所需的 Rancher 命名空间豁免。
|
||||
|
||||
```yaml
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
kind: AdmissionConfiguration
|
||||
plugins:
|
||||
- name: PodSecurity
|
||||
configuration:
|
||||
apiVersion: pod-security.admission.config.k8s.io/v1
|
||||
kind: PodSecurityConfiguration
|
||||
defaults:
|
||||
enforce: "restricted"
|
||||
enforce-version: "latest"
|
||||
audit: "restricted"
|
||||
audit-version: "latest"
|
||||
warn: "restricted"
|
||||
warn-version: "latest"
|
||||
exemptions:
|
||||
usernames: []
|
||||
runtimeClasses: []
|
||||
namespaces: [calico-apiserver,
|
||||
calico-system,
|
||||
cattle-alerting,
|
||||
cattle-csp-adapter-system,
|
||||
cattle-elemental-system,
|
||||
cattle-epinio-system,
|
||||
cattle-externalip-system,
|
||||
cattle-fleet-local-system,
|
||||
cattle-fleet-system,
|
||||
cattle-gatekeeper-system,
|
||||
cattle-global-data,
|
||||
cattle-global-nt,
|
||||
cattle-impersonation-system,
|
||||
cattle-istio,
|
||||
cattle-istio-system,
|
||||
cattle-logging,
|
||||
cattle-logging-system,
|
||||
cattle-monitoring-system,
|
||||
cattle-neuvector-system,
|
||||
cattle-prometheus,
|
||||
cattle-resources-system,
|
||||
cattle-sriov-system,
|
||||
cattle-system,
|
||||
cattle-ui-plugin-system,
|
||||
cattle-windows-gmsa-system,
|
||||
cert-manager,
|
||||
cis-operator-system,
|
||||
fleet-default,
|
||||
ingress-nginx,
|
||||
istio-system,
|
||||
kube-node-lease,
|
||||
kube-public,
|
||||
kube-system,
|
||||
longhorn-system,
|
||||
rancher-alerting-drivers,
|
||||
security-scan,
|
||||
tigera-operator]
|
||||
```
|
||||
+21
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: Rancher 安全最佳实践
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/rancher-security-best-practices"/>
|
||||
</head>
|
||||
|
||||
## 限制对 /version 和 /rancherversion 的公共访问
|
||||
|
||||
上游（本地） Rancher 实例提供正在运行的 Rancher 版本和用于构建它的 Go 版本信息。这些信息可以通过 `/version` 路径访问，该路径用于诸如自动化版本升级或确认部署成功等任务。上游实例还提供了可通过 `/rancherversion` 路径访问的 Rancher 版本信息。
|
||||
|
||||
攻击者可能会滥用这些信息来识别正在运行的 Rancher 版本，并与潜在的漏洞相关联以进行利用。如果你的上游 Rancher 实例在网上是公开可访问的，请使用 7 层防火墙来阻止 `/version` 和 `/rancherversion` 路径。
|
||||
|
||||
更多关于保护服务器的详细信息，请参阅 [OWASP Web Application Security Testing - Enumerate Infrastructure and Application Admin Interfaces](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/05-Enumerate_Infrastructure_and_Application_Admin_Interfaces.html)。
|
||||
|
||||
## 会话管理
|
||||
|
||||
某些环境可能需要额外的安全控制来管理会话。例如，你可能希望限制用户的并发活动会话或限制可以从哪些地理位置发起这些会话。Rancher 默认情况下不支持这些功能。
|
||||
|
||||
如果你需要此类功能，请将 7 层防火墙与[外部认证](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md#外部认证与本地认证)结合使用。
|
||||
+95
@@ -0,0 +1,95 @@
|
||||
---
|
||||
title: 安全
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security"/>
|
||||
</head>
|
||||
|
||||
<table width="100%">
|
||||
<tr style={{verticalAlign: 'top'}}>
|
||||
<td width="30%" style={{border: 'none'}}>
|
||||
<h4>安全策略</h4>
|
||||
<p style={{padding: '8px'}}>Rancher Labs 会负责任地披露问题，并致力于在合理的时间内解决所有问题。 </p>
|
||||
</td>
|
||||
<td width="30%" style={{border: 'none'}}>
|
||||
<h4>报告流程</h4>
|
||||
<p style={{padding: '8px'}}>请将安全问题发送至 <a href="mailto:security-rancher@suse.com">security-rancher@suse.com</a>。</p>
|
||||
</td>
|
||||
<td width="30%" style={{border: 'none'}}>
|
||||
<h4>公告</h4>
|
||||
<p style={{padding:'8px'}}>订阅 <a href="https://forums.rancher.com/c/announcements">Rancher 公告论坛</a>以获取版本更新。</p>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
安全是 Rancher 全部功能的基础。Rancher 集成了全部主流认证工具和服务，并提供了企业级的 [RBAC 功能](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)，让你的 Kubernetes 集群更加安全。
|
||||
|
||||
本文介绍了安全相关的文档以及资源，让你的 Rancher 安装和下游 Kubernetes 集群更加安全。
|
||||
|
||||
## NeuVector 与 Rancher 的集成
|
||||
|
||||
NeuVector 是一个开源的、以容器为中心的安全应用程序，现已集成到 Rancher 中。NeuVector 提供生产安全、DevOps 漏洞保护和容器防火墙等功能。请参阅 [Rancher 文档](../../integrations-in-rancher/neuvector/neuvector.md) 和 [NeuVector 文档](https://open-docs.neuvector.com/)了解更多信息。
|
||||
|
||||
## 在 Kubernetes 集群上运行 CIS 安全扫描
|
||||
|
||||
Rancher 使用 [kube-bench](https://github.com/aquasecurity/kube-bench) 来运行安全扫描，从而检查 Kubernetes 是否按照 [CIS](https://www.cisecurity.org/cis-benchmarks/)（Center for Internet Security，互联网安全中心）Kubernetes Benchmark 中定义的安全最佳实践进行部署。
|
||||
|
||||
CIS Kubernetes Benchmark 是一个参考文档，用于为 Kubernetes 建立安全配置基线。
|
||||
|
||||
CIS 是一个 501(c\)(3) 非营利组织，成立于 2000 年 10 月，其使命是识别、开发、验证、促进和维持网络防御的最佳实践方案，并建立和指导社区，以在网络空间中营造信任的环境。
|
||||
|
||||
CIS Benchmark 是目标系统安全配置的最佳实践。CIS Benchmark 是由安全专家、技术供应商、公开和私人社区成员，以及 CIS Benchmark 开发团队共同志愿开发的。
|
||||
|
||||
Benchmark 提供两种类型的建议，分别是自动（Automated）和手动（Manual）。我们只运行 Automated 相关的测试。
|
||||
|
||||
Rancher 在集群上运行 CIS 安全扫描时会生成一份报告，该报告会显示每个测试的结果，包括测试概要以及 `passed`、`skipped` 和 `failed` 的测试数量。报告还包括失败测试的修正步骤。
|
||||
|
||||
有关详细信息，请参阅[安全扫描](../../how-to-guides/advanced-user-guides/cis-scan-guides/cis-scan-guides.md)。
|
||||
|
||||
## SELinux RPM
|
||||
|
||||
[安全增强型 Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) 是对 Linux 的安全增强。被政府机构使用之后，SELinux 已成为行业标准，并在 CentOS 7 和 8 上默认启用。
|
||||
|
||||
我们提供了 `rancher-selinux` 和 `rke2-selinux` 两个 RPM（Red Hat 软件包），让 Rancher 产品能够在 SELinux 主机上正常运行。有关详细信息，请参阅[此页面](selinux-rpm/selinux-rpm.md)。
|
||||
|
||||
## Rancher 加固指南
|
||||
|
||||
Rancher 加固指南基于 <a href="https://www.cisecurity.org/benchmark/kubernetes/" target="_blank">CIS Kubernetes Benchmark</a>。
|
||||
|
||||
加固指南为加固 Rancher 的生产安装提供了说明性指导。有关安全管控的完整列表，请参阅 Rancher 的 [CIS Kubernetes Benchmark 自我评估](#cis-benchmark-和自我评估)指南。
|
||||
|
||||
> 加固指南描述了如何保护集群中的节点，建议在安装 Kubernetes 之前参考加固指南中的步骤。
|
||||
|
||||
每个加固指南版本都针对特定的 CIS Kubernetes Benchmark、Kubernetes 和 Rancher 版本。
|
||||
|
||||
## CIS Benchmark 和自我评估
|
||||
|
||||
Benchmark 自我评估是 Rancher 安全加固指南的辅助。加固指南展示了如何加固集群，而 Benchmark 指南旨在帮助你评估加固集群的安全级别。
|
||||
|
||||
由于 Rancher 和 RKE 将 Kubernetes 服务安装为 Docker 容器，因此 CIS Kubernetes Benchmark 中的许多管控验证检查都不适用。本指南将介绍各种 controls，并提供更新的示例命令来审计 Rancher 创建的集群的合规性。你可以前往 [CIS 网站](https://www.cisecurity.org/benchmark/kubernetes/)下载原始的 Benchmark 文档。
|
||||
|
||||
Rancher 自我评估指南的每个版本都对应于强化指南、Rancher、Kubernetes 和 CIS Benchmark 的特定版本。
|
||||
|
||||
## 第三方渗透测试报告
|
||||
|
||||
Rancher 会定期聘请第三方对 Rancher 软件栈进行安全审计和渗透测试。被测环境遵循 Rancher 在测试时提供的强化指南。以前的渗透测试报告如下。
|
||||
|
||||
结果：
|
||||
|
||||
- [Cure53 渗透测试 - 2019 年 7 月](https://releases.rancher.com/documents/security/pen-tests/2019/RAN-01-cure53-report.final.pdf)
|
||||
- [Untamed Theory 渗透测试 - 2019 年 3 月](https://releases.rancher.com/documents/security/pen-tests/2019/UntamedTheory-Rancher_SecurityAssessment-20190712_v5.pdf)
|
||||
|
||||
请注意，新报告不再共享或公开发布。
|
||||
|
||||
## Rancher 安全公告和 CVE
|
||||
|
||||
Rancher 致力于向社区通报我们产品中的安全问题。有关我们已解决的问题的 CVE（常见漏洞和暴露）列表，请参阅[此页](security-advisories-and-cves.md)。
|
||||
|
||||
## Kubernetes 安全最佳实践
|
||||
|
||||
有关保护 Kubernetes 集群的建议，请参阅 [Kubernetes 安全最佳实践](kubernetes-security-best-practices.md)指南。
|
||||
|
||||
## Rancher 安全最佳实践
|
||||
|
||||
有关保护 Rancher Manager 部署的建议，请参阅 [Rancher 安全最佳实践](rancher-security-best-practices.md)指南。
|
||||
+137
@@ -0,0 +1,137 @@
|
||||
---
|
||||
title: 加固 Rancher Webhook
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/rancher-webhook-hardening"/>
|
||||
</head>
|
||||
|
||||
Rancher Webhook 是 Rancher 中的一个重要组件，它在强制执行 Rancher 及其工作负载的安全要求方面发挥着重要的作用。为了减少其攻击面，对它的访问应限制为唯一有效的调用方：Kubernetes API server。这可以通过单独使用网络策略和认证，或相互结合使用以加固 webhook 免受攻击。
|
||||
|
||||
## 使用网络策略阻止外部流量
|
||||
|
||||
webhook 只应接受来自 Kubernetes API server 的请求。但是默认情况下，webhook 可以接受来自任何源的流量。如果你使用的是支持网络策略的 CNI，则可以创建一个策略来阻止来源不是 API server 的流量。
|
||||
|
||||
Kubernetes 中内置的网络策略资源无法阻止或允许来自集群主机的流量，并且 `kube-apiserver` 进程在主机网络上运行。因此你必须使用当前集群正在使用的 CNI 的高级网络策略资源。以下是 Calico 和 Cilium 的示例。更多详细的信息，请参阅你使用的 CNI 的文档。
|
||||
|
||||
### Calico
|
||||
|
||||
使用 `crd.projectcalico.org/v1` API 组中的网络策略资源。使用 `app == 'rancher-webhook'` selector 为 webhook 创建一个规则，并且将 control plane 主机的 CIDR 设置为入口源：
|
||||
|
||||
```yaml
|
||||
apiVersion: crd.projectcalico.org/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
name: allow-k8s
|
||||
namespace: cattle-system
|
||||
spec:
|
||||
selector: app == 'rancher-webhook'
|
||||
types:
|
||||
- Ingress
|
||||
ingress:
|
||||
- action: Allow
|
||||
protocol: TCP
|
||||
source:
|
||||
nets:
|
||||
- 192.168.42.0/24 # control plane 主机的 CIDR。如果主机位于不同的子网中，则可能会列出多个。
|
||||
destination:
|
||||
selector:
|
||||
app == 'rancher-webhook'
|
||||
```
|
||||
|
||||
### Cilium
|
||||
|
||||
使用 `cilium.io/v2` API 组中的 CiliumNetworkPolicy 资源。将 `host` 和 `remote-node` 键添加到 `fromEntities` 入口规则。这会阻止集群内和外部流量，同时允许来自主机的流量。
|
||||
|
||||
```yaml
|
||||
apiVersion: "cilium.io/v2"
|
||||
kind: CiliumNetworkPolicy
|
||||
metadata:
|
||||
name: allow-k8s
|
||||
namespace: cattle-system
|
||||
spec:
|
||||
endpointSelector:
|
||||
matchLabels:
|
||||
app: rancher-webhook
|
||||
ingress:
|
||||
- fromEntities:
|
||||
- host
|
||||
- remote-node
|
||||
```
|
||||
|
||||
## 要求 Kubernetes API Server 对 Webhook 进行认证
|
||||
|
||||
Webhook 应仅接受来自 Kubernetes API server 的请求。默认情况下，webhook 不要求客户端对其进行认证。它可以接受任何请求。你可以配置 webhook 验证凭据，以便只有 API server 可以访问它。更多信息可以在 [Kubernetes 文档](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#authenticate-apiservers)中找到。
|
||||
|
||||
1. 配置 API server 向 webhook 提供证书，指向 AdmissionConfiguration 文件以配置 ValidatingAdmissionWebhook 和 MutatingAdmissionWebhook 插件：
|
||||
|
||||
```yaml
|
||||
# /etc/rancher/admission/admission.yaml
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
kind: AdmissionConfiguration
|
||||
plugins:
|
||||
- name: ValidatingAdmissionWebhook
|
||||
configuration:
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
kind: WebhookAdmissionConfiguration
|
||||
kubeConfigFile: "/etc/rancher/admission/kubeconfig"
|
||||
- name: MutatingAdmissionWebhook
|
||||
configuration:
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
kind: WebhookAdmissionConfiguration
|
||||
kubeConfigFile: "/etc/rancher/admission/kubeconfig"
|
||||
```
|
||||
|
||||
这也是配置其他准入插件的同一配置文件，例如 PodSecurity。如果你的发行版或设置使用了额外的准入插件，请将它们也配置在这里。例如，将 [RKE2 的 PodSecurity 配置](https://docs.rke2.io/security/pod_security_standards)添加到这个文件中。
|
||||
|
||||
2. 创建准入插件引用的 kubeconfig 文件。Rancher Webhook 仅支持客户端证书认证，因此请生成一个 TLS 密钥对，并且将 kubeconfig 设置为使用 `client-certificate` 和 `client-key` 或者使用 `client-certificate-data` 和 `client-key-data`。 例如：
|
||||
|
||||
```yaml
|
||||
# /etc/rancher/admission/kubeconfig
|
||||
apiVersion: v1
|
||||
kind: Config
|
||||
users:
|
||||
- name: 'rancher-webhook.cattle-system.svc'
|
||||
user:
|
||||
client-certificate: /path/to/client/cert
|
||||
client-key: /path/to/client/key
|
||||
```
|
||||
|
||||
3. 使用 `--admission-control-config-file` 参数启动 kube-apiserver 服务，并将该参数值指向你的 AdmissionConfiguration 文件。具体的操作方式因发行版而异，并不受普遍支持，例如在托管的 Kubernetes 提供商中可能不支持。请查阅你的 Kubernetes 发行版的文档以获取详细的信息。
|
||||
|
||||
对于 RKE2，可以使用这样的配置文件启动 `rke2-server`：
|
||||
|
||||
```yaml
|
||||
# /etc/rancher/rke2/config.yaml
|
||||
kube-apiserver-arg:
|
||||
- admission-control-config-file=/etc/rancher/admission/admission.yaml
|
||||
kube-apiserver-extra-mount:
|
||||
- /etc/rancher/admission:/etc/rancher/admission:ro
|
||||
```
|
||||
|
||||
:::danger
|
||||
某些发行版会默认设置此参数。如果你的发行版预配置了它自己的 AdmissionConfiguration，则必须将其包含在你自定义的准入控制的配置文件中。例如，RKE2 在 `/etc/rancher/rke2/rke2-pss.yaml` 安装了一个 AdmissionConfiguration 文件，该文件配置了 PodSecurity 准入插件。在 config.yaml 中设置 `admission-control-config-file` 将会覆盖这个重要的安全设置。要包含两个插件，请参阅 [Default Pod Security Standards 文档](https://docs.rke2.io/security/pod_security_standards)并将相应的插件配置复制到你的 admission.yaml 中。
|
||||
:::
|
||||
|
||||
4. 如果你使用 Rancher 通过现有节点来配置你的集群，请在配置集群之前在节点上创建这些文件。
|
||||
|
||||
如果你使用 Rancher 在新节点上配置你的集群，请先允许集群配置完成，然后使用 Rancher 提供的 SSH key 和 IP 地址连接到节点，并将 RKE2 的配置文件放在 `/etc/rancher/rke2/config.yaml.d/` 目录下。
|
||||
|
||||
5. 使用这些凭证配置集群后，配置 Rancher cluster agent 以在 webhook 中启用认证。创建一个包含以下内容的 chart values 的文件：
|
||||
|
||||
```yaml
|
||||
# values.yaml
|
||||
auth:
|
||||
clientCA: <base64-encoded certificate authority that signed the kube-apiserver's client certificates>
|
||||
allowedCNs:
|
||||
- <list of Common Names identifying the kube-apiserver's client certificates.>
|
||||
- <if not provided, any cert signed by the given CA will be accepted.>
|
||||
```
|
||||
|
||||
6. 在配置的集群中的 `cattle-system` 命名空间下创建一个 configmap，并包含这些 values 配置：
|
||||
|
||||
```
|
||||
kubectl --namespace cattle-system create configmap rancher-config --from-file=rancher-webhook=values.yaml
|
||||
```
|
||||
|
||||
webhook 将会使用这些 values 配置重新启动。
|
||||
+66
@@ -0,0 +1,66 @@
|
||||
---
|
||||
title: 安全公告和 CVE
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/security-advisories-and-cves"/>
|
||||
</head>
|
||||
|
||||
Rancher 致力于向社区披露我们产品的安全问题。我们会针对已解决的问题发布安全公告和 CVE（Common Vulnerabilities and Exposures，通用漏洞披露）。Rancher GitHub 上的[安全页面](https://github.com/rancher/rancher/security/advisories)也会发布新的安全公告。
|
||||
|
||||
| ID | 描述 | 日期 | 解决 |
|
||||
|----|-------------|------|------------|
|
||||
| [CVE-2025-23390](https://github.com/rancher/fleet/security/advisories/GHSA-xgpc-q899-67p8) | This vulnerability only affects customers using [Continuous Delivery with Fleet](https://ranchermanager.docs.rancher.com/integrations-in-rancher/fleet) where Fleet does not validate a server's certificate when connecting through SSH. This can allow for a main-in-the-middle-attack against Fleet. The fix provides a new `insecureSkipHostKeyChecks` value for the `fleet` Helm chart. The default value is set to **`true` (opt-in) for Rancher v2.9 - v2.11** for backward compatibility. The default value is set to **`false` (opt-out) for Rancher v2.12 and later**, and Fleet v0.13 and later. <br/><br/> `true` (opt-in): <br/><br/><ul> If `insecureSkipHostKeyChecks` is set to `true`, then not finding any matching `known_hosts` entry for an SSH host will not lead to any error. Please note, regardless of the configuration setting, if the `known-hosts` ConfigMap is deleted it will lead to errors as it will be considered a symptom of an incomplete Fleet deployment. </ul> `false` (opt-out): <br/><br/><ul> If `insecureSkipHostKeyChecks` is set to `false`, then strict host key checks are enabled. When enabled, the checks ensure that when using SSH, Fleet rejects connection attempts to hosts not matching any entry found in (decreasing order of precedence): <br/><br/><ul> <li>A secret referenced by name in a `GitRepo` which is located in the same `GitRepo's` namespace.</li> <li> If no such secret name is provided, in a `gitcredential` secret located in the same namespace. </li> <li> A new `known-hosts` ConfigMap, created during the Fleet chart installation time and located in the namespace `cattle-fleet-system`. </li></ul> <br></br> This happens regardless of whether a `GitRepo` uses an SSH URL to point to a Git repository since, once cloned, a repository may be found to contain external resources to be retrieved, such as Helm artifacts. </ul> A limitation with the default `known_hosts` entries is that they are only provided for GitHub, Gitlab, Bitbucket and Azure DevOps hosts. If you need to connect to a different host, or if key fingerprints for the provided entries are updated, the following options are available: <br/><br/><ul><li> Manually update the default `known-hosts` ConfigMap. </li> <li> Reference a secret from your `GitRepo` resources, containing the updated or additional `known_hosts` entries. </li> <li> Create a `gitcredential` secret containing the entries for `GitRepo` resources that do not already reference a secret. </li></ul> | 24 Apr 2025 | Rancher [v2.11.1](https://github.com/rancher/rancher/releases/tag/v2.11.1), [v2.10.5](https://github.com/rancher/rancher/releases/tag/v2.10.5), and [v2.9.9](https://github.com/rancher/rancher/releases/tag/v2.9.9) |
|
||||
| [CVE-2025-22031](https://github.com/rancher/rancher/security/advisories/GHSA-8h6m-wv39-239m) | A vulnerability was found where users could create a project and then gain access to arbitrary projects. As a fix, a new field has been added to projects called the `BackingNampespace`, which represents the namespace created for a project containing all resources needed for project operations. This includes resources such as ProjectRoleTemplateBindings, project-scoped secrets and workloads. <br/><br/> The field is populated automatically during project creation and is formatted as `<clusterID>-<project.Name>`. For example, if your project is named `project-abc123` in a cluster with ID `cluster-xyz789`, then the project will have the `BackingNampespace`: `cluster-xyz789-project-abc123`. <br/><br/> If the `BackingNampespace` field is empty then the project will fallback to using the namespace that is the project's name as it did before. Existing projects will not be migrated and only newly created projects will have the new namespace naming convention. If listing projects via `kubectl` the `BackingNampespace` will also be listed as a column. | 24 Apr 2025 | Rancher [v2.11.1](https://github.com/rancher/rancher/releases/tag/v2.11.1), [v2.10.5](https://github.com/rancher/rancher/releases/tag/v2.10.5), and [v2.9.9](https://github.com/rancher/rancher/releases/tag/v2.9.9) |
|
||||
| [CVE-2025-32198](https://github.com/rancher/steve/security/advisories/GHSA-95fc-g4gj-mqmx) | A vulnerability was found where users with permission to create a service in the Kubernetes cluster where Rancher is deployed can take over the Rancher UI, display their own UI, and gather sensitive information. This is only possible when the setting `ui-offline-preferred` is set to `remote`. This release introduces a patch, and the malicious user can no longer serve their own UI. If users can't upgrade, please make sure that only trustable users have access to create a service in the local cluster. | 24 Apr 2025 | Rancher [v2.11.1](https://github.com/rancher/rancher/releases/tag/v2.11.1), [v2.10.5](https://github.com/rancher/rancher/releases/tag/v2.10.5), [v2.9.9](https://github.com/rancher/rancher/releases/tag/v2.9.9) and [v2.8.15](https://github.com/rancher/rancher/releases/tag/v2.8.15) |
|
||||
| [CVE-2025-23391](https://github.com/rancher/rancher/security/advisories/GHSA-8p83-cpfg-fj3g) | A vulnerability has been identified within Rancher where a Restricted Administrator can change the password of Administrators and take over their accounts. A Restricted Administrator should not be allowed to change the password of more privileged users unless it contains the Manage Users permissions. A new validation has been added to block a user from editing or deleting another user with more permissions than themselves. Rancher deployments where the Restricted Administrator role is not being used are not affected by this CVE. | 31 Mar 2025 | Rancher [v2.11.0](https://github.com/rancher/rancher/releases/tag/v2.11.0), [v2.10.4](https://github.com/rancher/rancher/releases/tag/v2.10.4), [v2.9.8](https://github.com/rancher/rancher/releases/tag/v2.9.8) and [v2.8.14](https://github.com/rancher/rancher/releases/tag/v2.8.14) |
|
||||
| [CVE-2025-23389](https://github.com/rancher/rancher/security/advisories/GHSA-5qmp-9x47-92q8) | A vulnerability in Rancher has been discovered, leading to a local user impersonation through SAML Authentication on first login. <br/><br/> The issue occurs when a SAML authentication provider (AP) is configured (e.g. Keycloak). A newly created AP user can impersonate any user on Rancher by manipulating cookie values during their initial login to Rancher. This vulnerability could also be exploited if a Rancher user (present on the AP) is removed, either manually or automatically via the [User Retention feature](../../how-to-guides/advanced-user-guides/enable-user-retention.md) with delete-inactive-user-after | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) |
|
||||
| [CVE-2025-23388](https://github.com/rancher/rancher/security/advisories/GHSA-xr9q-h9c7-xw8q) | An unauthenticated stack overflow crash, leading to a denial of service (DoS), was identified in Rancher’s `/v3-public/authproviders` public API endpoint. A malicious user could submit data to the API which would cause the Rancher server to crash, but no malicious or incorrect data would actually be written in the API. The downstream clusters, i.e., the clusters managed by Rancher, are not affected by this issue. <br/><br/> This vulnerability affects those using external authentication providers as well as Rancher’s local authentication. | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) |
|
||||
| [CVE-2025-23387](https://github.com/rancher/rancher/security/advisories/GHSA-mq23-vvg7-xfm4) | A vulnerability has been identified within Rancher where it is possible for an unauthenticated user to list all CLI authentication tokens and delete them before the CLI is able to get the token value. This effectively prevents users from logging in via the CLI when using rancher token as the execution command (instead of the token directly being in the kubeconfig). <br/><br/> Note that this token is not the kubeconfig token and if an attacker is able to intercept it they can't use it to impersonate a real user since it is encrypted. | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) |
|
||||
| [CVE-2024-52281](https://github.com/rancher/rancher/security/advisories/GHSA-2v2w-8v8c-wcm9) | A high severity vulnerability was identified within the Rancher UI that allows a malicious actor to perform a Stored XSS attack through the cluster description field. | 15 Jan 2025 | Rancher [v2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) and [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) |
|
||||
| [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) | 发现了 Rancher 和 Fleet 代理的一个漏洞，目前被认为是中到高危的 CVE。在非特定情况下，这个漏洞允许恶意行为者接管现有的 Rancher 节点。攻击者需要控制一个过期的域名，或者对该域名执行 DNS 欺骗/劫持攻击才可以利用此漏洞。被攻击的域名是 Rancher URL（用作 Rancher 集群的 server-url）。目前还没有可用的修复方案，它影响所有受支持的 Rancher 版本。建议客户和用户遵循我们[博客文章](https://www.suse.com/c/rancher-security-update/)中描述的建议和最佳实践。 | 2024 年 9 月 19 日 | 处理中 |
|
||||
| [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) |
|
||||
| [CVE-2023-22650](https://github.com/rancher/rancher/security/advisories/GHSA-9ghh-mmcq-8phc) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where Rancher did not have a user retention process for when external authentication providers are used, that could be configured to run periodically and disable and/or delete inactive users. The new user retention process added in Rancher v2.8.5 and Rancher v2.7.14 is disabled by default. If enabled, a user becomes subject to the retention process if they don't log in for a configurable period of time. It's possible to set overrides for user accounts that are primarily intended for programmatic access (e.g. CI, scripts, etc.) so that they don't become subject to the retention process for a longer period of time or at all. | 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-32191](https://github.com/rancher/rke/security/advisories/GHSA-6gr4-52w6-vmqx) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, in which supported RKE versions store credentials inside a ConfigMap that can be accessible by non-administrative users in Rancher. This vulnerability only affects an RKE-provisioned cluster. | 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-32193](https://github.com/rancher/norman/security/advisories/GHSA-r8f4-hv23-6qp6) | 在 Rancher 2.6.13、2.7.9 和 2.8.1 及之前的版本中发现了一个问题。多个 Cross-Site Scripting (XSS) 漏洞可通过 Rancher UI (Norman) 进行利用。 | 2024 年 2 月 8 日 | 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) 和 [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) | 在 Rancher 2.6.13、2.7.9 和 2.8.1 及之前的版本中发现了一个问题。多个 Cross-Site Scripting (XSS) 漏洞，可以通过 Rancher UI (Apiserver) 进行利用 | 2024 年 2 月 8 日 | 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) 和 [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
|
||||
| [CVE-2023-22649](https://github.com/rancher/rancher/security/advisories/GHSA-xfj7-qf8w-2gcr) | 在 Rancher 2.6.13、2.7.9 和 2.8.1 及之前的版本中发现了一个问题。敏感数据可能会泄漏到 Rancher 的审计日志中。 | 2024 年 2 月 8 日 | 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) 和 [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
|
||||
| [CVE-2023-32194](https://github.com/rancher/rancher/security/advisories/GHSA-c85r-fwc7-45vc) | 在 Rancher 2.6.13、2.7.9 和 2.8.1 及之前的版本中发现了一个问题。当为 “namespace” 资源类型授予 `create` 或 `*` 全局角色时，任何 API 组中拥有权限的用户可以管理核心 API 组中的 namespace。 | 2024 年 2 月 8 日 | 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) 和 [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
|
||||
| [CVE-2023-22648](https://github.com/rancher/rancher/security/advisories/GHSA-vf6j-6739-78m8) | 在 Rancher 2.6.12 和 2.7.3 及之前的版本中发现了一个问题。在用户注销并重新登录到 Rancher UI 之前，Azure AD 中的权限更改不会反映给用户。 | 2023 年 5 月 31 日 | Rancher [v2.7.4](https://github.com/rancher/rancher/releases/tag/v2.7.4) |
|
||||
| [CVE-2022-43760](https://github.com/rancher/rancher/security/advisories/GHSA-46v3-ggjg-qq3x) | 在 Rancher 2.6.12 和 2.7.3 及之前的版本中发现了一个问题。攻击者可以通过 Rancher UI 利用多个跨站脚本 (XSS) 漏洞。 | 2023 年 5 月 31 日 | Rancher [v2.7.4](https://github.com/rancher/rancher/releases/tag/v2.7.4) |
|
||||
| [CVE-2020-10676](https://github.com/rancher/rancher/security/advisories/GHSA-8vhc-hwhc-cpj4) | 在 Rancher 2.6.12 和 2.7.3 及之前的版本中发现了一个问题。具有更新命名空间权限的用户可以将该命名空间移动到他们无权访问的项目中。 | 2023 年 5 月 31 日 | Rancher [v2.7.4](https://github.com/rancher/rancher/releases/tag/v2.7.4) |
|
||||
| [CVE-2023-22647](https://github.com/rancher/rancher/security/advisories/GHSA-p976-h52c-26p6) | 在 Rancher 2.6.12 和 2.7.3 及之前的版本中发现了一个问题。Standard 及以上用户能够将他们的权限提升为 local 集群中的管理员。 | 2023 年 5 月 31 日 | Rancher [v2.7.4](https://github.com/rancher/rancher/releases/tag/v2.7.4) |
|
||||
| [CVE-2023-22651](https://github.com/rancher/rancher/security/advisories/GHSA-6m9f-pj6w-w87g) | 由于 webhook 的更新逻辑失败，Rancher 准入 webhook 可能会配置错误。准入 webhook 在资源允许进入 Kubernetes 集群之前会强制执行验证规则和安全检查。webhook 在降级状态下运行时将不再验证任何资源，这可能导致严重的权限提升和数据损坏。 | 2023 年 4 月 24 日 | Rancher [v2.7.3](https://github.com/rancher/rancher/releases/tag/v2.7.3) |
|
||||
| [CVE-2022-43758](https://github.com/rancher/rancher/security/advisories/GHSA-34p5-jp77-fcrc) | 在 Rancher 2.5.0 至 2.5.16、2.6.0 至 2.6.9 和 2.7.0 版本中发现了一个问题，Rancher Git 包中存在命令注入漏洞。这个包使用 Rancher 容器镜像中可用的底层 Git 二进制文件来执行 Git 操作。特制的命令如果没有消除歧义，可能会在通过 Git 执行时造成混淆，导致在底层 Rancher 主机中进行命令注入。 | 2023 年 1 月 24 日 | Rancher [v2.7.1](https://github.com/rancher/rancher/releases/tag/v2.7.1)、[v2.6.10](https://github.com/rancher/rancher/releases/tag/v2.6.10) 和 [v2.5.17](https://github.com/rancher/rancher/releases/tag/v2.5.17) |
|
||||
| [CVE-2022-43757](https://github.com/rancher/rancher/security/advisories/GHSA-cq4p-vp5q-4522) | 此问题影响 Rancher 2.5.0 到 2.5.16，2.6.0 至 2.6.9 和 2.7.0。我们发现 Rancher 之前发布的安全公告 [CVE-2021-36782](https://github.com/advisories/GHSA-g7j7-h4q8-8w2f) 没有解决某些敏感字段、Secret Token、加密密钥和 SSH 密钥，这些字段仍然以明文形式直接存储在 Kubernetes 上 `Clusters` 之类的对象。在 Rancher 中，集群中已认证的 `Cluster Owners`、`Cluster Members`、`Project Owners` 和 `Project Members` 可以看到公开的凭证。 | 2023 年 1 月 24 日 | Rancher [v2.7.1](https://github.com/rancher/rancher/releases/tag/v2.7.1)、[v2.6.10](https://github.com/rancher/rancher/releases/tag/v2.6.10) 和 [v2.5.17](https://github.com/rancher/rancher/releases/tag/v2.5.17) |
|
||||
| [CVE-2022-43755](https://github.com/rancher/rancher/security/advisories/GHSA-8c69-r38j-rpfj) | 在 Rancher 2.6.9 和 2.7.0 及之前的版本中发现了一个问题。`cattle-cluster-agent` 使用的 `cattle-token` Secret 是可预测的。重新生成 Token 之后，Token 的值依然相同。如果 Token 被泄露并且出于安全目的需要重新创建，这可能会造成严重的问题。Rancher 的 `cattle-cluster-agent` 使用 `cattle-token` 来连接到 Rancher 配置的下游集群 Kubernetes API。 | 2023 年 1 月 24 日 | Rancher [v2.7.1](https://github.com/rancher/rancher/releases/tag/v2.7.1) 和 [v2.6.10](https://github.com/rancher/rancher/releases/tag/v2.6.10) |
|
||||
| [CVE-2022-21953](https://github.com/rancher/rancher/security/advisories/GHSA-g25r-gvq3-wrq7) | 在 Rancher 2.5.16、2.6.9 和 2.7.0 及之前的版本中发现了一个问题。由于授权逻辑缺陷，任何下游集群上经过身份认证的用户都能在 Rancher `local` 集群中打开一个 shell pod (1)，而且对 kubectl 具有有限的访问权限 (2)。预期的行为是：除非明确授予权限，否则用户在 Rancher `local` 集群中没有这样的访问权限。 | 2023 年 1 月 24 日 | Rancher [v2.7.1](https://github.com/rancher/rancher/releases/tag/v2.7.1)、[v2.6.10](https://github.com/rancher/rancher/releases/tag/v2.6.10) 和 [v2.5.17](https://github.com/rancher/rancher/releases/tag/v2.5.17) |
|
||||
| [GHSA-c45c-39f6-6gw9](https://github.com/rancher/rancher/security/advisories/GHSA-c45c-39f6-6gw9) | 此问题影响 Rancher 2.5.0 到 2.5.16，2.6.0 至 2.6.9 和 2.7.0。只会影响配置了或配置过外部身份认证提供程序的 Rancher 设置。我们发现，当在 Rancher 中配置外部身份认证提供程序然后将其禁用时，Rancher 生成的 Token 如果关联了通过现已禁用的身份认证提供程序授予访问权限的用户，那么 Token 不会被撤销。 | 2023 年 1 月 24 日 | Rancher [v2.7.1](https://github.com/rancher/rancher/releases/tag/v2.7.1)、[v2.6.10](https://github.com/rancher/rancher/releases/tag/v2.6.10) 和 [v2.5.17](https://github.com/rancher/rancher/releases/tag/v2.5.17) |
|
||||
| [CVE-2022-31247](https://github.com/rancher/rancher/security/advisories/GHSA-6x34-89p7-95wg) | 在 Rancher 2.5.15 和 2.6.6 及之前的版本中发现了一个问题。授权逻辑缺陷允许在下游集群中通过集群角色模板绑定 (CRTB) 和项目角色模板绑定 (PRTB) 来提升权限。任何有权限创建/编辑 CRTB 或 PRTB 的用户（例如 `cluster-owner`、`manage cluster members`、`project-owner` 和 `manage project members`）都可以利用该漏洞，在同一集群的另一个项目或不同下游集群的另一个项目中获得所有者权限。 | 2022 年 8 月 18 日 | [Rancher 2.6.7](https://github.com/rancher/rancher/releases/tag/v2.6.7) 和 [Rancher 2.5.16](https://github.com/rancher/rancher/releases/tag/v2.5.16) |
|
||||
| [CVE-2021-36783](https://github.com/rancher/rancher/security/advisories/GHSA-8w87-58w6-hfv8) | 2.5.12 到 2.6.3 的 Rancher 版本无法正确清理集群模板 answer 中的凭证。此错误可能会导致明文存储以及凭证、密码和 API 令牌被暴露。在 Rancher 中，已认证的 `Cluster Owner`、`Cluster Member`、`Project Owner` 和 `Project Member` 可以在 `/v1/management.cattle.io.clusters`、`/v3/clusters` 和 `/k8s/clusters/local/apis/management.cattle.io/v3/clusters` 端点上看到暴露的凭证。 | 2022 年 8 月 18 日 | [Rancher 2.6.7](https://github.com/rancher/rancher/releases/tag/v2.6.7) 和 [Rancher 2.5.16](https://github.com/rancher/rancher/releases/tag/v2.5.16) |
|
||||
| [CVE-2021-36782](https://github.com/rancher/rancher/security/advisories/GHSA-g7j7-h4q8-8w2f) | 在 2.5.15 到 2.6.6 的 Rancher 版本中发现了一个问题，其中密码、API 密钥和 Rancher 的 ServiceAccount 令牌（用于配置集群）等敏感字段直接以明文形式存储在 `Cluster` 等 Kubernetes 对象上（例如，`cluster.management.cattle.io`）。任何能够读取 Kubernetes API 中的对象的用户都可以检索这些敏感数据的明文版本。该问题由 Florian Struck（来自 [Continum AG](https://www.continum.net/)）和 [Marco Stuurman](https://github.com/fe-ax)（来自 [Shock Media B.V.](https://www.shockmedia.nl/)）发现并报告。 | 2022 年 8 月 18 日 | [Rancher 2.6.7](https://github.com/rancher/rancher/releases/tag/v2.6.7) 和 [Rancher 2.5.16](https://github.com/rancher/rancher/releases/tag/v2.5.16) |
|
||||
| [CVE-2022-21951](https://github.com/rancher/rancher/security/advisories/GHSA-vrph-m5jj-c46c) | 此漏洞仅影响通过 [RKE 模板](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/about-rke1-templates.md)配置 [Weave](../../faq/container-network-interface-providers.md#weave) 容器网络接口 (CNI) 的客户。在 Rancher 2.5.0 到 2.5.13 和 Rancher 2.6.0 到 2.6.4 版本中发现了一个漏洞。如果将 CNI 选为 Weave，RKE 模板的用户界面 (UI) 不包括 Weave 密码的值。如果基于上述模板创建集群，并且将 Weave 配置为 CNI，则 Weave 中不会为[网络加密](https://github.com/weaveworks/weave/blob/master/site/tasks/manage/security-untrusted-networks.md)创建密码。因此，集群中的网络流量将不加密发送。 | 2022 年 5 月 24 日 | [Rancher 2.6.5](https://github.com/rancher/rancher/releases/tag/v2.6.5) 和 [Rancher 2.5.14](https://github.com/rancher/rancher/releases/tag/v2.5.14) |
|
||||
| [CVE-2021-36784](https://github.com/rancher/rancher/security/advisories/GHSA-jwvr-vv7p-gpwq) | 在 Rancher 2.5.0 到 2.5.12 和 Rancher 2.6.0 到 2.6.3 中发现了一个漏洞，该漏洞允许能创建或更新[全局角色](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)的用户将他们或其他用户升级为管理员。全局角色能授予用户 Rancher 级别的权限，例如能创建集群。在已识别的 Rancher 版本中，如果用户被授予了编辑或创建全局角色的权限，他们不仅仅能授予他们已经拥有的权限。此漏洞影响使用能够创建或编辑全局角色的非管理员用户的客户。此场景最常见的用例是 `restricted-admin` 角色。 | 2022 年 4 月 14 日 | [Rancher 2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) 和 [Rancher 2.5.13](https://github.com/rancher/rancher/releases/tag/v2.5.13) |
|
||||
| [CVE-2021-4200](https://github.com/rancher/rancher/security/advisories/GHSA-hx8w-ghh8-r4xf) | 此漏洞仅影响在 Rancher 中使用 `restricted-admin` 角色的客户。在 Rancher 2.5.0 到 2.5.12 和 2.6.0 到 2.6.3 中发现了一个漏洞，其中 `cattle-global-data` 命名空间中的 `global-data` 角色授予了应用商店的写权限。由于具有任何级别的应用商店访问权限的用户都会绑定到 `global-data` 角色，因此这些用户都能写入模板 `CatalogTemplates`) 和模板版本 (`CatalogTemplateVersions`)。在 Rancher 中创建的新用户默认分配到 `user` 角色（普通用户），该角色本不该具有写入应用商店的权限。此漏洞提升了能写入应用商店模板和应用商店模板版本资源的用户的权限。 | 2022 年 4 月 14 日 | [Rancher 2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) 和 [Rancher 2.5.13](https://github.com/rancher/rancher/releases/tag/v2.5.13) |
|
||||
| [GHSA-wm2r-rp98-8pmh](https://github.com/rancher/rancher/security/advisories/GHSA-wm2r-rp98-8pmh) | 此漏洞仅影响使用经过认证的 Git 和/或 Helm 仓库通过 [Fleet](../../integrations-in-rancher/fleet/fleet.md) 进行持续交付的客户。在 [`v1.5.11`](https://github.com/hashicorp/go-getter/releases/tag/v1.5.11) 之前版本中的 `go-getter` 库中发现了一个问题，错误消息中没有删除 Base64 编码的 SSH 私钥，导致该信息暴露。Rancher 中 [`v0.3.9`](https://github.com/rancher/fleet/releases/tag/v0.3.9) 之前的 Fleet 版本使用了该库的漏洞版本。此问题影响 Rancher 2.5.0 到 2.5.12（包括 2.5.12）以及 2.6.0 到 2.6.3（包括 2.6.3）。该问题由 Raft Engineering 的 Dagan Henderson 发现并报告。 | 2022 年 4 月 14 日 | [Rancher 2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) 和 [Rancher 2.5.13](https://github.com/rancher/rancher/releases/tag/v2.5.13) |
|
||||
| [CVE-2021-36778](https://github.com/rancher/rancher/security/advisories/GHSA-4fc7-hc63-7fjg) | 在 Rancher 2.5.0 到 2.5.11 和 Rancher 2.6.0 到 2.6.2 中发现了一个漏洞，当从配置的私有仓库下载 Helm Chart 时，对同源策略的检查不足可能导致仓库凭证暴露给第三方提供商。仅当用户在 Rancher 的`应用 & 应用市场 > 仓库`中配置私有仓库的访问凭证时才会出现此问题。该问题由 Martin Andreas Ullrich 发现并报告。 | 2022 年 4 月 14 日 | [Rancher 2.6.3](https://github.com/rancher/rancher/releases/tag/v2.6.3) 和 [Rancher 2.5.12](https://github.com/rancher/rancher/releases/tag/v2.5.12) |
|
||||
| [GHSA-hwm2-4ph6-w6m5](https://github.com/rancher/rancher/security/advisories/GHSA-hwm2-4ph6-w6m5) | 在 Rancher 2.0 到 2.6.3 中发现了一个漏洞。Rancher 提供的 `restricted` Pod 安全策略（PSP）与 Kubernetes 提供的上游 `restricted` 策略有差别，因此 Rancher 的 PSP 将 `runAsUser` 设置为 `runAsAny`，而上游将 `runAsUser` 设置为 `MustRunAsNonRoot`。因此，即使 Rancher 的 `restricted` 策略是在项目或集群级别上强制执行的，容器也可以以任何用户身份运行，包括特权用户 (`root`)。 | 2022 年 3 月 31 日 | [Rancher 2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) |
|
||||
| [CVE-2021-36775](https://github.com/rancher/rancher/security/advisories/GHSA-28g7-896h-695v) | 在 Rancher 2.4.17、2.5.11 和 2.6.2 以及更高的版本中发现了一个漏洞。从项目中删除与某个组关联的`项目角色`后，能让这些使用者访问集群级别资源的绑定（Binding）不会被删除。导致问题的原因是不完整的授权逻辑检查。如果用户是受影响组中的成员，且能对 Rancher 进行认证访问，那么用户可以利用此漏洞访问他们不应该能访问的资源。暴露级别取决于受影响项目角色的原始权限级别。此漏洞仅影响在 Rancher 中基于组进行身份验证的客户。 | 2022 年 3 月 31 日 | [Rancher 2.6.3](https://github.com/rancher/rancher/releases/tag/v2.6.3)、[Rancher 2.5.12](https://github.com/rancher/rancher/releases/tag/v2.5.12) 和 [Rancher 2.4.18](https://github.com/rancher/rancher/releases/tag/v2.4.18) |
|
||||
| [CVE-2021-36776](https://github.com/rancher/rancher/security/advisories/GHSA-gvh9-xgrq-r8hw) | 在 Rancher 2.5.0 到 2.5.9 中发现了一个漏洞，该漏洞允许经过认证用户通过 API 代理模拟集群上的任何用户，而无需知道被模拟用户的凭证。问题的原因是 API 代理在将请求发送到 Kubernetes API 之前未删除模拟标头。能认证访问 Rancher 的恶意用户可以冒充另一个在 Rancher 认证用户，从而对集群进行管理员级别的访问。 | 2022 年 3 月 31 日 | [Rancher 2.6.0](https://github.com/rancher/rancher/releases/tag/v2.6.0) 和 [Rancher 2.5.10](https://github.com/rancher/rancher/releases/tag/v2.5.10) |
|
||||
| [CVE-2021-25318](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25318) | Rancher 2.0 的不可编辑版本发现了一个漏洞，在该版本中，无论资源的 API 组如何，用户都可以访问资源。例如，Rancher 应该允许用户访问 `apps.catalog.cattle.io`，但却错误地授予了对 `apps.*` 的访问权限。你可以在[这里](https://github.com/rancher/rancher/security/advisories/GHSA-f9xf-jq4j-vqw4)找到**下游集群**和 **Rancher 管理集群**中受影响的资源。除了升级到打了补丁的 Rancher 版本之外，暂时没有直接的缓解措施。 | 2021 年 7 月 14 日 | [Rancher 2.5.9](https://github.com/rancher/rancher/releases/tag/v2.5.9) 和 [Rancher 2.4.16](https://github.com/rancher/rancher/releases/tag/v2.4.16) |
|
||||
| [CVE-2021-31999](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31999) | Rancher 2.0.0 的补丁版本发现了一个漏洞，恶意的 Rancher 用户可以针对托管集群的 Kubernetes API 的代理发起一个 API 请求，以获取他们无权访问的信息。这是通过在 Connection 标头中传递 “Impersonate-User” 或 “Impersonate-Group” 标头来实现的，然后代理会删除该标头。此时，请求不会模拟用户及其权限，而是会类似 Rancher management server 的请求，并错误地返回信息。该漏洞仅影响对集群具有一定级别权限的 Rancher 用户。除了升级到打了补丁的 Rancher 版本之外，暂时没有直接的缓解措施。 | 2021 年 7 月 14 日 | [Rancher 2.5.9](https://github.com/rancher/rancher/releases/tag/v2.5.9) 和 [Rancher 2.4.16](https://github.com/rancher/rancher/releases/tag/v2.4.16) |
|
||||
| [CVE-2021-25320](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25320) | Rancher 2.2.0 的补丁版本发现了一个漏洞，云凭证没有正确通过 Rancher API 验证。具体地说，是通过用于与云提供商通信的代理。任何登录并具有有效云提供商云凭证 ID 的 Rancher 用户都可以通过代理 API 调用该云提供商的 API，并且云凭证会被绑定。该漏洞仅影响有效的 Rancher 用户。除了升级到打了补丁的 Rancher 版本之外，暂时没有直接的缓解措施。 | 2021 年 7 月 14 日 | [Rancher 2.5.9](https://github.com/rancher/rancher/releases/tag/v2.5.9) 和 [Rancher 2.4.16](https://github.com/rancher/rancher/releases/tag/v2.4.16) |
|
||||
| [CVE-2021-25313](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25313) | 所有 Rancher 2 版本上都发现了一个安全漏洞。使用浏览器访问 Rancher API 时，URL 没有正确转义，导致它容易受到 XSS 攻击。这些 API 端点的特制 URL 可能包括嵌入页面并在浏览器中执行的 JavaScript。暂时没有直接的缓解措施。请不要单击指向 Rancher Server 的不受信任链接。 | 2021 年 3 月 2 日 | [Rancher v2.5.6](https://github.com/rancher/rancher/releases/tag/v2.5.6)、[Rancher v2.4.14](https://github.com/rancher/rancher/releases/tag/v2.4.14) 和 [Rancher v2.3.11](https://github.com/rancher/rancher/releases/tag/v2.3.11) |
|
||||
| [CVE-2019-14435](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14435) | 此漏洞让已验证的用户可以通过 Rancher 使用的系统服务容器可访问的 IP 提取私有数据。这包括但不限于云提供商元数据服务等服务。虽然 Rancher 允许用户为系统服务配置白名单域，但这个漏洞仍然可以被精心设计的 HTTP 请求利用。该问题由 Workiva 的 Matt Belisle 和 Alex Stevenson 发现并报告。 | 2019 年 8 月 5 日 | [Rancher 2.2.7](https://github.com/rancher/rancher/releases/tag/v2.2.7) 和 [Rancher 2.1.12](https://github.com/rancher/rancher/releases/tag/v2.1.12) |
|
||||
| [CVE-2019-14436](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14436) | 该漏洞允许有权编辑角色绑定的项目成员为自己或其他用户分配集群级别的角色，从而授予他们对该集群的管理员访问权限。该问题由 Nokia 的 Michal Lipinski 发现并报告。 | 2019 年 8 月 5 日 | [Rancher 2.2.7](https://github.com/rancher/rancher/releases/tag/v2.2.7) 和 [Rancher 2.1.12](https://github.com/rancher/rancher/releases/tag/v2.1.12) |
|
||||
| [CVE-2019-13209](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13209) | 该漏洞被称为[跨网页 Websocket 劫持攻击](https://www.christian-schneider.net/CrossSiteWebSocketHijacking.html)。该攻击允许攻击者以受害用户的角色/权限访问由 Rancher 管理的集群。它让受害用户登录到 Rancher Server，然后访问由攻击者托管的第三方站点。完成后，攻击者就可以使用受害用户的权限和身份对 Kubernetes API 执行命令。该问题由 Workiva 的 Matt Belisle 和 Alex Stevenson 报告。 | 2019 年 7 月 15 日 | [Rancher 2.2.5](https://github.com/rancher/rancher/releases/tag/v2.2.5)、[Rancher 2.1.11](https://github.com/rancher/rancher/releases/tag/v2.1.11) 和 [Rancher 2.0.16](https://github.com/rancher/rancher/releases/tag/v2.0.16) |
|
||||
| [CVE-2019-12303](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12303) | 项目所有者可以注入额外的 fluentd 日志配置，从而在 fluentd 容器内读取文件或执行任意命令。该问题由 Untamed Theory 的 Tyler Welton 报告。 | 2019 年 6 月 5 日 | [Rancher 2.2.4](https://github.com/rancher/rancher/releases/tag/v2.2.4)、[Rancher 2.1.10](https://github.com/rancher/rancher/releases/tag/v2.1.10) 和 [Rancher 2.0.15](https://github.com/rancher/rancher/releases/tag/v2.0.15) |
|
||||
| [CVE-2019-12274](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12274) | 如果节点使用的内置主机驱动使用了文件路径选项，则节点可以读取 Rancher Server 容器内的任意文件，包括敏感文件。 | 2019 年 6 月 5 日 | [Rancher 2.2.4](https://github.com/rancher/rancher/releases/tag/v2.2.4)、[Rancher 2.1.10](https://github.com/rancher/rancher/releases/tag/v2.1.10) 和 [Rancher 2.0.15](https://github.com/rancher/rancher/releases/tag/v2.0.15) |
|
||||
| [CVE-2019-11202](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11202) | 即使已被显式删除，Rancher 的默认管理员会在 Rancher 重启时重新创建。 | 2019 年 4 月 16 日 | [Rancher 2.2.2](https://github.com/rancher/rancher/releases/tag/v2.2.2)、[Rancher 2.1.9](https://github.com/rancher/rancher/releases/tag/v2.1.9) 和 [Rancher 2.0.14](https://github.com/rancher/rancher/releases/tag/v2.0.14) |
|
||||
| [CVE-2019-6287](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6287) | 如果将项目成员添加到多个项目中，则成员还能继续访问被删除的项目中的命名空间。 | 2019 年 1 月 29 日 | [Rancher 2.1.6](https://github.com/rancher/rancher/releases/tag/v2.1.6) 和 [Rancher 2.0.11](https://github.com/rancher/rancher/releases/tag/v2.0.11) |
|
||||
| [CVE-2018-20321](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20321) | 任何有权访问 `default` 命名空间的项目成员都可以在 pod 中挂载 `netes-default` ServiceAccount，然后使用该 pod 对 Kubernetes 集群执行管理特权命令。 | 2019 年 1 月 29 日 | [Rancher 2.1.6](https://github.com/rancher/rancher/releases/tag/v2.1.6) 和 [Rancher 2.0.11](https://github.com/rancher/rancher/releases/tag/v2.0.11) - 对于这些版本或更高版本，我们有对应的[回滚说明](../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rollbacks.md)。 |
|
||||
+66
@@ -0,0 +1,66 @@
|
||||
---
|
||||
title: 关于 rancher-selinux
|
||||
---
|
||||
|
||||
要让 Rancher 使用 SELinux，你必须手动为 SELinux 节点启用一些功能。为了解决这个问题，Rancher 提供了一个 SELinux RPM。
|
||||
|
||||
The `rancher-selinux` RPM contains a set of SELinux policies designed to grant the necessary privileges to various Rancher components running on Linux systems with SELinux enabled.
|
||||
|
||||
`rancher-selinux` 的 GitHub 仓库在[这里](https://github.com/rancher/rancher-selinux)。
|
||||
|
||||
## 安装 rancher-selinux RPM
|
||||
|
||||
:::note 要求
|
||||
|
||||
rancher-selinux RPM 已在 CentOS 7 和 8 上进行了测试。
|
||||
|
||||
:::
|
||||
|
||||
### 1. 设置 yum 仓库
|
||||
|
||||
设置 yum 仓库，从而直接在集群中的所有主机上安装 `rancher-selinux`。
|
||||
|
||||
要使用 RPM 仓库，在 CentOS 7 或 RHEL 7 系统上运行以下 bash 代码片段：
|
||||
|
||||
```
|
||||
# cat << EOF > /etc/yum.repos.d/rancher.repo
|
||||
[rancher]
|
||||
name=Rancher
|
||||
baseurl=https://rpm.rancher.io/rancher/production/centos/7/noarch
|
||||
enabled=1
|
||||
gpgcheck=1
|
||||
gpgkey=https://rpm.rancher.io/public.key
|
||||
EOF
|
||||
```
|
||||
|
||||
要使用 RPM 仓库，在 CentOS 8 或 RHEL 8 系统上运行以下 bash 代码片段：
|
||||
|
||||
```
|
||||
# cat << EOF > /etc/yum.repos.d/rancher.repo
|
||||
[rancher]
|
||||
name=Rancher
|
||||
baseurl=https://rpm.rancher.io/rancher/production/centos/8/noarch
|
||||
enabled=1
|
||||
gpgcheck=1
|
||||
gpgkey=https://rpm.rancher.io/public.key
|
||||
EOF
|
||||
```
|
||||
### 2. 安装 RPM
|
||||
|
||||
安装 RPM：
|
||||
|
||||
```
|
||||
yum -y install rancher-selinux
|
||||
```
|
||||
|
||||
## 配置 Logging 应用程序以使用 SELinux
|
||||
|
||||
:::note 要求
|
||||
|
||||
Logging v2 已在 RHEL/CentOS 7 和 8 上使用 SELinux 进行了测试。
|
||||
|
||||
:::
|
||||
|
||||
在主机上安装 `rancher-selinux` RPM 后，应用程序不会自动运行。它们需要在 RPM 提供的允许的 SELinux 容器域中运行。
|
||||
|
||||
要将 `rancher-logging` Chart 配置为支持 SELinux，请在安装 Chart 时将 `values.yaml` 中的 `global.seLinux.enabled` 更改为 true。
|
||||
+9
@@ -0,0 +1,9 @@
|
||||
---
|
||||
title: 关于 rke2-selinux
|
||||
---
|
||||
|
||||
`rke2-selinux` 为 RKE2 提供策略。如果 RKE2 安装程序脚本检测到它运行在基于 RPM 的发行版上，它会自动安装。
|
||||
|
||||
`rke2-selinux` 的 GitHub 仓库在[这里](https://github.com/rancher/rke2-selinux)。
|
||||
|
||||
有关在启用 SELinux 的主机上安装 RKE2 的更多信息，请参阅 [RKE2 文档](https://docs.rke2.io/install/methods#rpm)。
|
||||
+20
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: SELinux RPM
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/selinux-rpm"/>
|
||||
</head>
|
||||
|
||||
[安全增强型 Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) 是对 Linux 的安全增强。
|
||||
|
||||
它由 Red Hat 开发，是 Linux 上 MAC（mandatory access controls，强制访问控制）的实现。系统管理员可以使用 MAC 设置应用程序和用户是如何访问不同资源的，例如文件、设备、网络和进程间的通信。SELinux 还通过默认限制操作系统来增强安全性。
|
||||
|
||||
被政府机构使用之后，SELinux 已成为行业标准，并在 CentOS 7 和 8 上默认启用。要检查 SELinux 是否在你的系统上启用和执行，请使用 `getenforce`：
|
||||
|
||||
```
|
||||
# getenforce
|
||||
Enforcing
|
||||
```
|
||||
|
||||
我们提供了 [`rancher-selinux`](about-rancher-selinux.md) 和 [`rke2-selinux`](about-rke2-selinux.md) 两个 RPM（Red Hat 软件包），让 Rancher 产品能够在 SELinux 主机上正常运行。
|
||||
Reference in New Issue
Block a user