Rancher Government Solutions Multi-Cluster Manager Security Technical Implementation Guide

  • Version/Release: V2R1
  • Published: 2024-06-10
  • Released: 2024-07-24
  • Expand All:
  • Severity:
  • Sort:
Compare

Select any two versions of this STIG to compare the individual requirements

View

Select any old version/release of this STIG to view the previous requirements

This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DOD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: disa.stig_spt@mail.mil.
c
Rancher MCM must use a centralized user management solution to support account management functions. For accounts using password authentication, the container platform must use FIPS-validated SHA-2 or later protocol to protect the integrity of the password authentication process.
AC-2 - High - CCI-000015 - V-252843 - SV-252843r986175_rule
RMF Control
AC-2
Severity
High
CCI
CCI-000015
Version
CNTR-RM-000030
Vuln IDs
  • V-252843
Rule IDs
  • SV-252843r986175_rule
RBAC Integration and Authn/Authz Centralized authentication services provide additional functionality fulfilling security requirements: - Multi-factor authentication, which is compatible with Rancher MCM. - Disabling users after a period of time. - Storage and transmission of secure information is encrypted. - Secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules. - PKI based authentication. Rancher MCM can integrate with external centralized authentication but does not offer a native solution. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. Satisfies: SRG-APP-000023-CTR-000055, SRG-APP-000024-CTR-000060, SRG-APP-000027-CTR-000075, SRG-APP-000029-CTR-000085, SRG-APP-000033-CTR-000095, SRG-APP-000038-CTR-000105, SRG-APP-000065-CTR-000115, SRG-APP-000099-CTR-000190, SRG-APP-000111-CTR-000220, SRG-APP-000118-CTR-000240, SRG-APP-000119-CTR-000245, SRG-APP-000120-CTR-000250, SRG-APP-000121-CTR-000255, SRG-APP-000122-CTR-000260, SRG-APP-000123-CTR-000265, SRG-APP-000126-CTR-000275, SRG-APP-000133-CTR-000310, SRG-APP-000148-CTR-000335, SRG-APP-000148-CTR-000340, SRG-APP-000148-CTR-000345, SRG-APP-000148-CTR-000350, SRG-APP-000149-CTR-000355, SRG-APP-000150-CTR-000360, SRG-APP-000156-CTR-000380, SRG-APP-000163-CTR-000395, SRG-APP-000164-CTR-000400, SRG-APP-000165-CTR-000405, SRG-APP-000166-CTR-000410, SRG-APP-000167-CTR-000415, SRG-APP-000168-CTR-000420, SRG-APP-000169-CTR-000425, SRG-APP-000170-CTR-000430, SRG-APP-000171-CTR-000435, SRG-APP-000172-CTR-000440, SRG-APP-000173-CTR-000445, SRG-APP-000174-CTR-000450, SRG-APP-000177-CTR-000465, SRG-APP-000178-CTR-000470, SRG-APP-000243-CTR-000595, SRG-APP-000317-CTR-000735, SRG-APP-000340-CTR-000770, SRG-APP-000345-CTR-000785, SRG-APP-000378-CTR-000880, SRG-APP-000378-CTR-000885, SRG-APP-000378-CTR-000890, SRG-APP-000380-CTR-000900, SRG-APP-000381-CTR-000905, SRG-APP-000384-CTR-000915, SRG-APP-000319-CTR-000745
Checks: C-56299r819977_chk

RBAC Integration and Authn/Authz View and modify authentication settings through the Rancher MCM UI. Navigate to Triple Bar Symbol(Global) >> Users & Authentication >> Auth Provider. This screen shows the authentication mechanism that is configured. If no authentication mechanism is configured or disabled, this is a finding.

Fix: F-56249r819978_fix

RBAC Integration and Authn/Authz Navigate to Triple Bar Symbol(Global) >> Users & Authentication >> Auth Provider. From this screen the authentication mechanism can be selected and configured. This STIG is written and tested with KeyCloak and not included with Rancher MCM. Installation instructions for KeyCloak can be found here: https://www.keycloak.org/getting-started/getting-started-kube

b
Rancher MCM must generate audit records for all DoD-defined auditable events within all components in the platform.
AC-2 - Medium - CCI-000018 - V-252844 - SV-252844r960777_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-000018
Version
CNTR-RM-000060
Vuln IDs
  • V-252844
Rule IDs
  • SV-252844r960777_rule
Audit logs must be enabled. Rancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected to ensure non-repudiation of actions taken. Audit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application. Audit log verbosity can be set to one of the following levels: 0 - Disable audit log (default setting). 1 - Log event metadata. 2 - Log event metadata and request body. 3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. Cluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails. To meet the requirements of this control, an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least 2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application. Satisfies: SRG-APP-000026-CTR-000070, SRG-APP-000033-CTR-000100, SRG-APP-000089-CTR-000150, SRG-APP-000090-CTR-000155, SRG-APP-000091-CTR-000160, SRG-APP-000092-CTR-000165, SRG-APP-000095-CTR-000170, SRG-APP-000096-CTR-000175, SRG-APP-000109-CTR-000215, SRG-APP-000343-CTR-000780, SRG-APP-000358-CTR-000805, SRG-APP-000374-CTR-000865, SRG-APP-000375-CTR-000870
Checks: C-56300r819980_chk

Ensure audit logging is enabled: Navigate to Triple Bar Symbol(Global) >> <local cluster> -From the drop down next to the cluster name, select "cattle-system". -Click "deployments" under Workload menu item. -Select "rancher" in the Deployments section. -Click the three dot config menu on the right. -Choose "Edit Config". -Scroll down to the "Environment Variables" section. If the 'AUDIT_LEVEL' environment variable does not exist or < Level 2, this is a finding.

Fix: F-56250r819981_fix

Ensure audit logging is enabled: Navigate to Triple Bar Symbol(Global) >> <local cluster> -From the drop down next to the cluster name, select 'cattle-system'. -Click "deployments" under Workload menu item. -Select "rancher" in the Deployments section. -Click the three dot config menu on the right. -Choose "Edit Config". -Scroll down to the "Environment Variables" section. -Change the AUDIT_LEVEL value to "2" or "3" and then click "Save". If the variable does not exist: -Click "Add Variable". -Keep Default key/Value Pair as "Type" -Add "AUDIT_LEVEL" as Variable Name. -Input "2,3" for a value. -Click "Save".

b
When allowed by the central authentication system, the default role assigned to a user must be User-Base.
AC-2 - Medium - CCI-001404 - V-252845 - SV-252845r960783_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-001404
Version
CNTR-RM-000080
Vuln IDs
  • V-252845
Rule IDs
  • SV-252845r960783_rule
Rancher MCM uses roles for authentication. It is necessary to ensure the proper roles and permissions are configured. The role used by default does not ensure least privilege. The default role needs to be changed to allow least privilege access.
Checks: C-56301r822505_chk

Verify User-Base is the default assigned role: -From the GUI, navigate to Triple Bar Symbol(Global) &gt;&gt; Users &amp; Authentication &gt;&gt; Roles. -Click "Standard User". -At the top right, click the three dots, and then choose "Edit Config". -Under "New User Default", ensure "No" is selected. -Click "User-Base". -At the top right, click the three dots, and then "Edit Config". -Under "New User Default", ensure "Yes" is selected. If "No" is not selected for Standard User, this is a finding. If "Yes" is not selected for User-Base, this is a finding.

Fix: F-56251r822506_fix

From the GUI, navigate to Triple Bar Symbol(Global) >> Users & Authentication >> Roles. -Click "Standard User". -At the top right, click the three dots, and then "Edit Config". -Under "New User Default", select "No" and click "Save". -Click "User-Base". -At the top right, click the three dots, and then click "Edit Config". -Under "New User Default", select "Yes", and then click "Save".

b
Rancher MCM must allocate audit record storage and generate audit records associated with events, users, and groups.
AU-3 - Medium - CCI-000133 - V-252846 - SV-252846r960900_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000133
Version
CNTR-RM-000250
Vuln IDs
  • V-252846
Rule IDs
  • SV-252846r960900_rule
Rancher logging capability and optional aggregation The Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems. Cluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also must include failover and buffering in the event a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails. Rancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected to ensure non-repudiation of actions taken. Audit log verbosity can be set to one of the following levels: 0 - Disable audit log (default setting). 1 - Log event metadata. 2 - Log event metadata and request body. 3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. Application logs can be set to one of the following levels: info = Logs informational messages. This is the default log level. debug = Logs more detailed messages that can be used to debug. trace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information. Log metadata includes the following information (sample): { 'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183', 'requestURI': '/v3/schemas', 'sourceIPs': ['::1'], 'user': { 'name': 'user-f4tt2', 'group': ['system:authenticated'] }, 'verb': 'GET', 'stage': 'RequestReceived', 'stageTimestamp': '2018-07-20 10:22:43 +0800' 'requestBody': { [redacted] } } Satisfies: SRG-APP-000098-CTR-000185, SRG-APP-000100-CTR-000195, SRG-APP-000100-CTR-000200, SRG-APP-000101-CTR-000205, SRG-APP-000181-CTR-000485, SRG-APP-000290-CTR-000670, SRG-APP-000357-CTR-000800, SRG-APP-000359-CTR-000810, SRG-APP-000360-CTR-000815, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000495-CTR-001235, SRG-APP-000496-CTR-001240, SRG-APP-000497-CTR-001245, SRG-APP-000498-CTR-001250, SRG-APP-000499-CTR-001255, SRG-APP-000500-CTR-001260, SRG-APP-000501-CTR-001265, SRG-APP-000502-CTR-001270, SRG-APP-000503-CTR-001275, SRG-APP-000504-CTR-001280, SRG-APP-000505-CTR-001285, SRG-APP-000506-CTR-001290, SRG-APP-000507-CTR-001295, SRG-APP-000508-CTR-001300, SRG-APP-000509-CTR-001305, SRG-APP-000510-CTR-001310, SRG-APP-000516-CTR-000790
Checks: C-56302r918219_chk

Ensure logging aggregation is enabled: Navigate to Triple Bar Symbol(Global). For each cluster in "EXPLORE CLUSTER": -Select "Cluster". -Select "Cluster Tools" (bottom left). This screen shows the current configuration for logging. OR Ensure logs are being aggregated and stored in a central logging solution. If the logging block has an Install button OR logs are not being aggregated in a central logging solution, this is a finding.

Fix: F-56252r918220_fix

Enable log aggregation: Navigate to Triple Bar Symbol(Global). For each cluster in "EXPLORE CLUSTER": -Select "Cluster". -Select "Cluster Tools" (bottom left). -In the "Logging Block", select "Install". -Select the newest version of logging in the dropdown. -Open the "Install into Project Dropdown". -Select the Project. (Note: Kubernetes STIG requires creating new project and namespace for deployments. Using Default or System is not best practice.) -Click "Next". -Review the options and click "Install".

b
Rancher MCM must never automatically remove or disable emergency accounts.
AC-2 - Medium - CCI-001682 - V-252847 - SV-252847r971528_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-001682
Version
CNTR-RM-000850
Vuln IDs
  • V-252847
Rule IDs
  • SV-252847r971528_rule
Emergency accounts are administrator accounts that are established in response to crisis situations where the need for rapid account activation is required. Therefore, emergency account activation may bypass normal account authorization processes. If these accounts are automatically disabled, system maintenance during emergencies may not be possible, thus adversely affecting system availability. Emergency accounts are different from infrequently used accounts (i.e., local logon accounts used by system administrators when network or normal logon/access is not available). Infrequently used accounts also remain available and are not subject to automatic termination dates. However, an emergency account is normally a different account that is created for use by vendors or system maintainers. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality. Local Admin user should exist so that Rancher can be used if the external authentication service encounters issues.
Checks: C-56303r819989_chk

Ensure local emergency admin account has not been removed and is the only Local account. Navigate to the Triple Bar Symbol(Global) &gt;&gt; Users &amp; Authentication. In the left navigation menu, click "Users". There should be only one local account and that account should have administrator role. If no local administrator account exists or there is more than one local account, this is a finding.

Fix: F-56253r819990_fix

Ensure local emergency admin account has not been removed and is the only Local account. Navigate to the Triple Bar Symbol(Global) >> Users & Authentication. In the left navigation menu, click "Users". To Create a User: -Click "Create". -Complete the "Add User" form. Ensure Global Permissions are set to "Administrator". -Click "Create". To Delete a User: -Select the user and click "Delete".

c
Rancher MCM must prohibit or restrict the use of protocols that transmit unencrypted authentication information or use flawed cryptographic algorithms for transmission.
CM-7 - High - CCI-000382 - V-252849 - SV-252849r961911_rule
RMF Control
CM-7
Severity
High
CCI
CCI-000382
Version
CNTR-RM-001730
Vuln IDs
  • V-252849
Rule IDs
  • SV-252849r961911_rule
The container platform and its components will adhere to NIST 800-52R2. To ensure that traffic coming through the ingress controller is re-encrypted internally, switch off port 80 on the service object and direct ingress traffic to port 443 over HTTPS.
Checks: C-56305r918222_chk

Navigate to Triple Bar Symbol(Global) &gt;&gt; &lt;local cluster&gt;. From the kubectl shell (&gt;_) execute: kubectl get ingress -n cattle-system rancher -o yaml Verify the port number for Rancher is using "443", like the following: spec: rules: - host: rancher.rfed.us http: paths: - backend: service: name: rancher port: number: 443 From the kubectl shell (&gt;_) execute: kubectl get networkpolicies -n cattle-system Verify networkpolicies exist and that they are only allowing traffic to port "444" of the Rancher pods, like the following: NAME POD-SELECTOR AGE rancher-allow-https app=rancher 10h rancher-deny-ingress app=rancher 10h If the ingress output is not using port 443, or there are not network policies in place to only allow traffic to port 444, this is a finding.

Fix: F-56255r918223_fix

Gather the current values of the Rancher deployment by running the following: helm get values -n cattle-system rancher > /tmp/rancher-values.yaml Create another values file to upgrade Rancher's ingress object for HTTPS. Add the following to "/tmp/rancher-ingress-values.yaml": ingress: extraAnnotations: nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" # If using NGINX ingress traefik.ingress.kubernetes.io/router.tls: "true" # If using Traefik ingress servicePort: 443 If using a different ingress controller than NGINX or Traefik, other annotations may need to be added to ensure the controller knows the Rancher backend is HTTPS. Upgrade Rancher, referencing the two files created: helm upgrade -n cattle-system -f /tmp/rancher-values.yaml -f /tmp/rancher-ingress-values.yaml rancher rancher-stable/rancher --version=CURRENT_RANCHER_VERSION Once Rancher ingress has been updated and it has been verified that Rancher is still accessible, run the following command to create NetworkPolicies that will block all traffic to Rancher with the exception of HTTPS: cat <<EOF | kubectl apply -f - kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: rancher-allow-https namespace: cattle-system spec: podSelector: matchLabels: app: rancher ingress: - ports: - port: 444 --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: rancher-deny-ingress namespace: cattle-system spec: podSelector: matchLabels: app: rancher policyTypes: - Ingress EOF

b
Rancher MCM must enforce organization-defined circumstances and/or usage conditions for organization-defined accounts.
AC-2 - Medium - CCI-002145 - V-257292 - SV-257292r961287_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-002145
Version
CNTR-RM-000970
Vuln IDs
  • V-257292
Rule IDs
  • SV-257292r961287_rule
Rancher MCM must verify the certificate used for Rancher's ingress is a valid DOD certificate. This is achieved by verifying the helm installation contains correct parameters.
Checks: C-60976r919163_chk

Verify helm installation contains correct parameters: Navigate to Triple Bar Symbol(Global) &gt;&gt; &lt;local cluster&gt;. From the kubectl shell (&gt;_) Execute: `helm get values rancher -n cattle-system` The output must contain: ``` privateCA: true ingress: tls: source: secret ``` If the output source is not "secret", this is a finding. Verify contents of certificates are correct: From the console, type: kubectl -n cattle-system get secret tls-rancher-ingress -o 'jsonpath={.data.tls\.crt}' | base64 --decode | openssl x509 -noout -text kubectl -n cattle-system get secret tls-ca -o 'jsonpath={.data.cacerts\.pem}' | base64 --decode | openssl x509 -noout -text

Fix: F-60903r919164_fix

Update the secrets to contain valid certificates. Put the correct and valid DOD certificate and key in files called "tls.crt" and "tls.key", respectively, and then run: kubectl -n cattle-system create secret tls tls-rancher-ingress \ --cert=tls.crt \ --key=tls.key Upload the CA required for the certs by creating another file called "cacerts.pem" and running: kubectl -n cattle-system create secret generic tls-ca \ --from-file=cacerts.pem=./cacerts.pem The helm chart values need to be updated to include the check section: privateCA: true ingress: tls: source: secret Rerun helm upgrade with the new values for the certs to take effect.