Skip to content
ATO Pathways
Log In
Overview
Search
Catalogs
SCAP
OSCAL
Catalogs
Profiles
Documents
References
Knowledge Base
Platform Documentation
Compliance Dictionary
Platform Changelog
About
Catalogs
XCCDF
Rancher Government Solutions Multi-Cluster Manager Security Technical Implementation Guide
Profiles
III - Administrative Classified
III - Administrative Classified
An XCCDF Profile
Details
Items
Prose
6 rules organized in 6 groups
SRG-APP-000026-CTR-000070
1 Rule
<GroupDescription></GroupDescription>
Rancher MCM must generate audit records for all DoD-defined auditable events within all components in the platform.
Medium Severity
<VulnDiscussion>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</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000028-CTR-000080
1 Rule
<GroupDescription></GroupDescription>
When allowed by the central authentication system, the default role assigned to a user must be User-Base.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000098-CTR-000185
1 Rule
<GroupDescription></GroupDescription>
Rancher MCM must allocate audit record storage and generate audit records associated with events, users, and groups.
Medium Severity
<VulnDiscussion>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</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000234-CTR-000590
1 Rule
<GroupDescription></GroupDescription>
Rancher MCM must never automatically remove or disable emergency accounts.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000645-CTR-001410
1 Rule
<GroupDescription></GroupDescription>
Rancher MCM must prohibit or restrict the use of protocols that transmit unencrypted authentication information or use flawed cryptographic algorithms for transmission.
High Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000318-CTR-000740
1 Rule
<GroupDescription></GroupDescription>
Rancher MCM must enforce organization-defined circumstances and/or usage conditions for organization-defined accounts.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>