SUSE Rancher Prime 安全最佳实践
限制对 /version 和 /rancherversion 的公共访问
上游（本地） Rancher 实例提供正在运行的 Rancher 版本和用于构建它的 Go 版本信息。这些信息可以通过 /version 路径访问，该路径用于诸如自动化版本升级或确认部署成功等任务。上游实例还提供了可通过 /rancherversion 路径访问的 Rancher 版本信息。
攻击者可能会滥用这些信息来识别正在运行的 Rancher 版本，并与潜在的漏洞相关联以进行利用。如果你的上游 Rancher 实例在网上是公开可访问的，请使用 7 层防火墙来阻止 /version 和 /rancherversion 路径。
会话管理
某些环境可能需要额外的安全控制来管理会话。例如，你可能希望限制用户的并发活动会话或限制可以从哪些地理位置发起这些会话。Rancher 默认情况下不支持这些功能。
如果你需要此类功能，请将 7 层防火墙与外部认证结合使用。
Use External Load Balancers to Protect Vulnerable Ports
You should protect the following ports behind an external load balancer that has SSL offload enabled:
-
K3s: Port 6443, used by the Kubernetes API.
-
RKE2: Port 6443, used by the Kubernetes API, and port 9345, used for node registration.
These ports have TLS SAN certificates which list nodes' public IP addresses. An attacker could use that information to gain unauthorized access or monitor activity on the cluster. Protecting these ports helps mitigate against nodes' public IP addresses being disclosed to potential attackers.
Rancher Username Policy
By default, Kubernetes does not provide enforcement mechanisms for baseline username policies. In Rancher, this means that any enforcement of username formats, naming conventions, or baseline policies is expected to be handled by the external identity provider’s policies, if such policies are in place.
In Rancher, admin is the default username for the Administrator user, as highlighted here
Examples of potential baseline policies include:
-
Requiring usernames to follow an organizational convention (e.g.,
firstname.lastname) -
Enforcing minimum or maximum length requirements
-
Disallowing certain special characters
-
Preventing impersonation by disallowing reserved names (e.g.,
admin,root)
Without these controls at the identity provider layer, there is a risk of inconsistent or insecure username practices, which can complicate access audits and lead to privilege escalation attempts.
|
Rancher currently enforces only a minimum password length. |
Recommendation: We strongly advice that customers:
-
Review and configure username baseline policies directly in their external identity providers (e.g., LDAP, Active Directory, SAML, or OIDC).
-
Ensure that those policies align with the organization’s security and compliance requirements.
-
Regularly audit user accounts to detect naming inconsistencies or policy violations.
For more information, see:
WAF Rules
Rancher is designed to support a wide range of deployment scenarios, including environments where customers may programmatically automate the creation or provisioning of large numbers of clusters. Imposing strict application-level limits within Rancher itself could interfere with legitimate workloads that require dynamic scaling.
For example:
-
CI/CD pipelines may create and tear down clusters frequently.
-
Self-service portals could provision clusters on-demand for developers.
-
Test environments may generate high volumes of API calls.
Risk: Without appropriate rate limiting, adversaries could exploit unauthenticated or authenticated endpoints to:
-
Exhaust resources (Denial of Service).
-
Inflate storage costs.
-
Degrade performance for legitimate users.
Recommendation: The most effective way to mitigate this risk is to implement rate limiting and abuse protection at the infrastructure or Web Application Firewall (WAF) layer. This approach allows thresholds to be tuned for each environment’s expected usage and scaling characteristics. Some examples of controls can be:
-
Configuring a Web Application Firewall or API Gateway to enforce rate limits on sensitive operations, such as cluster creation and provisioning.
-
Defining thresholds based on baseline workload expectations (e.g., max requests per minute per client).
-
Monitoring logs and alerting on anomalies to detect potential abuse.
-
Apply a resource quota, which is a Rancher feature that limits the resources available to a project or namespace.
For more information, see: