{"stig":{"title":"Rancher Government Solutions Multi-Cluster Manager Security Technical Implementation Guide","version":"2","release":"2"},"checks":[{"vulnId":"V-252843","ruleId":"SV-252843r1043176_rule","severity":"high","ruleTitle":"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.","description":"RBAC Integration and Authn/Authz\n\nCentralized authentication services provide additional functionality fulfilling security requirements:\n- Multi-factor authentication, which is compatible with Rancher MCM.\n- Disabling users after a period of time.\n- Storage and transmission of secure information is encrypted.\n- Secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules.\n- PKI based authentication.\n\nRancher 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.\n\nSatisfies: 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","checkContent":"RBAC Integration and Authn/Authz\n\nView and modify authentication settings through the Rancher MCM UI.\n\nNavigate to Triple Bar Symbol(Global) >> Users & Authentication >> Auth Provider.\n\nThis screen shows the authentication mechanism that is configured. If no authentication mechanism is configured or disabled, this is a finding.","fixText":"RBAC Integration and Authn/Authz\n\nNavigate to Triple Bar Symbol(Global) >> Users & Authentication >> Auth Provider.\n\nFrom this screen the authentication mechanism can be selected and configured. \n\nThis STIG is written and tested with KeyCloak and not included with Rancher MCM. Installation instructions for KeyCloak can be found here:\n\nhttps://www.keycloak.org/getting-started/getting-started-kube","ccis":["CCI-000015","CCI-000016","CCI-000044","CCI-000134","CCI-000154","CCI-000162","CCI-000163","CCI-000164","CCI-000187","CCI-004066","CCI-004062","CCI-000197","CCI-004061","CCI-000206","CCI-000213","CCI-000764","CCI-000765","CCI-000766","CCI-003627","CCI-001090","CCI-001350","CCI-001368","CCI-001403","CCI-001493","CCI-001494","CCI-001495","CCI-001499","CCI-001764","CCI-003980","CCI-001813","CCI-003938","CCI-001941","CCI-004045","CCI-002235","CCI-002238","CCI-000192","CCI-000193","CCI-000194","CCI-000195","CCI-000196","CCI-000198","CCI-000199","CCI-000205","CCI-000795","CCI-001619","CCI-001812","CCI-001814","CCI-002142"]},{"vulnId":"V-252844","ruleId":"SV-252844r960777_rule","severity":"medium","ruleTitle":"Rancher MCM must generate audit records for all DoD-defined auditable events within all components in the platform.","description":"Audit logs must be enabled.\n\nRancher 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.\n\nAudit 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.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster 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.\n\nTo 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.\n\nSatisfies: 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","checkContent":"Ensure audit logging is enabled:\n\nNavigate to Triple Bar Symbol(Global) >>  <local cluster> \n-From the drop down next to the cluster name, select \"cattle-system\".\n-Click \"deployments\" under Workload menu item.\n-Select \"rancher\" in the Deployments section.\n-Click the three dot config menu on the right.\n-Choose \"Edit Config\".\n-Scroll down to the \"Environment Variables\" section.\n\nIf the  'AUDIT_LEVEL' environment variable does not exist or < Level 2, this is a finding.","fixText":"Ensure audit logging is enabled:\n\nNavigate to Triple Bar Symbol(Global) >>  <local cluster> \n-From the drop down next to the cluster name, select 'cattle-system'.\n-Click \"deployments\" under Workload menu item.\n-Select \"rancher\" in the Deployments section.\n-Click the three dot config menu on the right.\n-Choose \"Edit Config\".\n-Scroll down to the \"Environment Variables\" section.\n-Change the AUDIT_LEVEL value to \"2\" or \"3\" and then click \"Save\".\n\nIf the variable does not exist:\n-Click \"Add Variable\".\n-Keep Default key/Value Pair as \"Type\"\n-Add \"AUDIT_LEVEL\" as Variable Name.\n-Input \"2,3\" for a value.\n-Click \"Save\".","ccis":["CCI-000018","CCI-000130","CCI-000131","CCI-000140","CCI-000169","CCI-000171","CCI-000172","CCI-000213","CCI-001464","CCI-001851","CCI-001889","CCI-001890","CCI-002234"]},{"vulnId":"V-252845","ruleId":"SV-252845r960783_rule","severity":"medium","ruleTitle":"When allowed by the central authentication system, the default role assigned to a user must be User-Base.","description":"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.","checkContent":"Verify User-Base is the default assigned role:\n-From the GUI, navigate to Triple Bar Symbol(Global) >> Users & Authentication >> Roles. \n-Click \"Standard User\".\n-At the top right, click the three dots, and then choose \"Edit Config\".\n-Under \"New User Default\", ensure \"No\" is selected. \n-Click \"User-Base\".\n-At the top right, click the three dots, and then \"Edit Config\".\n-Under \"New User Default\", ensure \"Yes\" is selected.\n\nIf \"No\" is not selected for Standard User, this is a finding. \n\nIf \"Yes\" is not selected for User-Base, this is a finding.","fixText":"From the GUI, navigate to Triple Bar Symbol(Global) >> Users & Authentication >> Roles.\n-Click \"Standard User\".\n-At the top right, click the three dots, and then \"Edit Config\".\n-Under \"New User Default\", select \"No\" and click \"Save\".\n-Click \"User-Base\".\n-At the top right, click the three dots, and then click \"Edit Config\".\n-Under \"New User Default\", select \"Yes\", and then click \"Save\".","ccis":["CCI-001404"]},{"vulnId":"V-252846","ruleId":"SV-252846r960900_rule","severity":"medium","ruleTitle":"Rancher MCM must allocate audit record storage and generate audit records associated with events, users, and groups.","description":"Rancher logging capability and optional aggregation\n\nThe 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.\n\nCluster 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.\n\nRancher 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.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n\n  'requestURI': '/v3/schemas',\n\n  'sourceIPs': ['::1'],\n\n  'user': {\n\n    'name': 'user-f4tt2',\n\n    'group': ['system:authenticated']\n\n  },\n\n  'verb': 'GET',\n\n  'stage': 'RequestReceived',\n\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n\n  'requestBody': {\n\n    [redacted]\n\n  }\n\n}\n\nSatisfies: 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","checkContent":"Ensure logging aggregation is enabled:\nNavigate to Triple Bar Symbol(Global).\n\nFor each cluster in \"EXPLORE CLUSTER\":\n-Select \"Cluster\".\n-Select \"Cluster Tools\" (bottom left).\n\nThis screen shows the current configuration for logging. \n\nOR\n\nEnsure logs are being aggregated and stored in a central logging solution.\n\nIf the logging block has an Install button OR logs are not being aggregated in a central logging solution, this is a finding.","fixText":"Enable log aggregation:\nNavigate to Triple Bar Symbol(Global).\n\nFor each cluster in \"EXPLORE CLUSTER\":\n-Select \"Cluster\".\n-Select \"Cluster Tools\" (bottom left).\n-In the \"Logging Block\", select \"Install\".\n-Select the newest version of logging in the dropdown. \n-Open the \"Install into Project Dropdown\".\n-Select the Project. (Note: Kubernetes STIG requires creating new project and namespace for deployments. Using Default or System is not best practice.)\n-Click \"Next\".\n-Review the options and click \"Install\".","ccis":["CCI-000133","CCI-000135","CCI-000172","CCI-000366","CCI-001487","CCI-001496","CCI-001849","CCI-001855","CCI-001858","CCI-001876"]},{"vulnId":"V-252847","ruleId":"SV-252847r971528_rule","severity":"medium","ruleTitle":"Rancher MCM must never automatically remove or disable emergency accounts.","description":"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.\n\nEmergency 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.\n\nTo 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.\n\nLocal Admin user should exist so that Rancher can be used if the external authentication service encounters issues.","checkContent":"Ensure local emergency admin account has not been removed and is the only Local account. \n\nNavigate to the Triple Bar Symbol(Global) >> Users & Authentication. In the left navigation menu, click \"Users\".\n\nThere should be only one local account and that account should have administrator role.\n\nIf no local administrator account exists or there is more than one local account, this is a finding.","fixText":"Ensure local emergency admin account has not been removed and is the only Local account. \n\nNavigate to the Triple Bar Symbol(Global) >> Users & Authentication. In the left navigation menu, click \"Users\".\n\nTo Create a User:\n-Click \"Create\".\n-Complete the \"Add User\" form. Ensure Global Permissions are set to \"Administrator\".\n-Click \"Create\".\n\nTo Delete a User:\n-Select the user and click \"Delete\".","ccis":["CCI-001682"]},{"vulnId":"V-252849","ruleId":"SV-252849r1155126_rule","severity":"high","ruleTitle":"Rancher MCM must prohibit or restrict the use of protocols that transmit unencrypted authentication information or use flawed cryptographic algorithms for transmission.","description":"The Rancher application will adhere to NIST 800-52R2. To ensure 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.","checkContent":"Navigate to Triple Bar Symbol(Global) >> <local cluster>.\nFrom the kubectl shell (>_), execute:\nkubectl get ingress -n cattle-system rancher -o yaml\n\nVerify the port number for Rancher is using \"443\", like the following:\n  spec:\n    rules:\n    - host: rancher.rfed.us\n      http:\n        paths:\n        - backend:\n            service:\n              name: rancher\n              port:\n                number: 443\n\nFrom the kubectl shell (>_), execute:\nkubectl get networkpolicies -n cattle-system\n\nVerify networkpolicies exist and that they are only allowing traffic to port \"444\" of the Rancher pods, like the following:\nNAME                               POD-SELECTOR   AGE\nrancher-allow-https      app=rancher        10h\nrancher-deny-ingress    app=rancher        10h\n\nIf 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.","fixText":"Gather the current values of the Rancher deployment by running the following:\n\nhelm get values -n cattle-system rancher > /tmp/rancher-values.yaml\n\nCreate another values file to upgrade Rancher's ingress object for HTTPS. Add the following to \"/tmp/rancher-ingress-values.yaml\":\n\ningress:\n  extraAnnotations:\n    nginx.ingress.kubernetes.io/backend-protocol: \"HTTPS\" # If using NGINX ingress\n    traefik.ingress.kubernetes.io/router.tls: \"true\" # If using Traefik ingress\n  servicePort: 443\n\nIf 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.\n\nUpgrade Rancher, referencing the two files created:\n\nhelm upgrade -n cattle-system -f /tmp/rancher-values.yaml -f /tmp/rancher-ingress-values.yaml rancher rancher-stable/rancher --version=CURRENT_RANCHER_VERSION\n\nOnce 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:\n\ncat <<EOF | kubectl apply -f -\nkind: NetworkPolicy\napiVersion: networking.k8s.io/v1\nmetadata:\n  name: rancher-allow-https\n  namespace: cattle-system\nspec:\n  podSelector:\n    matchLabels:\n      app: rancher\n  ingress:\n  - ports:\n    - port: 444\n---\napiVersion: networking.k8s.io/v1\nkind: NetworkPolicy\nmetadata:\n  name: rancher-deny-ingress\n  namespace: cattle-system\nspec:\n  podSelector:\n    matchLabels:\n      app: rancher\n  policyTypes:\n  - Ingress\nEOF","ccis":["CCI-000382"]},{"vulnId":"V-257292","ruleId":"SV-257292r961287_rule","severity":"medium","ruleTitle":"Rancher MCM must enforce organization-defined circumstances and/or usage conditions for organization-defined accounts.","description":"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.","checkContent":"Verify helm installation contains correct parameters:\nNavigate to Triple Bar Symbol(Global) >>  <local cluster>.\nFrom the kubectl shell (>_) Execute:\n`helm get values rancher -n cattle-system`\n\nThe output must contain:\n```\nprivateCA: true\ningress:\ntls:\nsource: secret\n```\nIf the output source is not \"secret\", this is a finding.\n\nVerify contents of certificates are correct: \nFrom the console, type:\nkubectl -n cattle-system get secret tls-rancher-ingress -o 'jsonpath={.data.tls\\.crt}' | base64 --decode | openssl x509 -noout -text\n\nkubectl -n cattle-system get secret tls-ca -o 'jsonpath={.data.cacerts\\.pem}' | base64 --decode | openssl x509 -noout -text","fixText":"Update the secrets to contain valid certificates.\n\nPut the correct and valid DOD certificate and key in files called \"tls.crt\" and \"tls.key\", respectively, and then run:\nkubectl -n cattle-system create secret tls tls-rancher-ingress \\  --cert=tls.crt \\   --key=tls.key                         \n\nUpload the CA required for the certs by creating another file called \"cacerts.pem\" and running: \nkubectl -n cattle-system create secret generic tls-ca \\   --from-file=cacerts.pem=./cacerts.pem \n\nThe helm chart values need to be updated to include the check section: \nprivateCA: true   \ningress:            \ntls:                                                                        \nsource: secret   \n\nRerun helm upgrade with the new values for the certs to take effect.","ccis":["CCI-002145"]}]}