U.S. flag   An official website of the United States government
Dot gov

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Https

Secure .gov websites use HTTPS
A lock (Dot gov) or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.

Rancher Government Solutions RKE2 STIG Ver 1, Rel 4 Checklist Details (Checklist Revisions)

Supporting Resources:

Target:

Target CPE Name
Rancher RKE2 cpe:/a:rancher:rke2:- (View CVEs)

Checklist Highlights

Checklist Name:
Rancher Government Solutions RKE2 STIG
Checklist ID:
1040
Version:
Ver 1, Rel 4
Type:
Compliance
Review Status:
Final
Authority:
Governmental Authority: Defense Information Systems Agency
Original Publication Date:
11/03/2022

Checklist Summary:

The RKE2 Security Technical Implementation Guide (STIG) provides technical requirements for securing an RKE2 platform version 1.23.6+rke2r2. RKE2, also known as RKE Government, is Rancher's next-generation Kubernetes distribution. It is a fully conformant Kubernetes distribution that focuses on security and compliance within the U.S. Federal Government. To meet these goals, RKE2 does the following: • Provides defaults and configuration options that allow clusters to pass the CIS Kubernetes Benchmark v1.5 or v1.6 with minimal operator intervention. • Enables FIPS 140-2 compliance. • Regularly scans components for CVEs using Trivy in the build pipeline. RKE2 combines the best of both worlds from the 1.x version of RKE (hereafter referred to as RKE1) and K3s. From K3s, it inherits the usability, ease-of-operations, and deployment model. From RKE1, it inherits close alignment with upstream Kubernetes. In places, K3s has diverged from upstream Kubernetes to optimize for edge deployments, but RKE1 and RKE2 can stay closely aligned with upstream. RKE2 does not rely on Docker as RKE1 does. RKE1 leveraged Docker for deploying and managing the control plane components as well as the container runtime for Kubernetes. RKE2 launches control plane components as static pods, managed by the kubelet. The embedded container runtime is “containerd.”

Checklist Role:

  • Server

Known Issues:

Not provided.

Target Audience:

Parties within the DOD and federal government’s computing environments can obtain the applicable STIG from the DOD Cyber Exchange website at https://cyber.mil/. This site contains the latest copies of STIGs, SRGs, and other related security information. Those without a Common Access Card (CAC) that has DOD Certificates can obtain the STIG from https://public.cyber.mil/.

Target Operational Environment:

  • Managed
  • Specialized Security-Limited Functionality (SSLF)

Testing Information:

Not provided.

Regulatory Compliance:

This document is provided under the authority of DODI 8500.01.

Comments/Warnings/Miscellaneous:

Not provided.

Disclaimer:

DISA accepts no liability for the consequences of applying specific configuration settings made on the basis of the SRGs/STIGs. It must be noted that the configuration settings specified should be evaluated in a local, representative test environment before implementation in a production environment, especially within large user populations. The extensive variety of environments makes it impossible to test these configuration settings for all potential software configurations. For all STIG requirements that pertain to a graphical user interface (GUI), the STIG check and fix assume an organization has implemented the TOSS 4 default, GNOME Shell GUI. If an organization is not using the default GUI, it is the responsibility of the organization to implement the security feature using their chosen GUI. For some production environments, failure to test before implementation may lead to a loss of required functionality. Evaluating the risks and benefits to a system’s particular circumstances and requirements is the system owner’s responsibility. The evaluated risks resulting from not applying specified configuration settings must be approved by the responsible AO. Furthermore, DISA implies no warranty that the application of all specified configurations will make a system 100 percent secure. Security guidance is provided for the DOD. While other agencies and organizations are free to use it, care must be given to ensure that all applicable security guidance is applied at both the device hardening level and the architectural level due to the fact that some settings may not be configurable in environments outside the DOD architecture.

Product Support:

Not provided.

Point of Contact:

This report will be available to component authorizing official (AO) personnel for risk assessment purposes by request via email to: disa.stig_spt@mail.mil.

Sponsor:

Not provided.

Licensing:

Not provided.

Change History:

updated to FINAL - 12/1/22
Updated resource per DISA - 4/27/23
Updated URLs per DISA - 7/25/23
updated URLs - 1/26/24

Dependency/Requirements:

URL Description

References:

Reference URL Description

NIST checklist record last modified on 01/26/2024