Rancher MCM must allocate audit record storage and generate audit records associated with events, users, and groups.

Description

<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>