| IA Control | CCI | SRGID | STIGID | SRG Requirement | Requirement | SRG VulDiscussion | Vul Discussion | Status | SRG Check | Check | SRG Fix | Fix | Severity | Mitigation | Artifact Description | Status Justification | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | CCI-001494 | SRG-APP-000122-CTR-000260 | CCE-90717-0 | The container platform must protect audit tools from unauthorized modification. | Red Hat OpenShift Container Platform 4 must protect audit tools from unauthorized modification. | Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data. Applications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the modification of audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators. |
Applicable - Configurable | Review the container platform to validate container platform audit tools are protected from unauthorized modification. If the audit tools are not protected from unauthorized modification, this is a finding. |
Perform a check to list the users and groups who have permission to edit the cluster logging configuration by running the following two commands. > oc policy who-can edit ClusterLogging -n openshift-logging > oc policy who-can edit ClusterLoggingForwarder -n openshift-logging Review the list of users and groups who have edit access to the cluster logging resources. If any user or group listed should not have access to edit the cluster logging resources, this is a finding. |
Remove edit permissions from any unauthorized user or group by performing one or more of the following commands: * Remove role from user > oc adm policy remove-role-from-user ROLE USER -n openshift-logging * Remove role from group > oc adm policy remove-role-from-group ROLE GROUP -n openshift-logging * Remove cluster role from user > oc adm policy remove-cluster-role-from-user CLUSTER_ROLE USER -n openshift-logging * Remove cluster role from group > oc adm policy remove-cluster-role-from-group CLUSTER_ROLE GROUP -n openshift-logging Where ROLE/CLUSTER_ROLE is the role granting user edit permission to resources in openshift-logging namespace.} |
CAT II | ||||||
| 1 | CCI-000877 | SRG-APP-000185-CTR-000490 | The container platform must employ strong authenticators in the establishment of non-local maintenance and diagnostic sessions. | Red Hat OpenShift Container Platform 4 must employ strong authenticators in the establishment of non-local maintenance and diagnostic sessions. | If maintenance tools are used by unauthorized personnel, they may accidentally or intentionally damage or compromise the system. The act of managing systems and applications includes the ability to access sensitive application information, such as, system configuration details, diagnostic information, user information, and potentially sensitive application data. Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the internet) or an internal network. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection. Typically, strong authentication requires authenticators that are resistant to replay attacks and employ multifactor authentication. Strong authenticators include, for example, PKI where certificates are stored on a token protected by a password, passphrase, or biometric. This requirement applies to hardware/software diagnostic test equipment or tools. This requirement does not cover hardware/software components that may support information system maintenance, yet are a part of the system (e.g., the software implementing "ping," "ls," "ipconfig," or the hardware and software implementing the monitoring port of an Ethernet switch). |
Applicable - Configurable | Review the container platform configuration to determine if the container platform is configured to employ strong authenticators in the establishment of non-local maintenance and diagnostic sessions. If the container platform is not configured to employ strong authenticators in the establishment of non-local maintenance and diagnostic sessions, this is a finding. |
CAT II | |||||||||
| 2 | CCI-000162,CCI-000163,CCI-000164,CCI-001314 | SRG-OS-000057-GPOS-00027,SRG-OS-000058-GPOS-00028,SRG-OS-000059-GPOS-00029,SRG-APP-000118-CTR-000240,SRG-OS-000042-GPOS-00020,SRG-OS-000392-GPOS-00172,SRG-OS-000471-GPOS-00215,SRG-APP-000499-CTR-001255,SRG-APP-000501-CTR-001265,SRG-APP-000502-CTR-001270,SRG-APP-000400-CTR-000960,SRG-APP-000190-CTR-000500,SRG-APP-000505-CTR-001285 | The container platform must protect audit information from any type of unauthorized read access. | If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is difficult if not impossible to achieve. In addition, access to audit records provides information an attacker could potentially use to his or her advantage. To ensure the veracity of audit data, the information system and/or the application must protect audit information from any and all unauthorized access. This includes read, write, and copy access. This requirement can be achieved through multiple methods, which will depend upon system architecture and design. Commonly employed methods for protecting audit information include least privilege permissions as well as restricting the location and number of log file repositories. Additionally, applications with user interfaces to audit records should not allow for the unfettered manipulation of or access to those records via the application. If the application provides access to the audit data, the application becomes accountable for ensuring audit information is protected from unauthorized access. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. |
Applicable - Configurable | Review the container platform configuration to determine where audit information is stored. If the audit information is not protected from any type of unauthorized read access, this is a finding. |
CAT II | ||||||||||
| 3 | CCI-000163,CCI-000164,CCI-001314,CCI-000162 | SRG-OS-000057-GPOS-00027,SRG-OS-000058-GPOS-00028,SRG-OS-000059-GPOS-00029,SRG-OS-000206-GPOS-00084,SRG-APP-000118-CTR-000240 | The container platform must protect audit information from any type of unauthorized read access. | Red Hat OpenShift Container Platform 4 audit logs file must have mode 0600 or less permissive to prevent unauthorized access to the audit log. | If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is difficult if not impossible to achieve. In addition, access to audit records provides information an attacker could potentially use to his or her advantage. To ensure the veracity of audit data, the information system and/or the application must protect audit information from any and all unauthorized access. This includes read, write, and copy access. This requirement can be achieved through multiple methods, which will depend upon system architecture and design. Commonly employed methods for protecting audit information include least privilege permissions as well as restricting the location and number of log file repositories. Additionally, applications with user interfaces to audit records should not allow for the unfettered manipulation of or access to those records via the application. If the application provides access to the audit data, the application becomes accountable for ensuring audit information is protected from unauthorized access. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. |
Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the Red Hat OpenShift Container Platform 4 system or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives. The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements. |
Applicable - Configurable | Review the container platform configuration to determine where audit information is stored. If the audit information is not protected from any type of unauthorized read access, this is a finding. |
Verify the audit logs have a mode of "0600". First determine where the audit logs are stored with the following command: $ sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Then using the location of the audit log file, determine if the audit log files as a mode of "0640" with the following command: $ sudo ls -la /var/log/audit/*.log rw-------. 2 root root 237923 Jun 11 11:56 /var/log/audit/audit.log If the audit logs have a mode more permissive than "0600", this is a finding. |
Configure the audit logs to have a mode of "0600" with the following command: Replace "[audit_log_file]" to the correct audit log path, by default this location is "/var/log/audit/audit.log". $ sudo chmod 0600 /var/log/audit/[audit_log_file] Check the group that owns the system audit logs: $ sudo grep -m 1 -q ^log_group /etc/audit/auditd.conf If the log_group is not defined or it is set to root, configure the permissions the following way: $ sudo chmod 0640 $log_file $ sudo chmod 0440 $log_file.* Otherwise, configure the permissions the following way: $ sudo chmod 0600 $log_file $ sudo chmod 0400 $log_file.* |
CAT II | ||||||
| 4 | CCI-001312 | SRG-APP-000118-CTR-000240 | The container platform must protect audit information from any type of unauthorized read access. | If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is difficult if not impossible to achieve. In addition, access to audit records provides information an attacker could potentially use to his or her advantage. To ensure the veracity of audit data, the information system and/or the application must protect audit information from any and all unauthorized access. This includes read, write, and copy access. This requirement can be achieved through multiple methods, which will depend upon system architecture and design. Commonly employed methods for protecting audit information include least privilege permissions as well as restricting the location and number of log file repositories. Additionally, applications with user interfaces to audit records should not allow for the unfettered manipulation of or access to those records via the application. If the application provides access to the audit data, the application becomes accountable for ensuring audit information is protected from unauthorized access. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. |
Applicable - Configurable | Review the container platform configuration to determine where audit information is stored. If the audit information is not protected from any type of unauthorized read access, this is a finding. |
CAT II | ||||||||||
| 5 | CCI-001314 | SRG-APP-000118-CTR-000240 | The container platform must protect audit information from any type of unauthorized read access. | If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is difficult if not impossible to achieve. In addition, access to audit records provides information an attacker could potentially use to his or her advantage. To ensure the veracity of audit data, the information system and/or the application must protect audit information from any and all unauthorized access. This includes read, write, and copy access. This requirement can be achieved through multiple methods, which will depend upon system architecture and design. Commonly employed methods for protecting audit information include least privilege permissions as well as restricting the location and number of log file repositories. Additionally, applications with user interfaces to audit records should not allow for the unfettered manipulation of or access to those records via the application. If the application provides access to the audit data, the application becomes accountable for ensuring audit information is protected from unauthorized access. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. |
Applicable - Configurable | Review the container platform configuration to determine where audit information is stored. If the audit information is not protected from any type of unauthorized read access, this is a finding. |
CAT II | ||||||||||
| 6 | CCI-001314 | SRG-APP-000118-CTR-000240 | The container platform must protect audit information from any type of unauthorized read access. | If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is difficult if not impossible to achieve. In addition, access to audit records provides information an attacker could potentially use to his or her advantage. To ensure the veracity of audit data, the information system and/or the application must protect audit information from any and all unauthorized access. This includes read, write, and copy access. This requirement can be achieved through multiple methods, which will depend upon system architecture and design. Commonly employed methods for protecting audit information include least privilege permissions as well as restricting the location and number of log file repositories. Additionally, applications with user interfaces to audit records should not allow for the unfettered manipulation of or access to those records via the application. If the application provides access to the audit data, the application becomes accountable for ensuring audit information is protected from unauthorized access. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. |
Applicable - Configurable | Review the container platform configuration to determine where audit information is stored. If the audit information is not protected from any type of unauthorized read access, this is a finding. |
CAT II | ||||||||||
| 7 | CCI-001314 | SRG-OS-000206-GPOS-00084,SRG-APP-000118-CTR-000240 | The container platform must protect audit information from any type of unauthorized read access. | Red Hat OpenShift Container Platform 4 /var/log directory must have mode 0755 or less permissive. | If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is difficult if not impossible to achieve. In addition, access to audit records provides information an attacker could potentially use to his or her advantage. To ensure the veracity of audit data, the information system and/or the application must protect audit information from any and all unauthorized access. This includes read, write, and copy access. This requirement can be achieved through multiple methods, which will depend upon system architecture and design. Commonly employed methods for protecting audit information include least privilege permissions as well as restricting the location and number of log file repositories. Additionally, applications with user interfaces to audit records should not allow for the unfettered manipulation of or access to those records via the application. If the application provides access to the audit data, the application becomes accountable for ensuring audit information is protected from unauthorized access. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. |
Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the Red Hat OpenShift Container Platform 4 system or platform. Additionally, personally identifiable information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives. The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements. |
Applicable - Configurable | Review the container platform configuration to determine where audit information is stored. If the audit information is not protected from any type of unauthorized read access, this is a finding. |
Verify that the "/var/log" directory has a mode of "0755" or less permissive with the following command: $ ls -ld /var/log drwxr-xr-x. 16 root root 4096 July 11 11:34 /var/log If "/var/log" does not have a mode of "0755" or less permissive, this is a finding. |
Configure the "/var/log" directory to a mode of "0755" by running the following command: $ sudo chmod 0755 /var/log |
CAT II | ||||||
| 8 | CCI-001314 | SRG-OS-000206-GPOS-00084,SRG-APP-000118-CTR-000240 | The container platform must protect audit information from any type of unauthorized read access. | Red Hat OpenShift Container Platform 4 /var/log directory must be owned by root. | If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is difficult if not impossible to achieve. In addition, access to audit records provides information an attacker could potentially use to his or her advantage. To ensure the veracity of audit data, the information system and/or the application must protect audit information from any and all unauthorized access. This includes read, write, and copy access. This requirement can be achieved through multiple methods, which will depend upon system architecture and design. Commonly employed methods for protecting audit information include least privilege permissions as well as restricting the location and number of log file repositories. Additionally, applications with user interfaces to audit records should not allow for the unfettered manipulation of or access to those records via the application. If the application provides access to the audit data, the application becomes accountable for ensuring audit information is protected from unauthorized access. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. |
Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the Red Hat OpenShift Container Platform 4 system or platform. Additionally, personally identifiable information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives. The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements. |
Applicable - Configurable | Review the container platform configuration to determine where audit information is stored. If the audit information is not protected from any type of unauthorized read access, this is a finding. |
Verify the "/var/log" directory is owned by root with the following command: $ ls -ld /var/log drwxr-xr-x. 16 root root 4096 July 11 11:34 /var/log If "/var/log" does not have an owner of "root", this is a finding. |
Configure the owner of the directory "/var/log" to "root" by running the following command: $ sudo chown root /var/log |
CAT II | ||||||
| 9 | CCI-001314 | SRG-OS-000206-GPOS-00084,SRG-APP-000118-CTR-000240 | The container platform must protect audit information from any type of unauthorized read access. | Red Hat OpenShift Container Platform 4 /var/log directory must be group-owned by root. | If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is difficult if not impossible to achieve. In addition, access to audit records provides information an attacker could potentially use to his or her advantage. To ensure the veracity of audit data, the information system and/or the application must protect audit information from any and all unauthorized access. This includes read, write, and copy access. This requirement can be achieved through multiple methods, which will depend upon system architecture and design. Commonly employed methods for protecting audit information include least privilege permissions as well as restricting the location and number of log file repositories. Additionally, applications with user interfaces to audit records should not allow for the unfettered manipulation of or access to those records via the application. If the application provides access to the audit data, the application becomes accountable for ensuring audit information is protected from unauthorized access. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. |
Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the Red Hat OpenShift Container Platform 4 system or platform. Additionally, personally identifiable information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives. The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements. |
Applicable - Configurable | Review the container platform configuration to determine where audit information is stored. If the audit information is not protected from any type of unauthorized read access, this is a finding. |
Verify the "/var/log" directory is group-owned by root with the following command: $ ls -ld /var/log drwxr-xr-x. 16 root root 4096 July 11 11:34 /var/log If "/var/log" does not have a group owner of "root", this is a finding. |
Configure the group owner of the directory "/var/log" to "root" by running the following command: $ sudo chgrp root /var/log |
CAT II | ||||||
| 10 | CCI-000162 | SRG-APP-000118-CTR-000240 | CCE-88593-9 | The container platform must protect audit information from any type of unauthorized read access. | OpenShift must protect audit information from unauthorized modification. | If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is difficult if not impossible to achieve. In addition, access to audit records provides information an attacker could potentially use to his or her advantage. To ensure the veracity of audit data, the information system and/or the application must protect audit information from any and all unauthorized access. This includes read, write, and copy access. This requirement can be achieved through multiple methods, which will depend upon system architecture and design. Commonly employed methods for protecting audit information include least privilege permissions as well as restricting the location and number of log file repositories. Additionally, applications with user interfaces to audit records should not allow for the unfettered manipulation of or access to those records via the application. If the application provides access to the audit data, the application becomes accountable for ensuring audit information is protected from unauthorized access. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. |
Applicable - Configurable | Review the container platform configuration to determine where audit information is stored. If the audit information is not protected from any type of unauthorized read access, this is a finding. |
Verify the permissions and ownership of files located under "/var/log/pods" that store the output of pods are set to protect from unauthorized access. 1. Verify the files are readable only by the owner by executing the following command: for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'echo -n "$HOSTNAME "; find /var/log/pods/ -type f \( -perm /022 -o -perm /044 \)' 2>/dev/null; done If any files are returned, this is a finding. 2. Verify files are group-owned by root and owned by root by executing the following: for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'echo -n "$HOSTNAME "; find /var/log/pods/ -type f \! -user 0' 2>/dev/null; done (Example output: ip-10-0-150-1 root root) If "root" is not returned as the owner, this is a finding. If "root" is not returned as the group owner, this is a finding. |
Change the permissions and ownership of files located under "/var/log/pods" to protect from unauthorized access. 1. Execute the following to set the output of pods readable only by the owner: for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'echo -n "$HOSTNAME "; find /var/log/pods/ -type f \( -perm /022 -o -perm /044 \) | xargs -r chmod 600' 2>/dev/null; done 2. Execute the following to set the group and group-ownership to root for files that store the output of pods: for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'echo -n "$HOSTNAME "; find /var/log/pods/ -type f \! -user 0 | xargs -r chown root:root' 2>/dev/null; done |
CAT II | ||||||
| 11 | CCI-001953 | SRG-APP-000391-CTR-000935 | The container platform must be configured to use multi-factor authentication for user authentication. | Red Hat OpenShift Container Platform 4 must be configured to use multi-factor authentication for user authentication. | Controlling access to the container platform and its components is paramount in having a secure and stable system. Validating users is the first step in controlling the access. Users may be validated by the overall container platform or they may be validated by each component. To standardize and reduce the risks of unauthorized access, the use of multifactor token-based credentials is the preferred method. DoD has mandated the use of the CAC to support identity management and personal authentication for systems covered under HSPD 12, as well as a primary component of layered protection for national security systems. |
Not Applicable | Review documentation and configuration to ensure the container platform is configured to use an approved DoD multifactor token (CAC) when accessing platform via user interfaces. If multifactor authentication is not configured, this is a finding. |
CAT II | Not Applicable. Applicable to Identity Management Provider and not OCP. Only configurable check is to ensure OCP is configured for an IDP under SRG-APP-000023-CTR-000055. Verify with IdM service provider admins that the IdM meets the requirements. |
||||||||
| 12 | CCI-000133,CCI-001881,CCI-001875,CCI-000154,CCI-001882,CCI-000158,CCI-001914,CCI-000169,CCI-001464,CCI-001878,CCI-001877,CCI-001889,CCI-000135,CCI-002884,CCI-001487,CCI-003938,CCI-000132,CCI-004188,CCI-000134,CCI-000172,CCI-000130,CCI-000131,CCI-001879,CCI-001880,CCI-001876 | SRG-OS-000062-GPOS-00031,SRG-OS-000037-GPOS-00015,SRG-OS-000038-GPOS-00016,SRG-OS-000039-GPOS-00017,SRG-OS-000040-GPOS-00018,SRG-OS-000041-GPOS-00019,SRG-OS-000042-GPOS-00021,SRG-OS-000051-GPOS-00024,SRG-OS-000054-GPOS-00025,SRG-OS-000122-GPOS-00063,SRG-OS-000254-GPOS-00095,SRG-OS-000255-GPOS-00096,SRG-OS-000337-GPOS-00129,SRG-OS-000348-GPOS-00136,SRG-OS-000349-GPOS-00137,SRG-OS-000350-GPOS-00138,SRG-OS-000351-GPOS-00139,SRG-OS-000352-GPOS-00140,SRG-OS-000353-GPOS-00141,SRG-OS-000354-GPOS-00142,SRG-OS-000358-GPOS-00145,SRG-OS-000365-GPOS-00152,SRG-OS-000392-GPOS-00172,SRG-OS-000475-GPOS-00220,SRG-APP-000095-CTR-000170,SRG-APP-000409-CTR-000990,SRG-APP-000508-CTR-001300,SRG-APP-000510-CTR-001310 | Direct access to the container platform must generate audit records. | Red Hat OpenShift Container Platform 4 audit service must be enabled. | Direct access to the container platform and its components must generate audit records. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible. | Without establishing what type of events occurred, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Ensuring the "auditd" service is active ensures audit records generated by the kernel are appropriately recorded. Additionally, a properly configured audit subsystem ensures that actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions. |
Applicable - Configurable | Review the container platform configuration to determine if direct access of the container platform generates audit records. If audit records are not generated, this is a finding. |
Verify the audit service is configured to produce audit records with the following command: $ systemctl status auditd.service auditd.service - Security Auditing Service Loaded:loaded (/usr/lib/systemd/system/auditd.service; enabled; vendor preset: enabled) Active: active (running) since Tues 2022-05-24 12:56:56 EST; 4 weeks 0 days ago If the audit service is not "active" and "running", this is a finding. |
To enable the auditd service run the following command: $ sudo systemctl enable --now auditd |
CAT II | ||||||
| 13 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000468-GPOS-00212,SRG-OS-000471-GPOS-00215,SRG-APP-000029-CTR-000085,SRG-APP-000495-CTR-001235,SRG-APP-000501-CTR-001265,SRG-APP-000502-CTR-001270 | The container platform must automatically audit account removal actions. | Red Hat OpenShift Container Platform 4 must audit all uses of the chage command. | When application accounts are removed, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to remove authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account removal actions provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding 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. |
Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to determine if account removal is automatically audited. If account removal is not automatically audited, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "chage" command with the following command: $ sudo auditctl -l | grep chage -a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=unset -k privileged-chage If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "chage" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=unset -k privileged-chage The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 14 | CCI-001405 | SRG-APP-000029-CTR-000085 | The container platform must automatically audit account removal actions. | Red Hat OpenShift Container Platform 4 must audit all uses of the /usr/libexec/dbus-1/dbus-daemon-launch-helper command. | When application accounts are removed, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to remove authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account removal actions provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding 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. |
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to determine if account removal is automatically audited. If account removal is not automatically audited, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "/usr/libexec/dbus-1/dbus-daemon-launch-helper" command with the following command: $ sudo auditctl -l | grep /usr/libexec/dbus-1/dbus-daemon-launch-helper -a always,exit -F path=/usr/libexec/dbus-1/dbus-daemon-launch-helper -F perm=x -F auid>=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "polkit-agent-helper" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path= /usr/libexec/dbus-1/dbus-daemon-launch-helper -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 15 | CCI-001405 | SRG-APP-000029-CTR-000085 | The container platform must automatically audit account removal actions. | Red Hat OpenShift Container Platform 4 must audit all uses of the fusermount command. | When application accounts are removed, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to remove authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account removal actions provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding 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. |
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to determine if account removal is automatically audited. If account removal is not automatically audited, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "fusermount" command with the following command: $ sudo auditctl -l | grep fusermount -a always,exit -F path=/usr/bin/fusermount -F perm=x -F auid>=1000 -F auid!=unset -k privileged-fusermount If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "fusermount" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/bin/fusermount -F perm=x -F auid>=1000 -F auid!=unset -k privileged-fusermount The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 16 | CCI-001405 | SRG-APP-000029-CTR-000085 | The container platform must automatically audit account removal actions. | Red Hat OpenShift Container Platform 4 must audit all uses of the fusermount3 command. | When application accounts are removed, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to remove authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account removal actions provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding 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. |
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to determine if account removal is automatically audited. If account removal is not automatically audited, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "fusermount3" command with the following command: $ sudo auditctl -l | grep fusermount3 -a always,exit -F path=/usr/bin/fusermount3 -F perm=x -F auid>=1000 -F auid!=unset -k privileged-fusermount3 If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "fusermount3" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/bin/fusermount3 -F perm=x -F auid>=1000 -F auid!=unset -k privileged-fusermount3 The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 17 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-APP-000029-CTR-000085,SRG-APP-000495-CTR-001235 | The container platform must automatically audit account removal actions. | Red Hat OpenShift Container Platform 4 must audit all uses of the gpasswd command. | When application accounts are removed, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to remove authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account removal actions provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding 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. |
Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to determine if account removal is automatically audited. If account removal is not automatically audited, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "gpasswd" command with the following command: $ sudo auditctl -l | grep gpasswd -a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -k privileged-gpasswd If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "gpasswd" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -k privileged-gpasswd The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 18 | CCI-001405 | SRG-APP-000029-CTR-000085 | The container platform must automatically audit account removal actions. | Red Hat OpenShift Container Platform 4 must audit all uses of the /usr/sbin/grub2-set-bootflag command. | When application accounts are removed, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to remove authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account removal actions provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding 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. |
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to determine if account removal is automatically audited. If account removal is not automatically audited, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "/usr/sbin/grub2-set-bootflag" command with the following command: $ sudo auditctl -l | grep /usr/sbin/grub2-set-bootflag -a always,exit -F path=/usr/sbin/grub2-set-bootflag -F perm=x -F auid>=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "/usr/sbin/grub2-set-bootflag" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/sbin/grub2-set-bootflag -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 19 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-APP-000029-CTR-000085 | The container platform must automatically audit account removal actions. | Red Hat OpenShift Container Platform 4 must audit all uses of the mount command. | When application accounts are removed, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to remove authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account removal actions provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding 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. |
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to determine if account removal is automatically audited. If account removal is not automatically audited, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "mount" command with the following command: $ sudo auditctl -l | grep /usr/bin/mount -a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -k privileged-mount If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "mount" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -k privileged-mount The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 20 | CCI-001405 | SRG-APP-000029-CTR-000085 | The container platform must automatically audit account removal actions. | Red Hat OpenShift Container Platform 4 must audit all uses of the /usr/sbin/mount.nfs command. | When application accounts are removed, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to remove authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account removal actions provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding 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. |
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to determine if account removal is automatically audited. If account removal is not automatically audited, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "/usr/sbin/mount.nfs" command with the following command: $ sudo auditctl -l | grep /usr/sbin/mount.nfs -a always,exit -F path=/usr/sbin/mount.nfs -F perm=x -F auid>=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "/usr/sbin/mount.nfs" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/sbin/mount.nfs -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 21 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-APP-000029-CTR-000085,SRG-APP-000495-CTR-001235 | The container platform must automatically audit account removal actions. | Red Hat OpenShift Container Platform 4 must audit all uses of the newgrp command. | When application accounts are removed, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to remove authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account removal actions provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding 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. |
Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to determine if account removal is automatically audited. If account removal is not automatically audited, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "newgrp" command with the following command: $ sudo auditctl -l | grep newgrp -a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -k priv_cmd If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "newgrp" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -k priv_cmd The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 22 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-APP-000029-CTR-000085,SRG-APP-000495-CTR-001235 | The container platform must automatically audit account removal actions. | Red Hat OpenShift Container Platform 4 must audit all uses of the passwd command. | When application accounts are removed, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to remove authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account removal actions provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding 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. |
Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to determine if account removal is automatically audited. If account removal is not automatically audited, this is a finding. |
Verify Red Hat OpenShift Container Platform 4 generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/gshadow" with the following command: $ sudo auditctl -l | egrep '(/usr/bin/passwd)' -a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -k privileged-passwd If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "passwd" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -k privileged-passwd The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 23 | CCI-001405 | SRG-APP-000029-CTR-000085 | The container platform must automatically audit account removal actions. | Red Hat OpenShift Container Platform 4 must audit all uses of the pkexec command. | When application accounts are removed, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to remove authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account removal actions provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding 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. |
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to determine if account removal is automatically audited. If account removal is not automatically audited, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "pkexec" command with the following command: $ sudo auditctl -l | grep pkexec -a always,exit -F path=/usr/bin/pkexec -F perm=x -F auid>=1000 -F auid!=unset -k privileged-pkexec If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "pkexec" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/bin/pkexec -F perm=x -F auid>=1000 -F auid!=unset -k privileged-pkexec The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 24 | CCI-001405 | SRG-APP-000029-CTR-000085 | The container platform must automatically audit account removal actions. | Red Hat OpenShift Container Platform 4 must audit all uses of the /usr/libexec/sssd/krb5_child command. | When application accounts are removed, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to remove authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account removal actions provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding 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. |
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to determine if account removal is automatically audited. If account removal is not automatically audited, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "/usr/libexec/sssd/krb5_child" command with the following command: $ sudo auditctl -l | grep /usr/libexec/sssd/krb5_child -a always,exit -F path=/usr/libexec/sssd/krb5_child -F perm=x -F auid>=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "/usr/libexec/sssd/krb5_child" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/libexec/sssd/krb5_child -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 25 | CCI-001405 | SRG-APP-000029-CTR-000085 | The container platform must automatically audit account removal actions. | Red Hat OpenShift Container Platform 4 must audit all uses of the /usr/libexec/sssd/ldap_child command. | When application accounts are removed, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to remove authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account removal actions provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding 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. |
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to determine if account removal is automatically audited. If account removal is not automatically audited, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "/usr/libexec/sssd/ldap_child" command with the following command: $ sudo auditctl -l | grep /usr/libexec/sssd/ldap_child -a always,exit -F path=/usr/libexec/sssd/ldap_child -F perm=x -F auid>=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "/usr/libexec/sssd/ldap_child" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/libexec/sssd/ldap_child -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 26 | CCI-001405 | SRG-APP-000029-CTR-000085 | The container platform must automatically audit account removal actions. | Red Hat OpenShift Container Platform 4 must audit all uses of the /usr/libexec/sssd/proxy_child command. | When application accounts are removed, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to remove authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account removal actions provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding 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. |
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to determine if account removal is automatically audited. If account removal is not automatically audited, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "/usr/libexec/sssd/proxy_child" command with the following command: $ sudo auditctl -l | grep /usr/libexec/sssd/proxy_child -a always,exit -F path=/usr/libexec/sssd/proxy_child -F perm=x -F auid>=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "/usr/libexec/sssd/proxy_child" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/libexec/sssd/proxy_child -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 27 | CCI-001405 | SRG-APP-000029-CTR-000085 | The container platform must automatically audit account removal actions. | Red Hat OpenShift Container Platform 4 must audit all uses of the /usr/libexec/sssd/selinux_child command. | When application accounts are removed, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to remove authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account removal actions provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding 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. |
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to determine if account removal is automatically audited. If account removal is not automatically audited, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "/usr/libexec/sssd/selinux_child" command with the following command: $ sudo auditctl -l | grep /usr/libexec/sssd/selinux_child -a always,exit -F path=/usr/libexec/sssd/selinux_child -F perm=x -F auid>=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "/usr/libexec/sssd/selinux_child" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/libexec/sssd/selinux_child -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 28 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-APP-000029-CTR-000085,SRG-APP-000495-CTR-001235 | The container platform must automatically audit account removal actions. | Red Hat OpenShift Container Platform 4 must audit all uses of the ssh-keysign command. | When application accounts are removed, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to remove authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account removal actions provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding 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. |
Without generating audit record specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to determine if account removal is automatically audited. If account removal is not automatically audited, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "ssh-keysign" command with the following command: $ sudo auditctl -l | grep ssh-keysign -a always,exit -F path=/usr/libexec/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=unset -k privileged-ssh If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "ssh-keysign" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/libexec/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=unset -k privileged-ssh The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 29 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000064-GPOS-0003,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-OS-000466-GPOS-00210,SRG-APP-000029-CTR-000085,SRG-APP-000495-CTR-001235,SRG-APP-000499-CTR-001255,SRG-OS-000755-GPOS-00220 | The container platform must automatically audit account removal actions. | Red Hat OpenShift Container Platform 4 must audit all uses of the su command. | When application accounts are removed, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to remove authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account removal actions provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding 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. |
Without generating audit record specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to determine if account removal is automatically audited. If account removal is not automatically audited, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "su" command with the following command: $ sudo auditctl -l | grep /usr/bin/su -a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=unset -k privileged-priv_change If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "su" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=unset -k privileged-priv_change The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 30 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-OS-000466-GPOS-00210,SRG-APP-000029-CTR-000085,SRG-APP-000495-CTR-001235,SRG-APP-000499-CTR-001255,SRG-OS-000755-GPOS-00220 | The container platform must automatically audit account removal actions. | Red Hat OpenShift Container Platform 4 must audit all uses of the sudo command. | When application accounts are removed, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to remove authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account removal actions provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding 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. |
Without generating audit record specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to determine if account removal is automatically audited. If account removal is not automatically audited, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "sudo" command with the following command: $ sudo auditctl -l | grep /usr/bin/sudo -a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=unset -k priv_cmd If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "sudo" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=unset -k priv_cmd The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 31 | CCI-000172,CCI-000130,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-APP-000029-CTR-000085 | The container platform must automatically audit account removal actions. | Red Hat OpenShift Container Platform 4 must audit all uses of umount system calls. | When application accounts are removed, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to remove authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account removal actions provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding 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. |
Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to determine if account removal is automatically audited. If account removal is not automatically audited, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "umount" command with the following command: $ sudo auditctl -l | grep umount -a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -k privileged-mount If the command does not return an audit rule for "umount" or any of the lines returned are commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "umount" command by adding or updating the following rules in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -k privileged-mount The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 32 | CCI-001405 | SRG-APP-000029-CTR-000085 | The container platform must automatically audit account removal actions. | Red Hat OpenShift Container Platform 4 must audit all uses of the /usr/libexec/utempter command. | When application accounts are removed, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to remove authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account removal actions provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding 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. |
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to determine if account removal is automatically audited. If account removal is not automatically audited, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "/usr/libexec/utempter" command with the following command: $ sudo auditctl -l | grep /usr/libexec/utempter -a always,exit -F path=/usr/libexec/utempter -F perm=x -F auid>=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "polkit-agent-helper" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path= /usr/libexec/utempter -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 33 | CCI-001405 | SRG-APP-000029-CTR-000085 | The container platform must automatically audit account removal actions. | Red Hat OpenShift Container Platform 4 must audit all uses of the /usr/lib/polkit-1/polkit-agent-helper-1 command. | When application accounts are removed, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to remove authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account removal actions provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding 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. |
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to determine if account removal is automatically audited. If account removal is not automatically audited, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "/usr/lib/polkit-1/polkit-agent-helper-1" command with the following command: $ sudo auditctl -l | grep polkit-agent-helper-1 -a always,exit -F path=/usr/lib/polkit-1/polkit-agent-helper-1 -F perm=x -F auid>=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "polkit-agent-helper" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path= /usr/lib/polkit-1/polkit-agent-helper-1-F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 34 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-APP-000029-CTR-000085,SRG-APP-000495-CTR-001235 | The container platform must automatically audit account removal actions. | Red Hat OpenShift Container Platform 4 must audit all uses of the pam_timestamp_check command. | When application accounts are removed, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to remove authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account removal actions provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding 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. |
Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to determine if account removal is automatically audited. If account removal is not automatically audited, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "pam_timestamp_check" command with the following command: $ sudo auditctl -l | grep timestamp -a always,exit -F path=/usr/sbin/pam_timestamp_check -F perm=x -F auid>=1000 -F auid!=unset -k privileged-pam_timestamp_check If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "pam_timestamp_check" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/sbin/pam_timestamp_check -F perm=x -F auid>=1000 -F auid!=unset -k privileged-pam_timestamp_check The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 35 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-APP-000029-CTR-000085,SRG-APP-000495-CTR-001235 | The container platform must automatically audit account removal actions. | Red Hat OpenShift Container Platform 4 must audit all uses of the unix_chkpwd command. | When application accounts are removed, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to remove authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account removal actions provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding 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. |
Without generating audit record specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to determine if account removal is automatically audited. If account removal is not automatically audited, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "unix_chkpwd" command with the following command: $ sudo auditctl -l | grep unix_chkpwd -a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix-update If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "unix_chkpwd" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix-update The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 36 | CCI-001405 | SRG-APP-000029-CTR-000085 | The container platform must automatically audit account removal actions. | Red Hat OpenShift Container Platform 4 must audit all uses of the write command. | When application accounts are removed, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to remove authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account removal actions provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding 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. |
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to determine if account removal is automatically audited. If account removal is not automatically audited, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "write" command with the following command: $ sudo auditctl -l | grep write -a always,exit -F path=/usr/bin/write -F perm=x -F auid>=1000 -F auid!=unset -k privileged-write If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "write" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/bin/write -F perm=x -F auid>=1000 -F auid!=unset -k privileged-write The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 37 | CCI-000803 | SRG-APP-000126-CTR-000275,SRG-APP-000219-CTR-000550,SRG-APP-000411-CTR-000995,SRG-APP-000412-CTR-001000,SRG-APP-000416-CTR-001015,SRG-APP-000514-CTR-001315,SRG-APP-000610-CTR-001385,SRG-APP-000635-CTR-001405 | CCE-85860-5 | The container platform must use FIPS-validated SHA-2 or higher hash function for digital signature generation and verification (non-legacy use). | Red Hat OpenShift Container Platform 4 must use FIPS validated cryptographic mechanisms to protect the integrity of log information. |
Without the use of digital signature, information can be altered by unauthorized accounts accessing or modifying the container platform registry, keystore, and container at runtime. Digital signatures provide non-repudiation for transactions between the components within the container platform. Without the use of approved FIPS-validated SHA-2 or higher hash function with digital signatures, the container platform cannot claim the validity of the individual or service identity and guarantee private key is kept secret. Keeping the private keys secure is vital for validating individuals or service identity prior to information exchange. The container platform must be configured to use SHA-2 or higher hash functions for digital signatures in accordance with SP 800-131Ar2. | Applicable - Configurable | Review the container platform configuration to validate that a FIPS-validated SHA-2 or higher hash function is being used for digital signature generation and verification. If a FIPS-validated SHA-2 or higher hash function is not being used for digital signature generation and verification, this is a finding. |
OpenShift must be configured at the time of installation. Because FIPS must be enabled before the operating system that your cluster uses boots for the first time, you cannot enable FIPS after you deploy a cluster. If a cluster is installed in FIPS mode, the nodes will indicate FIPS mode and this will propagate into the platform. To validate that the OpenShift cluster is running with FIPS enabled on each node run the command: > for node in $(oc get node -oname); \ do oc debug $node -- chroot /host /bin/bash -c 'echo -n "$HOSTNAME "; \ sysctl crypto.fips_enabled' 2>/dev/null; done If any lines of output end in anything other than a 1, this is a finding. |
Reinstall the OpenShift cluster in FIPS mode. The file install-config.yaml has a top level key that enables FIPS mode for all nodes and the cluster platform layer. If your install-config.yaml was not backed up prior to consumption as part of the installation, you will need to recreate it. An example install-config.yaml with some sections trimmed out for brevity, and the "fips: true" key applied at the top level is shown below: apiVersion: v1 baseDomain: example.com controlPlane: name: master platform: aws: [...] replicas: 3 compute: - name: worker platform: aws: replicas: 3 metadata: name: fips-cluster networking: [...] platform: aws: [...] sshKey: ssh-ed25519 AAAA... pullSecret: '{"auths": ...}' fips: true Once you have saved the install-config.yaml with corresponding correct information for your installation infrastructure, run the installer to create a cluster that uses FIPS Validated / Modules in Process cryptographic libraries. The command to install a cluster and consume the install-config.yaml is: > ./openshift-install create cluster --dir= \ --log-level=info Where is the directory that contains install-config.yaml Additional Details can be found here: https://docs.openshift.com/container-platform/latest/installing/installing-fips.html |
CAT II | ||||||
| 38 | CCI-000382 | SRG-APP-000142-CTR-000330 | CCE-86255-7 | The container platform runtime must enforce the use of ports that are non-privileged. | runtime must enforce the use of ports that are non-privileged. | Privileged ports are those ports below 1024 and that require system privileges for their use. If containers are able to use these ports, the container must be run as a privileged user. The container platform must stop containers that try to map to these ports directly. Allowing non-privileged ports to be mapped to the container-privileged port is the allowable method when a certain port is needed. An example is mapping port 8080 externally to port 80 in the container. | Applicable - Configurable | Review the container platform configuration and the containers within the platform by performing the following checks: 1. Verify the container platform is configured to disallow the use of privileged ports by containers. 2. Validate all containers within the container platform are using non-privileged ports. 3. Attempt to instantiate a container image that uses a privileged port. If the container platform is not configured to disallow the use of privileged ports, this is a finding. If the container platform has containers using privileged ports, this is a finding. If the container platform allows containers to be instantiated that use privileged ports, this is a finding. |
Identify any SCC policy that allows containers to access the host filesystem resources by running the following command > oc get scc -ojson | jq '.items[]|select(.allowHostDirVolumePlugin)|.metadata.name,{"Group:":.groups},{"User":.users}' For each SCC listed, if any of those users or groups are anything other than the following, this is a finding: * system:cluster-admins * system:nodes * system:masters * system:admin * system:serviceaccount:openshift-infra:build-controller * system:serviceaccount:openshift-infra:pv-recycler-controller * system:serviceaccount:openshift-machine-api:machine-api-termination-handler The group "system:authenticated" is the default group for any authenticated user, this group should only be associated with the restricted profile. If this group is listed under any other SCC Policy, or the restricted SCC policy has been altered to allow any of the non-permitted actions, this is a finding. Next, determine if there are any cluster roles or local roles that allow the use of use of non-permitted SCC policies. The following commands will print the Role's name and namespace, followed by a list of resource names and if that resource is an SCC. > oc get clusterrole.rbac -ojson | jq -r '.items[]|select(.rules[]?|select( (.apiGroups[]? == ("security.openshift.io")) and (.resources[]? == ("securitycontextconstraints")) and (.verbs[]? == ("use"))))|.metadata.name,{"scc":(.rules[]?|select((.resources[]? == ("securitycontextconstraints"))).resourceNames[]?)}' > oc get role.rbac --all-namespaces -ojson | jq -r '.items[]|select(.rules[]?|select( (.apiGroups[]? == ("security.openshift.io")) and (.resources[]? == ("securitycontextconstraints")) and (.verbs[]? == ("use"))))|.metadata.name,{"scc":(.rules[]?|select((.resources[]? == ("securitycontextconstraints"))).resourceNames[]?)}' Excluding platform specific roles, identify any roles that allow use of non-permitted SCC policies for example the follow output shows that the role 'examplePrivilegedRole' allows use of the 'privileged' SCC. examplePrivilegedRole { "scc": "privileged" } Finally, determine if there are any role bindings to cluster or local roles that allow use of non-permitted SCCs. > oc get clusterrolebinding.rbac -ojson | jq -r '.items[]|select(.roleRef.kind == ("ClusterRole","Role") and .roleRef.name == ( ))|{ "crb": .metadata.name, "roleRef": .roleRef, "subjects": .subjects}' > oc get rolebinding.rbac --all-namespaces -ojson | jq -r '.items[]|select(.roleRef.kind == ("ClusterRole","Role") and .roleRef.name == ( ))|{ "crb": .metadata.name, "roleRef": .roleRef, "subjects": .subjects}' Where and are comma-separated lists of the roles allowing use of non-permitted SCC policies as identified above. For example: ... .roleRef.name == ("system:openshift:scc:privileged","system:openshift:scc:hostnetwork","system:openshift:scc:hostaccess") ... Excluding any platform namespaces (kube-*,openshift-*), if there are any rolebindings to roles that are not permitted, this is a finding. |
For users and groups that are defined in the SCC policy, remove the users or groups by editing the corresponding SCC policy. > oc edit scc The following instructions will remove the user or group from the cluster role binding for the SCC policy. Remove user from the SCC Policy binding: > oc adm policy remove-scc-from-user Remove a group from the SCC Policy binding: > oc adm policy remove-scc-from-group Remove service account from the SCC Policy binding: > oc project > oc adm policy remove-scc-from-user -z Finally, remove any roles that allows use of non-permitted SCC policies (excluding platform defined roles) > oc delete clusterrole.rbac or > oc delete role.rbac -n |
CAT II | ||||||
| 39 | CCI-000382 | SRG-APP-000142-CTR-000330 | CCE-86205-2 | The container platform runtime must enforce the use of ports that are non-privileged. | runtime must enforce the use of ports that are non-privileged. | Privileged ports are those ports below 1024 and that require system privileges for their use. If containers are able to use these ports, the container must be run as a privileged user. The container platform must stop containers that try to map to these ports directly. Allowing non-privileged ports to be mapped to the container-privileged port is the allowable method when a certain port is needed. An example is mapping port 8080 externally to port 80 in the container. | Applicable - Configurable | Review the container platform configuration and the containers within the platform by performing the following checks: 1. Verify the container platform is configured to disallow the use of privileged ports by containers. 2. Validate all containers within the container platform are using non-privileged ports. 3. Attempt to instantiate a container image that uses a privileged port. If the container platform is not configured to disallow the use of privileged ports, this is a finding. If the container platform has containers using privileged ports, this is a finding. If the container platform allows containers to be instantiated that use privileged ports, this is a finding. |
Identify any SCC policy that allows containers to access the host ports by running the following command. > oc get scc -ojson | jq '.items[]|select(.allowHostPorts)|.metadata.name,{"Group:":.groups},{"User":.users}' For each SCC listed, if any of those users or groups are anything other than the following, this is a finding: * system:cluster-admins * system:nodes * system:masters * system:admin * system:serviceaccount:openshift-infra:build-controller * system:serviceaccount:openshift-infra:pv-recycler-controller * system:serviceaccount:openshift-machine-api:machine-api-termination-handler The group "system:authenticated" is the default group for any authenticated user, this group should only be associated with the restricted profile. If this group is listed under any other SCC Policy, or the restricted SCC policy has been altered to allow any of the non-permitted actions, this is a finding. Next, determine if there are any cluster roles or local roles that allow the use of use of non-permitted SCC policies. The following commands will print the Role's name and namespace, followed by a list of resource names and if that resource is an SCC. > oc get clusterrole.rbac -ojson | jq -r '.items[]|select(.rules[]?|select( (.apiGroups[]? == ("security.openshift.io")) and (.resources[]? == ("securitycontextconstraints")) and (.verbs[]? == ("use"))))|.metadata.name,{"scc":(.rules[]?|select((.resources[]? == ("securitycontextconstraints"))).resourceNames[]?)}' > oc get role.rbac --all-namespaces -ojson | jq -r '.items[]|select(.rules[]?|select( (.apiGroups[]? == ("security.openshift.io")) and (.resources[]? == ("securitycontextconstraints")) and (.verbs[]? == ("use"))))|.metadata.name,{"scc":(.rules[]?|select((.resources[]? == ("securitycontextconstraints"))).resourceNames[]?)}' Excluding platform specific roles, identify any roles that allow use of non-permitted SCC policies for example the follow output shows that the role 'examplePrivilegedRole' allows use of the 'privileged' SCC. examplePrivilegedRole { "scc": "privileged" } Finally, determine if there are any role bindings to cluster or local roles that allow use of non-permitted SCCs. > oc get clusterrolebinding.rbac -ojson | jq -r '.items[]|select(.roleRef.kind == ("ClusterRole","Role") and .roleRef.name == ( ))|{ "crb": .metadata.name, "roleRef": .roleRef, "subjects": .subjects}' > oc get rolebinding.rbac --all-namespaces -ojson | jq -r '.items[]|select(.roleRef.kind == ("ClusterRole","Role") and .roleRef.name == ( ))|{ "crb": .metadata.name, "roleRef": .roleRef, "subjects": .subjects}' Where and are comma-separated lists of the roles allowing use of non-permitted SCC policies as identified above. For example: ... .roleRef.name == ("system:openshift:scc:privileged","system:openshift:scc:hostnetwork","system:openshift:scc:hostaccess") ... Excluding any platform namespaces (kube-*,openshift-*), if there are any rolebindings to roles that are not permitted, this is a finding. |
For users and groups that are defined in the SCC policy, remove the users or groups by editing the corresponding SCC policy. > oc edit scc The following instructions will remove the user or group from the cluster role binding for the SCC policy. Remove user from the SCC Policy binding: > oc adm policy remove-scc-from-user Remove a group from the SCC Policy binding: > oc adm policy remove-scc-from-group Remove service account from the SCC Policy binding: > oc project > oc adm policy remove-scc-from-user -z Finally, remove any roles that allows use of non-permitted SCC policies (excluding platform defined roles) > oc delete clusterrole.rbac or > oc delete role.rbac -n |
CAT II | ||||||
| 40 | CCI-000382 | SRG-APP-000142-CTR-000330 | CCE-83492-9 | The container platform runtime must enforce the use of ports that are non-privileged. | runtime must enforce the use of ports that are non-privileged. | Privileged ports are those ports below 1024 and that require system privileges for their use. If containers are able to use these ports, the container must be run as a privileged user. The container platform must stop containers that try to map to these ports directly. Allowing non-privileged ports to be mapped to the container-privileged port is the allowable method when a certain port is needed. An example is mapping port 8080 externally to port 80 in the container. | Applicable - Configurable | Review the container platform configuration and the containers within the platform by performing the following checks: 1. Verify the container platform is configured to disallow the use of privileged ports by containers. 2. Validate all containers within the container platform are using non-privileged ports. 3. Attempt to instantiate a container image that uses a privileged port. If the container platform is not configured to disallow the use of privileged ports, this is a finding. If the container platform has containers using privileged ports, this is a finding. If the container platform allows containers to be instantiated that use privileged ports, this is a finding. |
Identify any SCC policy that allows containers to access the host network or filesystem resources, or allows privileged containers by running the following command. > oc get scc -ojson | jq '.items[]|select(.allowHostNetwork)|.metadata.name,{"Group:":.groups},{"User":.users}' For each SCC listed, if any of those users or groups are anything other than the following, this is a finding: * system:cluster-admins * system:nodes * system:masters * system:admin * system:serviceaccount:openshift-infra:build-controller * system:serviceaccount:openshift-infra:pv-recycler-controller * system:serviceaccount:openshift-machine-api:machine-api-termination-handler The group "system:authenticated" is the default group for any authenticated user, this group should only be associated with the restricted profile. If this group is listed under any other SCC Policy, or the restricted SCC policy has been altered to allow any of the non-permitted actions, this is a finding. Next, determine if there are any cluster roles or local roles that allow the use of use of non-permitted SCC policies. The following commands will print the Role's name and namespace, followed by a list of resource names and if that resource is an SCC. > oc get clusterrole.rbac -ojson | jq -r '.items[]|select(.rules[]?|select( (.apiGroups[]? == ("security.openshift.io")) and (.resources[]? == ("securitycontextconstraints")) and (.verbs[]? == ("use"))))|.metadata.name,{"scc":(.rules[]?|select((.resources[]? == ("securitycontextconstraints"))).resourceNames[]?)}' > oc get role.rbac --all-namespaces -ojson | jq -r '.items[]|select(.rules[]?|select( (.apiGroups[]? == ("security.openshift.io")) and (.resources[]? == ("securitycontextconstraints")) and (.verbs[]? == ("use"))))|.metadata.name,{"scc":(.rules[]?|select((.resources[]? == ("securitycontextconstraints"))).resourceNames[]?)}' Excluding platform specific roles, identify any roles that allow use of non-permitted SCC policies for example the follow output shows that the role 'examplePrivilegedRole' allows use of the 'privileged' SCC. examplePrivilegedRole { "scc": "privileged" } Finally, determine if there are any role bindings to cluster or local roles that allow use of non-permitted SCCs. > oc get clusterrolebinding.rbac -ojson | jq -r '.items[]|select(.roleRef.kind == ("ClusterRole","Role") and .roleRef.name == ( ))|{ "crb": .metadata.name, "roleRef": .roleRef, "subjects": .subjects}' > oc get rolebinding.rbac --all-namespaces -ojson | jq -r '.items[]|select(.roleRef.kind == ("ClusterRole","Role") and .roleRef.name == ( ))|{ "crb": .metadata.name, "roleRef": .roleRef, "subjects": .subjects}' Where and are comma-separated lists of the roles allowing use of non-permitted SCC policies as identified above. For example: ... .roleRef.name == ("system:openshift:scc:privileged","system:openshift:scc:hostnetwork","system:openshift:scc:hostaccess") ... Excluding any platform namespaces (kube-*,openshift-*), if there are any rolebindings to roles that are not permitted, this is a finding. |
For users and groups that are defined in the SCC policy, remove the users or groups by editing the corresponding SCC policy. > oc edit scc The following instructions will remove the user or group from the cluster role binding for the SCC policy. Remove user from the SCC Policy binding: > oc adm policy remove-scc-from-user Remove a group from the SCC Policy binding: > oc adm policy remove-scc-from-group Remove service account from the SCC Policy binding: > oc project > oc adm policy remove-scc-from-user -z Finally, remove any roles that allows use of non-permitted SCC policies (excluding platform defined roles) > oc delete clusterrole.rbac or > oc delete role.rbac -n |
CAT II | ||||||
| 41 | CCI-000382 | SRG-APP-000342-CTR-000775,SRG-APP-000142-CTR-000330 | The container platform runtime must enforce the use of ports that are non-privileged. | Container images instantiated by the container platform must execute using least privileges. | Privileged ports are those ports below 1024 and that require system privileges for their use. If containers are able to use these ports, the container must be run as a privileged user. The container platform must stop containers that try to map to these ports directly. Allowing non-privileged ports to be mapped to the container-privileged port is the allowable method when a certain port is needed. An example is mapping port 8080 externally to port 80 in the container. | Applicable - Configurable | Review the container platform configuration and the containers within the platform by performing the following checks: 1. Verify the container platform is configured to disallow the use of privileged ports by containers. 2. Validate all containers within the container platform are using non-privileged ports. 3. Attempt to instantiate a container image that uses a privileged port. If the container platform is not configured to disallow the use of privileged ports, this is a finding. If the container platform has containers using privileged ports, this is a finding. If the container platform allows containers to be instantiated that use privileged ports, this is a finding. |
Inspect each SCC and the users and groups allowed to use it returned from running the following command: oc get scc -ojson | jq '.items[]|select(.allowPrivilegedContainer)|.metadata.name,{"Group:":.groups},{"User":.users}' The group "system:authenticated" is the default group for any authenticated user, this group should only be associated with the restricted profile. If this group is listed under any other SCC Policy, or the restricted SCC policy has been altered to allow any of the non-permitted actions, this is a finding. Next, determine if there are any cluster roles or local roles that allow the use of use of non-permitted SCC policies. The following commands will print the Role's name and namespace, followed by a list of resource names and if that resource is an SCC. > oc get clusterrole.rbac -ojson | jq -r '.items[]|select(.rules[]?|select( (.apiGroups[]? == ("security.openshift.io")) and (.resources[]? == ("securitycontextconstraints")) and (.verbs[]? == ("use"))))|.metadata.name,{"scc":(.rules[]?|select((.resources[]? == ("securitycontextconstraints"))).resourceNames[]?)}' > oc get role.rbac --all-namespaces -ojson | jq -r '.items[]|select(.rules[]?|select( (.apiGroups[]? == ("security.openshift.io")) and (.resources[]? == ("securitycontextconstraints")) and (.verbs[]? == ("use"))))|.metadata.name,{"scc":(.rules[]?|select((.resources[]? == ("securitycontextconstraints"))).resourceNames[]?)}' Excluding platform specific roles, identify any roles that allow use of non-permitted SCC policies for example the follow output shows that the role 'examplePrivilegedRole' allows use of the 'privileged' SCC. examplePrivilegedRole { "scc": "privileged" } Finally, determine if there are any role bindings to cluster or local roles that allow use of non-permitted SCCs. > oc get clusterrolebinding.rbac -ojson | jq -r '.items[]|select(.roleRef.kind == ("ClusterRole","Role") and .roleRef.name == ( ))|{ "crb": .metadata.name, "roleRef": .roleRef, "subjects": .subjects}' > oc get rolebinding.rbac --all-namespaces -ojson | jq -r '.items[]|select(.roleRef.kind == ("ClusterRole","Role") and .roleRef.name == ( ))|{ "crb": .metadata.name, "roleRef": .roleRef, "subjects": .subjects}' Where "CLUSTER_ROLE_LIST" and "LOCAL_ROLE_LIST" are comma-separated lists of the roles allowing use of non-permitted SCC policies as identified above. For example: ... .roleRef.name == ("system:openshift:scc:privileged","system:openshift:scc:hostnetwork","system:openshift:scc:hostaccess") ... Excluding any platform namespaces (kube-*,openshift-*), if there are any rolebindings to roles that are not permitted, this is a finding. |
For users and groups that are defined in the SCC policy, remove the users or groups by editing the corresponding SCC policy. > oc edit scc The following instructions will remove the user or group from the cluster role binding for the SCC policy. Remove user from the SCC Policy binding: > oc adm policy remove-scc-from-user Remove a group from the SCC Policy binding: > oc adm policy remove-scc-from-group Remove service account from the SCC Policy binding: > oc project > oc adm policy remove-scc-from-user -z Finally, remove any roles that allows use of non-permitted SCC policies (excluding platform defined roles) > oc delete clusterrole.rbac or > oc delete role.rbac -n |
CAT II | |||||||
| 42 | CCI-001876 | SRG-APP-000181-CTR-000485 | The container platform must provide an audit reduction capability that supports on-demand reporting requirements. | Red Hat OpenShift Container Platform 4 must provide an audit reduction capability that supports on-demand reporting requirements. | The ability to generate on-demand reports, including after the audit data has been subjected to audit reduction, greatly facilitates the organization's ability to generate incident reports as needed to better handle larger-scale or more complex security incidents. Audit reduction is a process that manipulates collected audit information and organizes such information in a summary format that is more meaningful to analysts. The report generation capability provided by the application must support on-demand (i.e., customizable, ad hoc, and as-needed) reports. This requirement is specific to applications with audit reduction capabilities; however, applications need to support on-demand audit review and analysis. |
Not Applicable | Review the container platform configuration to determine if the container platform is configured to provide an audit reduction capability that supports on-demand reporting requirements. If the container platform is not configured to support on-demand reporting requirements, this is a finding. |
CAT II | Not applicable - The location of the external logging server used for audit log aggregation is outside the scope of Red Hat OpenShift Container Platform 4 configuration. Because the configuration recommended in response to SRG-APP-000111-CTR-000220 configures an external log aggregation server outside of the control of the Red Hat OpenShift Container Platform 4 cluster, it is up to individual implementation to ensure that the location of that log aggregation point meets other requirements. |
||||||||
| 43 | CCI-002039 | SRG-APP-000390-CTR-000930 | The container platform must require devices to reauthenticate when organization-defined circumstances or situations requiring reauthentication. | Red Hat OpenShift Container Platform 4 must require devices to reauthenticate when organization-defined circumstances or situations requiring reauthentication. | The container platform may require external devices be used to fully orchestrate the services needed for users. Examples would be storage or external servers. Without reauthentication, unidentified or unknown devices may be introduced; thereby facilitating malicious activity. The container platform must be capable of allowing the organization to set requirements associated with device reauthentication. Examples are: Organizations may require reauthentication of devices, including (but not limited to), the following other situations: (i) When authenticators change; (ii) When roles change; (iii) When security categories of information systems change; (iv) After a fixed period of time; or (v) Periodically. For distributed architectures (e.g., service-oriented architectures), the decisions regarding the validation of identification claims may be made by services separate from the services acting on those decisions. In such situations, it is necessary to provide the identification decisions (as opposed to the actual identifiers) to the services that need to act on those decisions. |
Not Applicable | Review documentation and configuration to determine if the container platform requires devices to reauthenticate when organization-defined circumstances or situations require reauthentication. If the container platform does not require a device to reauthenticate, this is a finding. |
CAT II | Supporting evidence is in the following documentation https://docs.openshift.com/container-platform/latest/authentication/using-rbac.html |
The OpenShift Container Platform does not required a user/device to re-authenticate when changes to the RBAC policy, or permissions to a service/object change in the system. These changes are applied and effective immediately and do not require the user/device to first logout. https://docs.openshift.com/container-platform/latest/authentication/using-rbac.html |
|||||||
| 44 | CCI-000366 | SRG-APP-000516-CTR-000790 | The container platform must provide the configuration for organization-identified individuals or roles to change the auditing to be performed on all components, based on all selectable event criteria within organization-defined time thresholds. | Red Hat OpenShift Container Platform 4 must provide the configuration for organization-identified individuals or roles to change the auditing to be performed on all components, based on all selectable event criteria within organization-defined time thresholds. | Auditing requirements may change per organization or situation within and organization. With the container platform allowing an organization to customize the auditing, an organization can decide to extend or limit auditing as necessary to meet organizational requirements. Auditing that is limited to conserve resources may be extended to address certain threat situations. In addition, auditing may be limited to a specific set of events to facilitate audit reduction, analysis, and reporting. Organizations can establish time thresholds in which audit actions are changed, for example, near real-time, within minutes, or within hours. Modifying auditing within the container platform must be controlled to only those individuals or roles identified by the organization to modify auditable events. |
Applicable - Does Not Meet | Review documentation and configuration setting. If the container platform does not provide the ability for users in authorized roles to reconfigure auditing at any time of the user's choosing, this is a finding. If changes in audit configuration cannot take effect until after a certain time or date, or until some event, such as a server restart, has occurred, and if that time or event does not meet the requirements specified by the organization, this is a finding. |
CAT II | A way of mitigating the control is to set a verbose audit log level, forward the logs off-cluster and then filter or correlate the log information that are needed using SIEM tools such as Elastic. Documentation regarding how to forward cluster logs using the Cluster Logging Operator to specific endpoints can be found at: https://docs.openshift.com/container-platform/latest/logging/cluster-logging.html |
Custom audit policies are not supported. However, the WriteRequestBodies (or even AllRequestBodies) policies should satisfy all the information the other controls ask for. Red Hat OpenShift supports three different audit policies which are documented at https://docs.openshift.com/container-platform/4.7/security/audit-log-policy-config.html |
|||||||
| 45 | CCI-001090 | SRG-APP-000516-CTR-001325 | The container platform must prohibit containers from accessing privileged resources. | Containers images instantiated within the container platform may request access to host system resources. Access to privileged resources can allow for unauthorized and unintended transfer of information, but in some cases, these resources may be needed for the service being offered by the container. By default, containers should be denied instantiation when privileged system resources are requested and granted only after approval has been given. When access to privileged resources is necessary for a container, a new policy for execution should be written for the container. The default behavior must not give containers privileged access to host system resources. Examples of system resources that should be protected are kernel namespaces and host system sensitive directories such as /etc and /usr. |
Applicable - Configurable | Review documentation and configuration to determine if the container platform disallows instantiation of containers trying to access host system privileged resources. If the container platform does not block containers requesting host system privileged resources, this is a finding. |
CAT II | ||||||||||
| 46 | CCI-001090 | SRG-APP-000516-CTR-001325 | CCE-84042-1 | The container platform must prohibit containers from accessing privileged resources. | Containers images instantiated within the container platform may request access to host system resources. Access to privileged resources can allow for unauthorized and unintended transfer of information, but in some cases, these resources may be needed for the service being offered by the container. By default, containers should be denied instantiation when privileged system resources are requested and granted only after approval has been given. When access to privileged resources is necessary for a container, a new policy for execution should be written for the container. The default behavior must not give containers privileged access to host system resources. Examples of system resources that should be protected are kernel namespaces and host system sensitive directories such as /etc and /usr. |
Applicable - Configurable | Review documentation and configuration to determine if the container platform disallows instantiation of containers trying to access host system privileged resources. If the container platform does not block containers requesting host system privileged resources, this is a finding. |
CAT II | |||||||||
| 47 | CCI-000196 | SRG-APP-000171-CTR-000435 | For container platform using password authentication, the application must store only cryptographic representations of passwords. | For container platform using password authentication, the application must store only cryptographic representations of passwords. | Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read and easily compromised. Use of passwords for authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication. Examples of situations where a user ID and password might be used include: - When the user does not use a CAC and is not a current DoD employee, member of the military, or DoD contractor. - When a user has been officially designated as temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) (i.e., Temporary Exception User) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied. - When the application is publicly available and or hosting publicly releasable data requiring some degree of need-to-know protection. If the password is already encrypted and not a plaintext password, this meets this requirement. Implementation of this requirement requires configuration of FIPS-approved cipher block algorithm and block cipher modes for encryption. This method uses a one-way hashing encryption algorithm with a salt value to validate a user's password without having to store the actual password. Performance and time required to access are factors that must be considered, and the one-way hash is the most feasible means of securing the password and providing an acceptable measure of password security. Verifying the user knows a password is performed using a password verifier. In its simplest form, a password verifier is a computational function that is capable of creating a hash of a password and determining if the value provided by the user matches the hash. A more secure version of verifying a user knowing a password is to store the result of an iterating hash function and a large random salt value as follows: H0 = H(pwd, H(salt)) Hn = H(Hn-1,H(salt)) In the above, "n" is a cryptographically-strong random [*3] number. "Hn" is stored along with the salt. When the application wishes to verify that the user knows a password, it simply repeats the process and compares "Hn" with the stored "Hn". A salt is essentially a fixed-length cryptographically strong random value. Another method is using a keyed-hash message authentication code (HMAC). HMAC calculates a message authentication code via a cryptographic hash function used in conjunction with an encryption key. The key must be protected as with any private key. This requirement applies to all accounts including authentication server, AAA, and local account, including the root account and the account of last resort. |
Not Applicable | Review the container platform configuration to determine if it using password authentication and stores only cryptographic representations of the passwords. If the container platform is using password authentication and does not store only cryptographic representations of passwords, this is a finding. |
CAT II | Not Applicable. Applicable to Identity Management Provider and not OCP. Only configurable check is to ensure OCP is configured for an IDP under SRG-APP-000023-CTR-000055. Verify with IdM service provider admins that the IdM meets the requirements. |
||||||||
| 48 | CCI-000195 | SRG-APP-000170-CTR-000430 | The container platform must require the change of at least 15 of the total number of characters when passwords are changed. | Red Hat OpenShift Container Platform 4 must require the change of at least 15 of the total number of characters when passwords are changed. | If the application allows the user to consecutively reuse extensive portions of passwords, this increases the chances of password compromise by increasing the window of opportunity for attempts at guessing and brute-force attacks. The number of changed characters refers to the number of changes required with respect to the total number of positions in the current password. In other words, characters may be the same within the two passwords; however, the positions of the like characters must be different. |
Not Applicable | Review the container platform configuration to determine if it requires the change of at least 15 of the total number of characters when passwords are changed. If the container platform does not require the change of at least 15 of the total number of characters when passwords are changed, this is a finding. |
CAT II | Not Applicable. Applicable to Identity Management Provider and not OCP. Only configurable check is to ensure OCP is configured for an IDP under SRG-APP-000023-CTR-000055. Verify with IdM service provider admins that the IdM meets the requirements. |
||||||||
| 49 | CCI-001813 | SRG-APP-000033-CTR-000090,SRG-APP-000033-CTR-000095,SRG-APP-000033-CTR-000100,SRG-APP-000133-CTR-000290,SRG-APP-000133-CTR-000295,SRG-APP-000133-CTR-000300,SRG-APP-000133-CTR-000305,SRG-APP-000133-CTR-000310,SRG-APP-000148-CTR-000350,SRG-APP-000153-CTR-000375,SRG-APP-000340-CTR-000770,SRG-APP-000378-CTR-000880,SRG-APP-000378-CTR-000885,SRG-APP-000378-CTR-000890,SRG-APP-000380-CTR-000900,SRG-APP-000386-CTR-000920 | CCE-90678-4 | The container platform must enforce access restrictions for container platform configuration changes. | Least privilege access and need to know must be required to access the OpenShift components. | Configuration changes cause the container platform to change the way it operates. These changes can be used to improve the system with added features or performance, but these configuration changes can also be used to introduce malicious features and degrade performance. To control the configuration changes made to the container platform, it is important that only authorized users are allowed, through container platform enforcement, to make configuration changes. | Applicable - Configurable | Review documentation and configuration settings to determine if the container platform enforces access restrictions associated with changes to container platform components configuration. If the container platform does not enforce such access restrictions, this is a finding. |
The administrator must verify that Openshift is configured with the necessary RBAC access controls. Review the RBAC configuration. As the cluster-admin, view the cluster roles and their associated rule sets by executing the following:: oc describe clusterrole.rbac Now view the current set of cluster role bindings, which shows the users and groups that are bound to various roles by executing the following: oc describe clusterrolebinding.rbac Local roles and bindings can be determined using the follow commands by executing the following: oc describe rolebinding.rbac If these results show users with privileged access that do not require that access, this is a finding. |
If users or groups exist that are bound to roles they must not have, modify the user or group permissions using the following cluster and local role binding commands: Remove a User from a Cluster RBAC role by executing the following: oc adm policy remove-cluster-role-from-user role username Remove a Group from a Cluster RBAC role by executing the following: oc adm policy remove-cluster-role-from-group role groupname Remove a User from a Local RBAC role by executing the following: oc adm policy remove-role-from-user role username Remove a Group from a Local RBAC role by executing the following: oc adm policy remove-role-from-group role groupname NOTE: For additional information. https://docs.openshift.com/container-platform/latest/authentication/using-rbac.html |
CAT II | ||||||
| 50 | CCI-000185 | SRG-APP-000605-CTR-001380 | The container platform must validate certificates used for Transport Layer Security (TLS) functions by performing an RFC 5280-compliant certification path validation. | Red Hat OpenShift Container Platform 4 must validate certificates used for Transport Layer Security (TLS) functions by performing an RFC 5280-compliant certification path validation. | A certification path is the path from the end entity certificate to a trusted root certification authority (CA). Certification path validation is necessary for a relying party to make an informed decision regarding acceptance of an end entity certificate and discourages the use of self-signed certificates. Certification path validation includes checks such as certificate issuer trust, time validity, and revocation status for each certificate in the certification path. Revocation status information for CA and subject certificates in a certification path is commonly provided via certificate revocation lists (CRLs) or online certificate status protocol (OCSP) responses. Compliance checks should be in accordance to RFC 5280. Not adhering to RFC 5280 could result in rogue certificates, session hijacks, man-in-the-middle, denial-of-service attacks, malware, and data or information manipulation. |
Applicable - Inherently Met | Review the container platform configuration to verify the container platform is validating certificates used for Transport Layer Security (TLS) functions by performing a RFC 5280-compliant certification path validation and that self-signed certificates are not being used. If the container platform is not validating certificates used for TLS functions by performing an RFC 5280-compliant certification path validation, this is a finding. If self-signed certificates are in use, this is a finding. |
CAT II | Supporting evidence is in the following documentation https://docs.openshift.com/container-platform/latest/security/certificate_types_descriptions/node-certificates.html |
Internal components are secured with two-way TLS. Certificate revocation lists (CRLs) are not currently supported by Kubernetes upstream - https://github.com/kubernetes/kubernetes/issues/18982. Application components can be fully compliant by adding the checks inside container images. https://docs.openshift.com/container-platform/latest/security/certificate_types_descriptions/node-certificates.html Node certificates are signed by the cluster; they come from a certificate authority (CA) that is generated by the bootstrap process. Once the cluster is installed, the node certificates are auto-rotated. Node certificates are managed by the cluster and not the user |
|||||||
| 51 | CCI-000194 | SRG-APP-000168-CTR-000420 | The container platform must enforce password complexity by requiring that at least one numeric character be used. | Red Hat OpenShift Container Platform 4 must enforce password complexity by requiring that at least one numeric character be used. | Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. |
Not Applicable | Review the container platform configuration to determine if it enforces password complexity by requiring that at least one numeric character be used. If the container platform does not enforce password complexity by requiring that at least one numeric character be used, this is a finding. |
CAT II | Not Applicable. Applicable to Identity Management Provider and not OCP. Only configurable check is to ensure OCP is configured for an IDP under SRG-APP-000023-CTR-000055. Verify with IdM service provider admins that the IdM meets the requirements. |
||||||||
| 52 | CCI-000366,CCI-001849 | SRG-OS-000341-GPOS-00132,SRG-OS-000480-GPOS-00227,SRG-APP-000357-CTR-000800 | The container platform must allocate audit record storage capacity in accordance with organization-defined audit record storage requirements. | Red Hat OpenShift Container Platform 4 must use a separate file system for the system audit data path. | In order to ensure applications have a sufficient storage capacity in which to write the audit logs, applications need to be able to allocate audit record storage capacity. The task of allocating audit record storage capacity is usually performed during initial installation of the application and is closely associated with the DBA and system administrator roles. The DBA or system administrator will usually coordinate the allocation of physical drive space with the application owner/installer and the application will prompt the installer to provide the capacity information, the physical location of the disk, or both. |
Placing "/var/log/audit" in its own partition enables better separation between audit files and other system files, and helps ensure that auditing cannot be halted due to the partition running out of space. | Applicable - Configurable | Review the container platform configuration to determine if audit record storage capacity is allocated in accordance with organization-defined audit record storage requirements. If audit record storage capacity is not allocated in accordance with organization-defined audit record storage requirements, this is a finding. |
Verify that a separate file system/partition has been created for the system audit data path with the following command: Note: /var/log/audit is used as the example as it is a common location. $ mount | grep /var/log/audit UUID=2efb2979-45ac-82d7-0ae632d11f51 on /var/log/home type xfs (rw,realtime,seclabel,attr2,inode64) If no line is returned, this is a finding. |
Migrate the system audit data path onto a separate file system. | CAT II | ||||||
| 53 | CCI-000366,CCI-001487 | SRG-OS-000255-GPOS-00096,SRG-OS-000480-GPOS-00227,SRG-APP-000096-CTR-000175,SRG-APP-000097-CTR-000180,SRG-APP-000098-CTR-000185,SRG-APP-000099-CTR-000190,SRG-APP-000100-CTR-000195,SRG-APP-000100-CTR-000200,SRG-APP-000109-CTR-000215,SRG-APP-000290-CTR-000670,SRG-APP-000357-CTR-000800 | The container platform must allocate audit record storage capacity in accordance with organization-defined audit record storage requirements. | Red Hat OpenShift Container Platform 4 must produce audit records containing information to establish the identity of any individual or process associated with the event. | In order to ensure applications have a sufficient storage capacity in which to write the audit logs, applications need to be able to allocate audit record storage capacity. The task of allocating audit record storage capacity is usually performed during initial installation of the application and is closely associated with the DBA and system administrator roles. The DBA or system administrator will usually coordinate the allocation of physical drive space with the application owner/installer and the application will prompt the installer to provide the capacity information, the physical location of the disk, or both. |
Without establishing what type of events occurred, the source of events, where events occurred, and the outcome of events, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Audit record content that may be necessary to satisfy this requirement includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. Enriched logging aids in making sense of who, what, and when events occur on a system. Without this, determining root cause of an event will be much more difficult. |
Applicable - Configurable | Review the container platform configuration to determine if audit record storage capacity is allocated in accordance with organization-defined audit record storage requirements. If audit record storage capacity is not allocated in accordance with organization-defined audit record storage requirements, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 audit system is configured to resolve audit information before writing to disk, with the following command: $ sudo grep log_format /etc/audit/auditd.conf log_format = ENRICHED If the "log_format" option is not "ENRICHED", or the line is commented out, this is a finding. |
Edit the /etc/audit/auditd.conf file and add or update the "log_format" option: log_format = ENRICHED The audit daemon must be restarted for changes to take effect. |
CAT II | ||||||
| 54 | CCI-000140 | SRG-OS-000047-GPOS-00023,SRG-APP-000098-CTR-000185,SRG-APP-000099-CTR-000190,SRG-APP-000100-CTR-000195,SRG-APP-000100-CTR-000200,SRG-APP-000109-CTR-000215,SRG-APP-000290-CTR-000670,SRG-APP-000357-CTR-000800 | The container platform must allocate audit record storage capacity in accordance with organization-defined audit record storage requirements. | In order to ensure applications have a sufficient storage capacity in which to write the audit logs, applications need to be able to allocate audit record storage capacity. The task of allocating audit record storage capacity is usually performed during initial installation of the application and is closely associated with the DBA and system administrator roles. The DBA or system administrator will usually coordinate the allocation of physical drive space with the application owner/installer and the application will prompt the installer to provide the capacity information, the physical location of the disk, or both. |
Applicable - Configurable | Review the container platform configuration to determine if audit record storage capacity is allocated in accordance with organization-defined audit record storage requirements. If audit record storage capacity is not allocated in accordance with organization-defined audit record storage requirements, this is a finding. |
CAT II | ||||||||||
| 55 | CCI-000140 | SRG-OS-000047-GPOS-00023,SRG-APP-000098-CTR-000185,SRG-APP-000099-CTR-000190,SRG-APP-000100-CTR-000195,SRG-APP-000100-CTR-000200,SRG-APP-000109-CTR-000215,SRG-APP-000290-CTR-000670,SRG-APP-000357-CTR-000800 | The container platform must allocate audit record storage capacity in accordance with organization-defined audit record storage requirements. | The Red Hat OpenShift Container Platform 4 audit system must take appropriate action when the audit files have reached maximum size. | In order to ensure applications have a sufficient storage capacity in which to write the audit logs, applications need to be able to allocate audit record storage capacity. The task of allocating audit record storage capacity is usually performed during initial installation of the application and is closely associated with the DBA and system administrator roles. The DBA or system administrator will usually coordinate the allocation of physical drive space with the application owner/installer and the application will prompt the installer to provide the capacity information, the physical location of the disk, or both. |
It is critical that when the operating system is at risk of failing to process audit logs as required, it takes action to mitigate the failure. Audit processing failures include: software/hardware errors; failures in the audit capturing mechanisms; and audit storage capacity being reached or exceeded. Responses to audit failure depend upon the nature of the failure mode. | Applicable - Configurable | Review the container platform configuration to determine if audit record storage capacity is allocated in accordance with organization-defined audit record storage requirements. If audit record storage capacity is not allocated in accordance with organization-defined audit record storage requirements, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 takes the appropriate action when the audit files have reached maximum size with the following command: $ sudo grep max_log_file_action /etc/audit/auditd.conf max_log_file_action = ROTATE If the value of the "max_log_file_action" option is not "ROTATE", "SINGLE", or the line is commented out, ask the system administrator to indicate how the system takes appropriate action when an audit storage volume is full. If there is no evidence of appropriate action, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to rotate the audit log when it reaches maximum size. Add or update the following line in "/etc/audit/auditd.conf" file: max_log_file_action = ROTATE |
CAT II | ||||||
| 56 | CCI-000044 | SRG-APP-000065-CTR-000115 | The container platform must enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period. | Red Hat OpenShift Container Platform 4 must enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period. | By limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced. Limits are imposed by locking the account. | Not Applicable | Review the container platform to determine if it is configured to enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period. If the container platform is not configured to enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period, this is a finding. |
CAT II | Not Applicable. Applicable to Identity Management Provider and not OCP. Only configurable check is to ensure OCP is configured for an IDP under SRG-APP-000023-CTR-000055. Verify with IdM service provider admins that the IdM meets the requirements. |
||||||||
| 57 | CCI-001685 | SRG-APP-000293-CTR-000685,SRG-APP-000292-CTR-000680,SRG-APP-000294-CTR-000690,SRG-APP-000319-CTR-000745,SRG-APP-000320-CTR-000750,SRG-APP-000028-CTR-000080,SRG-APP-000291-CTR-000675,SRG-APP-000509-CTR-001305 | The container platform must notify system administrators and ISSO for account disabling actions. | Red Hat OpenShift Container Platform 4 must generate audit rules to capture account creation, modification, disabling, removal and enabling actions. | When application accounts are disabled, user accessibility is affected. Accounts are utilized for identifying individual users or for identifying the application processes themselves. Sending notification of account disabling events to the system administrator and ISSO is one method for mitigating this risk. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes. To address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. |
Applicable - Configurable | Review the container platform configuration to determine if system administrators and ISSO are notified when accounts are disabled. If system administrators and ISSO are not notified, this is a finding. |
Verify the audit rules capture account creation, modification, disabling, removal and enabling actions by executing the following: for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'echo -n "$HOSTNAME "; grep -e user-modify -e group-modify -e audit_rules_usergroup_modification /etc/audit/rules.d/* /etc/audit/audit.rules' 2>/dev/null; done Confirm the following rules exist on each node: -w /etc/group -p wa -k audit_rules_usergroup_modification -w /etc/gshadow -p wa -k audit_rules_usergroup_modification -w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification -w /etc/passwd -p wa -k audit_rules_usergroup_modification -w /etc/shadow -p wa -k audit_rules_usergroup_modification If the above rules are not listed on each node, this is a finding. |
Apply the machine config using the following command: for mcpool in $(oc get mcp -oname | sed "s:.*/::" ); do echo "apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: name: 75-account-modifications-rules-$mcpool labels: machineconfiguration.openshift.io/role: $mcpool spec: config: ignition: version: 3.1.0 storage: files: - contents: source: data:,-w%20/etc/sudoers.d/%20-p%20wa%20-k%20actions%0A-w%20/etc/sudoers%20-p%20wa%20-k%20actions%0A mode: 0644 path: /etc/audit/rules.d/75-audit-sysadmin-actions.rules overwrite: true - contents: source: data:,-w%20/etc/group%20-p%20wa%20-k%20audit_rules_usergroup_modification%0A mode: 0644 path: /etc/audit/rules.d/30-etc_group_usergroup_modification.rules overwrite: true - contents: source: data:,-w%20/etc/gshadow%20-p%20wa%20-k%20audit_rules_usergroup_modification%0A mode: 0644 path: /etc/audit/rules.d/30-etc_gshadow_usergroup_modification.rules overwrite: true - contents: source: data:,-w%20/etc/security/opasswd%20-p%20wa%20-k%20audit_rules_usergroup_modification%0A mode: 0644 path: /etc/audit/rules.d/30-etc_security_opasswd_usergroup_modification.rules overwrite: true - contents: source: data:,-w%20/etc/passwd%20-p%20wa%20-k%20audit_rules_usergroup_modification%0A mode: 0644 path: /etc/audit/rules.d/30-etc_passwd_usergroup_modification.rules overwrite: true - contents: source: data:,-w%20/etc/shadow%20-p%20wa%20-k%20audit_rules_usergroup_modification%0A mode: 0644 path: /etc/audit/rules.d/30-etc_shadow_usergroup_modification.rules overwrite: true " | oc apply -f - done |
CAT II | |||||||
| 58 | CCI-000162,CCI-000163,CCI-000164 | SRG-OS-000462-GPOS-00206,SRG-OS-000475-GPOS-00220,SRG-OS-000057-GPOS-00027,SRG-OS-000058-GPOS-00028,SRG-OS-000059-GPOS-00029,SRG-APP-000121-CTR-000255,SRG-APP-000495-CTR-001235 | The container platform must protect audit tools from unauthorized access. | Red Hat OpenShift Container Platform 4 audit system must protect logon UIDs from unauthorized change. | Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data. Applications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order to make access decisions regarding the access to audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators. |
If modification of login UIDs is not prevented, they can be changed by unprivileged users and make auditing complicated or impossible. | Applicable - Configurable | Review the container platform to validate container platform audit tools are protected from unauthorized access. If the audit tools are not protected from unauthorized access, this is a finding. |
Verify the audit system prevents unauthorized changes to logon UIDs with the following command: $ sudo grep -i immutable /etc/audit/audit.rules --loginuid-immutable If the "--loginuid-immutable" option is not returned in the "/etc/audit/audit.rules", or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 auditing to prevent modification of login UIDs once they are set by adding the following line to /etc/audit/rules.d/audit.rules: --loginuid-immutable The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 59 | CCI-001493 | SRG-APP-000121-CTR-000255 | CCE-90648-7 | The container platform must protect audit tools from unauthorized access. | Red Hat OpenShift Container Platform 4 must protect audit tools from unauthorized access. | Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data. Applications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order to make access decisions regarding the access to audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators. |
Applicable - Configurable | Review the container platform to validate container platform audit tools are protected from unauthorized access. If the audit tools are not protected from unauthorized access, this is a finding. |
Perform a check to list the users and groups who have permission to view the cluster logging configuration by running the following two commands. > oc policy who-can view ClusterLogging -n openshift-logging > oc policy who-can view ClusterLoggingForwarder -n openshift-logging Review the list of users and groups who have view access to the cluster logging resources. If any user or group listed should not have access to view the cluster logging resources, this is a finding. |
Remove view permissions from any unauthorized user or group by performing one or more of the following commands: * Remove role from user > oc adm policy remove-role-from-user ROLE USER -n openshift-logging * Remove role from group > oc adm policy remove-role-from-group ROLE GROUP -n openshift-logging * Remove cluster role from user > oc adm policy remove-cluster-role-from-user CLUSTER_ROLE USER -n openshift-logging * Remove cluster role from group > oc adm policy remove-cluster-role-from-group CLUSTER_ROLE GROUP -n openshift-logging Where ROLE/CLUSTER_ROLE is the role granting user view permission to resources in openshift-logging namespace.} |
CAT II | ||||||
| 60 | CCI-000048 | SRG-APP-000068-CTR-000120 | CCE-84197-3 | The container platform must display the Standard Mandatory DoD Notice and Consent Banner before granting access to platform components. | Red Hat OpenShift Container Platform 4 must display the Standard Mandatory DoD Notice and Consent Banner before granting access to platform components. |
The container platform has countless components where different access levels are needed. To control access, the user must first log in to the component and then be presented with a DoD-approved use notification banner before granting access to the component. This guarantees privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. | Applicable - Configurable | Review the container platform configuration to determine if the Standard Mandatory DoD Notice and Consent Banner is configured to be displayed before granting access to platform components. Log in to the container platform components and verify that the Standard Mandatory DoD Notice and Consent Banner is being displayed before granting access. If the Standard Mandatory DoD Notice and Consent Banner is not configured or is not displayed before granting access to container platform components, this is a finding. |
Check whether a classification banner was configured by creating a Console Notification CRD on OpenShift > oc get consolenotification classification-banner -o=jsonpath='{.spec.text}' If the above does not return classification text to be displayed in the console, this is a finding. |
The following steps may be used to create a console classification banner. Replace the text in the example below with an appropriate text. cat << EOF | oc apply -f - apiVersion: console.openshift.io/v1 kind: ConsoleNotification metadata: name: classification-banner spec: text: Unclassified ##Classification Level location: BannerTopBottom ##Other options are BannerBottom, BannerTopBottom color: '#FFFFFF' ##Hexcode for white text color backgroundColor: '#008000' ##Hexcode for banner background color EOF |
CAT III | ||||||
| 61 | CCI-000048 | SRG-APP-000068-CTR-000120 | CCE-84198-1 | The container platform must display the Standard Mandatory DoD Notice and Consent Banner before granting access to platform components. | Red Hat OpenShift Container Platform 4 must display the Standard Mandatory DoD Notice and Consent Banner before granting access to platform components. |
The container platform has countless components where different access levels are needed. To control access, the user must first log in to the component and then be presented with a DoD-approved use notification banner before granting access to the component. This guarantees privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. | Applicable - Configurable | Review the container platform configuration to determine if the Standard Mandatory DoD Notice and Consent Banner is configured to be displayed before granting access to platform components. Log in to the container platform components and verify that the Standard Mandatory DoD Notice and Consent Banner is being displayed before granting access. If the Standard Mandatory DoD Notice and Consent Banner is not configured or is not displayed before granting access to container platform components, this is a finding. |
From a web browser, go to the Openshift web console to login (logout if already logged in). Verify that the DOD notice and consent banner is displayed before proceeding to the login page. If the DOD notice and consent banner is not displayed, this is a finding. |
The following steps may be used to provide a custom login page that will display the DOD notice and consent banner. This will replace OpenShift's default login page. Please note that depending on the number and type of identity providers configured, it is possible that these pages will not be used. If that is the case, then it is the responsibility of the identity provider being used to display the DOD notice and consent banner. 1. Create a login page template > oc adm create-login-template > login.html 2. Edit the template to add the DOD notice and consent banner by adding the following lines at the end of the html body. In addition, any look and feel customizations should also be applied to the pages. window.onload = function(){ alert("You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."); } 3. Add custom login pages to OpenShift > oc create secret generic login-template --from-file=login.html -n openshift-config > oc patch oauths cluster --type='merge' -p '{"spec":{"templates":{"login":{"name":"login-template"}}}}' |
CAT III | ||||||
| 62 | CCI-000048 | SRG-APP-000068-CTR-000120 | CCE-90666-9 | The container platform must display the Standard Mandatory DoD Notice and Consent Banner before granting access to platform components. | Red Hat OpenShift Container Platform 4 must display the Standard Mandatory DoD Notice and Consent Banner before granting access to platform components. |
The container platform has countless components where different access levels are needed. To control access, the user must first log in to the component and then be presented with a DoD-approved use notification banner before granting access to the component. This guarantees privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. | Applicable - Configurable | Review the container platform configuration to determine if the Standard Mandatory DoD Notice and Consent Banner is configured to be displayed before granting access to platform components. Log in to the container platform components and verify that the Standard Mandatory DoD Notice and Consent Banner is being displayed before granting access. If the Standard Mandatory DoD Notice and Consent Banner is not configured or is not displayed before granting access to container platform components, this is a finding. |
From a web browser, go to the Openshift web console to login (logout if already logged in). Verify that the DOD notice and consent banner is displayed before proceeding to the login page. If the DOD notice and consent banner is not displayed, this is a finding. |
The following steps may be used to provide a custom provider selection page that will display the DOD notice and consent banner. This will replace OpenShift's default the login providers selection page. Please note that depending on the number and type of identity providers configured, it is possible that these pages will not be used. If that is the case, then it is the responsibility of the identity provider being used to display the DOD notice and consent banner. 1. Create a providers selection page template > oc adm create-provider-selection-template > providers.html 2. Edit the template to add the DOD notice and consent banner by adding the following lines at the end of the html body. In addition, any look and feel customizations should also be applied to the pages. window.onload = function(){ alert("You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."); } 3. Add custom providers selection to OpenShift > oc create secret generic providers-template --from-file=providers.html -n openshift-config > oc patch oauths cluster --type='merge' -p '{"spec":{"templates":{"providerSelection":{"name":"providers-template"}}}}' |
CAT III | ||||||
| 63 | CCI-000048 | SRG-APP-000068-CTR-000120 | CCE-84200-5 | The container platform must display the Standard Mandatory DoD Notice and Consent Banner before granting access to platform components. | Red Hat OpenShift Container Platform 4 must display the Standard Mandatory DoD Notice and Consent Banner before granting access to platform components. |
The container platform has countless components where different access levels are needed. To control access, the user must first log in to the component and then be presented with a DoD-approved use notification banner before granting access to the component. This guarantees privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. | Applicable - Configurable | Review the container platform configuration to determine if the Standard Mandatory DoD Notice and Consent Banner is configured to be displayed before granting access to platform components. Log in to the container platform components and verify that the Standard Mandatory DoD Notice and Consent Banner is being displayed before granting access. If the Standard Mandatory DoD Notice and Consent Banner is not configured or is not displayed before granting access to container platform components, this is a finding. |
Login to OpenShift using the oc cli tool > oc login -u enter password when prompted If the DoD Notice and Consent Banner is not displayed, this is a finding. Or Verify that motd config map exists and contains the DoD Notice and Consent Banner > oc describe configmap/motd -n openshift If the configmap does not exist, or it does not contain the DoD Notice and Consent Banner text in the message data attribute, this is a finding. |
The following command will create a configmap that displays the DOD notice and consent banner when logging in using the OpenShift CLI tool (oc) > echo 'apiVersion: v1 kind: ConfigMap metadata: name: motd namespace: openshift data: message: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."' | oc apply -f - |
CAT III | ||||||
| 64 | CCI-000068 | SRG-APP-000014-CTR-000035 | CCE-86123-7 | The container platform must use TLS 1.2 or greater for secure container image transport from trusted sources. | Red Hat OpenShift Container Platform 4 must use TLS 1.2 or greater for secure container image transport from trusted sources. |
The authenticity and integrity of the container image during the container image lifecycle is part of the overall security posture of the container platform. This begins with the container image creation and pull of a base image from a trusted source for child container image creation and the instantiation of the new image into a running service. If an insecure protocol is used during transmission of container images at any step of the lifecycle, a bad actor may inject nefarious code into the container image. The container image, when instantiated, then becomes a security risk to the container platform, the host server, and other containers within the container platform. To thwart the injection of code during transmission, a secure protocol (TLS 1.2 or newer) must be used. Further guidance on secure transport protocols can be found in NIST SP 800-52. | The authenticity and integrity of the container image during the container image lifecycle is part of the overall security posture of the container platform. This begins with the container image creation and pull of a base image from a trusted source for child container image creation and the instantiation of the new image into a running service. If an insecure protocol is used during transmission of container images at any step of the lifecycle, a bad actor may inject nefarious code into the container image. The container image, when instantiated, then becomes a security risk to the container platform, the host server, and other containers within the container platform. To thwart the injection of code during transmission, a secure protocol (TLS 1.2 or newer) must be used. Further guidance on secure transport protocols can be found in NIST SP 800-52. |
Applicable - Configurable | Review the container platform configuration to verify that TLS 1.2 or greater is being used for secure container image transport from trusted sources. If TLS 1.2 or greater is not being used for secure container image transport, this is a finding. |
Verify that no insecure registries are configured: $ oc get image.config.openshift.io/cluster -ojsonpath='{.spec.registrySources}' If the results contain any "insecureRegistries", this is a finding |
Remove any insecureRegistries configured using the following command: $ oc patch image.config.openshift.io cluster --type=json -p "[{'op': 'remove', 'path': '/spec/registrySources/insecureRegistries'}]" or by editing the whole registry configuration: $ oc edit image.config.openshift.io/cluster |
CAT II | |||||
| 65 | CCI-000068 | SRG-APP-000014-CTR-000035 | CCE-86235-9 | The container platform must use TLS 1.2 or greater for secure container image transport from trusted sources. | Red Hat OpenShift Container Platform 4 must use TLS 1.2 or greater for secure container image transport from trusted sources. |
The authenticity and integrity of the container image during the container image lifecycle is part of the overall security posture of the container platform. This begins with the container image creation and pull of a base image from a trusted source for child container image creation and the instantiation of the new image into a running service. If an insecure protocol is used during transmission of container images at any step of the lifecycle, a bad actor may inject nefarious code into the container image. The container image, when instantiated, then becomes a security risk to the container platform, the host server, and other containers within the container platform. To thwart the injection of code during transmission, a secure protocol (TLS 1.2 or newer) must be used. Further guidance on secure transport protocols can be found in NIST SP 800-52. | The authenticity and integrity of the container image during the container image lifecycle is part of the overall security posture of the container platform. This begins with the container image creation and pull of a base image from a trusted source for child container image creation and the instantiation of the new image into a running service. If an insecure protocol is used during transmission of container images at any step of the lifecycle, a bad actor may inject nefarious code into the container image. The container image, when instantiated, then becomes a security risk to the container platform, the host server, and other containers within the container platform. To thwart the injection of code during transmission, a secure protocol (TLS 1.2 or newer) must be used. Further guidance on secure transport protocols can be found in NIST SP 800-52. |
Applicable - Configurable | Review the container platform configuration to verify that TLS 1.2 or greater is being used for secure container image transport from trusted sources. If TLS 1.2 or greater is not being used for secure container image transport, this is a finding. |
Verify that no insecure registries are configured: $ oc get image.config.openshift.io/cluster -o json | jq '.spec | (.allowedRegistriesForImport[])? | select(.insecure==true)' If the command produces any output, this is a finding. |
Remove any insecureRegistries configured using the following command by editing the registry configuration: $ oc edit image.config.openshift.io/cluster |
CAT II | |||||
| 66 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-OS-000064-GPOS-00033,SRG-OS-000466-GPOS-00210,SRG-OS-000458-GPOS-00203,SRG-APP-000091-CTR-000160,SRG-APP-000492-CTR-001220,SRG-APP-000493-CTR-001225,SRG-APP-000494-CTR-001230,SRG-APP-000500-CTR-001260,SRG-APP-000507-CTR-001295,SRG-APP-000495-CTR-001235,SRG-APP-000499-CTR-001255 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must audit all uses of the chmod, fchmod, and fchmodat syscalls. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "chmod", "fchmod", and "fchmodat" syscalls with the following command: $ sudo auditctl -l | grep chmod -a always,exit -F arch=b32 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=unset -k perm_mod If both the "b32" and "b64" audit rules are not defined for the "chmod", "fchmod", and "fchmodat" syscalls, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "chmod", "fchmod", and "fchmodat" syscalls. Add or update the following rules in "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 67 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-OS-000064-GPOS-00033,SRG-OS-000466-GPOS-00210,SRG-OS-000458-GPOS-00203,SRG-OS-000474-GPOS-00219,SRG-APP-000091-CTR-000160,SRG-APP-000492-CTR-001220,SRG-APP-000493-CTR-001225,SRG-APP-000494-CTR-001230,SRG-APP-000500-CTR-001260,SRG-APP-000507-CTR-001295,SRG-APP-000495-CTR-001235,SRG-APP-000499-CTR-001255 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must audit all uses of the chown, fchown, fchownat, and lchown syscalls. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "chown", "fchown", "fchownat", and "lchown" syscalls with the following command: $ sudo auditctl -l | grep chown -a always,exit -F arch=b32 -S chown,fchown,fchownat,lchown -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S chown,fchown,fchownat,lchown -F auid>=1000 -F auid!=unset -k perm_mod If both the "b32" and "b64" audit rules are not defined for the "chown", "fchown", "fchownat", and "lchown" syscalls, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "chown", "fchown", "fchownat", and "lchown"" syscalls. Add or update the following rules in "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S chown,fchown,fchownat,lchown -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S chown,fchown,fchownat,lchown -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 68 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-OS-000064-GPOS-00033,SRG-OS-000466-GPOS-00210,SRG-OS-000458-GPOS-00203,SRG-APP-000091-CTR-000160,SRG-APP-000492-CTR-001220,SRG-APP-000493-CTR-001225,SRG-APP-000494-CTR-001230,SRG-APP-000500-CTR-001260,SRG-APP-000507-CTR-001295,SRG-APP-000495-CTR-001235,SRG-APP-000499-CTR-001255 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Successful/unsuccessful uses of the fchmod system call in Red Hat OpenShift Container Platform 4 must generate an audit record. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
To determine if the system is configured to audit calls to the fchmod system call, run the following command: $ sudo grep "fchmod" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. If no line is returned, then this is a finding. |
Configure the audit system to generate an audit event for any successful/unsuccessful use of the "fchmod" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=unset -k perm_mod It's allowed to group this system call within the same line as "chmod", "fchmod" and "fchmodat". The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 69 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-OS-000064-GPOS-00033,SRG-OS-000466-GPOS-00210,SRG-OS-000458-GPOS-00203,SRG-APP-000091-CTR-000160,SRG-APP-000492-CTR-001220,SRG-APP-000493-CTR-001225,SRG-APP-000494-CTR-001230,SRG-APP-000500-CTR-001260,SRG-APP-000507-CTR-001295,SRG-APP-000495-CTR-001235,SRG-APP-000499-CTR-001255 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Successful/unsuccessful uses of the fchmodat system call in Red Hat OpenShift Container Platform 4 must generate an audit record. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
To determine if the system is configured to audit calls to the fchmodat system call, run the following command: $ sudo grep "fchmodat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. If no line is returned, then this is a finding. |
Configure the audit system to generate an audit event for any successful/unsuccessful use of the "fchmodat" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=unset -k perm_mod It's allowed to group this system call within the same line as "chmod", "fchmod" and "fchmodat". The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 70 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-OS-000064-GPOS-00033,SRG-OS-000466-GPOS-00210,SRG-OS-000458-GPOS-00203,SRG-OS-000474-GPOS-00219,SRG-APP-000091-CTR-000160,SRG-APP-000492-CTR-001220,SRG-APP-000493-CTR-001225,SRG-APP-000494-CTR-001230,SRG-APP-000500-CTR-001260,SRG-APP-000507-CTR-001295,SRG-APP-000495-CTR-001235,SRG-APP-000499-CTR-001255 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Successful/unsuccessful uses of the fchown system call in Red Hat OpenShift Container Platform 4 must generate an audit record. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
To determine if the system is configured to audit calls to the fchown system call, run the following command: $ sudo grep "fchown" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. If no line is returned, then this is a finding. |
Configure the audit system to generate an audit event for any successful/unsuccessful use of the "fchown" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -k perm_mod It's allowed to group this system call within the same line as "chown", "fchown", "fchownat" and "lchown". The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 71 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-OS-000064-GPOS-00033,SRG-OS-000466-GPOS-00210,SRG-OS-000458-GPOS-00203,SRG-OS-000474-GPOS-00219,SRG-APP-000091-CTR-000160,SRG-APP-000492-CTR-001220,SRG-APP-000493-CTR-001225,SRG-APP-000494-CTR-001230,SRG-APP-000500-CTR-001260,SRG-APP-000507-CTR-001295,SRG-APP-000495-CTR-001235,SRG-APP-000499-CTR-001255 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Successful/unsuccessful uses of the fchownat system call in Red Hat OpenShift Container Platform 4 must generate an audit record. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
To determine if the system is configured to audit calls to the fchownat system call, run the following command: $ sudo grep "fchownat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. If no line is returned, then this is a finding. |
Configure the audit system to generate an audit event for any successful/unsuccessful use of the "fchownat" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -k perm_mod It's allowed to group this system call within the same line as "chown", "fchown", "fchownat" and "lchown". The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 72 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000458-GPOS-00203,SRG-OS-000462-GPOS-00206,SRG-OS-000463-GPOS-00207,SRG-OS-000471-GPOS-00215,SRG-OS-000474-GPOS-00219,SRG-OS-000466-GPOS-00210,SRG-OS-000468-GPOS-00212,SRG-OS-000064-GPOS-00033,SRG-APP-000091-CTR-000160,SRG-APP-000492-CTR-001220,SRG-APP-000493-CTR-001225,SRG-APP-000494-CTR-001230,SRG-APP-000500-CTR-001260,SRG-APP-000507-CTR-001295,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 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must audit all uses of the setxattr, fsetxattr, lsetxattr, removexattr, fremovexattr, and lremovexattr system calls. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "setxattr", "fsetxattr", "lsetxattr", "removexattr", "fremovexattr", and "lremovexattr" system calls with the following command: $ sudo auditctl -l | grep xattr -a always,exit -F arch=b32 -S setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr,lremovexattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr,lremovexattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b32 -S setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr,lremovexattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr,lremovexattr -F auid=0 -k perm_mod If both the "b32" and "b64" audit rules are not defined for the "chmod", "fchmod", and "fchmodat" syscalls "setxattr", "fsetxattr", "lsetxattr", "removexattr", "fremovexattr", and "lremovexattr" ssytem calls, or any of the lines returned are commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to audit the execution of the "setxattr", "fsetxattr", "lsetxattr", "removexattr", "fremovexattr", and "lremovexattr" system calls by adding or updating the following lines to "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr,lremovexattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr,lremovexattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b32 -S setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr,lremovexattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr,lremovexattr -F auid=0 -k perm_mod The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 73 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000458-GPOS-00203,SRG-OS-000462-GPOS-00206,SRG-OS-000463-GPOS-00207,SRG-OS-000466-GPOS-00210,SRG-OS-000468-GPOS-00212,SRG-OS-000471-GPOS-00215,SRG-OS-000474-GPOS-00219,SRG-OS-000064-GPOS-00033,SRG-APP-000091-CTR-000160,SRG-APP-000492-CTR-001220,SRG-APP-000493-CTR-001225,SRG-APP-000494-CTR-001230,SRG-APP-000500-CTR-001260,SRG-APP-000507-CTR-001295,SRG-APP-000495-CTR-001235,SRG-APP-000496-CTR-001240,SRG-APP-000497-CTR-001245,SRG-APP-000498-CTR-001250,SRG-APP-000501-CTR-001265,SRG-APP-000502-CTR-001270 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Successful/unsuccessful uses of the fsetxattr system call in Red Hat OpenShift Container Platform 4 must generate an audit record. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
To determine if the system is configured to audit calls to the fsetxattr system call, run the following command: $ sudo grep "fsetxattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. If no line is returned, then this is a finding. |
Configure the audit system to generate an audit event for any successful/unsuccessful use of the "fsetxattr" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -k perm_mod It's allowed to group this system call within the same line as "fremovexattr", "lremovexattr", "removexattr", "fsetxattr", "lsetxattr" and "setxattr". The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 74 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-OS-000064-GPOS-00033,SRG-OS-000466-GPOS-00210,SRG-OS-000458-GPOS-00203,SRG-OS-000474-GPOS-00219,SRG-APP-000091-CTR-000160,SRG-APP-000492-CTR-001220,SRG-APP-000493-CTR-001225,SRG-APP-000494-CTR-001230,SRG-APP-000500-CTR-001260,SRG-APP-000507-CTR-001295,SRG-APP-000495-CTR-001235,SRG-APP-000499-CTR-001255 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Successful/unsuccessful uses of the lchown system call in Red Hat OpenShift Container Platform 4 must generate an audit record. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
To determine if the system is configured to audit calls to the lchown system call, run the following command: $ sudo grep "lchown" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. If no line is returned, then this is a finding. |
Configure the audit system to generate an audit event for any successful/unsuccessful use of the "lchown" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -k perm_mod It's allowed to group this system call within the same line as "chown", "fchown", "fchownat" and "lchown". The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 75 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000458-GPOS-00203,SRG-OS-000462-GPOS-00206,SRG-OS-000463-GPOS-00207,SRG-OS-000468-GPOS-00212,SRG-OS-000471-GPOS-00215,SRG-OS-000474-GPOS-00219,SRG-OS-000466-GPOS-00210,SRG-OS-000064-GPOS-00033,SRG-APP-000091-CTR-000160,SRG-APP-000492-CTR-001220,SRG-APP-000493-CTR-001225,SRG-APP-000494-CTR-001230,SRG-APP-000500-CTR-001260,SRG-APP-000507-CTR-001295,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-000501-CTR-001265,SRG-APP-000502-CTR-001270 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Successful/unsuccessful uses of the lremovexattr system call in Red Hat OpenShift Container Platform 4 must generate an audit record. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
To determine if the system is configured to audit calls to the lremovexattr system call, run the following command: $ sudo grep "lremovexattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. If no line is returned, then this is a finding. |
Configure the audit system to generate an audit event for any successful/unsuccessful use of the "lremovexattr" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S lremovexattr -F auid>=1000 -F auid!=unset -k perm_mod It's allowed to group this system call within the same line as "fremovexattr", "lremovexattr", "removexattr", "fsetxattr", "lsetxattr" and "setxattr". The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 76 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000458-GPOS-00203,SRG-OS-000462-GPOS-00206,SRG-OS-000463-GPOS-00207,SRG-OS-000466-GPOS-00210,SRG-OS-000468-GPOS-00212,SRG-OS-000471-GPOS-00215,SRG-OS-000474-GPOS-00219,SRG-OS-000064-GPOS-00033,SRG-APP-000091-CTR-000160,SRG-APP-000492-CTR-001220,SRG-APP-000493-CTR-001225,SRG-APP-000494-CTR-001230,SRG-APP-000500-CTR-001260,SRG-APP-000507-CTR-001295,SRG-APP-000495-CTR-001235,SRG-APP-000496-CTR-001240,SRG-APP-000497-CTR-001245,SRG-APP-000498-CTR-001250,SRG-APP-000501-CTR-001265,SRG-APP-000502-CTR-001270 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Successful/unsuccessful uses of the lsetxattr system call in Red Hat OpenShift Container Platform 4 must generate an audit record. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
To determine if the system is configured to audit calls to the lsetxattr system call, run the following command: $ sudo grep "lsetxattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. If no line is returned, then this is a finding. |
Configure the audit system to generate an audit event for any successful/unsuccessful use of the "lsetxattr" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -k perm_mod It's allowed to group this system call within the same line as "fremovexattr", "lremovexattr", "removexattr", "fsetxattr", "lsetxattr" and "setxattr". The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 77 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000458-GPOS-00203,SRG-OS-000462-GPOS-00206,SRG-OS-000463-GPOS-00207,SRG-OS-000468-GPOS-00212,SRG-OS-000471-GPOS-00215,SRG-OS-000474-GPOS-00219,SRG-OS-000466-GPOS-00210,SRG-OS-000064-GPOS-00033,SRG-APP-000091-CTR-000160,SRG-APP-000492-CTR-001220,SRG-APP-000493-CTR-001225,SRG-APP-000494-CTR-001230,SRG-APP-000500-CTR-001260,SRG-APP-000507-CTR-001295,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-000501-CTR-001265,SRG-APP-000502-CTR-001270 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Successful/unsuccessful uses of the removexattr system call in Red Hat OpenShift Container Platform 4 must generate an audit record. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
To determine if the system is configured to audit calls to the removexattr system call, run the following command: $ sudo grep "removexattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. If no line is returned, then this is a finding. |
Configure the audit system to generate an audit event for any successful/unsuccessful use of the "removexattr" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S removexattr -F auid>=1000 -F auid!=unset -k perm_mod It's allowed to group this system call within the same line as "fremovexattr", "lremovexattr", "removexattr", "fsetxattr", "lsetxattr" and "setxattr". The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 78 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000466-GPOS-00210,SRG-OS-000471-GPOS-00215,SRG-OS-000064-GPOS-00033,SRG-OS-000458-GPOS-00203,SRG-APP-000091-CTR-000160,SRG-APP-000492-CTR-001220,SRG-APP-000493-CTR-001225,SRG-APP-000494-CTR-001230,SRG-APP-000500-CTR-001260,SRG-APP-000507-CTR-001295,SRG-APP-000495-CTR-001235 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Successful/unsuccessful uses of the setxattr system call in Red Hat OpenShift Container Platform 4 must generate an audit record. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
To determine if the system is configured to audit calls to the setxattr system call, run the following command: $ sudo grep "setxattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. If no line is returned, then this is a finding. |
Configure the audit system to generate an audit event for any successful/unsuccessful use of the "setxattr" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=unset -k perm_mod It's allowed to group this system call within the same line as "fremovexattr", "lremovexattr", "removexattr", "fsetxattr", "lsetxattr" and "setxattr". The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 79 | CCI-000172,CCI-000130,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-APP-000495-CTR-001235 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Successful/unsuccessful uses of the umount system call in Red Hat OpenShift Container Platform 4 must generate an audit record. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. | Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 generates an audit record for all uses of the "umount" and system call with the following command: $ sudo grep "umount" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line like the following: -a always,exit -F arch=b32 -S umount -F auid>=1000 -F auid!=unset -k privileged-umount If the command does not return a line, or the line is commented out, this is a finding. |
Configure the audit system to generate an audit event for any successful/unsuccessful use of the "umount" system call by adding or updating the following rules in "/etc/audit/audit.rules" and adding the following rules to "/etc/audit/rules.d/perm_mod.rules" or updating the existing rules in files in the "/etc/audit/rules.d/" directory: -a always,exit -F arch=b32 -S umount -F auid>=1000 -F auid!=unset -k privileged-umount The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 80 | CCI-000172,CCI-000130,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-APP-000495-CTR-001235 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Successful/unsuccessful uses of the umount2 system call in Red Hat OpenShift Container Platform 4 must generate an audit record. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. | Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
To determine if the system is configured to audit calls to the umount2 system call, run the following command: $ sudo grep "umount2" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. If no line is returned, this is a finding. |
Configure the audit system to generate an audit event for any successful/unsuccessful use of the "umount2" system call by adding or updating the following rules in "/etc/audit/audit.rules" and adding the following rules to "/etc/audit/rules.d/perm_mod.rules" or updating the existing rules in files in the "/etc/audit/rules.d/" directory: -a always,exit -F arch=b32 -S umount2 -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S umount2 -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 81 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-OS-000466-GPOS-00210,SRG-APP-000495-CTR-001235,SRG-APP-000499-CTR-001255 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must audit all uses of the chacl command. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "chacl" command with the following command: $ sudo auditctl -l | grep chacl -a always,exit -F path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=unset -k perm_mod If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "chacl" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 82 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-APP-000495-CTR-001235 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must audit all uses of the setfacl command. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "setfacl" command with the following command: $ sudo auditctl -l | grep setfacl -a always,exit -F path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=unset -k perm_mod If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "setfacl" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 83 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000468-GPOS-00212,SRG-OS-000471-GPOS-00215,SRG-OS-000463-GPOS-00207,SRG-OS-000465-GPOS-00209,SRG-APP-000495-CTR-001235,SRG-APP-000496-CTR-001240,SRG-APP-000497-CTR-001245,SRG-APP-000498-CTR-001250,SRG-APP-000501-CTR-001265,SRG-APP-000502-CTR-001270 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must audit all uses of the chcon command. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "chcon" command with the following command: $ sudo auditctl -l | grep chcon -a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=unset -k perm_mod If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "chcon" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 84 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-OS-000463-GPOS-00207,SRG-OS-000465-GPOS-00209,SRG-APP-000495-CTR-001235,SRG-APP-000496-CTR-001240,SRG-APP-000497-CTR-001245,SRG-APP-000498-CTR-001250 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must audit all uses of the semanage command. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "semanage" command with the following command: $ sudo auditctl -l | grep semanage -a always,exit -F path=/usr/sbin/semanage -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix-update If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "semanage" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/sbin/semanage -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix-update The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 85 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-OS-000463-GPOS-00207,SRG-OS-000465-GPOS-00209,SRG-APP-000495-CTR-001235,SRG-APP-000496-CTR-001240,SRG-APP-000497-CTR-001245,SRG-APP-000498-CTR-001250 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must audit all uses of the setfiles command. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "setfiles" command with the following command: $ sudo auditctl -l | grep setfiles -a always,exit -F path=/usr/sbin/setfiles -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix-update If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "setfiles" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/sbin/setfiles -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix-update The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 86 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-OS-000463-GPOS-00207,SRG-OS-000465-GPOS-00209,SRG-APP-000495-CTR-001235,SRG-APP-000496-CTR-001240,SRG-APP-000497-CTR-001245,SRG-APP-000498-CTR-001250 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must audit all uses of the setsebool command. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "setsebool" command with the following command: $ sudo auditctl -l | grep setsebool -a always,exit -F path=/usr/sbin/setsebool -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate an audit event for any successful/unsuccessful use of the "setsebool " command by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/sbin/setsebool -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 87 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-OS-000466-GPOS-00210,SRG-OS-000467-GPOS-00211,SRG-OS-000468-GPOS-00212,SRG-APP-000495-CTR-001235,SRG-APP-000499-CTR-001255,SRG-APP-000501-CTR-001265,SRG-APP-000502-CTR-001270 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must audit all uses of the rename,unlink,rmdir,renameat, and unlinkat system calls. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit successful/unsuccessful attempts to use the "rename", "unlink", "rmdir", "renameat", and "unlinkat" system calls with the following command: $ sudo auditctl -l | grep 'rename\|unlink\|rmdir' -a always,exit -F arch=b32 -S rename,unlink,rmdir,renameat,unlinkat -F auid>=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S rename,unlink,rmdir,renameat,unlinkat -F auid>=1000 -F auid!=unset -k delete If the command does not return an audit rule for "rename", "unlink", "rmdir", "renameat", and "unlinkat" or any of the lines returned are commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate an audit event for any successful/unsuccessful use of the "rename", "unlink", "rmdir", "renameat", and "unlinkat" system calls by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S rename,unlink,rmdir,renameat,unlinkat -F auid>=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S rename,unlink,rmdir,renameat,unlinkat -F auid>=1000 -F auid!=unset -k delete The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 88 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-OS-000466-GPOS-00210,SRG-OS-000467-GPOS-00211,SRG-OS-000468-GPOS-00212,SRG-APP-000495-CTR-001235,SRG-APP-000499-CTR-001255,SRG-APP-000501-CTR-001265,SRG-APP-000502-CTR-001270 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Successful/unsuccessful uses of the renameat system call in Red Hat OpenShift Container Platform 4 must generate an audit record. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Auditing file deletions will create an audit trail for files that are removed from the system. The audit trail could aid in system troubleshooting, as well as, detecting malicious processes that attempt to delete log files to conceal their presence. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
To determine if the system is configured to audit calls to the renameat system call, run the following command: $ sudo grep "renameat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. If no line is returned, then this is a finding. |
Configure the audit system to generate an audit event for any successful/unsuccessful use of the "renameat" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S renameat -F auid>=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S renameat -F auid>=1000 -F auid!=unset -k delete It's allowed to group this system call within the same line as "rename", "unlink", "rmdir", "renameat", and "unlinkat". The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 89 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-OS-000466-GPOS-00210,SRG-OS-000467-GPOS-00211,SRG-OS-000468-GPOS-00212,SRG-APP-000495-CTR-001235,SRG-APP-000499-CTR-001255,SRG-APP-000501-CTR-001265,SRG-APP-000502-CTR-001270 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Successful/unsuccessful uses of the rmdir system call in Red Hat OpenShift Container Platform 4 must generate an audit record. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Auditing file deletions will create an audit trail for files that are removed from the system. The audit trail could aid in system troubleshooting, as well as, detecting malicious processes that attempt to delete log files to conceal their presence. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
To determine if the system is configured to audit calls to the rmdir system call, run the following command: $ sudo grep "rmdir" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. If no line is returned, then this is a finding. |
Configure the audit system to generate an audit event for any successful/unsuccessful use of the "rmdir" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S rmdir -F auid>=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S rmdir -F auid>=1000 -F auid!=unset -k delete It's allowed to group this system call within the same line as "rename", "unlink", "rmdir", "renameat", and "unlinkat". The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 90 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-OS-000466-GPOS-00210,SRG-OS-000467-GPOS-00211,SRG-OS-000468-GPOS-00212,SRG-APP-000495-CTR-001235,SRG-APP-000499-CTR-001255,SRG-APP-000501-CTR-001265,SRG-APP-000502-CTR-001270 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Successful/unsuccessful uses of the unlink system call in Red Hat OpenShift Container Platform 4 must generate an audit record. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Auditing file deletions will create an audit trail for files that are removed from the system. The audit trail could aid in system troubleshooting, as well as, detecting malicious processes that attempt to delete log files to conceal their presence. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
To determine if the system is configured to audit calls to the unlink system call, run the following command: $ sudo grep "unlink" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. If no line is returned, then this is a finding. |
Configure the audit system to generate an audit event for any successful/unsuccessful use of the "unlink" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S unlink -F auid>=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S unlink -F auid>=1000 -F auid!=unset -k delete It's allowed to group this system call within the same line as "rename", "unlink", "rmdir", "renameat", and "unlinkat". The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 91 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-OS-000466-GPOS-00210,SRG-OS-000467-GPOS-00211,SRG-OS-000468-GPOS-00212,SRG-APP-000495-CTR-001235,SRG-APP-000499-CTR-001255,SRG-APP-000501-CTR-001265,SRG-APP-000502-CTR-001270 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Successful/unsuccessful uses of the unlinkat system call in Red Hat OpenShift Container Platform 4 must generate an audit record. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Auditing file deletions will create an audit trail for files that are removed from the system. The audit trail could aid in system troubleshooting, as well as, detecting malicious processes that attempt to delete log files to conceal their presence. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
To determine if the system is configured to audit calls to the unlinkat system call, run the following command: $ sudo grep "unlinkat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. If no line is returned, then this is a finding. |
Configure the audit system to generate an audit event for any successful/unsuccessful use of the "unlinkat" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S unlinkat -F auid>=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S unlinkat -F auid>=1000 -F auid!=unset -k delete It's allowed to group this system call within the same line as "rename", "unlink", "rmdir", "renameat", and "unlinkat". The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 92 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-OS-000064-GPOS-00033,SRG-OS-000458-GPOS-00203,SRG-OS-000461-GPOS-00205,SRG-APP-000495-CTR-001235 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must audit all uses of the truncate, ftruncate, creat, open, openat, and open_by_handle_at system calls. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit successful/unsuccessful attempts to use the "truncate", "ftruncate", "creat", "open", "openat", and "open_by_handle_at" system calls with the following command: $ sudo auditctl -l | grep'open\|truncate\|creat' -a always,exit -F arch=b32 -S truncate,ftruncate,creat,open,openat,open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S truncate,ftruncate,creat,open,openat,open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S truncate,ftruncate,creat,open,openat,open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S truncate,ftruncate,creat,open,openat,open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access If the output does not produce rules containing "-F exit=-EPERM", this is a finding. If the output does not produce rules containing "-F exit=-EACCES", this is a finding. If the command does not return an audit rule for "truncate", "ftruncate", "creat", "open", "openat", and "open_by_handle_at" or any of the lines returned are commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate an audit event for any successful/unsuccessful use of the "truncate", "ftruncate", "creat", "open", "openat", and "open_by_handle_at" system calls by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S truncate,ftruncate,creat,open,openat,open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S truncate,ftruncate,creat,open,openat,open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S truncate,ftruncate,creat,open,openat,open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S truncate,ftruncate,creat,open,openat,open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 93 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-OS-000064-GPOS-00033,SRG-OS-000458-GPOS-00203,SRG-OS-000461-GPOS-00205,SRG-APP-000495-CTR-001235 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Successful/unsuccessful uses of the ftruncate system call in Red Hat OpenShift Container Platform 4 must generate an audit record. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
To determine if the system is configured to audit calls to the ftruncate system call, run the following command: $ sudo grep "ftruncate" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. If no line is returned, then this is a finding. |
Configure the audit system to generate an audit event for any successful/unsuccessful use of the "ftruncate" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access It's allowed to group this system call within the same line as "creat", "ftruncate", "truncate", "open", "openat" and "open_by_handle_at". The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 94 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-OS-000064-GPOS-00033,SRG-OS-000458-GPOS-00203,SRG-OS-000461-GPOS-00205,SRG-APP-000495-CTR-001235 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Successful/unsuccessful uses of the open system call in Red Hat OpenShift Container Platform 4 must generate an audit record. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
To determine if the system is configured to audit calls to the open system call, run the following command: $ sudo grep "open" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. If no line is returned, then this is a finding. |
Configure the audit system to generate an audit event for any successful/unsuccessful use of the "open" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access It's allowed to group this system call within the same line as "creat", "ftruncate", "truncate", "open", "openat" and "open_by_handle_at". The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 95 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-OS-000064-GPOS-00033,SRG-OS-000458-GPOS-00203,SRG-OS-000461-GPOS-00205,SRG-APP-000495-CTR-001235 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Successful/unsuccessful uses of the open_by_handle_at system call in Red Hat OpenShift Container Platform 4 must generate an audit record. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
To determine if the system is configured to audit calls to the open_by_handle_at system call, run the following command: $ sudo grep "open_by_handle_at" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. If no line is returned, then this is a finding. |
Configure the audit system to generate an audit event for any successful/unsuccessful use of the "open_by_handle_at" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access It's allowed to group this system call within the same line as "creat", "ftruncate", "truncate", "open", "openat" and "open_by_handle_at". The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 96 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-OS-000064-GPOS-00033,SRG-OS-000458-GPOS-00203,SRG-OS-000461-GPOS-00205,SRG-APP-000495-CTR-001235 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Successful/unsuccessful uses of the openat system call in Red Hat OpenShift Container Platform 4 must generate an audit record. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
To determine if the system is configured to audit calls to the openat system call, run the following command: $ sudo grep "openat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. If no line is returned, then this is a finding. |
Configure the audit system to generate an audit event for any successful/unsuccessful use of the "openat" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access It's allowed to group this system call within the same line as "creat", "ftruncate", "truncate", "open", "openat" and "open_by_handle_at". The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 97 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-OS-000064-GPOS-00033,SRG-OS-000458-GPOS-00203,SRG-OS-000461-GPOS-00205,SRG-APP-000495-CTR-001235 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Successful/unsuccessful uses of the truncate system call in Red Hat OpenShift Container Platform 4 must generate an audit record. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
To determine if the system is configured to audit calls to the truncate system call, run the following command: $ sudo grep "truncate" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. If no line is returned, then this is a finding. |
Configure the audit system to generate an audit event for any successful/unsuccessful use of the "truncate" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access It's allowed to group this system call within the same line as "creat", "ftruncate", "truncate", "open", "openat" and "open_by_handle_at". The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 98 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-OS-000471-GPOS-00216,SRG-OS-000477-GPOS-00222,SRG-APP-000495-CTR-001235,SRG-APP-000504-CTR-001280 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must audit all uses of the delete_module system call. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "delete_module" system call with the following command: $ sudo auditctl -l | grep delete_module -a always,exit -F arch=b32 -S delete_module -F auid>=1000 -F auid!=unset -k module_chng -a always,exit -F arch=b64 -S delete_module -F auid>=1000 -F auid!=unset -k module_chng If both the "b32" and "b64" audit rules are not defined for the "delete_module" system call, or any of the lines returned are commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate an audit event for any successful/unsuccessful use of the "delete_module" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S delete_module -F auid>=1000 -F auid!=unset -k module_chng -a always,exit -F arch=b64 -S delete_module -F auid>=1000 -F auid!=unset -k module_chng The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 99 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-OS-000471-GPOS-00216,SRG-OS-000477-GPOS-00222,SRG-APP-000495-CTR-001235,SRG-APP-000504-CTR-001280 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must audit all uses of the init_module and finit_module system calls. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "init_module" and "finit_module" syscalls with the following command: $ sudo auditctl -l | grep init_module -a always,exit -F arch=b32 -S init_module,finit_module -F auid>=1000 -F auid!=unset -k module_chng -a always,exit -F arch=b64 -S init_module,finit_module -F auid>=1000 -F auid!=unset -k module_chng If both the "b32" and "b64" audit rules are not defined for the "delete_module" syscall, or any of the lines returned are commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate an audit event for any successful/unsuccessful use of the "init_module" and "finit_module" system calls by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S init_module,finit_module -F auid>=1000 -F auid!=unset -k module_chng -a always,exit -F arch=b64 -S init_module,finit_module -F auid>=1000 -F auid!=unset -k module_chng The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 100 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-OS-000471-GPOS-00216,SRG-OS-000477-GPOS-00222,SRG-APP-000495-CTR-001235,SRG-APP-000504-CTR-001280 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 Must Provide Audit Record Generation Capability For Dod-Defined Auditable Events For All Operating System Components. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
The addition of kernel modules can be used to alter the behavior of the kernel and potentially introduce malicious code into kernel space. It is important to have an audit trail of modules that have been introduced into the kernel. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
To determine if the system is configured to audit calls to the init_module system call, run the following command: $ sudo grep "init_module" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. If no line is returned, then this is a finding. |
CAT II | |||||||
| 101 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-OS-000473-GPOS-00218,SRG-OS-000470-GPOS-00214,SRG-APP-000495-CTR-001235,SRG-APP-000503-CTR-001275,SRG-APP-000506-CTR-001290 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must generate audit records for all account creations, modifications, disabling, and termination events that affect /var/log/lastlog. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. | Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify Red Hat OpenShift Container Platform 4 generates audit records for all account creations, modifications, disabling, and termination events that affect "/var/log/lastlog" with the following command: $ sudo auditctl -l | grep /var/log/lastlog -w /var/log/lastlog -p wa -k logins If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records for all account creations, modifications, disabling, and termination events that affect "/var/log/lastlog". Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -w /var/log/lastlog -p wa -k logins The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 102 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-APP-000495-CTR-001235 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must audit all uses of the chsh command. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "chsh" command with the following command: $ sudo auditctl -l | grep chsh -a always,exit -F path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=unset -k priv_cmd If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "chsh" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=unset -k priv_cmd The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 103 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-APP-000495-CTR-001235 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must audit all uses of the crontab command. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "crontab" command with the following command: $ sudo auditctl -l | grep crontab -a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -k privileged-crontab If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "crontab" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -k privileged-crontab The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 104 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-OS-000471-GPOS-00216,SRG-OS-000477-GPOS-00222,SRG-APP-000495-CTR-001235,SRG-APP-000504-CTR-001280 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must audit all uses of the kmod command. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "kmod" command with the following command: $ sudo auditctl -l | grep kmod -a always,exit -F path=/usr/bin/kmod -F perm=x -F auid>=1000 -F auid!=unset -k modules If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "kmod" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/bin/kmod -F perm=x -F auid>=1000 -F auid!=unset -k modules The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 105 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-APP-000495-CTR-001235 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must audit all uses of the postdrop command. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped however, by combining system calls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "postdrop" command with the following command: $ sudo auditctl -l | grep postdrop -a always,exit -F path=/usr/sbin/postdrop -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix-update If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "postdrop" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/sbin/postdrop -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix-update The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 106 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-APP-000495-CTR-001235 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must audit all uses of the postqueue command. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Without generating audit record specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "postqueue" command with the following command: $ sudo auditctl -l | grep postqueue -a always,exit -F path=/usr/sbin/postqueue -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix-update If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "postqueue" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/sbin/postqueue -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix-update The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 107 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-APP-000495-CTR-001235 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must audit all uses of the ssh-agent command. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Without generating audit record specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "ssh-agent" command with the following command: $ sudo auditctl -l | grep ssh-agent -a always,exit -F path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=unset -k privileged-ssh If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "ssh-agent" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=unset -k privileged-ssh The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 108 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-APP-000495-CTR-001235,SRG-OS-000755-GPOS-00220 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must audit all uses of the sudoedit command. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Without generating audit record specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "sudoedit" command with the following command: $ sudo auditctl -l | grep /usr/bin/sudoedit -a always,exit -F path=/usr/bin/sudoedit -F perm=x -F auid>=1000 -F auid!=unset -k priv_cmd If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "sudoedit" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/bin/sudoedit -F perm=x -F auid>=1000 -F auid!=unset -k priv_cmd The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 109 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000064-GPOS-00033,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-APP-000495-CTR-001235 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must audit all uses of the unix_update command. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Without generating audit record specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "unix_update" command with the following command: $ sudo auditctl -l | grep unix_update -a always,exit -F path=/usr/sbin/unix_update -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix-update If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "unix_update" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/sbin/unix_update -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix-update The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 110 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-APP-000495-CTR-001235 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must audit all uses of the userhelper command. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Without generating audit record specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "userhelper" command with the following command: $ sudo auditctl -l | grep userhelper -a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix-update If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "userhelper" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix-update The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 111 | CCI-000172,CCI-000130,CCI-000135,CCI-000169,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-OS-000466-GPOS-00210,SRG-APP-000495-CTR-001235,SRG-APP-000499-CTR-001255 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must audit all uses of the usermod command. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Without generating audit record specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "usermod" command with the following command: $ sudo auditctl -l | grep usermod -a always,exit -F path=/usr/sbin/usermod -F perm=x -F auid>=1000 -F auid!=unset -k privileged-usermod If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "usermod " command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/sbin/usermod -F perm=x -F auid>=1000 -F auid!=unset -k privileged-usermod The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 112 | CCI-000130,CCI-000135,CCI-000169,CCI-000172,CCI-002884 | SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000471-GPOS-00215,SRG-APP-000495-CTR-001235 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must audit all uses of the mount command. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user logs on, the auid is set to the uid of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32-bit integer, which equals 4294967295. The audit system interprets -1, 4294967295, and "unset" in the same way. The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "mount" command with the following command: $ sudo auditctl -l | grep /usr/bin/mount -a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -k privileged-mount If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records upon successful/unsuccessful attempts to use the "mount" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": --a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -k privileged-mount The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 113 | CCI-001403,CCI-001404,CCI-001405,CCI-000172,CCI-000130,CCI-002130,CCI-000135,CCI-000169,CCI-002884,CCI-000018,CCI-000015 | SRG-OS-000004-GPOS-00004,SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000304-GPOS-00121,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000470-GPOS-00214,SRG-OS-000471-GPOS-00215,SRG-OS-000239-GPOS-00089,SRG-OS-000240-GPOS-00090,SRG-OS-000241-GPOS-00091,SRG-OS-000303-GPOS-00120,SRG-OS-000466-GPOS-00210,SRG-OS-000476-GPOS-00221,SRG-APP-000495-CTR-001235,SRG-APP-000499-CTR-001255,SRG-APP-000503-CTR-001275 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/sudoers. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
The actions taken by system administrators must be audited to keep a record of what was executed on the system, as well as for accountability purposes. Editing the sudoers file may be sign of an attacker trying to establish persistent methods to a system, auditing the editing of the sudoers files mitigates this risk. | Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify Red Hat OpenShift Container Platform 4 generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/sudoers" with the following command: $ sudo auditctl -l | grep /etc/sudoers -w /etc/sudoers -p wa -k identity If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/sudoers". Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -w /etc/sudoers -p wa -k identity The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 114 | CCI-001403,CCI-001404,CCI-001405,CCI-000172,CCI-000130,CCI-002130,CCI-000135,CCI-000169,CCI-002884,CCI-000018,CCI-000015 | SRG-OS-000004-GPOS-00004,SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000304-GPOS-00121,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000470-GPOS-00214,SRG-OS-000471-GPOS-00215,SRG-OS-000239-GPOS-00089,SRG-OS-000240-GPOS-00090,SRG-OS-000241-GPOS-00091,SRG-OS-000303-GPOS-00120,SRG-OS-000466-GPOS-00210,SRG-OS-000476-GPOS-00221,SRG-APP-000495-CTR-001235,SRG-APP-000499-CTR-001255,SRG-APP-000503-CTR-001275 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/sudoers.d/ directory. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
The actions taken by system administrators must be audited to keep a record of what was executed on the system, as well as for accountability purposes. Editing the sudoers file may be sign of an attacker trying to establish persistent methods to a system, auditing the editing of the sudoers files mitigates this risk. | Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify Red Hat OpenShift Container Platform 4 generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/sudoers.d/" with the following command: $ sudo auditctl -l | grep /etc/sudoers.d -w /etc/sudoers.d/ -p wa -k identity If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/sudoers.d/". Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -w /etc/sudoers.d/ -p wa -k identity The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 115 | CCI-001403,CCI-001404,CCI-001405,CCI-000172,CCI-000130,CCI-002130,CCI-000135,CCI-000169,CCI-002884,CCI-000018,CCI-000015 | SRG-OS-000004-GPOS-00004,SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000304-GPOS-00121,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000470-GPOS-00214,SRG-OS-000471-GPOS-00215,SRG-OS-000239-GPOS-00089,SRG-OS-000240-GPOS-00090,SRG-OS-000241-GPOS-00091,SRG-OS-000303-GPOS-00120,SRG-OS-000466-GPOS-00210,SRG-OS-000476-GPOS-00221,SRG-APP-000495-CTR-001235,SRG-APP-000499-CTR-001255,SRG-APP-000503-CTR-001275 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/group. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications must be investigated for legitimacy. | Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify Red Hat OpenShift Container Platform 4 generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/group" with the following command: $ sudo auditctl -l | egrep '(/etc/group)' -w /etc/group -p wa -k identity If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/group". Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -w /etc/group -p wa -k identity The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 116 | CCI-001403,CCI-001404,CCI-001405,CCI-000172,CCI-000130,CCI-002130,CCI-000135,CCI-000169,CCI-002884,CCI-000018,CCI-000015 | SRG-OS-000004-GPOS-00004,SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000304-GPOS-00121,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000470-GPOS-00214,SRG-OS-000471-GPOS-00215,SRG-OS-000239-GPOS-00089,SRG-OS-000240-GPOS-00090,SRG-OS-000241-GPOS-00091,SRG-OS-000303-GPOS-00120,SRG-OS-000466-GPOS-00210,SRG-OS-000476-GPOS-00221,SRG-APP-000495-CTR-001235,SRG-APP-000499-CTR-001255,SRG-APP-000503-CTR-001275 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/gshadow. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy. | Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify Red Hat OpenShift Container Platform 4 generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/gshadow" with the following command: $ sudo auditctl -l | egrep '(/etc/gshadow)' -w /etc/gshadow -p wa -k identity If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/gshadow". Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -w /etc/gshadow -p wa -k identity The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 117 | CCI-001403,CCI-001404,CCI-001405,CCI-000172,CCI-000130,CCI-002130,CCI-000135,CCI-000169,CCI-002884,CCI-000018,CCI-000015 | SRG-OS-000004-GPOS-00004,SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000304-GPOS-00121,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000470-GPOS-00214,SRG-OS-000471-GPOS-00215,SRG-OS-000239-GPOS-00089,SRG-OS-000240-GPOS-00090,SRG-OS-000241-GPOS-00091,SRG-OS-000303-GPOS-00120,SRG-OS-000466-GPOS-00210,SRG-OS-000476-GPOS-00221,SRG-APP-000495-CTR-001235,SRG-APP-000496-CTR-001240,SRG-APP-000497-CTR-001245,SRG-APP-000498-CTR-001250,SRG-APP-000503-CTR-001275 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/opasswd. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy. | Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify Red Hat OpenShift Container Platform 4 generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/security/opasswd" with the following command: $ sudo auditctl -l | egrep '(/etc/security/opasswd)' -w /etc/security/opasswd -p wa -k identity If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/security/opasswd". Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -w /etc/security/opasswd -p wa -k identity The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 118 | CCI-001403,CCI-001404,CCI-001405,CCI-000172,CCI-000130,CCI-002130,CCI-000135,CCI-000169,CCI-002884,CCI-000018,CCI-000015 | SRG-OS-000004-GPOS-00004,SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000304-GPOS-00121,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000470-GPOS-00214,SRG-OS-000471-GPOS-00215,SRG-OS-000239-GPOS-00089,SRG-OS-000240-GPOS-00090,SRG-OS-000241-GPOS-00091,SRG-OS-000303-GPOS-00120,SRG-OS-000304-GPOS-00121,SRG-OS-000466-GPOS-00210,SRG-OS-000476-GPOS-00221,SRG-OS-000274-GPOS-00104,SRG-OS-000275-GPOS-00105,SRG-OS-000276-GPOS-00106,SRG-OS-000277-GPOS-00107,SRG-APP-000495-CTR-001235,SRG-APP-000499-CTR-001255,SRG-APP-000503-CTR-001275 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/passwd. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy. | Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify Red Hat OpenShift Container Platform 4 generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/passwd" with the following command: $ sudo auditctl -l | egrep '(/etc/passwd)' -w /etc/passwd -p wa -k identity If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/passwd". Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -w /etc/passwd -p wa -k identity The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 119 | CCI-001403,CCI-001404,CCI-001405,CCI-000172,CCI-000130,CCI-002130,CCI-000135,CCI-000169,CCI-002884,CCI-000018,CCI-000015 | SRG-OS-000004-GPOS-00004,SRG-OS-000037-GPOS-00015,SRG-OS-000042-GPOS-00020,SRG-OS-000062-GPOS-00031,SRG-OS-000304-GPOS-00121,SRG-OS-000392-GPOS-00172,SRG-OS-000462-GPOS-00206,SRG-OS-000470-GPOS-00214,SRG-OS-000471-GPOS-00215,SRG-OS-000239-GPOS-00089,SRG-OS-000240-GPOS-00090,SRG-OS-000241-GPOS-00091,SRG-OS-000303-GPOS-00120,SRG-OS-000466-GPOS-00210,SRG-OS-000476-GPOS-00221,SRG-APP-000495-CTR-001235,SRG-APP-000499-CTR-001255,SRG-APP-000503-CTR-001275 | The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur. | Red Hat OpenShift Container Platform 4 must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/shadow. | Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). |
In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy. | Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. If audit records are not generated, this is a finding. |
Verify Red Hat OpenShift Container Platform 4 generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/passwd with the following command: $ sudo auditctl -l | egrep '(/etc/shadow)' -w /etc/shadow -p wa -k identity If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/shadow". Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -w /etc/shadow -p wa -k identity The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 120 | CCI-001350 | SRG-APP-000126-CTR-000275 | CCE-90688-3 | The container platform must use FIPS validated cryptographic mechanisms to protect the integrity of log information. | The container platform must use FIPS validated cryptographic mechanisms to protect the integrity of log information. |
To fully investigate an incident and to have trust in the audit data that is generated, it is important to put in place data protections. Without integrity protections, unauthorized changes may be made to the audit files and reliable forensic analysis and discovery of the source of malicious system activity may be degraded. Although digital signatures are one example of protecting integrity, this control is not intended to cause a new cryptographic hash to be generated every time a record is added to a log file. Integrity protections can also be implemented by using cryptographic techniques for security function isolation and file system protections to protect against unauthorized changes. |
Applicable - Configurable | Review the container platform configuration to determine if FIPS-validated cryptographic mechanisms are being used to protect the integrity of log information. If FIPS-validated cryptographic mechanisms are not being used to protect the integrity of log information, this is a finding. |
Verify that the Cluster Log Forwarder is using an encrypted transport: > oc get clusterlogforwarder -n openshift-logging For each Cluster Log Forwarder, run the following command to display the configuration > oc describe clusterlogforwarder -n openshift-logging Review the configuration and determine if the transport is secure, such as tls:// or https://. If there are any transports configured that are not secured by TLS, this is a finding. |
Edit the Cluster Log Forwarder configuration to configure TLS on the transport. > oc edit clusterlogforwarder -n openshift-logging For detailed information regarding configuration of the Cluster Log Forwarder see https://docs.openshift.com/container-platform/latest/logging/cluster-logging-external.html |
CAT II | ||||||
| 121 | CCI-000382 | SRG-APP-000645-CTR-001410 | The container platform must prohibit or restrict the use of protocols that transmit unencrypted authentication information or use flawed cryptographic algorithms for transmission. | Red Hat OpenShift Container Platform 4 must prohibit or restrict the use of protocols that transmit unencrypted authentication information or use flawed cryptographic algorithms for transmission. | The use of secure ports, protocols and services within the container platform must be controlled and conform to the PPSM CAL. Those ports, protocols, and services that fall outside the PPSM CAL must be blocked by the runtime. Instructions on the PPSM can be found in DoD Instruction 8551.01 Policy. Unsecure protocols for transmission will expose the information system data and information, making the session susceptible to manipulation, hijacking, and man-in-the middle attacks. |
Applicable - Inherently Met | Review the container platform configuration to verify that container platform is not using protocols that transmit authentication data unencrypted and that the container platform is not using flawed cryptographic algorithms for transmission. If the container platform is using protocols to transmit authentication data unencrypted or is using flawed cryptographic algorithms, this is a finding. |
CAT I | Supporting evidence is in the following documentation https://docs.openshift.com/container-platform/latest/post_installation_configuration/network-configuration.html |
The ports and protocols configured with OpenShift are required for the proper functioning of the clusters and associated network. Details on configuration options are located in the following document: https://docs.openshift.com/container-platform/latest/post_installation_configuration/network-configuration.html |
|||||||
| 122 | CCI-000172 | SRG-OS-000458-GPOS-00203,SRG-OS-000474-GPOS-00219,SRG-OS-000475-GPOS-00220,SRG-OS-000463-GPOS-00207,SRG-OS-000465-GPOS-00209,SRG-OS-000461-GPOS-00205,SRG-APP-000091-CTR-000160,SRG-APP-000492-CTR-001220,SRG-APP-000493-CTR-001225,SRG-APP-000494-CTR-001230,SRG-APP-000500-CTR-001260,SRG-APP-000507-CTR-001295 | The container platform must generate audit records when successful/unsuccessful attempts to delete security levels occur. | The container platform and its components must generate audit records when deleting security levels. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible. Without audit record generation, unauthorized users can delete security levels unknowingly for malicious intent creating vulnerabilities within the container platform. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to delete security levels. If audit records are not generated, this is a finding. |
CAT II | ||||||||||
| 123 | CCI-000172 | SRG-OS-000458-GPOS-00203,SRG-OS-000474-GPOS-00219,SRG-OS-000475-GPOS-00220,SRG-OS-000463-GPOS-00207,SRG-OS-000465-GPOS-00209,SRG-OS-000461-GPOS-00205,SRG-APP-000091-CTR-000160,SRG-APP-000492-CTR-001220,SRG-APP-000493-CTR-001225,SRG-APP-000494-CTR-001230,SRG-APP-000500-CTR-001260,SRG-APP-000507-CTR-001295 | The container platform must generate audit records when successful/unsuccessful attempts to delete security levels occur. | The container platform and its components must generate audit records when deleting security levels. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible. Without audit record generation, unauthorized users can delete security levels unknowingly for malicious intent creating vulnerabilities within the container platform. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to delete security levels. If audit records are not generated, this is a finding. |
CAT II | ||||||||||
| 124 | CCI-000172 | SRG-OS-000458-GPOS-00203,SRG-OS-000474-GPOS-00219,SRG-OS-000475-GPOS-00220,SRG-OS-000463-GPOS-00207,SRG-OS-000465-GPOS-00209,SRG-OS-000461-GPOS-00205,SRG-APP-000091-CTR-000160,SRG-APP-000492-CTR-001220,SRG-APP-000493-CTR-001225,SRG-APP-000494-CTR-001230,SRG-APP-000500-CTR-001260,SRG-APP-000507-CTR-001295 | The container platform must generate audit records when successful/unsuccessful attempts to delete security levels occur. | The container platform and its components must generate audit records when deleting security levels. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible. Without audit record generation, unauthorized users can delete security levels unknowingly for malicious intent creating vulnerabilities within the container platform. |
Applicable - Configurable | Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to delete security levels. If audit records are not generated, this is a finding. |
CAT II | ||||||||||
| 125 | CCI-002233,CCI-002234 | SRG-OS-000326-GPOS-00126,SRG-OS-000327-GPOS-00127,SRG-APP-000343-CTR-000780,SRG-APP-000381-CTR-000905,SRG-OS-000755-GPOS-00220 | The container platform must audit the execution of privileged functions. | Red Hat OpenShift Container Platform 4 must audit uses of the "execve" system call. | Privileged functions within the container platform can be component specific or can envelope the entire container platform. Because of the nature of the commands, it is important to understand what command was executed for either investigation of an incident or for debugging/error correction; therefore, privileged function execution must be audited. | Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised information system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider threats and the advanced persistent threat. | Applicable - Configurable | Review container platform documentation and log configuration to verify the application server logs privileged activity. If the container platform is not configured to log privileged activity, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 is configured to audit the execution of the "execve" system call with the following command: $ sudo auditctl -l | grep execve -a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -k execpriv -a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -k execpriv -a always,exit -F arch=b32 -S execve -C gid!=egid -F egid=0 -k execpriv -a always,exit -F arch=b64 -S execve -C gid!=egid -F egid=0 -k execpriv If the command does not return all lines, or the lines are commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to audit the execution of the "execve" system call. Add or update the following file system rules to "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -k execpriv -a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -k execpriv -a always,exit -F arch=b32 -S execve -C gid!=egid -F egid=0 -k execpriv -a always,exit -F arch=b64 -S execve -C gid!=egid -F egid=0 -k execpriv The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 126 | CCI-001190 | SRG-APP-000225-CTR-000570 | The container platform runtime must fail to a secure state if system initialization fails, shutdown fails, or aborts fail. | Red Hat OpenShift Container Platform 4 runtime must fail to a secure state if system initialization fails, shutdown fails, or aborts fail. | The container platform offers services for container image orchestration and services for users. If any of these services were to fail into an insecure state, security measures for user and data separation and image instantiation could become absent. In addition, audit log protections could be relaxed allowing for investigation of what occurred could be lost. To protect services and data, it is important for the container platform to fail to a secure state if the container platform registry initialization fails, shutdown fails, or aborts fail. | Applicable - Inherently Met | Review documentation and configuration to determine if the container platform runtime fails to a secure state if system initialization fails, shutdown fails, or aborts fail. If the container platform runtime cannot be configured to fail securely, this is a finding. |
CAT II | Supporting evidence is in the following documentation https://docs.openshift.com/container-platform/latest/support/gathering-cluster-data.html |
In the event that there is a failure or disruption to the OpenShift platform, information necessary to identifying the cause would be preserved. The cluster state (resource definitions) is preserved by etcd, audit and system logs are preserved via journald service at the node levels. The following guide provide steps on how to gather cluster data in order to investigate issue with the cluster. https://docs.openshift.com/container-platform/latest/support/gathering-cluster-data.html |
|||||||
| 127 | CCI-001082 | SRG-APP-000211-CTR-000530 | The container platform must separate user functionality (including user interface services) from information system management functionality. | Red Hat OpenShift Container Platform 4 must separate user functionality (including user interface services) from information system management functionality. | Separating user functionality from management functionality is a requirement for all the components within the container platform. Without the separation, users may have access to management functions that can degrade the container platform and the services being offered and can offer a method to bypass testing and validation of functions before introduced into a production environment. The separation should be enforced by each component within the container platform. |
Applicable - Configurable | Review the container platform configuration to determine if management functionality is separated from user functionality. Validate that the separation is also implemented within the components by trying to execute management functions for each component as a user. If the container platform is not configured to separate management and user functionality or if component management and user functionality are not separated, this is a finding. |
Verify that root and core are the only user accounts on the nodes by executing the following: for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'echo -n "$HOSTNAME "; cat /etc/passwd' 2>/dev/null; done The output will look something like <node_name> root:x:0:0:root:/root:/bin/bash core:x:1000:1000:CoreOS Admin:/var/home/core:/bin/bash containers:x:993:995:User for housing the sub ID range for containers:/var/home/containers:/sbin/nologin If there are any user accounts in addition to root, containers and core, this is a finding. Verify the root and core users are set to disable password logon by executing the following: for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'echo -n "$HOSTNAME "; grep -e "^root" -e "^core" /etc/shadow' 2>/dev/null; done The output will look something like <node_name> root:*:18367:0:99999:7::: core:*:18939:0:99999:7::: If the password entry has anything other than '*', this is a finding. |
Disable and remove passwords from root and core accounts by executing the following: for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'usermod -p "*" root; usermod -p "*" core' 2>/dev/null; done Remove any additional user accounts from the nodes by executing the following: oc debug node/<node> -- chroot /host /bin/bash -c 'userdel <user>' |
CAT II | |||||||
| 128 | CCI-000197 | SRG-APP-000172-CTR-000440 | 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. | 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. | Passwords need to be protected on entry, in transmission, during authentication, and when stored. If compromised at any of these security points, a nefarious user can use the password along with stolen user account information to gain access or to escalate privileges. The container platform may require account authentication during container platform tasks and before accessing container platform components, e.g. runtime, registry, and keystore. During any user authentication, the container platform must use FIPS-validated SHA-2 or later protocol to protect the integrity of the password authentication process. |
Not Applicable | Review the documentation and configuration to determine if the container platform enforces the required FIPS-validated encrypt passwords when they are transmitted. If the container platform is not configured to meet this requirement, this is a finding. |
CAT I | Not Applicable. Applicable to Identity Management Provider and not OCP. Only configurable check is to ensure OCP is configured for an IDP under SRG-APP-000023-CTR-000055. Verify with IdM service provider admins that the IdM meets the requirements. |
||||||||
| 129 | CCI-000192 | SRG-APP-000166-CTR-000410 | The container platform must enforce password complexity by requiring that at least one uppercase character be used. | Red Hat OpenShift Container Platform 4 must enforce password complexity by requiring that at least one uppercase character be used. | Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised. |
Not Applicable | Review the container platform configuration to determine if it enforces password complexity by requiring that at least one uppercase character be used. If the container platform does not enforce password complexity by requiring that at least one uppercase character be used, this is a finding. |
CAT II | Not Applicable. Applicable to Identity Management Provider and not OCP. Only configurable check is to ensure OCP is configured for an IDP under SRG-APP-000023-CTR-000055. Verify with IdM service provider admins that the IdM meets the requirements. |
||||||||
| 130 | CCI-000068 | SRG-APP-000014-CTR-000040,SRG-APP-000560-CTR-001340 | CCE-86232-6 | The container platform must use TLS 1.2 or greater for secure communication. | Red Hat OpenShift Container Platform 4 must use TLS 1.2 or greater for secure communication. |
The authenticity and integrity of the container platform and communication between nodes and components must be secure. If an insecure protocol is used during transmission of data, the data can be intercepted and manipulated. The manipulation of data can be used to inject status changes of the container platform, causing the execution of containers or reporting an incorrect healthcheck. To thwart the manipulation of the data during transmission, a secure protocol (TLS 1.2 or newer) must be used. Further guidance on secure transport protocols can be found in NIST SP 800-52. | The authenticity and integrity of the container platform and communication between nodes and components must be secure. If an insecure protocol is used during transmission of data, the data can be intercepted and manipulated. The manipulation of data can be used to inject status changes of the container platform, causing the execution of containers or reporting an incorrect healthcheck. To thwart the manipulation of the data during transmission, a secure protocol (TLS 1.2 or newer) must be used. Further guidance on secure transport protocols can be found in NIST SP 800-52. |
Applicable - Configurable | Review the container platform configuration to verify that TLS 1.2 or greater is being used for communication by the container platform nodes and components. If TLS 1.2 or greater is not being used for secure communication, this is a finding. |
Verify that the control plane TLS Security Profile is not set to old, or a custom profile that does not enforce TLS 1.2 or above. > oc get APIServer cluster -o jsonpath='{.spec.tlsSecurityProfile}' If the above returns a TLS profile of "Old", this is a finding. If the above returns a TLS profile of "Custom" and the minTLSVersion is not set to "VersionTLS12" or greater, this is a finding. |
Edit the apiserver/cluster resource and set the TLS Security Profile to Intermediate > oc edit APIServer cluster set to the following apiVersion: config.openshift.io/v1 kind: APIServer ... spec: tlsSecurityProfile: intermediate: {} type: Intermediate |
CAT II | |||||
| 131 | CCI-000068 | SRG-APP-000014-CTR-000040,SRG-APP-000560-CTR-001340 | CCE-86234-2 | The container platform must use TLS 1.2 or greater for secure communication. | Red Hat OpenShift Container Platform 4 must use TLS 1.2 or greater for secure communication. |
The authenticity and integrity of the container platform and communication between nodes and components must be secure. If an insecure protocol is used during transmission of data, the data can be intercepted and manipulated. The manipulation of data can be used to inject status changes of the container platform, causing the execution of containers or reporting an incorrect healthcheck. To thwart the manipulation of the data during transmission, a secure protocol (TLS 1.2 or newer) must be used. Further guidance on secure transport protocols can be found in NIST SP 800-52. | The authenticity and integrity of the container platform and communication between nodes and components must be secure. If an insecure protocol is used during transmission of data, the data can be intercepted and manipulated. The manipulation of data can be used to inject status changes of the container platform, causing the execution of containers or reporting an incorrect healthcheck. To thwart the manipulation of the data during transmission, a secure protocol (TLS 1.2 or newer) must be used. Further guidance on secure transport protocols can be found in NIST SP 800-52. |
Applicable - Configurable | Review the container platform configuration to verify that TLS 1.2 or greater is being used for communication by the container platform nodes and components. If TLS 1.2 or greater is not being used for secure communication, this is a finding. |
Verify that IngressController TLS Security Profile is not set to old, or a custom profile that does not enforce TLS 1.2 or above. > oc get IngressControllers -nopenshift-ingress-operator -o \ jsonpath='{range.items[]} Name: {.metadata.name} Profile: {.spec.tlsSecurityProfile}{" "}' If the above returns a TLS profile of "Old", this is a finding. If the above returns a TLS profile of "Custom" and the minTLSVersion is not set to "VersionTLS12" or greater, this is a finding. |
Edit each resource and set the TLS Security Profile to Intermediate > oc edit ingresscontroller -nopenshift-ingress-operator set to the following apiVersion: config.openshift.io/v1 kind: IngressController ... spec: tlsSecurityProfile: intermediate: {} type: Intermediate |
CAT II | |||||
| 132 | CCI-000068 | SRG-APP-000014-CTR-000040,SRG-APP-000560-CTR-001340 | CCE-86623-6 | The container platform must use TLS 1.2 or greater for secure communication. | Red Hat OpenShift Container Platform 4 must use TLS 1.2 or greater for secure communication. |
The authenticity and integrity of the container platform and communication between nodes and components must be secure. If an insecure protocol is used during transmission of data, the data can be intercepted and manipulated. The manipulation of data can be used to inject status changes of the container platform, causing the execution of containers or reporting an incorrect healthcheck. To thwart the manipulation of the data during transmission, a secure protocol (TLS 1.2 or newer) must be used. Further guidance on secure transport protocols can be found in NIST SP 800-52. | The authenticity and integrity of the container platform and communication between nodes and components must be secure. If an insecure protocol is used during transmission of data, the data can be intercepted and manipulated. The manipulation of data can be used to inject status changes of the container platform, causing the execution of containers or reporting an incorrect healthcheck. To thwart the manipulation of the data during transmission, a secure protocol (TLS 1.2 or newer) must be used. Further guidance on secure transport protocols can be found in NIST SP 800-52. |
Applicable - Configurable | Review the container platform configuration to verify that TLS 1.2 or greater is being used for communication by the container platform nodes and components. If TLS 1.2 or greater is not being used for secure communication, this is a finding. |
Verify that the Kubelet TLS Security Profile is not set to old, or a custom profile that does not enforce TLS 1.2 or above. > oc get KubeletConfigs -o \ jsonpath='{range .items[]} Name: {.metadata.name} Profile: {.spec.tlsSecurityProfile}{" "}' If the above returns a TLS profile of "Old", this is a finding. If the above returns a TLS profile of "Custom" and the minTLSVersion is not set to "VersionTLS12" or greater, this is a finding. |
Edit the KubeletConfig and set the TLS Security Profile to Intermediate > oc edit KubeletConfig set to the following apiVersion: config.openshift.io/v1 kind: KubeletConfig ... spec: tlsSecurityProfile: intermediate: {} type: Intermediate |
CAT II | |||||
| 133 | CCI-000172,CCI-002884 | SRG-OS-000392-GPOS-00172,SRG-OS-000470-GPOS-00214,SRG-OS-000473-GPOS-00218,SRG-APP-000503-CTR-001275,SRG-APP-000506-CTR-001290 | The container platform must generate audit records when successful/unsuccessful logon attempts occur. | Red Hat OpenShift Container Platform 4 must generate audit records for all account creations, modifications, disabling, and termination events that affect /var/log/faillock. | The container platform and its components must generate audit records when successful and unsuccessful logon attempts occur. The information system can determine if an account is compromised or is in the process of being compromised and can take actions to thwart the attack. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible. | Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. | Applicable - Configurable | Review the container platform configuration for audit logon events. Ensure audit policy for successful and unsuccessful logon events are enabled. Verify events are written to the log. Validate system documentation is current. If logon attempts do not generate log records, this is a finding. |
Verify Red Hat OpenShift Container Platform 4 generates audit records for all account creations, modifications, disabling, and termination events that affect "/var/log/faillock" with the following command: $ sudo auditctl -l | grep /var/log/faillock -w /var/log/faillock -p wa -k logins If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records for all account creations, modifications, disabling, and termination events that affect "/var/log/faillock". Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -w /var/log/faillock -p wa -k logins The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 134 | CCI-000172,CCI-002884 | SRG-OS-000392-GPOS-00172,SRG-OS-000470-GPOS-00214,SRG-OS-000473-GPOS-00218,SRG-APP-000503-CTR-001275 | The container platform must generate audit records when successful/unsuccessful logon attempts occur. | Red Hat OpenShift Container Platform 4 must generate audit records for all account creations, modifications, disabling, and termination events that affect /var/log/tallylog. | The container platform and its components must generate audit records when successful and unsuccessful logon attempts occur. The information system can determine if an account is compromised or is in the process of being compromised and can take actions to thwart the attack. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible. | Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. | Applicable - Configurable | Review the container platform configuration for audit logon events. Ensure audit policy for successful and unsuccessful logon events are enabled. Verify events are written to the log. Validate system documentation is current. If logon attempts do not generate log records, this is a finding. |
Verify Red Hat OpenShift Container Platform 4 generates audit records for all account creations, modifications, disabling, and termination events that affect "/var/log/tallylog" with the following command: $ sudo auditctl -l | grep /var/log/tallylog -w /var/log/tallylog -p wa -k logins If the command does not return a line, or the line is commented out, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to generate audit records for all account creations, modifications, disabling, and termination events that affect "/var/log/tallylog". Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -w /var/log/tallylog -p wa -k logins The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 135 | CCI-002009 | SRG-APP-000402-CTR-000970 | The container platform must accept Personal Identity Verification (PIV) credentials from other federal agencies. | Red Hat OpenShift Container Platform 4 must accept Personal Identity Verification (PIV) credentials from other federal agencies. | Controlling access to the container platform and its components is paramount in having a secure and stable system. Validating users is the first step in controlling the access. Users may be validated by the overall container platform or they may be validated by each component. It is essential to accept PIV credentials from other federal agencies and eliminate the possibility of access being denied to authorized users. PIV credentials are those credentials issued by federal agencies that conform to FIPS Publication 201 and supporting guidance documents. OMB Memorandum 11-11 requires federal agencies to continue implementing the requirements specified in HSPD-12 to enable agency-wide use of PIV credentials. |
Not Applicable | Review the documentation and configuration to determine if the container platform accepts PIV credentials from other federal agencies. If the container platform does not accept other federal agency PIV credentials, this is a finding. |
CAT II | Not Applicable. Applicable to Identity Management Provider and not OCP. Only configurable check is to ensure OCP is configured for an IDP under SRG-APP-000023-CTR-000055. Verify with IdM service provider admins that the IdM meets the requirements. |
||||||||
| 136 | CCI-002420 | SRG-APP-000441-CTR-001090 | The container platform must maintain the confidentiality and integrity of information during preparation for transmission. | Red Hat OpenShift Container Platform 4 must maintain the confidentiality and integrity of information during preparation for transmission. | Information may be unintentionally or maliciously disclosed or modified during preparation for transmission within the container platform during aggregation, at protocol transformation points, and during container image runtime. These unauthorized disclosures or modifications compromise the confidentiality or integrity of the information. When transmitting data, the container platform components need to leverage transmission protection mechanisms, such as TLS, TLS VPNs, or IPsec. | Applicable - Inherently Met | Review the documentation and deployed configuration to determine if the container platform maintains the confidentiality and integrity of information during preparation before transmission. If the confidentiality and integrity are not maintained using mechanisms such as TLS, TLS VPNs, or IPsec during preparation before transmission, this is a finding. |
CAT II | Supporting evidence is in the following documentation https://access.redhat.com/articles/5348961 |
The OpenShift Container Platform uses TLS encryption for communication with the internal components. Many of these components support additional levels of configuration, such as allowed cyphers and minimum TLS levels. Although not all components support this additional configuration, they still use TLS for encryption of the internal communications. | |||||||
| 137 | CCI-001619 | SRG-APP-000169-CTR-000425 | The container platform must enforce password complexity by requiring that at least one special character be used. | Red Hat OpenShift Container Platform 4 must enforce password complexity by requiring that at least one special character be used. | Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor in determining how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. Special characters are those characters that are not alphanumeric. Examples include ~ ! @ # $ % ^ *. |
Not Applicable | Review the container platform configuration to determine if it enforces password complexity by requiring that at least one special character be used. If the container platform does not enforce password complexity by requiring that at least one special character be used, this is a finding. |
CAT II | Not Applicable. Applicable to Identity Management Provider and not OCP. Only configurable check is to ensure OCP is configured for an IDP under SRG-APP-000023-CTR-000055. Verify with IdM service provider admins that the IdM meets the requirements. |
||||||||
| 138 | CCI-000366,CCI-004045 | SRG-OS-000109-GPOS-00056,SRG-OS-000480-GPOS-00227,SRG-APP-000148-CTR-000335,SRG-APP-000190-CTR-000500 | The container platform must uniquely identify and authenticate users. | Red Hat OpenShift Container Platform 4 must not permit direct logons to the root account using remote access via SSH. | The container platform requires user accounts to perform container platform tasks. These tasks may pertain to the overall container platform or may be component-specific, thus requiring users to authenticate against those specific components. To ensure accountability and prevent unauthenticated access, users must be identified and authenticated to prevent potential misuse and compromise of the system. | Even though the communications channel may be encrypted, an additional layer of security is gained by extending the policy of not logging directly on as root. In addition, logging in with a user-specific account provides individual accountability of actions performed on the system and also helps to minimize direct attack attempts on root's password. | Applicable - Configurable | Review the container platform configuration to determine if users are uniquely identified and authenticated. If users are not uniquely identified or are not authenticated, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 remote access using SSH prevents users from logging on directly as "root" with the following command: $ sudo /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '\r' | tr '' ' ' | xargs sudo grep -iH '^\s*permitrootlogin' PermitRootLogin no If the "PermitRootLogin" keyword is set to "yes", is missing, or is commented out, this is a finding. |
To configure the system to prevent SSH users from logging on directly as root add or modify the following line in "/etc/ssh/sshd_config". PermitRootLogin no Restart the SSH daemon for the settings to take effect: $ sudo systemctl restart sshd.service |
CAT II | ||||||
| 139 | CCI-002422 | SRG-APP-000442-CTR-001095 | The container platform must maintain the confidentiality and integrity of information during reception. | Red Hat OpenShift Container Platform 4 must maintain the confidentiality and integrity of information during reception. | Information either can be unintentionally or maliciously disclosed or modified during reception for reception within the container platform during aggregation, at protocol transformation points, and during container image runtime. These unauthorized disclosures or modifications compromise the confidentiality or integrity of the information. When receiving data, the container platform components need to leverage protection mechanisms, such as TLS, TLS VPNs, or IPsec. | Applicable - Inherently Met | Review documentation and configuration settings to determine if the container platform maintains the confidentiality and integrity of information during reception. If confidentiality and integrity are not maintained using mechanisms such as TLS, TLS VPNs, or IPsec during reception, this is a finding. |
CAT II | Supporting evidence is in the following documentation https://access.redhat.com/articles/5348961 |
The OpenShift Container Platform uses TLS encryption for communication with the internal components. Many of these components support additional levels of configuration, such as allowed cyphers and minimum TLS levels. Although not all components support this additional configuration, they still use TLS for encryption of the internal communications. | |||||||
| 140 | CCI-001368 | SRG-APP-000038-CTR-000105 | The container platform must enforce approved authorizations for controlling the flow of information within the container platform based on organization-defined information flow control policies. | Red Hat OpenShift Container Platform 4 must enforce approved authorizations for controlling the flow of information within Red Hat OpenShift Container Platform 4 based on organization-defined information flow control policies. |
Controlling information flow between the container platform components and container user services instantiated by the container platform must enforce organization-defined information flow policies. Example methods for information flow control are using labels and separate namespace for containers to segregate services; user permissions and roles to limit what user services are available to each user; controlling the user the services are able to execute as; and limiting inter-container network traffic and the resources containers can consume. | Applicable - Configurable | Review the container platform to determine if approved authorizations for controlling the flow of information within the container platform based on organization-defined information flow control policies is being enforced. If the organization-defined information flow policies are not being enforced, this is a finding. |
Verify that each user namespace has a Network Policy 1. Get a list of existing projects(namespaces), exclude default, kube-*, openshift-* > oc get namespaces -ojson | jq -r '[.items[] | select((.metadata.name | startswith("openshift") | not) and (.metadata.name | startswith("kube-") | not) and .metadata.name != "default") | .metadata.name]' 2. Get a list of namespaces, excluding default, kube-* and openshift-* that contain a NetworkPolicy object. > oc get NetworkPolicy -A -ojson | jq -r '[.items[] | select((.metadata.namespace | startswith("openshift") | not) and (.metadata.namespace | startswith("kube-") | not) and .metadata.namespace != "default") | .metadata.namespace] | unique' If the two lists do not match, in other words, if a project does not have any NetworkPolicy definitions, this is a finding. |
Configure a default network policy as necessary to protect the flow of information by performing the following steps. 1. Create a networkpolicy.yaml file with the NetworkPolicy object definitions desired. For example, the following section defines two policies one to allow requests from the same namespace, the other to allow from the openshift ingress routing service. apiVersion: v1 kind: List items: - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-same-namespace spec: podSelector: ingress: - from: - podSelector: {} - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-ingress spec: ingress: - from: - namespaceSelector: matchLabels: network.openshift.io/policy-group: ingress podSelector: {} policyTypes: - Ingress 3. Apply the NetworkPolicy object to the appropriate namespaces by running the following command: > oc apply -f networkpolicy.yaml -n For additional information regarding network policies, see https://docs.openshift.com/container-platform/latest/networking/network_policy/about-network-policy.html |
CAT II | |||||||
| 141 | CCI-001368 | SRG-APP-000038-CTR-000105 | The container platform must enforce approved authorizations for controlling the flow of information within the container platform based on organization-defined information flow control policies. | Red Hat OpenShift Container Platform 4 must enforce approved authorizations for controlling the flow of information within Red Hat OpenShift Container Platform 4 based on organization-defined information flow control policies. |
Controlling information flow between the container platform components and container user services instantiated by the container platform must enforce organization-defined information flow policies. Example methods for information flow control are using labels and separate namespace for containers to segregate services; user permissions and roles to limit what user services are available to each user; controlling the user the services are able to execute as; and limiting inter-container network traffic and the resources containers can consume. | Applicable - Configurable | Review the container platform to determine if approved authorizations for controlling the flow of information within the container platform based on organization-defined information flow control policies is being enforced. If the organization-defined information flow policies are not being enforced, this is a finding. |
Verify that the CNI supports NetworkPolicies: > oc get network cluster -oyaml -ojsonpath='{.spec.networkType}' The result should list a CNI plugin that supports NetworkPolicies, currently the plugins that do support NetworkPolicies are OpenShiftSDN, OVN and Calico. If the cluster does not return a CNI that supports NetworkPolicies, this is a finding. |
Migration to a supported CNI plugin is not automated. For additional information regarding network policies, see https://docs.openshift.com/container-platform/latest/networking/network_policy/about-network-policy.html |
CAT II | |||||||
| 142 | CCI-000767 | SRG-APP-000151-CTR-000365 | The container platform must use multifactor authentication for local access to privileged accounts. | Red Hat OpenShift Container Platform 4 must use multifactor authentication for local access to privileged accounts. | To ensure accountability and prevent unauthenticated access, privileged users must utilize multifactor authentication to prevent potential misuse and compromise of the system. Multifactor authentication is defined as using two or more factors to achieve authentication. Factors include: (i) Something a user knows (e.g., password/PIN); (ii) Something a user has (e.g., cryptographic identification device, token); or (iii) Something a user is (e.g., biometric). A privileged account is defined as an information system account with authorizations of a privileged user. Local access is defined as access to an organizational information system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network. |
Not Applicable | Review the container platform configuration to determine if multifactor authentication is used for local access to privileged accounts. If multifactor authentication for local access to privileged accounts is not being used, this is a finding. |
CAT II | Not Applicable. Applicable to Identity Management Provider and not OCP. Only configurable check is to ensure OCP is configured for an IDP under SRG-APP-000023-CTR-000055. Verify with IdM service provider admins that the IdM meets the requirements. |
||||||||
| 143 | CCI-001749 | SRG-APP-000131-CTR-000285 | CCE-90254-4 | The container platform must verify container images. | Red Hat OpenShift Container Platform 4 must verify container images. | The container platform must be capable of validating container images are signed and that the digital signature is from a recognized and approved source approved by the organization. Allowing any container image to be introduced into the registry and instantiated into a container can allow for services to be introduced that are not trusted and may contain malicious code, which introduces unwanted services. These unwanted services can cause harm and security risks to the hosting server, the container platform, other services running within the container platform, and the overall organization. | Applicable - Configurable | Review the container platform configuration to determine if container images are verified by enforcing image signing and that the image is signed recognized by an approved source. If container images are not verified or the signature is not verified as a recognized and approved source, this is a finding. |
Check to see if a policy has been put in place by running the commands: > for node in $(oc get node -oname); do \ oc debug $node -- chroot /host/bin/bash \ -c 'echo -n "$HOSTNAME "; cat /etc/containers/policy.json'2>/dev/null; \ done Make sure that the default policy to verify container images is set to reject. Also, ensure that the registries have the appropriate signature keys. This should look as follows: { "default": [{"type": "reject"}], "transports": { "docker": { "registry.access.redhat.com": [ { "type": "signedBy", "keyType": "GPGKeys", "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release" } ], "registry.redhat.io": [ { "type": "signedBy", "keyType": "GPGKeys", "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release" } ], ... } If the policy is not set to reject by default, and the signature keys are not configure appropriately on the registries, this is a finding. |
Configure the OpenShift Container policy to validate that images signatures are verified and enforced. This can be configured manually or through the use of the MachineConfig Operator published by Red Hat. > for mcpool in $(oc get mcp -oname | sed "s:.*/::" ); do echo "apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: $mcpool name: 51-rh-registry-trust-$mcpool spec: config: ignition: version: 3.2.0 storage: files: - contents: source: data:text/plain;charset=utf-8;base64,LS0tCmRvY2tlcjoKICByZWdpc3RyeS5hY2Nlc3MucmVkaGF0LmNvbToKICAgIHNpZ3N0b3JlOiBodHRwczovL2FjY2Vzcy5yZWRoYXQuY29tL3dlYmFzc2V0cy9kb2NrZXIvY29udGVudC9zaWdzdG9yZQo= verification: {} filesystem: root mode: 420 path: /etc/containers/registries.d/registry.access.redhat.com.yaml - contents: source: data:text/plain;charset=utf-8;base64,LS0tCmRvY2tlcjoKICByZWdpc3RyeS5yZWRoYXQuaW86CiAgICBzaWdzdG9yZTogaHR0cHM6Ly9yZWdpc3RyeS5yZWRoYXQuaW8vY29udGFpbmVycy9zaWdzdG9yZQo= verification: {} filesystem: root mode: 420 path: /etc/containers/registries.d/registry.redhat.io.yaml - contents: source: data:text/plain;charset=utf-8;base64,ewogICJkZWZhdWx0IjogW3sidHlwZSI6ICJyZWplY3QifV0sCiAgInRyYW5zcG9ydHMiOiB7CiAgICAiZG9ja2VyIjogewogICAgICAicmVnaXN0cnkuYWNjZXNzLnJlZGhhdC5jb20iOiBbCiAgICAgICAgewogICAgICAgICAgInR5cGUiOiAic2lnbmVkQnkiLAogICAgICAgICAgImtleVR5cGUiOiAiR1BHS2V5cyIsCiAgICAgICAgICAia2V5UGF0aCI6ICIvZXRjL3BraS9ycG0tZ3BnL1JQTS1HUEctS0VZLXJlZGhhdC1yZWxlYXNlIgogICAgICAgIH0KICAgICAgXSwKICAgICAgInJlZ2lzdHJ5LnJlZGhhdC5pbyI6IFsKICAgICAgICB7CiAgICAgICAgICAidHlwZSI6ICJzaWduZWRCeSIsCiAgICAgICAgICAia2V5VHlwZSI6ICJHUEdLZXlzIiwKICAgICAgICAgICJrZXlQYXRoIjogIi9ldGMvcGtpL3JwbS1ncGcvUlBNLUdQRy1LRVktcmVkaGF0LXJlbGVhc2UiCiAgICAgICAgfQogICAgICBdLAogICAgICAiaW1hZ2UtcmVnaXN0cnkub3BlbnNoaWZ0LWltYWdlLXJlZ2lzdHJ5LnN2Yzo1MDAwIjogW3sidHlwZSI6ICJpbnNlY3VyZUFjY2VwdEFueXRoaW5nIn1dLAogICAgICAicXVheS5pby9jb21wbGlhbmNlYXNjb2RlIjogW3sidHlwZSI6ICJpbnNlY3VyZUFjY2VwdEFueXRoaW5nIn1dLAogICAgICAicXVheS5pby9jb21wbGlhbmNlLW9wZXJhdG9yIjogW3sidHlwZSI6ICJpbnNlY3VyZUFjY2VwdEFueXRoaW5nIn1dLAogICAgICAicXVheS5pby9rZXljbG9hayI6IFt7InR5cGUiOiAiaW5zZWN1cmVBY2NlcHRBbnl0aGluZyJ9XSwKICAgICAgInF1YXkuaW8vb3BlbnNoaWZ0LXJlbGVhc2UtZGV2IjogW3sidHlwZSI6ICJpbnNlY3VyZUFjY2VwdEFueXRoaW5nIn1dLAogICAgICAicmVnaXN0cnkuYnVpbGQwMi5jaS5vcGVuc2hpZnQub3JnIjogW3sidHlwZSI6ICJpbnNlY3VyZUFjY2VwdEFueXRoaW5nIn1dLAogICAgICAicmVnaXN0cnkuYnVpbGQwMS5jaS5vcGVuc2hpZnQub3JnIjogW3sidHlwZSI6ICJpbnNlY3VyZUFjY2VwdEFueXRoaW5nIn1dCiAgICB9CiAgfQp9Cg== verification: {} filesystem: root mode: 420 path: /etc/containers/policy.json " | oc apply -f - done |
CAT II | ||||||
| 144 | CCI-000193 | SRG-APP-000167-CTR-000415 | The container platform must enforce password complexity by requiring that at least one lowercase character be used. | Red Hat OpenShift Container Platform 4 must enforce password complexity by requiring that at least one lowercase character be used. | Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. |
Not Applicable | Review the container platform configuration to determine if it enforces password complexity by requiring that at least one lowercase character be used. If the container platform does not enforce password complexity by requiring that at least one lowercase character be used, this is a finding. |
CAT II | Not Applicable. Applicable to Identity Management Provider and not OCP. Only configurable check is to ensure OCP is configured for an IDP under SRG-APP-000023-CTR-000055. Verify with IdM service provider admins that the IdM meets the requirements. |
||||||||
| 145 | CCI-001991 | SRG-APP-000401-CTR-000965 | The container platform, for PKI-based authentication, must implement a local cache of revocation data to support path discovery and validation in case of the inability to access revocation information via the network. | Red Hat OpenShift Container Platform 4, for PKI-based authentication, must implement a local cache of revocation data to support path discovery and validation in case of the inability to access revocation information via the network. | The potential of allowing access to users who are no longer authorized (have revoked certificates) increases unless a local cache of revocation data is configured. | Not Applicable | Review the container platform configuration. If the container platform is not implemented to use a local cache of revocation data to support path discovery and validation in case of the inability to access revocation information via the network, this is a finding. |
CAT II | Not Applicable. Applicable to Identity Management Provider and not OCP. Only configurable check is to ensure OCP is configured for an IDP under SRG-APP-000023-CTR-000055. Verify with IdM service provider admins that the IdM meets the requirements. |
||||||||
| 146 | CCI-001495 | SRG-APP-000123-CTR-000265 | CCE-90433-4 | The container platform must protect audit tools from unauthorized deletion. | Red Hat OpenShift Container Platform 4 must protect audit tools from unauthorized deletion. | Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data. Applications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the deletion of audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators. |
Applicable - Configurable | Review the container platform to validate container platform audit tools are protected from unauthorized deletion. If the audit tools are not protected from unauthorized deletion, this is a finding. |
Perform a check to list the users and groups who have permission to delete the cluster logging configuration by running the following two commands. > oc policy who-can delete ClusterLogging -n openshift-logging > oc policy who-can delete ClusterLoggingForwarder -n openshift-logging Review the list of users and groups who have delete access to the cluster logging resources. If any user or group listed should not have access to delete the cluster logging resources, this is a finding. |
Remove delete permissions from any unauthorized user or group by performing one or more of the following commands: * Remove role from user > oc adm policy remove-role-from-user ROLE USER -n openshift-logging * Remove role from group > oc adm policy remove-role-from-group ROLE GROUP -n openshift-logging * Remove cluster role from user > oc adm policy remove-cluster-role-from-user CLUSTER_ROLE USER -n openshift-logging * Remove cluster role from group > oc adm policy remove-cluster-role-from-group CLUSTER_ROLE GROUP -n openshift-logging Where ROLE/CLUSTER_ROLE is the role granting user delete permission to resources in openshift-logging namespace.} |
CAT II | ||||||
| 147 | CCI-000017 | SRG-APP-000025-CTR-000065 | The container platform must automatically disable accounts after a 35-day period of account inactivity. | Red Hat OpenShift Container Platform 4 must automatically disable accounts after a 35-day period of account inactivity. | Attackers that are able to exploit an inactive account can potentially obtain and maintain undetected access to an application. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. Applications need to track periods of user inactivity and disable accounts after 35 days of inactivity. Such a process greatly reduces the risk that accounts will be hijacked, leading to a data compromise. 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. This policy does not apply to either emergency accounts or infrequently used accounts. Infrequently used accounts are local login administrator accounts used by system administrators when network or normal logon/access is not available. Emergency accounts are administrator accounts created in response to crisis situations. |
Not Applicable | Determine if the container platform automatically disables accounts after a 35-day period of account inactivity. If the container platform does not automatically disable accounts after a 35-day period of account inactivity, this is a finding. |
CAT II | Not Applicable. Applicable to Identity Management Provider and not OCP. Only configurable check is to ensure OCP is configured for an IDP under SRG-APP-000023-CTR-000055. Verify with IdM service provider admins that the IdM meets the requirements. |
||||||||
| 148 | CCI-001403 | SRG-APP-000027-CTR-000075 | The container platform must automatically audit account modification. | Red Hat OpenShift Container Platform 4 must automatically audit account modification. | Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to modify an existing account. Auditing of account creation is one method for mitigating this risk. A comprehensive account management process will ensure an audit trail documents the creation of application user accounts and, as required, notifies administrators and/or application when accounts are created. Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/auditing 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. |
Applicable - Configurable | Review the container platform configuration to determine if account modification is automatically audited. If account modification is not automatically audited, this is a finding. |
Verify for each of the files that contain account information the system is configured to emit an audit event in case of a write, by executing the following: for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'echo -n "$HOSTNAME "; for f in /etc/passwd /etc/group /etc/gshadow /etc/security/opasswd /etc/shadow /etc/sudoers /etc/sudoers.d/; do grep -q "\-w $f \-p wa \-k" /etc/audit/audit.rules || echo "rule for $f not found"; done' 2>/dev/null; done If for any of the files a line saying "rule for $filename not found" is printed, this is a finding. |
Apply the machine config using the following command: for mcpool in $(oc get mcp -oname | sed "s:.*/::" ); do echo "apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: name: 75-account-modifications-rules-$mcpool labels: machineconfiguration.openshift.io/role: $mcpool spec: config: ignition: version: 3.1.0 storage: files: - contents: source: data:,-w%20/etc/sudoers.d/%20-p%20wa%20-k%20actions%0A-w%20/etc/sudoers%20-p%20wa%20-k%20actions%0A mode: 0644 path: /etc/audit/rules.d/75-audit-sysadmin-actions.rules overwrite: true - contents: source: data:,-w%20/etc/group%20-p%20wa%20-k%20audit_rules_usergroup_modification%0A mode: 0644 path: /etc/audit/rules.d/30-etc_group_usergroup_modification.rules overwrite: true - contents: source: data:,-w%20/etc/gshadow%20-p%20wa%20-k%20audit_rules_usergroup_modification%0A mode: 0644 path: /etc/audit/rules.d/30-etc_gshadow_usergroup_modification.rules overwrite: true - contents: source: data:,-w%20/etc/security/opasswd%20-p%20wa%20-k%20audit_rules_usergroup_modification%0A mode: 0644 path: /etc/audit/rules.d/30-etc_security_opasswd_usergroup_modification.rules overwrite: true - contents: source: data:,-w%20/etc/passwd%20-p%20wa%20-k%20audit_rules_usergroup_modification%0A mode: 0644 path: /etc/audit/rules.d/30-etc_passwd_usergroup_modification.rules overwrite: true - contents: source: data:,-w%20/etc/shadow%20-p%20wa%20-k%20audit_rules_usergroup_modification%0A mode: 0644 path: /etc/audit/rules.d/30-etc_shadow_usergroup_modification.rules overwrite: true " | oc apply -f - done |
CAT II | |||||||
| 149 | CCI-002530 | SRG-APP-000431-CTR-001065 | The container platform runtime must maintain separate execution domains for each container by assigning each container a separate address space. | Red Hat OpenShift Container Platform 4 runtime must maintain separate execution domains for each container by assigning each container a separate address space. | Container namespace access is limited upon runtime execution. Each container is a distinct process so that communication between containers is performed in a manner controlled through security policies that limits the communication so one container cannot modify another container. Different groups of containers with different security needs should be deployed in separate namespaces as a first level of isolation. Namespaces are a key boundary for network policies, orchestrator access control restrictions, and other important security controls. Separating workloads into namespaces can help contain attacks and limit the impact of mistakes or destructive actions by authorized users. |
Applicable - Inherently Met | Review container platform runtime documentation and configuration is maintaining a separate execution domain for each executing process. Different groups of applications, and services with different security needs, should be deployed in separate namespaces as a first level of isolation. If container platform runtime is not configured to execute processes in separate domains and namespaces, this is a finding. If namespaces use defaults, this is a finding. |
CAT II | Supporting evidence is in the following documentation https://docs.openshift.com/container-platform/latest/authentication/using-rbac.html#rbac-default-projects_using-rbac https://docs.openshift.com/container-platform/latest/authentication/managing-security-context-constraints.html https://docs.openshift.com/container-platform/latest/authentication/managing-security-context-constraints.html#examining-a-security-context-constraints-object_configuring-internal-oauth |
The control is met because SELinux and namespaces are enabled by default. https://docs.openshift.com/container-platform/latest/authentication/using-rbac.html#rbac-default-projects_using-rbac https://docs.openshift.com/container-platform/latest/authentication/managing-security-context-constraints.html https://docs.openshift.com/container-platform/latest/authentication/managing-security-context-constraints.html#examining-a-security-context-constraints-object_configuring-internal-oauth - OpenShift comes with a number of default projects, and projects starting with `openshift-` are considered essential to users. Resources in OpenShift should be segregated by project, to allow for security controls to be applied at that level and to make it easier to manage resources. Review projects to ensure that only system managed resources belong in default projects. oc project < project-name > && oc get all - By default, OpenShift also sets a SCC for all authenticated users. Specifically, it sets the restricted SCC by default, which denies access to all host features and requires pods to be run with a UID and SELinux context that are allocated to the project. To get all SCC's: oc get scc To describe an SCC, including which users, service accounts, and groups SCC is applied to: oc describe scc <scc-name> |
|||||||
| 150 | CCI-000172 | SRG-OS-000458-GPOS-00203,SRG-OS-000474-GPOS-00219,SRG-OS-000475-GPOS-00220,SRG-OS-000463-GPOS-00207,SRG-OS-000465-GPOS-00209,SRG-OS-000461-GPOS-00205,SRG-OS-000468-GPOS-00212,SRG-APP-000501-CTR-001265,SRG-APP-000502-CTR-001270 | The container platform must generate audit records when successful/unsuccessful attempts to delete security objects occur. | Unauthorized users modify level the security levels to exploit vulnerabilities within the container platform component. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible. Without audit record generation, unauthorized users can access delete security objects unknowingly for malicious intent creating vulnerabilities within the container platform. |
Applicable - Configurable | Review the container platform configuration to determine if audit records are generated on successful/unsuccessful attempts to delete security objects occur. If audit records are not generated, this is a finding. |
CAT II | ||||||||||
| 151 | CCI-000172,CCI-002884 | SRG-OS-000064-GPOS-00033,SRG-OS-000392-GPOS-00172,SRG-OS-000458-GPOS-00203,SRG-OS-000461-GPOS-00205,SRG-OS-000468-GPOS-00212,SRG-APP-000501-CTR-001265,SRG-APP-000502-CTR-001270 | The container platform must generate audit records when successful/unsuccessful attempts to delete security objects occur. | Unauthorized users modify level the security levels to exploit vulnerabilities within the container platform component. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible. Without audit record generation, unauthorized users can access delete security objects unknowingly for malicious intent creating vulnerabilities within the container platform. |
Applicable - Configurable | Review the container platform configuration to determine if audit records are generated on successful/unsuccessful attempts to delete security objects occur. If audit records are not generated, this is a finding. |
CAT II | ||||||||||
| 152 | CCI-000172,CCI-002884 | SRG-OS-000064-GPOS-00033,SRG-OS-000392-GPOS-00172,SRG-OS-000458-GPOS-00203,SRG-OS-000461-GPOS-00205,SRG-OS-000468-GPOS-00212,SRG-APP-000501-CTR-001265,SRG-APP-000502-CTR-001270 | The container platform must generate audit records when successful/unsuccessful attempts to delete security objects occur. | Unauthorized users modify level the security levels to exploit vulnerabilities within the container platform component. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible. Without audit record generation, unauthorized users can access delete security objects unknowingly for malicious intent creating vulnerabilities within the container platform. |
Applicable - Configurable | Review the container platform configuration to determine if audit records are generated on successful/unsuccessful attempts to delete security objects occur. If audit records are not generated, this is a finding. |
CAT II | ||||||||||
| 153 | CCI-000172,CCI-002884 | SRG-OS-000064-GPOS-00033,SRG-OS-000392-GPOS-00172,SRG-OS-000458-GPOS-00203,SRG-OS-000461-GPOS-00205,SRG-OS-000468-GPOS-00212,SRG-APP-000501-CTR-001265,SRG-APP-000502-CTR-001270 | The container platform must generate audit records when successful/unsuccessful attempts to delete security objects occur. | Unauthorized users modify level the security levels to exploit vulnerabilities within the container platform component. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible. Without audit record generation, unauthorized users can access delete security objects unknowingly for malicious intent creating vulnerabilities within the container platform. |
Applicable - Configurable | Review the container platform configuration to determine if audit records are generated on successful/unsuccessful attempts to delete security objects occur. If audit records are not generated, this is a finding. |
CAT II | ||||||||||
| 154 | CCI-000172,CCI-002884 | SRG-OS-000064-GPOS-00033,SRG-OS-000392-GPOS-00172,SRG-OS-000458-GPOS-00203,SRG-OS-000461-GPOS-00205,SRG-OS-000468-GPOS-00212,SRG-APP-000501-CTR-001265,SRG-APP-000502-CTR-001270 | The container platform must generate audit records when successful/unsuccessful attempts to delete security objects occur. | Unauthorized users modify level the security levels to exploit vulnerabilities within the container platform component. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible. Without audit record generation, unauthorized users can access delete security objects unknowingly for malicious intent creating vulnerabilities within the container platform. |
Applicable - Configurable | Review the container platform configuration to determine if audit records are generated on successful/unsuccessful attempts to delete security objects occur. If audit records are not generated, this is a finding. |
CAT II | ||||||||||
| 155 | CCI-000366 | SRG-APP-000516-CTR-001335 | CCE-90613-1 | The container platform must continuously scan components, containers, and images for vulnerabilities. | Red Hat OpenShift Container Platform 4 must continuously scan components, containers, and images for vulnerabilities. | Finding vulnerabilities quickly within the container platform and within containers deployed within the platform is important to keep the overall platform secure. When a vulnerability within a component or container is unknown or allowed to remain unpatched, other containers and customers within the platform become vulnerability. The vulnerability can lead to the loss of application data, organizational infrastructure data, and denial of service (DoS) to hosted applications. Vulnerability scanning can be performed by the container platform or by external applications. |
Applicable - Configurable | Review the container platform to validate continuous vulnerability scans of components, containers, and container images are being performed. If continuous vulnerability scans are not being performed, this is a finding. |
The Container Security Operator, provided by Red Hat as a supported optional component, can be installed to continuously scan container images associated with running containers for vulnerabilities via their manifests. Other tools such as Red Hat Advanced Cluster Security (formerly StackRox) provide documentation on identifying vulnerabilities: https://help.stackrox.com/docs/manage-vulnerabilities/ For 3rd party tools, reference their documentation to configure vulnerability scanning. To check if the Container Security Operator is installed, run the following command: > oc get sub -nopenshift-operators container-security-operator -ojsonpath='{.status.installedCSV}' If this command returns an error or an empty string, and a separate tool is not being used to perform continuous vulnerability scans of components, containers, and container images, this is a finding. To check if the Container Security Operator is running, run the following command: > oc get deploy -n openshift-operators container-security-operator -ojsonpath='{.status.readyReplicas}' If this command returns an error or the number 0, and a separate tool is not being used to perform continuous vulnerability scans of components, containers, and container images, this is a finding. |
Vulnerability scanning can be performed by the Container Security Operator, Red Hat Advanced Cluster Security (formerly StackRox) or by external applications. To install the Container Security Operator into your cluster, run the following command: > oc apply -f - << 'EOF' --- apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: labels: operators.coreos.com/container-security-operator.openshift-operators: '' name: container-security-operator namespace: openshift-operators spec: channel: quay-v3.5 installPlanApproval: Automatic name: container-security-operator source: redhat-operators sourceNamespace: openshift-marketplace ... EOF |
CAT II | ||||||
| 156 | CCI-000171 | SRG-APP-000089-CTR-000150,SRG-APP-000090-CTR-000155,SRG-APP-000101-CTR-000205 | CCE-83577-7 | The container platform must allow only the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited. | The container platform must generate audit records for all DoD-defined auditable events within all components in the platform. |
Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records. |
Applicable - Configurable | Review the container platform to determine if the container platform is configured to allow only the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited. If the container platform is not configured to only allow the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited, this is a finding. |
As the cluster administrator, update the APIServer.config.openshift.io/cluster object to set the profile to the defined level of detail. For example, to configure the profile to Write Request Bodies, meaning that all write requests to any API server object are logged in their entirety, run the following command: > oc patch apiserver.config.openshift.io/cluster --type=merge \ -p '{"spec":{"audit": {"profile": "WriteRequestBodies"}}}' |
CAT II | |||||||
| 157 | CCI-001762 | SRG-APP-000383-CTR-000910 | All non-essential, unnecessary, and unsecure DoD ports, protocols, and services must be disabled in the container platform. | All non-essential, unnecessary, and unsecure DoD ports, protocols, and services must be disabled in the container platform. | To properly offer services to the user and to orchestrate containers, the container platform may offer services that use ports and protocols that best fit those services. The container platform, when offering the services, must only offer the services on ports and protocols authorized by the DoD. To validate that the services are using only the approved ports and protocols, the organization must perform a periodic scan/review of the container platform and disable functions, ports, protocols, and services deemed to be unneeded or non-secure. |
Applicable - Inherently Met | Review the container platform configuration to determine if services or capabilities presently on the information system are required for operational or mission needs. If additional services or capabilities are present on the system, this is a finding. |
CAT II | Supporting evidence is in the following documentation https://docs.openshift.com/container-platform/latest/installing/installing_bare_metal/installing-bare-metal.html#installation-network-user-infra_installing-bare-metal |
The container platform inherently only exposes the ports which are needed and adhere to DoD standards. By default all communications use two-way TLS. A full list is available here: https://docs.openshift.com/container-platform/latest/installing/installing_bare_metal/installing-bare-metal.html#installation-network-user-infra_installing-bare-metal |
|||||||
| 158 | CCI-000366 | SRG-APP-000516-CTR-001330 | The container platform must be able to store and instantiate industry standard container images. | Red Hat OpenShift Container Platform 4 must be able to store and instantiate industry standard container images. | Monitoring the container images and containers during their lifecycle is important to guarantee the container platform is secure. To monitor the containers and images, security tools can be put in place. To fully utilize the security tools available, using images formatted in an industry standard format should be used. This allows the tools to fully understand the images and containers. One standard being worked on by industry leaders in the container space is the Open Container Initiative (OCI). This group is developing a standard container image format. | Applicable - Inherently Met | Review the container platform configuration and documentation to determine if the platform is configured to store and instantiate industry standard container images. If the container platform cannot instantiate industry standard container images, this is a finding. |
CAT II | Supporting evidence is in the following documentation https://docs.openshift.com/container-platform/latest/architecture/architecture.html |
Red Hat OpenShift leverages CRI-O as its runtime which was designed as a container engine specifically to work with Kubernetes and can run the legacy Docker container format as well as the newer industry standard OCI container image format | |||||||
| 159 | CCI-002385 | SRG-APP-000246-CTR-000605,SRG-APP-000435-CTR-001070 | CCE-90734-5 | The container platform must protect against or limit the effects of all types of denial-of-service (DoS) attacks by employing organization-defined security safeguards. | Red Hat OpenShift Container Platform 4 must restrict individuals the ability to launch organizational-defined Denial-of-Service (DOS) attacks against other information systems. | DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity. This requirement addresses the configuration of the container platform to mitigate the impact of DoS attacks that have occurred. For each container platform component, known and potential DoS attacks must be identified and solutions for each type implemented. A variety of technologies exist to limit or, in some cases, eliminate the effects of DoS attacks (e.g., limiting runtime processes or restricting the number of sessions the container platform runtime open, limiting container resources to memory and CPU). Processes are an important indicator of security-and operations-relevant container activity. Process names and their arguments provide important visibility into a container’s activity. If an image includes non-default aliases or renamed binaries, attackers will still attempt to use well-known names. The same malicious or unwanted activity might affect multiple deployments across different applications or environments. Staff investigating a potential incident need to find those exposures quickly. |
Applicable - Configurable | Review documentation and configuration to determine if the container platform can protect against or limit the effects of all types of DoS attacks by employing defined security safeguards against resource depletion. Examples of resource limits are on memory, storage, and CPU. If the container platform cannot be configured to protect against or limit the effects of all types of DoS, this is a finding. |
Configure a default resource quota as necessary to protect resource over utilization by performing the following steps. 1. Create a bootstrap project template > oc adm create-bootstrap-project-template -o yaml > template.yaml 2. Edit the template and add a ResourceQuota object definition before the parameters section - apiVersion: v1 kind: ResourceQuota metadata: name: example spec: hard: persistentvolumeclaims: "10" requests.storage: "50Gi" ... parameters: 3. Apply the project template to the cluster > oc create -f template.yaml -n openshift-config 4. Set the default cluster project request template > oc patch project.config.openshift.io/cluster --type=merge -p '{"spec":{"projectRequestTemplate":{"name": " "}}}' Details regarding the configuration of resource quotas can be reviewed at the below documentation. https://docs.openshift.com/container-platform/latest/applications/quotas/quotas-setting-per-project.html |
CAT II | |||||||
| 160 | CCI-002385 | SRG-APP-000246-CTR-000605,SRG-APP-000435-CTR-001070,SRG-APP-000450-CTR-001105 | CCE-90582-8 | The container platform must protect against or limit the effects of all types of denial-of-service (DoS) attacks by employing organization-defined security safeguards. | Red Hat OpenShift Container Platform 4 must restrict individuals the ability to launch organizational-defined Denial-of-Service (DOS) attacks against other information systems. | DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity. This requirement addresses the configuration of the container platform to mitigate the impact of DoS attacks that have occurred. For each container platform component, known and potential DoS attacks must be identified and solutions for each type implemented. A variety of technologies exist to limit or, in some cases, eliminate the effects of DoS attacks (e.g., limiting runtime processes or restricting the number of sessions the container platform runtime open, limiting container resources to memory and CPU). Processes are an important indicator of security-and operations-relevant container activity. Process names and their arguments provide important visibility into a container’s activity. If an image includes non-default aliases or renamed binaries, attackers will still attempt to use well-known names. The same malicious or unwanted activity might affect multiple deployments across different applications or environments. Staff investigating a potential incident need to find those exposures quickly. |
Applicable - Configurable | Review documentation and configuration to determine if the container platform can protect against or limit the effects of all types of DoS attacks by employing defined security safeguards against resource depletion. Examples of resource limits are on memory, storage, and CPU. If the container platform cannot be configured to protect against or limit the effects of all types of DoS, this is a finding. |
Add a resource quota to an existing project namespace by performing the following steps: 1. Create a quota.yml file with the ResourceQuota object definition, and edit the file with the desired resource quota content. The following is an example resource quota definition. apiVersion: v1 kind: ResourceQuota metadata: name: compute-resources spec: hard: pods: "4" requests.cpu: "1" requests.memory: 1Gi requests.ephemeral-storage: 2Gi limits.cpu: "2" limits.memory: 2Gi limits.ephemeral-storage: 4Gi 2. Apply the ResourceQuota definition to the project namespace > oc apply -f quota.yml -n Details regarding the configuration of resource quotas can be reviewed at the below documentation. https://docs.openshift.com/container-platform/latest/applications/quotas/quotas-setting-per-project.html |
CAT II | |||||||
| 161 | CCI-002385 | SRG-APP-000246-CTR-000605,SRG-APP-000435-CTR-001070 | CCE-90779-0 | The container platform must protect against or limit the effects of all types of denial-of-service (DoS) attacks by employing organization-defined security safeguards. | The container platform must protect against or limit the effects of all types of Denial-of-Service (DoS) attacks by employing organization-defined security safeguards. | DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity. This requirement addresses the configuration of the container platform to mitigate the impact of DoS attacks that have occurred. For each container platform component, known and potential DoS attacks must be identified and solutions for each type implemented. A variety of technologies exist to limit or, in some cases, eliminate the effects of DoS attacks (e.g., limiting runtime processes or restricting the number of sessions the container platform runtime open, limiting container resources to memory and CPU). Processes are an important indicator of security-and operations-relevant container activity. Process names and their arguments provide important visibility into a container’s activity. If an image includes non-default aliases or renamed binaries, attackers will still attempt to use well-known names. The same malicious or unwanted activity might affect multiple deployments across different applications or environments. Staff investigating a potential incident need to find those exposures quickly. |
Applicable - Configurable | Review documentation and configuration to determine if the container platform can protect against or limit the effects of all types of DoS attacks by employing defined security safeguards against resource depletion. Examples of resource limits are on memory, storage, and CPU. If the container platform cannot be configured to protect against or limit the effects of all types of DoS, this is a finding. |
Add the haproxy.router.openshift.io/rate-limit-connections annotation to any routes outside the kube-* or openshift-* namespaces | CAT II | |||||||
| 162 | CCI-000764 | SRG-APP-000148-CTR-000345 | The container platform must uniquely identify and authenticate processes acting on behalf of the users. | Red Hat OpenShift Container Platform 4 must uniquely identify and authenticate processes acting on behalf of the users. | The container platform will instantiate a container image and use the user privileges given to the user used to execute the container. To ensure accountability and prevent unauthenticated access to containers, the user the container is using to execute must be uniquely identified and authenticated to prevent potential misuse and compromise of the system. | Applicable - Inherently Met | Review the container platform configuration to determine if processes acting on behalf of users are uniquely identified and authenticated. If processes acting on behalf of users are not uniquely identified or are not authenticated, this is a finding. |
CAT II | Supporting evidence is in the following documentation: https://cloud.redhat.com/blog/a-guide-to-openshift-and-uids |
OpenShift does not execute containers with a user's account, as users of OpenShift do not have accounts on the host operating system. Pods are executed using UIDs that do not exist on the system and have no privileges on the host system at all. It is deliberately isolated further per logical namespace to allow for a mapping of UIDs to applications within the context of the API, without allowing for UID collision across logical namespaces. For more background information, see: https://cloud.redhat.com/blog/a-guide-to-openshift-and-uids |
|||||||
| 163 | CCI-002476 | SRG-APP-000429-CTR-001060 | CCE-83585-0 | The container platform keystore must implement encryption to prevent unauthorized disclosure of information at rest within the container platform. | TheRed Hat OpenShift Container Platform 4 keystore must implement encryption to prevent unauthorized disclosure of information at rest within the container platform. | Container platform keystore is used for container deployments for persistent storage of all its REST API objects. These objects are sensitive in nature and should be encrypted at rest to avoid any unauthorized disclosure. Selection of a cryptographic mechanism is based on the need to protect the confidentiality of organizational information. The strength of mechanism is commensurate with the security category and/or classification of the information. | Applicable - Configurable | Review container platform keystore documentation and configuration to verify encryption levels meet the information sensitivity level. If the container platform keystore encryption configuration does not meet system requirements, this is a finding. |
Review the api server encryption by running the following commands: > oc edit apiserver EXAMPLE OUTPUT spec: encryption: type: aescbc If the encryption type is not aescbc then this is a finding. |
Run the following command: > oc edit apiserver Set the encryption field type to aescbc: spec: encryption: type: aescbc Additional details about the configuration can be found in the documentation: https://docs.openshift.com/container-platform/latest/security/encrypting-etcd.html |
CAT II | ||||||
| 164 | CCI-000163,CCI-000164,CCI-000162 | SRG-OS-000057-GPOS-00027,SRG-OS-000058-GPOS-00028,SRG-OS-000059-GPOS-00029,SRG-APP-000119-CTR-000245,SRG-APP-000120-CTR-000250 | The container platform must protect audit information from unauthorized deletion. | Red Hat OpenShift Container Platform 4 audit system must protect auditing rules from unauthorized change. | If audit data were to become compromised, then forensic analysis and discovery of the true source of potentially malicious system activity would be impossible to achieve. To ensure the veracity of audit data, the information system and/or the application must protect audit information from unauthorized deletion. This requirement can be achieved through multiple methods, which will depend upon system architecture and design. Some commonly employed methods include: ensuring log files receive the proper file system permissions utilizing file system protections, restricting access, and backing up log data to ensure log data is retained. Applications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights the user enjoys in order make access decisions regarding the deletion of audit data. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. Audit information may include data from other applications or be included with the audit application itself. |
Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit Red Hat OpenShift Container Platform 4 system activity. In immutable mode, unauthorized users cannot execute changes to the audit system to potentially hide malicious activity and then put the audit rules back. A system reboot would be noticeable, and a system administrator could then investigate the unauthorized changes. |
Applicable - Configurable | Review the container platform configuration to determine where audit information is stored. If the audit log data is not protected from unauthorized deletion, this is a finding. |
Verify the audit system prevents unauthorized changes with the following command: $ sudo grep "^\s*[^#]" /etc/audit/audit.rules | tail -1 -e 2 If the audit system is not set to be immutable by adding the "-e 2" option to the end of "/etc/audit/audit.rules", this is a finding. |
Configure the audit system to set the audit rules to be immutable by adding the following line to end of "/etc/audit/rules.d/audit.rules" -e 2 The audit daemon must be restarted for the changes to take effect. |
CAT II | ||||||
| 165 | CCI-000200 | SRG-APP-000165-CTR-000405 | The container platform must prohibit password reuse for a minimum of 10 generations. | Red Hat OpenShift Container Platform 4 must prohibit password reuse for a minimum of 10 generations. | Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. To meet password policy requirements, passwords need to be changed at specific policy-based intervals. If the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the result is a password that is not changed as per policy requirements. The references for this check are: NIST SP 800-53 :: IA-5 (1) (e) NIST SP 800-53A :: IA-5 (1).1 (v) NIST SP 800-53 Revision 4 :: IA-5 (1) CNSS 1253 |
Not Applicable | Review the container platform configuration to determine if it prohibits password reuse for a minimum of five generations. If the container platform does not prohibit password reuse for a minimum of five generations, this is a finding. |
CAT II | Not Applicable. Applicable to Identity Management Provider and not OCP. Only configurable check is to ensure OCP is configured for an IDP under SRG-APP-000023-CTR-000055. Verify with IdM service provider admins that the IdM meets the requirements. |
||||||||
| 166 | CCI-001942 | SRG-APP-000157-CTR-000385 | The container platform must implement replay-resistant authentication mechanisms for network access to non-privileged accounts. | Red Hat OpenShift Container Platform 4 must implement replay-resistant authentication mechanisms for network access to non-privileged accounts. | A replay attack may enable an unauthorized user to gain access to the application. Authentication sessions between the authenticator and the application validating the user credentials must not be vulnerable to a replay attack. An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. A non-privileged account is any operating system account with authorizations of a non-privileged user. Techniques used to address this include protocols using nonces (e.g., numbers generated for a specific one-time use) or challenges (e.g., TLS, WS_Security). Additional techniques include time-synchronous or challenge-response one-time authenticators. |
Not Applicable | Review the container platform configuration to determine if the container platform is configured to provide replay-resistant authentication mechanisms for network access to non-privileged accounts. If the container platform is not configured to provide replay-resistant authentication mechanisms for network access to non-privileged accounts, this is a finding. |
CAT II | Not Applicable. Applicable to Identity Management Provider and not OCP. Only configurable check is to ensure OCP is configured for an IDP under SRG-APP-000023-CTR-000055. Verify with IdM service provider admins that the IdM meets the requirements. |
||||||||
| 167 | CCI-002617 | SRG-APP-000454-CTR-001110,SRG-APP-000454-CTR-001115 | CCE-86480-1 | The container platform must remove old components after updated versions have been installed. | The container platform registry must remove old container images after updating versions have been made available. | Previous versions of container platform components that are not removed from the container platform after updates have been installed may be exploited by adversaries by causing older components to execute which contain vulnerabilities. When these components are deleted, the likelihood of this happening is removed. | Applicable - Configurable | Review container platform registry documentation and configuration to determine if organization-defined images contains latest approved vendor software image version. If organization-defined images do not contain the latest approved vendor software image version, this is a finding. Review container platform registry documentation and configuration to determine if organization-defined images are removed after updated versions have been installed. If organization-defined images are not removed after updated versions have been installed, this is a finding. Review container platform runtime documentation and configuration to determine if organization-define images are executing latest image version from the container platform registry. If container platform runtime is not executing latest organization-defined images from the container platform registry, this is a finding. |
Ensure that the imagepruner is configured and is not in a suspended state. > oc get imagepruners.imageregistry.operator.openshift.io/cluster -o jsonpath='{.spec}{" "}' Review the settings and if suspend is set to true, this is a finding. |
Enable the image pruner automate the pruning of images from the cluster. > oc patch imagepruners.imageregistry.operator.openshift.io/cluster --type=merge -p '{"spec":{"suspend":false}}' For additional details on configuring the image pruner operator see the following document https://docs.openshift.com/container-platform/latest/applications/pruning-objects.html#pruning-images_pruning-objects |
CAT II | ||||||
| 168 | CCI-001941 | SRG-APP-000023-CTR-000055 | CCE-84088-4 | The container platform must use FIPS-validated SHA-1 or higher hash function to provide replay-resistant authentication mechanisms for network access to privileged accounts. | Red Hat OpenShift Container Platform 4 must use a centralized user management solution to support account management functions. |
A replay attack may enable an unauthorized user to gain access to the application. Authentication sessions between the authenticator and the application validating the user credentials must not be vulnerable to a replay attack. Anti-replay is a cryptographically based mechanism; thus, it must use FIPS-approved algorithms. An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. Note that the anti-replay service is implicit when data contains monotonically increasing sequence numbers and data integrity is assured. Use of DoD PKI is inherently compliant with this requirement for user and device access. Use of Transport Layer Security (TLS), including application protocols such as HTTPS and DNSSEC, that use TLS/SSL as the underlying security protocol is also compliant. Configure the information system to use the hash message authentication code (HMAC) algorithm for authentication services to Kerberos, SSH, web management tool, and any other access method. |
OpenShift supports several different types of identity providers. In order to add users and grant access to OpenShift, an identity provider needs to be configured. Some of the identity provider types, such as HTPassword, only provide simple user management and are not intended for production. Other types are public services, like GitHub. These provider types may not be appropriate as they are managed by public service providers and therefore are unable to enforce the organizations account management requirements. After a new install, the default authentication uses kubeadmin as the default cluster-admin account. This default account needs to be disabled, and another user account should be given cluster-admin rights. |
Applicable - Configurable | Review the container platform configuration to determine if the container platform is configured to use FIPS-validated SHA-1 or higher hash function to provide replay-resistant authentication mechanisms for network access to privileged accounts. If the container platform is not configured to use FIPS-validated SHA-1 or higher hash function to provide replay-resistant authentication mechanisms for network access to privileged accounts, this is a finding. |
Verify that the authentication operator is configure to use either an LDAP or a OpenIDConnect or an approved identity provider: > oc get oauth cluster -o jsonpath="{.spec.identityProviders[*].type}{' '}" If the output doesn't list an IdP, this is a finding. |
Configure OpenShift to use an appropriate Identity Provider. Do not use HTPasswd. Use either LDAP(AD), OpenIDConnect or an approved identity provider. Steps to configure LDAP provider: 1. Create Secret for BIND DN password > oc create secret generic ldap-secret --from-literal=bindPassword= \ -n openshift-config 2. Create config map for LDAP Trust CA > oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n \ openshift-config 3. Create LDAP Auth Config Resource YAML Using your preferred text editor, create a file named ldapidp.yaml using the example content (replacing config values as appropriate): apiVersion: config.openshift.io/v1 kind: OAuth metadata: name: cluster spec: identityProviders: - name: ldapidp mappingMethod: claim type: LDAP ldap: attributes: id: - dn email: name: - cn preferredUsername: - uid bindDN: "" bindPassword: name: ldap-secret ca: name: ca-config-map insecure: false url: "ldaps://ldap.example.com/ou=users,dc=acme,dc=com?uid" 4. Apply LDAP config to cluster > oc apply -f ldapidp.yaml For more information on configuring an LDAP provider refer to the documentation: https://docs.openshift.com/container-platform/4.8/authentication/identity_providers/configuring-ldap-identity-provider.html Steps to configure OpenID provider: 1. Create Secret for Client Secret > oc create secret generic \ --from-literal=clientSecret= -n openshift-config 2. Create config map for OpenID Trust CA > oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca \ -n openshift-config 3. Create OpenID Auth Config Resource YAML Using your preferred text editor, create a file named oidcidp.yaml using the example content (replacing config values as appropriate): apiVersion: config.openshift.io/v1 kind: OAuth metadata: name: cluster spec: identityProviders: - name: ldapidp mappingMethod: claim type: LDAP ldap: attributes: id: - dn email: name: - cn preferredUsername: - uid bindDN: "" bindPassword: name: ldap-secret ca: name: ca-config-map insecure: false url: "ldaps://ldap.example.com/ou=users,dc=acme,dc=com?uid" 4. Apply OpenID config to cluster > oc apply -f ldapidp.yaml For more information on configuring an OpenID provider refer to the documentation: https://docs.openshift.com/container-platform/latest/authentication/identity_providers/configuring-oidc-identity-provider.html |
CAT II | |||||
| 169 | CCI-001941 | SRG-APP-000023-CTR-000055 | CCE-84209-6 | The container platform must use FIPS-validated SHA-1 or higher hash function to provide replay-resistant authentication mechanisms for network access to privileged accounts. | Red Hat OpenShift Container Platform 4 must use a centralized user management solution to support account management functions. |
A replay attack may enable an unauthorized user to gain access to the application. Authentication sessions between the authenticator and the application validating the user credentials must not be vulnerable to a replay attack. Anti-replay is a cryptographically based mechanism; thus, it must use FIPS-approved algorithms. An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. Note that the anti-replay service is implicit when data contains monotonically increasing sequence numbers and data integrity is assured. Use of DoD PKI is inherently compliant with this requirement for user and device access. Use of Transport Layer Security (TLS), including application protocols such as HTTPS and DNSSEC, that use TLS/SSL as the underlying security protocol is also compliant. Configure the information system to use the hash message authentication code (HMAC) algorithm for authentication services to Kerberos, SSH, web management tool, and any other access method. |
OpenShift supports several different types of identity providers. In order to add users and grant access to OpenShift, an identity provider needs to be configured. Some of the identity provider types, such as HTPassword, only provide simple user management and are not intended for production. Other types are public services, like GitHub. These provider types may not be appropriate as they are managed by public service providers and therefore are unable to enforce the organizations account management requirements. After a new install, the default authentication uses kubeadmin as the default cluster-admin account. This default account needs to be disabled, and another user account should be given cluster-admin rights. |
Applicable - Configurable | Review the container platform configuration to determine if the container platform is configured to use FIPS-validated SHA-1 or higher hash function to provide replay-resistant authentication mechanisms for network access to privileged accounts. If the container platform is not configured to use FIPS-validated SHA-1 or higher hash function to provide replay-resistant authentication mechanisms for network access to privileged accounts, this is a finding. |
Run the following command to list the identity providers configured: > oc get oauth cluster -o jsonpath="{.spec.identityProviders[*].type}{' '}" If any of the IDP providers' type is HTPasswd, this is a finding. |
Configure OpenShift to use an appropriate Identity Provider. Do not use HTPasswd. Use either LDAP(AD), OpenIDConnect or an approved identity provider. Steps to configure LDAP provider: 1. Create Secret for BIND DN password > oc create secret generic ldap-secret --from-literal=bindPassword= \ -n openshift-config 2. Create config map for LDAP Trust CA > oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n \ openshift-config 3. Create LDAP Auth Config Resource YAML Using your preferred text editor, create a file named ldapidp.yaml using the example content (replacing config values as appropriate): apiVersion: config.openshift.io/v1 kind: OAuth metadata: name: cluster spec: identityProviders: - name: ldapidp mappingMethod: claim type: LDAP ldap: attributes: id: - dn email: name: - cn preferredUsername: - uid bindDN: "" bindPassword: name: ldap-secret ca: name: ca-config-map insecure: false url: "ldaps://ldap.example.com/ou=users,dc=acme,dc=com?uid" 4. Apply LDAP config to cluster > oc apply -f ldapidp.yaml For more information on configuring an LDAP provider refer to the documentation: https://docs.openshift.com/container-platform/4.8/authentication/identity_providers/configuring-ldap-identity-provider.html Steps to configure OpenID provider: 1. Create Secret for Client Secret > oc create secret generic \ --from-literal=clientSecret= -n openshift-config 2. Create config map for OpenID Trust CA > oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca \ -n openshift-config 3. Create OpenID Auth Config Resource YAML Using your preferred text editor, create a file named oidcidp.yaml using the example content (replacing config values as appropriate): apiVersion: config.openshift.io/v1 kind: OAuth metadata: name: cluster spec: identityProviders: - name: ldapidp mappingMethod: claim type: LDAP ldap: attributes: id: - dn email: name: - cn preferredUsername: - uid bindDN: "" bindPassword: name: ldap-secret ca: name: ca-config-map insecure: false url: "ldaps://ldap.example.com/ou=users,dc=acme,dc=com?uid" 4. Apply OpenID config to cluster > oc apply -f ldapidp.yaml For more information on configuring an OpenID provider refer to the documentation: https://docs.openshift.com/container-platform/4.8/authentication/identity_providers/configuring-oidc-identity-provider.html |
CAT II | |||||
| 170 | CCI-001941 | SRG-APP-000023-CTR-000055 | CCE-90387-2 | The container platform must use FIPS-validated SHA-1 or higher hash function to provide replay-resistant authentication mechanisms for network access to privileged accounts. | Red Hat OpenShift Container Platform 4 must use a centralized user management solution to support account management functions. |
A replay attack may enable an unauthorized user to gain access to the application. Authentication sessions between the authenticator and the application validating the user credentials must not be vulnerable to a replay attack. Anti-replay is a cryptographically based mechanism; thus, it must use FIPS-approved algorithms. An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. Note that the anti-replay service is implicit when data contains monotonically increasing sequence numbers and data integrity is assured. Use of DoD PKI is inherently compliant with this requirement for user and device access. Use of Transport Layer Security (TLS), including application protocols such as HTTPS and DNSSEC, that use TLS/SSL as the underlying security protocol is also compliant. Configure the information system to use the hash message authentication code (HMAC) algorithm for authentication services to Kerberos, SSH, web management tool, and any other access method. |
OpenShift supports several different types of identity providers. In order to add users and grant access to OpenShift, an identity provider needs to be configured. Some of the identity provider types, such as HTPassword, only provide simple user management and are not intended for production. Other types are public services, like GitHub. These provider types may not be appropriate as they are managed by public service providers and therefore are unable to enforce the organizations account management requirements. After a new install, the default authentication uses kubeadmin as the default cluster-admin account. This default account needs to be disabled, and another user account should be given cluster-admin rights. |
Applicable - Configurable | Review the container platform configuration to determine if the container platform is configured to use FIPS-validated SHA-1 or higher hash function to provide replay-resistant authentication mechanisms for network access to privileged accounts. If the container platform is not configured to use FIPS-validated SHA-1 or higher hash function to provide replay-resistant authentication mechanisms for network access to privileged accounts, this is a finding. |
Verify that the kubeadmin account is disabled > oc get secrets kubeadmin -n kube-system If the command returns an error that the secret was not found, this is not a finding. If the command returns a listing that includes the kubeadmin secret, its type, the data count, and age, this is a finding. |
> oc delete secrets kubeadmin -n kube-system | CAT II | |||||
| 171 | CCI-000765 | SRG-APP-000149-CTR-000355 | The container platform must use multifactor authentication for network access to privileged accounts. | Red Hat OpenShift Container Platform 4 must use multifactor authentication for network access to privileged accounts. | Without the use of multifactor authentication, the ease of access to privileged functions is greatly increased. Multifactor authentication requires using two or more factors to achieve authentication. Factors include: (i) something a user knows (e.g., password/PIN); (ii) something a user has (e.g., cryptographic identification device, token); or (iii) something a user is (e.g., biometric). A privileged account is defined as an information system account with authorizations of a privileged user. Network access is defined as access to an information system by a user (or a process acting on behalf of a user) communicating through a network (e.g., local area network, wide area network, or the internet). |
Not Applicable | Review the container platform configuration to determine if the container platform is configured to use multifactor authentication for network access to privileged accounts. If the container platform does not use multifactor authentication for network access to privileged accounts, this is a finding. |
CAT II | Not Applicable. Applicable to Identity Management Provider and not OCP. Only configurable check is to ensure OCP is configured for an IDP under SRG-APP-000023-CTR-000055. Verify with IdM service provider admins that the IdM meets the requirements. |
||||||||
| 172 | CCI-001067 | SRG-APP-000414-CTR-001010 | Vulnerability scanning applications must implement privileged access authorization to all container platform components, containers, and container images for selected organization-defined vulnerability scanning activities. | Vulnerability scanning applications must implement privileged access authorization to all container platform components, containers, and container images for selected organization-defined vulnerability scanning activities. | In certain situations, the nature of the vulnerability scanning may be more intrusive, or the container platform component that is the subject of the scanning may contain highly sensitive information. Privileged access authorization to selected system components facilitates more thorough vulnerability scanning and protects the sensitive nature of such scanning. The vulnerability scanning application must utilize privileged access authorization for the scanning account. |
Applicable - Configurable | Validate that scanning applications have privileged access to container platform components, containers, and container images to properly perform vulnerability scans. If privileged access is not given to the scanning application, this is a finding. |
Identify the service accounts used by the vulnerability scanning tools. If the tool runs as a container on the platform, then service account information can be found in the the pod details. > oc get pod <POD_ID> -o jsonpath='{.spec.serviceAccount}{" "}' View cluster role bindings to determine which role the service account is bound to. > oc get clusterrolebinding -ojson | jq '.items[]|select(.subjects[]?|select(.kind == "ServiceAccount" and .name == "<SA_NAME>"))|{ "crb": .metadata.name, "roleRef": .roleRef, "subjects": .subjects}' Find the role to which the service account is bound, if the service account is not bound to a cluster role, or the role does not provide sufficient access, this is a finding. If no service account exists for the vulnerabilty scanning toll, this is also a finding. |
Create a service if one does not already exist in the appropriate namespace. > oc create serviceaccount <NAME> Bind to the appropriate cluster RBAC role > oc adm policy add-cluster-role-to-user <ROLE> -z <NAME> For more information see the following guides: https://docs.openshift.com/container-platform/latest/authentication/using-rbac.html https://docs.openshift.com/container-platform/latest/authentication/understanding-and-creating-service-accounts.html https://docs.openshift.com/container-platform/latest/authentication/using-service-accounts-in-applications.html |
CAT II | |||||||
| 173 | CCI-001889 | SRG-APP-000375-CTR-000870 | The container platform must record time stamps for audit records that meet a granularity of one second for a minimum degree of precision. | Red Hat OpenShift Container Platform 4 must record time stamps for audit records that meet a granularity of one second for a minimum degree of precision. | To properly investigate an event, it is important to have enough granularity within the time stamps to determine the chronological order of the audited events. Without this granularity, events may be interpreted out of proper sequence, thus hobbling the investigation or causing the investigation to come to inaccurate conclusions. Time stamps generated by the container platform include date and time. Granularity of time measurements refers to the degree of synchronization between information system clocks and reference clocks. |
Applicable - Inherently Met | Review the container platform documentation and configuration files to determine if time stamps for log records meet a granularity of one second. If the time stamp cannot generate to a one-second granularity, this is a finding. |
CAT II | Supporting evidence is in the following documentation https://docs.openshift.com/container-platform/latest/security/audit-log-view.html |
Openshift Container Platform conforms to DoD/DISA requirements regarding audit log fields. | |||||||
| 174 | CCI-000050 | SRG-APP-000069-CTR-000125 | The container platform must retain the Standard Mandatory DoD Notice and Consent Banner on the screen until users acknowledge the usage and conditions and take explicit actions to log on for further access. | Red Hat OpenShift Container Platform 4 must retain the Standard Mandatory DoD Notice and Consent Banner on the screen until users acknowledge the usage and conditions and take explicit actions to log on for further access. | The banner must be acknowledged by the user prior to allowing the user access to any container platform component. This provides assurance that the user has seen the message and accepted the conditions for access. If the consent banner is not acknowledged by the user, DoD will not be in compliance with system use notifications required by law. To establish acceptance of the application usage policy, a click-through banner at application logon is required. The application must prevent further activity until the user executes a positive action to manifest agreement by clicking on a box indicating "OK". |
Applicable - Configurable | Log in to the container platform components to determine if the Standard Mandatory DoD Notice and Consent Banner remains on the screen until users acknowledge the usage and conditions and take explicit actions to log on for further access. If the Standard Mandatory DoD Notice and Consent Banner does not stay on the screen until the users acknowledge the usage and conditions, this is a finding. |
From a web browser, go to the Openshift web console to login (logout if already logged in). Verify that the DOD notice and consent banner is displayed, and that the user must select 'Ok' before proceeding to the login page. If the DOD notice and consent banner is not displayed, or does not have an 'Ok' button to acknowledge consent before proceeding, this is a finding. |
This control is resolved by resolving SRG-APP-000068-CTR-000120 | CAT III | |||||||
| 175 | CCI-000022,CCI-000032 | SRG-APP-000233-CTR-000585 | The container platform runtime must isolate security functions from non-security functions. | The container platform runtime must be configured to isolate those services used for security functions from those used for non-security functions. This separation can be performed using environment variables, labels, network segregation, and kernel groups. | Applicable - Configurable | Verify container platform runtime configuration settings to determine whether container services used for security functions are located in an isolated security function such as a separate environment variables, labels, network segregation, and kernel groups. If security-related functions are not separate, this is a finding. |
CAT II | ||||||||||
| 176 | CCI-002696 | SRG-OS-000445-GPOS-00199,SRG-APP-000233-CTR-000585 | The container platform runtime must isolate security functions from non-security functions. | Red Hat OpenShift Container Platform 4 must enable the SELinux targeted policy. | The container platform runtime must be configured to isolate those services used for security functions from those used for non-security functions. This separation can be performed using environment variables, labels, network segregation, and kernel groups. | Setting the SELinux policy to "targeted" or a more specialized policy ensures the system will confine processes that are likely to be targeted for exploitation, such as network or system services. Note: During the development or debugging of SELinux modules, it is common to temporarily place non-production systems in "permissive" mode. In such temporary cases, SELinux policies should be developed, and once work is completed, the system should be reconfigured to "targeted". |
Applicable - Configurable | Verify container platform runtime configuration settings to determine whether container services used for security functions are located in an isolated security function such as a separate environment variables, labels, network segregation, and kernel groups. If security-related functions are not separate, this is a finding. |
Verify the SELINUX on Red Hat OpenShift Container Platform 4 is using the targeted policy with the following command: $ sestatus | grep policy Loaded policy name: targeted If the loaded policy name is not "targeted", this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to use the targetd SELINUX policy. Edit the file "/etc/selinux/config" and add or modify the following line: SELINUXTYPE=targeted A reboot is required for the changes to take effect. |
CAT II | ||||||
| 177 | CCI-002696,CCI-001084 | SRG-OS-000445-GPOS-00199,SRG-OS-000134-GPOS-00068 | The container platform runtime must isolate security functions from non-security functions. | Red Hat OpenShift Container Platform 4 must use a Linux Security Module configured to enforce limits on system services. | The container platform runtime must be configured to isolate those services used for security functions from those used for non-security functions. This separation can be performed using environment variables, labels, network segregation, and kernel groups. | Without verification of the security functions, security functions may not operate correctly and the failure may go unnoticed. Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. This requirement applies to operating systems performing security function verification/testing and/or systems and environments that require this functionality. |
Applicable - Configurable | Verify container platform runtime configuration settings to determine whether container services used for security functions are located in an isolated security function such as a separate environment variables, labels, network segregation, and kernel groups. If security-related functions are not separate, this is a finding. |
Ensure that Red Hat OpenShift Container Platform 4 verifies correct operation of security functions through the use of SELinux with the following command: $ getenforce Enforcing If SELINUX is not set to "Enforcing", this is a finding. Verify that SELinux is configured to be enforcing at boot. grep "SELINUX=" /etc/selinux/config # SELINUX= can take one of these three values: # NOTE: In earlier Fedora kernel builds, SELINUX=disabled would also SELINUX=enforcing If SELINUX line is missing, commented out, or not set to "enforcing", this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to verify correct operation of security functions. Edit the file "/etc/selinux/config" and add or modify the following line: SELINUX=enforcing A reboot is required for the changes to take effect. |
CAT II | ||||||
| 178 | CCI-000381 | SRG-APP-000141-CTR-000320 | The container platform registry must contain only container images for those capabilities being offered by the container platform. | Red Hat OpenShift Container Platform 4 registry must contain only container images for those capabilities being offered by the container platform. | Allowing container images to reside within the container platform registry that are not essential to the capabilities being offered by the container platform becomes a potential security risk. By allowing these non-essential container images to exist, the possibility for accidental instantiation exists. The images may be unpatched, not supported, or offer non-approved capabilities. Those images for customer services are considered essential capabilities. | Applicable - Configurable | Review the container platform registry and the container images being stored. If container images are stored in the registry and are not being used to offer container platform capabilities, this is a finding. |
To review the container images within the container platform registry, run the following command: > oc get images Review the container platform container images to validate that only necessary container images for the functionality of the information system are present. |
Remove all container images from the container platform registry that are not being used or contain features and functions not supported by the platform. |
CAT II | |||||||
| 179 | CCI-000381 | SRG-APP-000185-CTR-000490,SRG-APP-000141-CTR-000315 | The container platform must be configured with only essential configurations. | The container platform can be built with components that are not used for the intended purpose of the organization. To limit the attack surface of the container platform, it is essential that the non-essential services are not installed. | Applicable - Configurable | Review the container platform configuration and verify that only those components needed for operation are installed. If components are installed that are not used for the intended purpose of the organization, this is a finding. |
CAT II | ||||||||||
| 180 | CCI-000778,CCI-001958,CCI-003959 | SRG-OS-000114-GPOS-00059,SRG-OS-000378-GPOS-00163,SRG-OS-000480-GPOS-00227,SRG-APP-000141-CTR-000315 | The container platform must be configured with only essential configurations. | Red Hat OpenShift Container Platform 4 must be configured to disable USB mass storage. | The container platform can be built with components that are not used for the intended purpose of the organization. To limit the attack surface of the container platform, it is essential that the non-essential services are not installed. | USB mass storage permits easy introduction of unknown devices, thereby facilitating malicious activity. | Applicable - Configurable | Review the container platform configuration and verify that only those components needed for operation are installed. If components are installed that are not used for the intended purpose of the organization, this is a finding. |
Verify that Red Hat OpenShift Container Platform 4 disables the ability to load the USB Storage kernel module with the following command: $ sudo grep -r usb-storage /etc/modprobe.conf /etc/modprobe.d/* blacklist usb-storage If the command does not return any output, or the line is commented out, and use of USB Storage is not documented with the information system security officer (ISSO) as an operational requirement, this is a finding. |
To configure the system to prevent the usb-storage kernel module from being loaded, add the following line to the file /etc/modprobe.d/usb-storage.conf (or create usb-storage.conf if it does not exist): install usb-storage /bin/false blacklist usb-storage |
CAT II | ||||||
| 181 | CCI-001958,CCI-003959 | SRG-OS-000378-GPOS-00163,SRG-APP-000141-CTR-000315 | The container platform must be configured with only essential configurations. | Red Hat OpenShift Container Platform 4 must have the USBGuard package installed. | The container platform can be built with components that are not used for the intended purpose of the organization. To limit the attack surface of the container platform, it is essential that the non-essential services are not installed. | The USBguard-daemon is the main component of the USBGuard software framework. It runs as a service in the background and enforces the USB device authorization policy for all USB devices. The policy is defined by a set of rules using a rule language described in the usbguard-rules.conf file. The policy and the authorization state of USB devices can be modified during runtime using the usbguard tool. The system administrator (SA) must work with the site information system security officer (ISSO) to determine a list of authorized peripherals and establish rules within the USBGuard software framework to allow only authorized devices. |
Applicable - Configurable | Review the container platform configuration and verify that only those components needed for operation are installed. If components are installed that are not used for the intended purpose of the organization, this is a finding. |
Verify USBGuard is installed on the operating system with the following command: $ sudo dnf list installed usbguard Example output: Installed Packages usbguard.x86_64 1.0.0-10.el9_1.2 @rhel-9-for-x86_64-appstream-rpms If the USBGuard package is not installed, ask the SA to indicate how unauthorized peripherals are being blocked. If there is no evidence that unauthorized peripherals are being blocked before establishing a connection, this is a finding. |
Install the usbguard package with the following command: $ sudo dnf install usbguard |
CAT II | ||||||
| 182 | CCI-001958,CCI-003959 | SRG-OS-000378-GPOS-00163,SRG-APP-000141-CTR-000315 | The container platform must be configured with only essential configurations. | Red Hat OpenShift Container Platform 4 must have the USBGuard package enabled. | The container platform can be built with components that are not used for the intended purpose of the organization. To limit the attack surface of the container platform, it is essential that the non-essential services are not installed. | The USBguard-daemon is the main component of the USBGuard software framework. It runs as a service in the background and enforces the USB device authorization policy for all USB devices. The policy is defined by a set of rules using a rule language described in the usbguard-rules.conf file. The policy and the authorization state of USB devices can be modified during runtime using the usbguard tool. The system administrator (SA) must work with the site information system security officer (ISSO) to determine a list of authorized peripherals and establish rules within the USBGuard software framework to allow only authorized devices. |
Applicable - Configurable | Review the container platform configuration and verify that only those components needed for operation are installed. If components are installed that are not used for the intended purpose of the organization, this is a finding. |
Verify Red Hat OpenShift Container Platform 4 has USBGuard enabled with the following command: $ systemctl is-active usbguard active If usbguard is not active, ask the SA to indicate how unauthorized peripherals are being blocked. If there is no evidence that unauthorized peripherals are being blocked before establishing a connection, this is a finding. |
To enable the USBGuard service run the following command: $ sudo systemctl enable --now usbguard |
CAT II | ||||||
| 183 | CCI-000169 | SRG-OS-000062-GPOS-00031,SRG-OS-000471-GPOS-00215,SRG-APP-000141-CTR-000315 | The container platform must be configured with only essential configurations. | Red Hat OpenShift Container Platform 4 must enable Linux audit logging for the USBGuard daemon. | The container platform can be built with components that are not used for the intended purpose of the organization. To limit the attack surface of the container platform, it is essential that the non-essential services are not installed. | Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. If auditing is enabled late in the startup process, the actions of some startup processes may not be audited. Some audit systems also maintain state information only available if auditing is enabled before a given process is created. Audit records can be generated from various components within the information system (e.g., module or policy filter). The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records. DOD has defined the list of events for which Red Hat OpenShift Container Platform 4 will provide an audit record generation capability as the following: 1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); 2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; 3) All account creations, modifications, disabling, and terminations; and 4) All kernel module load, unload, and restart actions. |
Applicable - Configurable | Review the container platform configuration and verify that only those components needed for operation are installed. If components are installed that are not used for the intended purpose of the organization, this is a finding. |
To verify that Linux Audit logging is enabled for the USBGuard daemon with the following command: $ sudo grep AuditBackend /etc/usbguard/usbguard-daemon.conf AuditBackend=LinuxAudit If "AuditBackend" is not set to "LinuxAudit", this is a finding. |
Configure Red Hat OpenShift Container Platform 4 USBGuard AuditBackend to use the audit system. Add or edit the following line in /etc/usbguard/usbguard-daemon.conf AuditBackend=LinuxAudit |
CAT II | ||||||
| 184 | CCI-000381 | SRG-OS-000114-GPOS-00059,SRG-APP-000092-CTR-000165 | The container platform must be configured with only essential configurations. | The container platform can be built with components that are not used for the intended purpose of the organization. To limit the attack surface of the container platform, it is essential that the non-essential services are not installed. | Applicable - Configurable | Review the container platform configuration and verify that only those components needed for operation are installed. If components are installed that are not used for the intended purpose of the organization, this is a finding. |
CAT II | ||||||||||
| 185 | CCI-000018 | SRG-APP-000026-CTR-000070 | The container platform must automatically audit account creation. | Red Hat OpenShift Container Platform 4 must automatically audit account creation. | Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to create a new account. Auditing of account creation is one method for mitigating this risk. A comprehensive account management process will ensure an audit trail documents the creation of application user accounts and, as required, notifies administrators and/or application when accounts are created. Such a process greatly reduces the risk that accounts will be surreptitiously created, and provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/auditing 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. |
Applicable - Configurable | Review the container platform configuration to determine if audit records are automatically created upon account creation. If audit records are not automatically created upon account creation, this is a finding. |
Verify Red Hat Enterprise Linux CoreOS (RHCOS) generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/shadow". Logging on as administrator, check the auditing rules in "/etc/audit/audit.rules" by executing the following: for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'echo -n "$HOSTNAME: "; grep /etc/shadow /etc/audit/audit.rules /etc/audit/rules.d/*'; done (Example output: -w /etc/shadow -p wa -k identity) If the command does not return a line, or the line is commented out, this is a finding. |
Apply the machine config using the following command: for mcpool in $(oc get mcp -oname | sed "s:.*/::" ); do echo "apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: name: 75-account-modifications-rules-$mcpool labels: machineconfiguration.openshift.io/role: $mcpool spec: config: ignition: version: 3.1.0 storage: files: - contents: source: data:,-w%20/etc/sudoers.d/%20-p%20wa%20-k%20actions%0A-w%20/etc/sudoers%20-p%20wa%20-k%20actions%0A mode: 0644 path: /etc/audit/rules.d/75-audit-sysadmin-actions.rules overwrite: true - contents: source: data:,-w%20/etc/group%20-p%20wa%20-k%20audit_rules_usergroup_modification%0A mode: 0644 path: /etc/audit/rules.d/30-etc_group_usergroup_modification.rules overwrite: true - contents: source: data:,-w%20/etc/gshadow%20-p%20wa%20-k%20audit_rules_usergroup_modification%0A mode: 0644 path: /etc/audit/rules.d/30-etc_gshadow_usergroup_modification.rules overwrite: true - contents: source: data:,-w%20/etc/security/opasswd%20-p%20wa%20-k%20audit_rules_usergroup_modification%0A mode: 0644 path: /etc/audit/rules.d/30-etc_security_opasswd_usergroup_modification.rules overwrite: true - contents: source: data:,-w%20/etc/passwd%20-p%20wa%20-k%20audit_rules_usergroup_modification%0A mode: 0644 path: /etc/audit/rules.d/30-etc_passwd_usergroup_modification.rules overwrite: true - contents: source: data:,-w%20/etc/shadow%20-p%20wa%20-k%20audit_rules_usergroup_modification%0A mode: 0644 path: /etc/audit/rules.d/30-etc_shadow_usergroup_modification.rules overwrite: true " | oc apply -f - done |
CAT II | |||||||
| 186 | CCI-000015 | SRG-APP-000023-CTR-000055 | CCE-83699-9 | The container platform must use a centralized user management solution to support account management functions. | Red Hat OpenShift Container Platform 4 must use a centralized user management solution to support account management functions. |
Enterprise environments make application account management challenging and complex. A manual process for account management functions adds the risk of a potential oversight or other error. A comprehensive application account management process that includes automation helps to ensure accounts designated as requiring attention are consistently and promptly addressed. Examples include, but are not limited to, using automation to take action on multiple accounts designated as inactive, suspended, or terminated or by disabling accounts located in non-centralized account stores, such as multiple servers. This requirement applies to all account types, including individual/user, shared, group, system, guest/anonymous, emergency, developer/manufacturer/vendor, temporary, and service. The application must be configured to automatically provide account management functions, and these functions must immediately enforce the organization's current account policy. The automated mechanisms may reside within the application itself or may be offered by the operating system or other infrastructure-providing automated account management capabilities. Automated mechanisms may be comprised of differing technologies, that when placed together, contain an overall automated mechanism supporting an organization's automated account management requirements. Account management functions include: assignment of group or role membership; identifying account type; specifying user access authorizations (i.e., privileges); account removal, update, or termination; and administrative alerts. The use of automated mechanisms can include: using email or text messaging to automatically notify account managers when users are terminated or transferred; using the information system to monitor account usage; or using automated telephonic notification to report atypical system account usage. |
OpenShift supports several different types of identity providers. In order to add users and grant access to OpenShift, an identity provider needs to be configured. Some of the identity provider types, such as HTPassword, only provide simple user management and are not intended for production. Other types are public services, like GitHub. These provider types may not be appropriate as they are managed by public service providers and therefore are unable to enforce the organizations account management requirements. After a new install, the default authentication uses kubeadmin as the default cluster-admin account. This default account needs to be disabled, and another user account should be given cluster-admin rights. |
Applicable - Configurable | Review the container platform to determine if it is using a centralized user management system for user management functions. If the container platform is not using a centralized user management system for user management functions, this is a finding. |
Verify that the authentication operator is configure to use either an LDAP or a OpenIDConnect or an approved identity provider: > oc get oauth cluster -o jsonpath="{.spec.identityProviders}" | jq If any of the IDP provides' type is LDAP and any of them use the insecure flag, this is a finding. |
Configure OpenShift to use an appropriate Identity Provider. Do not use HTPasswd. Use either LDAP(AD), OpenIDConnect or an approved identity provider. Steps to configure LDAP provider: 1. Create Secret for BIND DN password > oc create secret generic ldap-secret --from-literal=bindPassword= \ -n openshift-config 2. Create config map for LDAP Trust CA > oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n \ openshift-config 3. Create LDAP Auth Config Resource YAML Using your preferred text editor, create a file named ldapidp.yaml using the example content (replacing config values as appropriate): apiVersion: config.openshift.io/v1 kind: OAuth metadata: name: cluster spec: identityProviders: - name: ldapidp mappingMethod: claim type: LDAP ldap: attributes: id: - dn email: name: - cn preferredUsername: - uid bindDN: "" bindPassword: name: ldap-secret ca: name: ca-config-map insecure: false url: "ldaps://ldap.example.com/ou=users,dc=acme,dc=com?uid" 4. Apply LDAP config to cluster > oc apply -f ldapidp.yaml For more information on configuring an LDAP provider refer to the documentation: https://docs.openshift.com/container-platform/4.8/authentication/identity_providers/configuring-ldap-identity-provider.html |
CAT II | |||||
| 187 | CCI-002233 | SRG-APP-000342-CTR-000775 | Container images instantiated by the container platform must execute using least privileges. | Container images instantiated by the container platform must execute using least privileges. | Containers running within the container platform must execute as non-privileged. When a container can execute as a privileged container, the privileged container is also a privileged user within the hosting system, and the hosting system becomes a major security risk. It is important for the container platform runtime to validate the container user and disallow instantiation if the container is trying to execute with more privileges than required, as a privileged user, or is trying to perform a privilege escalation. When privileged access is necessary for a container, a new policy for execution should be written for the container. The default behavior must not give containers privileged execution. Examples of privileged users are root, admin, and default service accounts for the container platform. |
Applicable - Configurable | Review documentation and configuration to determine if the container platform disallows instantiation of containers trying to execute with more privileges than required or with privileged permissions. If the container platform does not block containers requesting privileged permissions, privilege escalation, or allows containers to have more privileges than required, this is a finding. |
Inspect each SCC and the users and groups allowed to use it returned from running the following command: oc get scc -ojson | jq '.items[]|select(.runAsUser.type != "MustRunAsRange" )|.metadata.name,{"Group:":.groups},{"User":.users}' The group "system:authenticated" is the default group for any authenticated user, this group should only be associated with the restricted profile. If this group is listed under any other SCC Policy, or the restricted SCC policy has been altered to allow any of the non-permitted actions, this is a finding. Next, determine if there are any cluster roles or local roles that allow the use of use of non-permitted SCC policies. The following commands will print the Role's name and namespace, followed by a list of resource names and if that resource is an SCC. > oc get clusterrole.rbac -ojson | jq -r '.items[]|select(.rules[]?|select( (.apiGroups[]? == ("security.openshift.io")) and (.resources[]? == ("securitycontextconstraints")) and (.verbs[]? == ("use"))))|.metadata.name,{"scc":(.rules[]?|select((.resources[]? == ("securitycontextconstraints"))).resourceNames[]?)}' > oc get role.rbac --all-namespaces -ojson | jq -r '.items[]|select(.rules[]?|select( (.apiGroups[]? == ("security.openshift.io")) and (.resources[]? == ("securitycontextconstraints")) and (.verbs[]? == ("use"))))|.metadata.name,{"scc":(.rules[]?|select((.resources[]? == ("securitycontextconstraints"))).resourceNames[]?)}' Excluding platform specific roles, identify any roles that allow use of non-permitted SCC policies for example the follow output shows that the role 'examplePrivilegedRole' allows use of the 'privileged' SCC. examplePrivilegedRole { "scc": "privileged" } Finally, determine if there are any role bindings to cluster or local roles that allow use of non-permitted SCCs. > oc get clusterrolebinding.rbac -ojson | jq -r '.items[]|select(.roleRef.kind == ("ClusterRole","Role") and .roleRef.name == ( ))|{ "crb": .metadata.name, "roleRef": .roleRef, "subjects": .subjects}' > oc get rolebinding.rbac --all-namespaces -ojson | jq -r '.items[]|select(.roleRef.kind == ("ClusterRole","Role") and .roleRef.name == ( ))|{ "crb": .metadata.name, "roleRef": .roleRef, "subjects": .subjects}' Where "CLUSTER_ROLE_LIST" and "LOCAL_ROLE_LIST" are comma-separated lists of the roles allowing use of non-permitted SCC policies as identified above. For example: ... .roleRef.name == ("system:openshift:scc:privileged","system:openshift:scc:hostnetwork","system:openshift:scc:hostaccess") ... Excluding any platform namespaces (kube-*,openshift-*), if there are any rolebindings to roles that are not permitted, this is a finding. |
For users and groups that are defined in the SCC policy, remove the users or groups by editing the corresponding SCC policy. > oc edit scc The following instructions will remove the user or group from the cluster role binding for the SCC policy. Remove user from the SCC Policy binding: > oc adm policy remove-scc-from-user Remove a group from the SCC Policy binding: > oc adm policy remove-scc-from-group Remove service account from the SCC Policy binding: > oc project > oc adm policy remove-scc-from-user -z Finally, remove any roles that allows use of non-permitted SCC policies (excluding platform defined roles) > oc delete clusterrole.rbac or > oc delete role.rbac -n |
CAT II | |||||||
| 188 | CCI-000768 | SRG-APP-000152-CTR-000370 | The container platform must use multifactor authentication for local access to non-privileged accounts. | Red Hat OpenShift Container Platform 4 must use multifactor authentication for local access to non-privileged accounts. | To ensure accountability, prevent unauthenticated access, and prevent misuse of the system, non-privileged users must utilize multi-factor authentication for local access. Multifactor authentication is defined as using two or more factors to achieve authentication. Factors include: (i) Something a user knows (e.g., password/PIN); (ii) Something a user has (e.g., cryptographic identification device, token); or (iii) Something a user is (e.g., biometric). A non-privileged account is defined as an information system account with authorizations of a regular or non-privileged user. Local access is defined as access to an organizational information system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network. |
Not Applicable | Review the container platform configuration to determine if multifactor authentication is used for local access to non-privileged accounts. If multifactor authentication for local access to non-privileged accounts is not being used, this is a finding. |
CAT II | Not Applicable. Applicable to Identity Management Provider and not OCP. Only configurable check is to ensure OCP is configured for an IDP under SRG-APP-000023-CTR-000055. Verify with IdM service provider admins that the IdM meets the requirements. |
||||||||
| 189 | CCI-001090 | SRG-APP-000243-CTR-000600 | The container platform must prevent unauthorized and unintended information transfer via shared system resources. | The container platform makes host system resources available to container services. These shared resources, such as the host system kernel, network connections, and storage, must be protected to prevent unauthorized and unintended information transfer. The protections must be implemented for users and processes acting on behalf of users. | Applicable - Configurable | Review the container platform architecture documentation to find out if and how it protects the resources of one process or user (such as working memory, storage, host system kernel, network connections) from unauthorized access by another user or process. If the container platform configuration settings do not effectively implement these protections to prevent unauthorized access by another user or process, this is a finding. |
CAT II | ||||||||||
| 190 | CCI-001090 | SRG-OS-000480-GPOS-00227,SRG-APP-000243-CTR-000600 | The container platform must prevent unauthorized and unintended information transfer via shared system resources. | The container platform makes host system resources available to container services. These shared resources, such as the host system kernel, network connections, and storage, must be protected to prevent unauthorized and unintended information transfer. The protections must be implemented for users and processes acting on behalf of users. | Applicable - Configurable | Review the container platform architecture documentation to find out if and how it protects the resources of one process or user (such as working memory, storage, host system kernel, network connections) from unauthorized access by another user or process. If the container platform configuration settings do not effectively implement these protections to prevent unauthorized access by another user or process, this is a finding. |
CAT II | ||||||||||
| 191 | CCI-001090 | SRG-APP-000243-CTR-000600 | The container platform must prevent unauthorized and unintended information transfer via shared system resources. | The container platform makes host system resources available to container services. These shared resources, such as the host system kernel, network connections, and storage, must be protected to prevent unauthorized and unintended information transfer. The protections must be implemented for users and processes acting on behalf of users. | Applicable - Configurable | Review the container platform architecture documentation to find out if and how it protects the resources of one process or user (such as working memory, storage, host system kernel, network connections) from unauthorized access by another user or process. If the container platform configuration settings do not effectively implement these protections to prevent unauthorized access by another user or process, this is a finding. |
CAT II | ||||||||||
| 192 | CCI-001082,CCI-001090 | SRG-OS-000132-GPOS-00067,SRG-OS-000138-GPOS-00069,SRG-APP-000243-CTR-000600 | The container platform must prevent unauthorized and unintended information transfer via shared system resources. | Red Hat OpenShift Container Platform 4 must restrict access to the kernel message buffer. | The container platform makes host system resources available to container services. These shared resources, such as the host system kernel, network connections, and storage, must be protected to prevent unauthorized and unintended information transfer. The protections must be implemented for users and processes acting on behalf of users. | Preventing unauthorized information transfers mitigates the risk of information, including encrypted representations of information, produced by the actions of prior users/roles (or the actions of processes acting on behalf of prior users/roles) from being available to any current users/roles (or current processes) that obtain access to shared system resources (e.g., registers, main memory, hard disks) after those resources have been released back to information systems. The control of information in shared resources is also commonly referred to as object reuse and residual information protection. This requirement generally applies to the design of an information technology product, but it can also apply to the configuration of particular information system components that are, or use, such products. This can be verified by acceptance/validation processes in DOD or other government agencies. There may be shared resources with configurable protections (e.g., files in storage) that may be assessed on specific information system components. Restricting access to the kernel message buffer limits access to only root. This prevents attackers from gaining additional system information as a nonprivileged user. |
Applicable - Configurable | Review the container platform architecture documentation to find out if and how it protects the resources of one process or user (such as working memory, storage, host system kernel, network connections) from unauthorized access by another user or process. If the container platform configuration settings do not effectively implement these protections to prevent unauthorized access by another user or process, this is a finding. |
Verify Red Hat OpenShift Container Platform 4 is configured to restrict access to the kernel message buffer with the following commands: Check the status of the kernel.dmesg_restrict kernel parameter. $ sudo sysctl kernel.dmesg_restrict kernel.dmesg_restrict = 1 If "kernel.dmesg_restrict" is not set to "1" or is missing, this is a finding. Check that the configuration files are present to enable this kernel parameter. $ sudo /usr/lib/systemd/systemd-sysctl --cat-config | egrep -v '^(#|;)' | grep -F kernel.dmesg_restrict | tail -1 kernel.dmesg_restrict = 1 If "kernel.dmesg_restrict" is not set to "1" or is missing, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to restrict access to the kernel message buffer. Add or edit the following line in a system configuration file, in the "/etc/sysctl.d/" directory: kernel.dmesg_restrict = 1 Load settings from all system configuration files with the following command: $ sudo sysctl --system |
CAT II | ||||||
| 193 | CCI-001082,CCI-001090 | SRG-OS-000132-GPOS-00067,SRG-OS-000138-GPOS-00069,SRG-APP-000243-CTR-000600 | The container platform must prevent unauthorized and unintended information transfer via shared system resources. | Red Hat OpenShift Container Platform 4 must prevent kernel profiling by nonprivileged users. | The container platform makes host system resources available to container services. These shared resources, such as the host system kernel, network connections, and storage, must be protected to prevent unauthorized and unintended information transfer. The protections must be implemented for users and processes acting on behalf of users. | Preventing unauthorized information transfers mitigates the risk of information, including encrypted representations of information, produced by the actions of prior users/roles (or the actions of processes acting on behalf of prior users/roles) from being available to any current users/roles (or current processes) that obtain access to shared system resources (e.g., registers, main memory, hard disks) after those resources have been released back to information systems. The control of information in shared resources is also commonly referred to as object reuse and residual information protection. This requirement generally applies to the design of an information technology product, but it can also apply to the configuration of particular information system components that are, or use, such products. This can be verified by acceptance/validation processes in DOD or other government agencies. There may be shared resources with configurable protections (e.g., files in storage) that may be assessed on specific information system components. Setting the kernel.perf_event_paranoid kernel parameter to "2" prevents attackers from gaining additional system information as a nonprivileged user. |
Applicable - Configurable | Review the container platform architecture documentation to find out if and how it protects the resources of one process or user (such as working memory, storage, host system kernel, network connections) from unauthorized access by another user or process. If the container platform configuration settings do not effectively implement these protections to prevent unauthorized access by another user or process, this is a finding. |
Verify Red Hat OpenShift Container Platform 4 is configured to prevent kernel profiling by nonprivileged users with the following commands: Check the status of the kernel.perf_event_paranoid kernel parameter. $ sudo sysctl kernel.perf_event_paranoid kernel.perf_event_paranoid = 2 If "kernel.perf_event_paranoid" is not set to "2" or is missing, this is a finding. Check that the configuration files are present to enable this kernel parameter. $ sudo /usr/lib/systemd/systemd-sysctl --cat-config | egrep -v '^(#|;)' | grep -F kernel.perf_event_paranoid | tail -1 kernel.perf_event_paranoid = 2 If "kernel.perf_event_paranoid" is not set to "2" or is missing, this is a finding. |
Configure Red Hat OpenShift Container Platform 4 to prevent kernel profiling by nonprivileged users. Add or edit the following line in a system configuration file, in the "/etc/sysctl.d/" directory: kernel.perf_event_paranoid = 2 Load settings from all system configuration files with the following command: $ sudo sysctl --system |
CAT II | ||||||
| 194 | CCI-000016 | SRG-APP-000024-CTR-000060 | The container platform must automatically remove or disable temporary user accounts after 72 hours. | Red Hat OpenShift Container Platform 4 must automatically remove or disable temporary user accounts after 72 hours. | If temporary user accounts remain active when no longer needed or for an excessive period, these accounts may be used to gain unauthorized access. To mitigate this risk, automated termination of all temporary user accounts must be set upon account creation. Temporary user accounts are established as part of normal account activation procedures when there is a need for short-term accounts without the demand for immediacy in account activation. If temporary user accounts are used, the application must be configured to automatically terminate these types of accounts after a DoD-defined period of 72 hours. 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. |
Not Applicable | Review the container platform configuration to determine if temporary user accounts are automatically removed or disabled after 72 hours. If temporary user accounts are not automatically removed or disabled after 72 hours, this is a finding. |
CAT II | Not Applicable. Applicable to Identity Management Provider and not OCP. Only configurable check is to ensure OCP is configured for an IDP under SRG-APP-000023-CTR-000055. Verify with IdM service provider admins that the IdM meets the requirements. |
||||||||
| 195 | CCI-001890 | SRG-APP-000374-CTR-000865 | All audit records must use UTC or GMT time stamps. | All audit records must use UTC or GMT time stamps. | The container platform and its components must generate audit records using either Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT) time stamps or local time that offset from UTC. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. Time stamps generated by the container platform and its components must include date and time. |
Applicable - Inherently Met | Review the container platform documentation and configuration files to determine if time stamps for log records can be mapped to UTC or GMT or local time that offsets from UTC. If the time stamp cannot be mapped to UTC or GMT, this is a finding. |
CAT II | Supporting evidence is in the following documentation https://docs.openshift.com/container-platform/latest/security/audit-log-view.html |
Openshift Container Platform conforms to DoD/DISA requirements regarding audit log fields. | |||||||
| 196 | CCI-002702 | SRG-APP-000474-CTR-001180 | The container platform must provide system notifications to the system administrator and operational staff when anomalies in the operation of the organization-defined security functions are discovered. | Red Hat OpenShift Container Platform 4 must provide system notifications to the system administrator and operational staff when anomalies in the operation of the organization-defined security functions are discovered. | If anomalies are not acted upon, security functions may fail to secure the container within the container platform runtime. Security functions are responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. Notifications provided by information systems include, for example, electronic alerts to system administrators. |
Applicable - Does Not Meet | Review container platform runtime documentation and configuration settings. If the container platform is not configured to notify organization-defined information system role when anomalies in the operation of security functions as defined by site security plan are discovered, this is a finding. |
CAT II | Use external tooling, such as Red Hat Advanced Cluster Security or compliance solutions from other vendors to provide active alerts conditionally. Applying an external tool mitigates this risk to a CAT III. |
If the OpenShift Compliance Operator is configured in accordance with the Fix data in SRG-APP-000516-CTR-001325, then administrators will be able to query when a ComplianceCheckResult shows non-compliant status for any of the rules defined in the compliance profile, aligning with the SSP for the system. This capability does not currently natively support alerting for non-compliant status. External tooling, such as Red Hat Advanced Cluster Security or compliance solutions from other vendors, may be integrated using their own mechanisms to provide active alerts conditionally. |
|||||||
| 197 | CCI-001855 | SRG-APP-000359-CTR-000810 | The container platform must provide an immediate warning to the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75 percent of repository maximum audit record storage capacity. | Red Hat OpenShift Container Platform 4 must provide an immediate warning to the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75 percent of repository maximum audit record storage capacity. | If security personnel are not notified immediately upon storage volume utilization reaching 75 percent, they are unable to plan for storage capacity expansion. | Not Applicable | Review the container platform configuration to determine if it is configured to provide an immediate warning to the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75 percent of repository maximum audit record storage capacity. If the container platform is not configured to provide an immediate real-time alert, this is a finding. |
CAT II | Not applicable - The location of the external logging server used for audit log aggregation is outside the scope of OpenShift Container Platform configuration. Because the configuration recommended in response to SRG-APP-000111-CTR-000220 configures an external log aggregation server outside of the control of the OpenShift cluster, it is up to individual implementation to ensure that the location of that log aggregation point meets other requirements. |
||||||||
| 198 | CCI-002238 | SRG-APP-000345-CTR-000785 | The container platform must automatically lock an account until the locked account is released by an administrator when three unsuccessful login attempts in 15 minutes are exceeded. | Red Hat OpenShift Container Platform 4 must automatically lock an account until the locked account is released by an administrator when three unsuccessful login attempts in 15 minutes are exceeded. | By limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced. Limits are imposed by locking the account. | Not Applicable | Determine if the container platform is configured to automatically lock an account until the locked account is released by an administrator when three unsuccessful login attempts in 15 minutes are exceeded. If the container platform is not configured to lock the account, this is a finding. |
CAT II | Not Applicable. Applicable to Identity Management Provider and not OCP. Only configurable check is to ensure OCP is configured for an IDP under SRG-APP-000023-CTR-000055. Verify with IdM service provider admins that the IdM meets the requirements. |
||||||||
| 199 | CCI-000764 | SRG-APP-000148-CTR-000340 | The container platform application program interface (API) must uniquely identify and authenticate users. | Red Hat OpenShift Container Platform 4 application program interface (API) must uniquely identify and authenticate users. | The container platform requires user accounts to perform container platform tasks. These tasks are often performed through the container platform API. Protecting the API from users who are not authorized or authenticated is essential to keep the container platform stable. Protection of platform and application data and enhances the protections put in place for Denial-of Service (DoS) attacks. | Applicable - Inherently Met | Review the container platform configuration to determine if users are uniquely identified and authenticated before the API is executed. If users are not uniquely identified or are not authenticated, this is a finding. |
CAT II | Supporting evidence is in the following documentation https://docs.openshift.com/container-platform/latest/authentication/index.html |
Users of the OpenShift Platform must be uniquely identified and authenticated in order to access the platform's console. Anonymous users are prohibited, and authorization is enforced by the platform's RBAC policies. Refer to https://docs.openshift.com/container-platform/latest/authentication/index.html for more information. |
|||||||
| 200 | CCI-002364 | SRG-APP-000297-CTR-000705 | CCE-90780-8 | Access to the container platform must display an explicit logout message to user indicating the reliable termination of authenticated communication sessions. | Access to Red Hat OpenShift Container Platform 4 must display an explicit logout message to user indicating the reliable termination of authenticated communication sessions. |
Access to the container platform will occur through web and terminal sessions. Any web interfaces must conform to application and web security requirements. Terminal access to the container platform and its components must provide a logout facility that terminates the connection to the component or the platform. | Applicable - Configurable | Review documentation and configuration settings to determine if the container platform displays a logout message. If the container platform does not display a logout message, this is a finding. |
Verify that the logout redirect setting in web console configuration is set. > oc get console.config.openshift.io cluster -o jsonpath='{.spec.authentication.logoutRedirect}{" "}' If nothing is returned this is a finding. |
Configure the web console's logout redirect to direct to an appropriate logout page. If OpenShift is configured to use an OIDC provider, then the redirect needs to first go to the OIDC provider's logout page, and then it can be redirected to another logout page as needed. Run the following command to update the console > oc patch console.config.openshift.io cluster --type merge -p '{"spec":{"authentication":{"logoutRedirect":" "}}}' where LOGOUT_URL is set to the logout page |
CAT III | ||||||
| 201 | CCI-001851 | SRG-APP-000092-CTR-000165,SRG-APP-000111-CTR-000220,SRG-APP-000358-CTR-000805 | CCE-85918-1 | Audit records must be stored at a secondary location. | The container platform must initiate session auditing upon startup. | Auditable events are used in the investigation of incidents and must be protected from being deleted or altered. Often, events that took place in the past must be viewed to understand the entire incident. For the purposes of audit event protection and recall, audit events are often off-loaded to an external storage location. The container platform must provide a mechanism to assist in the off-loading of the audit data or at a minimum, must not hinder an external process used for audit event off-loading. | Applicable - Configurable | Verify the log records are being off-loaded to a separate system or transferred from the container platform storage location to a storage location other than the container platform itself. The information system may demonstrate this capability using a log management application, system configuration, or other means. If logs are not being off-loaded, this is a finding. |
Determine if cluster log forwarding is configured by performing the following commands. Verify that the cluster-logging operator is installed: > oc get subscription/cluster-logging -n openshift-logging NAME PACKAGE SOURCE CHANNEL cluster-logging cluster-logging redhat-operators stable If the cluster-logging operator is not present, this is a finding. |
To resolve this, the OpenShift Cluster Logging operator first needs to be installed, then the Cluster Log Forwarder is configured to forward logs to a centralized log aggregation service. In order to install the OpenShift Cluster Logging operator, Run the following command to apply the subscription manifests to your cluster: > oc apply -f - << 'EOF' --- apiVersion: project.openshift.io/v1 kind:Project metadata: labels: kubernetes.io/metadata.name: openshift-logging openshift.io/cluster-monitoring: "true" name: openshift-logging spec: {} ... --- apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: openshift-logging namespace: openshift-logging spec: targetNamespaces: - openshift-logging ... --- apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: labels: operators.coreos.com/cluster-logging.openshift-logging: "" name: cluster-logging namespace: openshift-logging spec: channel: stable installPlanApproval: Automatic name: cluster-logging source: redhat-operators sourceNamespace: openshift-marketplace ... EOF |
CAT II | ||||||
| 202 | CCI-001851 | SRG-APP-000092-CTR-000165,SRG-APP-000111-CTR-000220,SRG-APP-000358-CTR-000805 | CCE-84076-9 | Audit records must be stored at a secondary location. | The container platform must initiate session auditing upon startup. | Auditable events are used in the investigation of incidents and must be protected from being deleted or altered. Often, events that took place in the past must be viewed to understand the entire incident. For the purposes of audit event protection and recall, audit events are often off-loaded to an external storage location. The container platform must provide a mechanism to assist in the off-loading of the audit data or at a minimum, must not hinder an external process used for audit event off-loading. | Applicable - Configurable | Verify the log records are being off-loaded to a separate system or transferred from the container platform storage location to a storage location other than the container platform itself. The information system may demonstrate this capability using a log management application, system configuration, or other means. If logs are not being off-loaded, this is a finding. |
List the cluster log forwarders defined: > oc get clusterlogforwarder -n openshift-logging If there are no clusterlogforwarders defined, this is a finding. For each cluster log forwarder listed above, view the configuration details: > oc describe clusterlogforwarder/ -n openshift-logging Review the details of the cluster log forwarder. If the configuration is not set to forward logs the organization's centralized logging service, this is a finding. |
After the OpenShift Logging operator has been installed, you can create a ClusterLogForwarder instance to forward cluster logs to a log aggregator. A basic configuration that would forward OpenShift audit, application, and infrastructure logs to an rsyslog server that you manage separately, and is configured for mTLS authentication over TCP when sending Audit logs but traditional UDP access for other types of logs, can be provided by editing the appropriate values in the Secret resource below and changing the "url" parameters in the "outputs" section of the "spec" below, then running the command to apply it like this: oc apply -f - tls.key: ca-bundle.crt: ... --- apiVersion: logging.openshift.io/v1 kind: ClusterLogForwarder metadata: name: instance namespace: openshift-logging spec: outputs: - name: rsyslog-audit type: syslog syslog: facility: security rfc: RFC5424 severity: Informational appName: openshift msgID: audit procID: audit url: 'tls://rsyslogserver.example.com:514' secret: name: rsyslog-tls-secret - name: rsyslog-apps type: syslog syslog: facility: user rfc: RFC5424 severity: Informational appName: openshift msgID: apps procID: apps url: 'udp://rsyslogserver.example.com:514' - name: rsyslog-infra type: syslog syslog: facility: local0 rfc: RFC5424 severity: Informational appName: openshift msgID: infra procID: infra url: 'udp://rsyslogserver.example.com:514' pipelines: - name: audit-logs inputRefs: - audit outputRefs: - rsyslog-audit - name: apps-logs inputRefs: - application outputRefs: - rsyslog-apps - name: infrastructure-logs inputRefs: - infrastructure outputRefs: - rsyslog-infra ... EOF Please note that many log forwarding destinations are supported, and the fix does not require that you forward your audit logs to rsyslog over mTLS. To better understand how to configure the ClusterLogForwarder for your infrastructure and environment, please consult the OpenShift Logging documentation: https://docs.openshift.com/container-platform/latest/logging/cluster-logging-external.html |
CAT II | ||||||
| 203 | CCI-001414 | SRG-APP-000039-CTR-000110 | CCE-86070-0 | The container platform must enforce approved authorizations for controlling the flow of information between interconnected systems and services based on organization-defined information flow control policies. | Red Hat OpenShift Container Platform 4 must enforce approved authorizations for controlling the flow of information between interconnected systems and services based on organization-defined information flow control policies. |
Controlling information flow between the container platform components and container user services instantiated by the container platform must enforce organization-defined information flow policies. Example methods for information flow control are: using labels for containers to segregate services; user permissions and roles to limit what user services are available to each user; controlling the user the services are able to execute as; and limiting inter-container network traffic and the resources containers can consume. | OpenShift provides several layers of protection to control the flow of information between the container platform components and user services. Each user project is given a separate namespace and OpenShift enforces RBAC policies controlling which projects and services users have access to. In addition, NetworkPolicies are used to control the flow of requests to and from externally integrated services to services hosted on the container platform. It is important to define a default Network Policy that will be applied automatically to new projects to prevent unintended requests. These policies can be updated by the project's administrator (with the appropriate RBAC permissions) to apply a policy that is appropriate to the service(s) within the project namespace. |
Applicable - Configurable | Review the container platform configuration to determine if organization-defined information flow controls are implemented. If information flow controls are not implemented, this is a finding. |
Configure a default network policy as necessary to protect the flow of information by performing the following steps. 1. Create a bootstrap project template (if not already created) > oc adm create-bootstrap-project-template -o yaml > template.yaml 2. Edit the template and add NetworkPolicy object definitions before the parameters section. For example, the following section defines two policies one to allow requests from the same namespace, the other to allow from the openshift ingress routing service. - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-same-namespace spec: podSelector: ingress: - from: - podSelector: {} - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-ingress spec: ingress: - from: - namespaceSelector: matchLabels: network.openshift.io/policy-group: ingress podSelector: {} policyTypes: - Ingress parameters: 3. Apply the project template to the cluster by running the following command: > oc create -f template.yaml -n openshift-config 4. Set the default cluster project request template > oc patch project.config.openshift.io/cluster --type=merge \ -p '{spec":{"projectRequestTemplate":{"name": " "}}}' For additional information regarding network policies, see https://docs.openshift.com/container-platform/latest/networking/network_policy/about-network-policy.html |
CAT II | ||||||
| 204 | CCI-002754 | SRG-APP-000447-CTR-001100 | The container platform must behave in a predictable and documented manner that reflects organizational and system objectives when invalid inputs are received. | Red Hat OpenShift Container Platform 4 must behave in a predictable and documented manner that reflects organizational and system objectives when invalid inputs are received. | Software or code parameters typically follow well-defined protocols that use structured messages (i.e., commands or queries) to communicate between software modules or system components. Structured messages can contain raw or unstructured data interspersed with metadata or control information. If attacker-supplied inputs to construct structured messages without properly encoding such messages, then the attacker could insert malicious commands or special characters that can cause the data to be interpreted as control information or metadata. This requirement guards against adverse or unintended system behavior caused by invalid inputs, where container platform components responses to the invalid input may be disruptive or cause the container image runtime to fail into an unsafe state. The behavior will be derived from the organizational and system requirements and includes, but is not limited to, notification of the appropriate personnel, creating an audit record, and rejecting invalid input. |
Applicable - Inherently Met | Review the configuration to determine if the container platform behaves in a predictable and documented manner that reflects organizational and system objectives when invalid inputs are received. If the container platform does not meet this requirement, this is a finding. |
CAT II | Supporting evidence is in the following documentation https://docs.openshift.com/container-platform/latest/rest_api/understanding-compatibility-guidelines.html |
All changes to the system go through API Server which is protected through transport security (TLS), as well as authentication, authorization, and additional admission controllers. These security mechanisms are configured out of the box with strong security controls but can be even further limited to enforce least privilege. Additionally, the API Server safeguards against unintended consequences by rejecting invalid inputs and creating audit records of API events. Alerts and logs and also be setup to display changes of API events. | |||||||
| 205 | CCI-000766 | SRG-APP-000150-CTR-000360 | The container platform must use multifactor authentication for network access to non-privileged accounts. | Red Hat OpenShift Container Platform 4 must use multifactor authentication for network access to non-privileged accounts. | To ensure accountability and prevent unauthenticated access, non-privileged users must utilize multifactor authentication to prevent potential misuse and compromise of the system. Multifactor authentication uses two or more factors to achieve authentication. Factors include: (i) Something you know (e.g., password/PIN); (ii) Something you have (e.g., cryptographic identification device, token); or (iii) Something you are (e.g., biometric). A non-privileged account is any information system account with authorizations of a non-privileged user. Network access is any access to an application by a user (or process acting on behalf of a user) where said access is obtained through a network connection. Applications integrating with the DoD Active Directory and utilize the DoD CAC are examples of compliant multifactor authentication solutions. |
Not Applicable | Review the container platform configuration to determine if the container platform is configured to use multifactor authentication for network access to non-privileged accounts. If the container platform does not use multifactor authentication for network access to non-privileged accounts, this is a finding. |
CAT II | Not Applicable. Applicable to Identity Management Provider and not OCP. Only configurable check is to ensure OCP is configured for an IDP under SRG-APP-000023-CTR-000055. Verify with IdM service provider admins that the IdM meets the requirements. |
||||||||
| 206 | CCI-002041 | SRG-APP-000397-CTR-000955 | The container platform must allow the use of a temporary password for system logons with an immediate change to a permanent password. | Red Hat OpenShift Container Platform 4 must allow the use of a temporary password for system logons with an immediate change to a permanent password. | Without providing this capability, an account may be created without a password. Non-repudiation cannot be guaranteed once an account is created if a user is not forced to change the temporary password upon initial login. Temporary passwords are typically used to allow access to applications when new accounts are created or passwords are changed. It is common practice for administrators to create temporary passwords for user accounts, which allow the users to log in, yet forces them to change the password once they have successfully authenticated. |
Not Applicable | Review the container platform configuration to determine if the platform is configured to allow the use of a temporary password for system logons with an immediate change to a permanent password. If the container platform is not configured to allow temporary passwords with immediate change to a permanent password, this is a finding. |
CAT II | Not Applicable. Applicable to Identity Management Provider and not OCP. Only configurable check is to ensure OCP is configured for an IDP under SRG-APP-000023-CTR-000055. Verify with IdM service provider admins that the IdM meets the requirements. |
||||||||
| 207 | CCI-000206 | SRG-APP-000178-CTR-000470 | The container platform must obscure feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals. | Red Hat OpenShift Container Platform 4 must obscure feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals. | To prevent the compromise of authentication information such as passwords during the authentication process, the feedback from the container platform and its components, e.g., runtime, registry, and keystore, must not provide any information that would allow an unauthorized user to compromise the authentication mechanism. Obfuscation of user-provided information when typed is a method used in addressing this risk. Displaying asterisks when a user types in a password is an example of obscuring feedback of authentication information. |
Applicable - Inherently Met | Review container platform documentation and configuration to determine if any interfaces that are provided for authentication purposes display the user's password when it is typed into the data entry field. If authentication information is not obfuscated when entered, this is a finding. |
CAT II | Supporting evidence is in the following documentation https://docs.openshift.com/container-platform/latest/authentication/index.html |
The OpenShift Container Platform's web console hides the user's password as it is typed in. The CLI interface also hides the password as it is typed via standard input on the console. To access the API server a user must first authenticate and obtain an OAuth token (or a x.509 certificate) in order send requests to the API server. In this way, the user's authentication credentials (username/password) are protected from discovery. |
|||||||
| 208 | CCI-000366,CCI-002824 | SRG-OS-000433-GPOS-00193,SRG-OS-000480-GPOS-00227,SRG-APP-000450-CTR-001105 | The container platform must implement organization-defined security safeguards to protect system CPU and memory from resource depletion and unauthorized code execution. | Red Hat OpenShift Container Platform 4 must implement address space layout randomization (ASLR) to protect its memory from unauthorized code execution. | The execution of images within the container platform runtime must implement organizational defined security safeguards to prevent distributed denial-of-service (DDOS) and other possible attacks against the container image at runtime. Security safeguards employed to protect memory and CPU include, for example, data execution prevention and address space layout randomization. Data execution prevention safeguards can be software-enforced. Other means of protection are to limit memory and CPU resources to a container. |
Address space layout randomization (ASLR) makes it more difficult for an attacker to predict the location of attack code they have introduced into a process' address space during an attempt at exploitation. Additionally, ASLR makes it more difficult for an attacker to know the location of existing code in order to repurpose it using return oriented programming (ROP) techniques. | Applicable - Configurable | Review the container platform configuration to determine if safeguards are in place to protect the system memory and CPU from resource depletion and unauthorized execution. If safeguards are not in place, this is a finding. |
Verify Red Hat OpenShift Container Platform 4 is implementing ASLR with the following command: $ sudo sysctl kernel.randomize_va_space kernel.randomize_va_space = 2 Check that the configuration files are present to enable this kernel parameter. Verify the configuration of the kernel.kptr_restrict kernel parameter with the following command: $ sudo /usr/lib/systemd/systemd-sysctl --cat-config | egrep -v '^(#|;)' | grep -F kernel.randomize_va_space | tail -1 kernel.randomize_va_space = 2 If "kernel.randomize_va_space" is not set to "2" or is missing, this is a finding. |
Add or edit the following line in a system configuration file in the "/etc/sysctl.d/" directory: kernel.randomize_va_space = 2 Reload settings from all system configuration files with the following command: $ sudo sysctl --system |
CAT II | ||||||
| 209 | CCI-002824 | SRG-OS-000433-GPOS-00192,SRG-APP-000450-CTR-001105 | The container platform must implement organization-defined security safeguards to protect system CPU and memory from resource depletion and unauthorized code execution. | Red Hat OpenShift Container Platform 4 must implement non-executable data to protect its memory from unauthorized code execution. | The execution of images within the container platform runtime must implement organizational defined security safeguards to prevent distributed denial-of-service (DDOS) and other possible attacks against the container image at runtime. Security safeguards employed to protect memory and CPU include, for example, data execution prevention and address space layout randomization. Data execution prevention safeguards can be software-enforced. Other means of protection are to limit memory and CPU resources to a container. |
ExecShield uses the segmentation feature on all x86 systems to prevent execution in memory higher than a certain address. It writes an address as a limit in the code segment descriptor, to control where code can be executed, on a per-process basis. When the kernel places a process's memory regions such as the stack and heap higher than this address, the hardware prevents execution in that address range. This is enabled by default on the latest Red Hat and Fedora systems if supported by the hardware. |
Applicable - Configurable | Review the container platform configuration to determine if safeguards are in place to protect the system memory and CPU from resource depletion and unauthorized execution. If safeguards are not in place, this is a finding. |
Verify the NX (no-execution) bit flag is set on the system. Check that the no-execution bit flag is set with the following commands: $ sudo dmesg | grep NX [ 0.000000] NX (Execute Disable) protection: active If "dmesg" does not show "NX (Execute Disable) protection" active, check the cpuinfo settings with the following command: $ sudo grep -i flags /proc/cpuinfo flags : fpu vme de pse tsc ms nx rdtscp lm constant_tsc If "flags" does not contain the "nx" flag, this is a finding. |
Update the GRUB 2 bootloader configuration. Run the following command: $ sudo grubby --update-kernel=ALL --remove-args=noexec |
CAT II | ||||||
| 210 | CCI-002696 | SRG-APP-000472-CTR-001170 | CCE-83697-3 | The organization-defined role must verify correct operation of security functions in the container platform. | The organization-defined role must verify correct operation of security functions in the container platform. | Without verification, security functions may not operate correctly and this failure may go unnoticed within the container platform. The container platform components must identity and ensure the security functions are still operational and applicable to the organization. Security functions are responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. Notifications provided by information systems include, for example, electronic alerts to system administrators. |
Applicable - Configurable | Review container platform documentation and configuration verification of the correct operation of security functions, which may include the valid connection to an external security manager (ESM). If verification of the correct operation of security functions is not performed, this is a finding. |
Review the cluster configuration to validate that all required security functions are being validated with the Compliance Operator. To see if any scans have been applied to your cluster, and what their status is, run the following command: > oc get compliancescan -n openshift-compliance Example output: NAME PHASE RESULT ocp4-cis DONE NON-COMPLIANT ocp4-cis-manual DONE NON-COMPLIANT ocp4-cis-node-master DONE NON-COMPLIANT ocp4-cis-node-master-manual DONE NON-COMPLIANT ocp4-cis-node-worker DONE NON-COMPLIANT ocp4-cis-node-worker-manual DONE NON-COMPLIANT ocp4-moderate DONE NON-COMPLIANT ocp4-moderate-manual DONE NON-COMPLIANT rhcos4-moderate-master DONE NON-COMPLIANT rhcos4-moderate-master-manual DONE NON-COMPLIANT rhcos4-moderate-worker DONE NON-COMPLIANT rhcos4-moderate-worker-manual DONE NON-COMPLIANT If no ComplianceScan names return, the scans don't align to the organizationally-defined appropriate security functions, the command returns with an error, or any of the results show "NON-COMPLIANT" as their result, then this is a finding. |
The compliance operator can be leveraged to ensure that components are configured in alignment with the SSP. To install the Compliance Operator, run the following command: > oc apply -f - oc apply -f my-scansettingbinding.yml -n openshift-compliance For more information about the compliance operator and its use, including the creation of TailoredProfiles and the ScanSettings available to meet specific security functions or organizational goals defined in the SSP, please see the product documentation https://docs.openshift.com/container-platform/4.8/security/compliance_operator/compliance-operator-understanding.html |
CAT II | ||||||
| 211 | CCI-000795 | SRG-APP-000163-CTR-000395 | The container platform must disable identifiers (individuals, groups, roles, and devices) after 35 days of inactivity. | Red Hat OpenShift Container Platform 4 must disable identifiers (individuals, groups, roles, and devices) after 35 days of inactivity. | Inactive identifiers pose a risk to systems and applications. Attackers that are able to exploit an inactive identifier can potentially obtain and maintain undetected access to the application. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. Applications need to track periods of inactivity and disable application identifiers after 35 days of inactivity. Management of user identifiers is not applicable to shared information system accounts (e.g., guest and anonymous accounts). It is commonly the case that a user account is the name of an information system account associated with an individual. To avoid having to build complex user management capabilities directly into their application, wise developers leverage the underlying OS or other user account management infrastructure (AD, LDAP) that is already in place within the organization and meets organizational user account management requirements. |
Not Applicable | Review the container platform configuration to determine if the container platform is configured to disable identifiers (individuals, groups, roles, and devices) after 35 days of inactivity. If identifiers are not disabled after 35 days of inactivity, this is a finding. |
CAT II | Not Applicable. Applicable to Identity Management Provider and not OCP. Only configurable check is to ensure OCP is configured for an IDP under SRG-APP-000023-CTR-000055. Verify with IdM service provider admins that the IdM meets the requirements. |
||||||||
| 212 | CCI-001665 | SRG-APP-000226-CTR-000575 | The container platform must preserve any information necessary to determine the cause of the disruption or failure. | Red Hat OpenShift Container Platform 4 must preserve any information necessary to determine the cause of the disruption or failure. | When a failure occurs within the container platform, preserving the state of the container platform and its components, along with other container services, helps to facilitate container platform restart and return to the operational mode of the organization with less disruption to mission essential processes. When preserving state, considerations for preservation of data confidentiality and integrity must be taken into consideration. | Applicable - Inherently Met | Review the container platform configuration to determine if information necessary to determine the cause of a disruption or failure is preserved. If the information is not preserved, this is a finding. |
CAT II | Supporting evidence is in the following documentation https://docs.openshift.com/container-platform/latest/support/gathering-cluster-data.html |
In the event that there is a failure or disruption to the OpenShift platform, information necessary to identifying the cause would be preserved. The cluster state (resource definitions) is preserved by etcd, audit and system logs are preserved via journald service at the node levels. The following guide provide steps on how to gather cluster data in order to investigate issue with the cluster. https://docs.openshift.com/container-platform/latest/support/gathering-cluster-data.html |
|||||||
| 213 | CCI-000205 | SRG-APP-000164-CTR-000400 | The container platform must enforce a minimum 15-character password length. | Red Hat OpenShift Container Platform 4 must enforce a minimum 15-character password length. | The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password. The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised. Use of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password. |
Not Applicable | Review the container platform configuration to determine if the container platform enforces a minimum 15-character password length. If the container platform does not enforce a 15-character password length, this is a finding. |
CAT II | Not Applicable. Applicable to Identity Management Provider and not OCP. Only configurable check is to ensure OCP is configured for an IDP under SRG-APP-000023-CTR-000055. Verify with IdM service provider admins that the IdM meets the requirements. |
||||||||
| 214 | CCI-000187 | SRG-APP-000177-CTR-000465 | The container platform must map the authenticated identity to the individual user or group account for PKI-based authentication. | Red Hat OpenShift Container Platform 4 must map the authenticated identity to the individual user or group account for PKI-based authentication. | The container platform and its components may require authentication before use. When the authentication is PKI-based, the container platform or component must map the certificate to a user account. If the certificate is not mapped to a user account, the ability to determine the identity of the individual user or group will not be available for forensic analysis. | Not Applicable | Review documentation and configuration to ensure the container platform provides a PKI integration capability that meets DoD PKI infrastructure requirements. If the container platform is not configured to meet this requirement, this is a finding. |
CAT II | Not Applicable. Applicable to Identity Management Provider and not OCP. Only configurable check is to ensure OCP is configured for an IDP under SRG-APP-000023-CTR-000055. Verify with IdM service provider admins that the IdM meets the requirements. |
||||||||
| 215 | CCI-002699 | SRG-APP-000473-CTR-001175 | CCE-90762-6 | The container platform must perform verification of the correct operation of security functions: upon system startup and/or restart; upon command by a user with privileged access; and/or every 30 days. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. | The container platform must perform verification of the correct operation of security functions: upon system startup and/or restart; upon command by a user with privileged access; and/or every 30 days. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. | Without verification, security functions may not operate correctly and this failure may go unnoticed within the container platform. Security functions are responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. Notifications provided by information systems include, for example, electronic alerts to organization-defined role. |
Applicable - Configurable | Review container platform documentation. Verify that the container platform is configured to perform verification of the correct operation of security functions, which may include the valid connection to an external security manager (ESM), upon product startup/restart, by a user with privileged access, and/or every 30 days. If it is not, this is a finding. |
Review the cluster configuration to validate that all required security functions are being validated with the Compliance Operator. To map the schedule of every profile through its ScanSettingBinding and output the schedules on which each Profile or TailoredProfile is run, execute the following commands: > declare -A binding_profiles > declare -A binding_schedule > while read binding setting profiles; do binding_profiles[$binding]="$profiles"; binding_schedule[$binding]=$(oc get scansetting -n openshift-compliance $setting -ojsonpath='{.schedule}'); done for binding in "${!binding_profiles[@]}"; do for profile in ${binding_profiles[$binding]}; do echo "$profile: ${binding_schedule[$binding]}"; done; done If the profiles that are bound to schedules do not cover the organization-designed security functions, or if the schedules are not at least monthly or within the organization defined periodicity, this is a finding. To determine which rules are enforced by the profiles that are currently bound to the scheduled periodicities, execute the following commands: > for binding in "${!binding_profiles[@]}"; do for profile in ${binding_profiles[$binding]}; do for rule in $(oc get profile.compliance $profile -n openshift-compliance -ojsonpath='{range .rules[*]}{$}{" "}{end}'); do echo "$rule: ${binding_schedule[$binding]}"; done; done; done | sort -u |
The compliance operator can be leveraged to ensure that components are configured in alignment with the SSP at a desired schedule. To install the Compliance Operator, run the following command: > oc apply -f - oc apply -f my-scansettingbinding.yml -n openshift-compliance For more information about the compliance operator and its use, including the configurability of scheduling of scan cadence in ScanSetting resources and the Role-based access control requirements for manually triggered scans, please see the product documentation https://docs.openshift.com/container-platform/4.8/security/compliance_operator/compliance-operator-understanding.html |
CAT II | ||||||
| 216 | CCI-002605 | SRG-APP-000456-CTR-001125 | The container platform registry must contain the latest images with most recent updates and execute within the container platform runtime as authorized by IAVM, CTOs, DTMs, and STIGs. | Red Hat OpenShift Container Platform 4 registry must contain the latest images with most recent updates and execute within the container platform runtime as authorized by IAVM, CTOs, DTMs, and STIGs. |
Software supporting the container platform, images in the registry must stay up to date with the latest patches, service packs, and hot fixes. Not updating the container platform and container images will expose the organization to vulnerabilities. Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling must also be addressed expeditiously. Organization-defined time periods for updating security-relevant container platform components may vary based on a variety of factors including, for example, the security category of the information system or the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw). This requirement will apply to software patch management solutions that are used to install patches across the enclave and to applications themselves that are not part of that patch management solution. For example, many browsers today provide the capability to install their own patch software. Patch criticality, as well as system criticality will vary. Therefore, the tactical situations regarding the patch management process will also vary. This means that the time period utilized must be a configurable parameter. Time frames for application of security-relevant software updates may be dependent upon the Information Assurance Vulnerability Management (IAVM) process. The container platform components will be configured to check for and install security-relevant software updates within an identified time period from the availability of the update. The container platform registry will ensure the images are current. The specific time period will be defined by an authoritative source (e.g., IAVM, CTOs, DTMs, and STIGs). |
It is critical to the security ond stability of the container platform and the software services running on the platform to ensure that images are deployed through a trusted software supply chain. Some key elements to having a trusted supply chain include ensuring that images deployed to the container platform come from known, trusted sources. Additionally, it is also important to check for and apply security relevant updates in a timely manner. In order to help users manage images, OpenShift uses image streams to provide a level of abstraction for the users. In this way the users can trigger automatic redeployments as images are updated. It is also possible to configure the image stream to periodically check the image source repository for any updates and automatically pull in the latest updates. The OpenShift platform can be configured to limit and control which image source repositories may be used by the platform and the users of the platform. By configuring this to only allow users to deploy images from trusted sources, lowers the risk for a user to deploy unsafe, or untested images that would be detrimental to the security and stability of the platform. |
Applicable - Configurable | Review documentation and configuration to determine if the container platform registry inspects and contains approved vendor repository latest images containing security-relevant updates within a timeframe directed by an authoritative source (IAVM, CTOs, DTMs, STIGs, etc.). If the container platform registry does not contain the latest image with security-relevant updates within the time period directed by the authoritative source, this is a finding. The container platform registry should help the user understand where the code in the environment was deployed from, and must provide controls that prevent deployment from untrusted sources or registries. |
To list all the imagestreams and identify which imagestream tags are configured to periodically check for updates (imagePolicy = { scheduled: true }) and (kind = DockerImage) run the following command: > oc get imagestream --all-namespaces -o jsonpath='{range .items[*]}{.metadata.name}{" "}{range .spec.tags[*]}{"\t"}{.name}{": "}{.importPolicy}{"\t"}{.from}{" "} You will see an ouput similar to: httpd 2.4: {} 2.4-el7: {} 2.4-el8: {} latest: {} : installer latest: {"scheduled":true} : installer-artifacts latest: {"scheduled":true} : Review the listing, and for each imagestream tag version that does not have the value '{"scheduled":true}' that should otherwise check for updates, this is a finding. |
For container images that are not scheduled to check for updates that otherwise should, update the imagestream to schedule updates for each tag using the following command. > oc patch imagestream -n NAMESPACE --type merge -p '{"spec":{"tags":[{"name":" ","importPolicy":{"scheduled":true}}]}}' where, NAME: The imagestream name to update NAMESPACE: The namespace the imagestream is in. This will most often be 'openshift'. TAG_NAME: The imagestream tag to update |
CAT II | ||||||
| 217 | CCI-002605 | SRG-APP-000456-CTR-001125 | The container platform registry must contain the latest images with most recent updates and execute within the container platform runtime as authorized by IAVM, CTOs, DTMs, and STIGs. | Red Hat OpenShift Container Platform 4 registry must contain the latest images with most recent updates and execute within the container platform runtime as authorized by IAVM, CTOs, DTMs, and STIGs. |
Software supporting the container platform, images in the registry must stay up to date with the latest patches, service packs, and hot fixes. Not updating the container platform and container images will expose the organization to vulnerabilities. Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling must also be addressed expeditiously. Organization-defined time periods for updating security-relevant container platform components may vary based on a variety of factors including, for example, the security category of the information system or the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw). This requirement will apply to software patch management solutions that are used to install patches across the enclave and to applications themselves that are not part of that patch management solution. For example, many browsers today provide the capability to install their own patch software. Patch criticality, as well as system criticality will vary. Therefore, the tactical situations regarding the patch management process will also vary. This means that the time period utilized must be a configurable parameter. Time frames for application of security-relevant software updates may be dependent upon the Information Assurance Vulnerability Management (IAVM) process. The container platform components will be configured to check for and install security-relevant software updates within an identified time period from the availability of the update. The container platform registry will ensure the images are current. The specific time period will be defined by an authoritative source (e.g., IAVM, CTOs, DTMs, and STIGs). |
It is critical to the security ond stability of the container platform and the software services running on the platform to ensure that images are deployed through a trusted software supply chain. Some key elements to having a trusted supply chain include ensuring that images deployed to the container platform come from known, trusted sources. Additionally, it is also important to check for and apply security relevant updates in a timely manner. In order to help users manage images, OpenShift uses image streams to provide a level of abstraction for the users. In this way the users can trigger automatic redeployments as images are updated. It is also possible to configure the image stream to periodically check the image source repository for any updates and automatically pull in the latest updates. The OpenShift platform can be configured to limit and control which image source repositories may be used by the platform and the users of the platform. By configuring this to only allow users to deploy images from trusted sources, lowers the risk for a user to deploy unsafe, or untested images that would be detrimental to the security and stability of the platform. |
Applicable - Configurable | Review documentation and configuration to determine if the container platform registry inspects and contains approved vendor repository latest images containing security-relevant updates within a timeframe directed by an authoritative source (IAVM, CTOs, DTMs, STIGs, etc.). If the container platform registry does not contain the latest image with security-relevant updates within the time period directed by the authoritative source, this is a finding. The container platform registry should help the user understand where the code in the environment was deployed from, and must provide controls that prevent deployment from untrusted sources or registries. |
To verify that the image source policy is configured, run the following command > oc get image.config.openshift.io/cluster -o jsonpath='{.spec.registrySources}{" AllowedRegistriesForImport: "}{.spec.allowedRegistriesForImport}{" "}' You will see an output similar to the following: {"allowedRegistries":["quay.io","registry.redhat.io","image-registry.openshift-image-registry.svc:5000"]} AllowedRegistriesForImport: [{"domainName":"quay.io","insecure":false}] If nothing is returned, this is a finding. If the registries listed under allowedRegistries, insecureRegistries, or AllowedRegistriesForImport are not from trusted sources as defined by the organization, this is a finding. |
Edit the cluster image config resource to define the allowed registries. > oc edit image.config.openshift.io/cluster The following is an example configuration, for a detailed explanation of the configuration properties see https://docs.openshift.com/container-platform/4.8/openshift_images/image-configuration.html ---------------------------------------------------------------------- apiVersion: config.openshift.io/v1 kind: Image metadata: annotations: release.openshift.io/create-only: "true" creationTimestamp: "2019-05-17T13:44:26Z" generation: 1 name: cluster resourceVersion: "8302" selfLink: /apis/config.openshift.io/v1/images/cluster uid: e34555da-78a9-11e9-b92b-06d6c7da38dc spec: allowedRegistriesForImport: - domainName: quay.io insecure: false additionalTrustedCA: name: myconfigmap registrySources: allowedRegistries: - example.com - quay.io - registry.redhat.io - image-registry.openshift-image-registry.svc:5000 - reg1.io/myrepo/myapp:latest insecureRegistries: - insecure.com status: internalRegistryHostname: image-registry.openshift-image-registry.svc:5000 ---------------------------------------------------------------------- |
CAT II | ||||||
| 218 | CCI-002605 | SRG-APP-000456-CTR-001125 | The container platform registry must contain the latest images with most recent updates and execute within the container platform runtime as authorized by IAVM, CTOs, DTMs, and STIGs. | Red Hat OpenShift Container Platform 4 registry must contain the latest images with most recent updates and execute within the container platform runtime as authorized by IAVM, CTOs, DTMs, and STIGs. |
Software supporting the container platform, images in the registry must stay up to date with the latest patches, service packs, and hot fixes. Not updating the container platform and container images will expose the organization to vulnerabilities. Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling must also be addressed expeditiously. Organization-defined time periods for updating security-relevant container platform components may vary based on a variety of factors including, for example, the security category of the information system or the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw). This requirement will apply to software patch management solutions that are used to install patches across the enclave and to applications themselves that are not part of that patch management solution. For example, many browsers today provide the capability to install their own patch software. Patch criticality, as well as system criticality will vary. Therefore, the tactical situations regarding the patch management process will also vary. This means that the time period utilized must be a configurable parameter. Time frames for application of security-relevant software updates may be dependent upon the Information Assurance Vulnerability Management (IAVM) process. The container platform components will be configured to check for and install security-relevant software updates within an identified time period from the availability of the update. The container platform registry will ensure the images are current. The specific time period will be defined by an authoritative source (e.g., IAVM, CTOs, DTMs, and STIGs). |
It is critical to the security ond stability of the container platform and the software services running on the platform to ensure that images are deployed through a trusted software supply chain. Some key elements to having a trusted supply chain include ensuring that images deployed to the container platform come from known, trusted sources. Additionally, it is also important to check for and apply security relevant updates in a timely manner. In order to help users manage images, OpenShift uses image streams to provide a level of abstraction for the users. In this way the users can trigger automatic redeployments as images are updated. It is also possible to configure the image stream to periodically check the image source repository for any updates and automatically pull in the latest updates. The OpenShift platform can be configured to limit and control which image source repositories may be used by the platform and the users of the platform. By configuring this to only allow users to deploy images from trusted sources, lowers the risk for a user to deploy unsafe, or untested images that would be detrimental to the security and stability of the platform. |
Applicable - Configurable | Review documentation and configuration to determine if the container platform registry inspects and contains approved vendor repository latest images containing security-relevant updates within a timeframe directed by an authoritative source (IAVM, CTOs, DTMs, STIGs, etc.). If the container platform registry does not contain the latest image with security-relevant updates within the time period directed by the authoritative source, this is a finding. The container platform registry should help the user understand where the code in the environment was deployed from, and must provide controls that prevent deployment from untrusted sources or registries. |
To verify that the image source policy is configured, run the following command > oc get image.config.openshift.io/cluster -o jsonpath='{.spec.registrySources}{" AllowedRegistriesForImport: "}{.spec.allowedRegistriesForImport}{" "}' You will see an output similar to the following: {"allowedRegistries":["quay.io","registry.redhat.io","image-registry.openshift-image-registry.svc:5000"]} AllowedRegistriesForImport: [{"domainName":"quay.io","insecure":false}] If nothing is returned, this is a finding. If the registries listed under allowedRegistries, insecureRegistries, or AllowedRegistriesForImport are not from trusted sources as defined by the organization, this is a finding. |
Edit the cluster image config resource to define the allowed registries. > oc edit image.config.openshift.io/cluster The following is an example configuration, for a detailed explanation of the configuration properties see https://docs.openshift.com/container-platform/4.8/openshift_images/image-configuration.html ---------------------------------------------------------------------- apiVersion: config.openshift.io/v1 kind: Image metadata: annotations: release.openshift.io/create-only: "true" creationTimestamp: "2019-05-17T13:44:26Z" generation: 1 name: cluster resourceVersion: "8302" selfLink: /apis/config.openshift.io/v1/images/cluster uid: e34555da-78a9-11e9-b92b-06d6c7da38dc spec: allowedRegistriesForImport: - domainName: quay.io insecure: false additionalTrustedCA: name: myconfigmap registrySources: allowedRegistries: - example.com - quay.io - registry.redhat.io - image-registry.openshift-image-registry.svc:5000 - reg1.io/myrepo/myapp:latest insecureRegistries: - insecure.com status: internalRegistryHostname: image-registry.openshift-image-registry.svc:5000 ---------------------------------------------------------------------- |
CAT II | ||||||
| 219 | CCI-000140 | SRG-APP-000109-CTR-000215 | CCE-90744-4 | The container platform must take appropriate action upon an audit failure. | must take appropriate action upon an audit failure. | It is critical that when the container platform is at risk of failing to process audit logs as required that it take action to mitigate the failure. Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. Responses to audit failure depend upon the nature of the failure mode. Because availability of the services provided by the container platform, approved actions in response to an audit failure are as follows: (i) If the failure was caused by the lack of audit record storage capacity, the container platform must continue generating audit records if possible (automatically restarting the audit service if necessary), overwriting the oldest audit records in a first-in-first-out manner. (ii) If audit records are sent to a centralized collection server and communication with this server is lost or the server fails, the container platform must queue audit records locally until communication is restored or until the audit records are retrieved manually. Upon restoration of the connection to the centralized collection server, action should be taken to synchronize the local audit data with the collection server. |
Applicable - Configurable | Review the configuration settings to determine how the container platform components are configured for audit failures. When the audit failure is due to the lack of audit record storage, the container platform must continue generating audit records, restarting services if necessary, and overwrite the oldest audit records in a first-in-first-out manner. If the audit failure is due to a communication to a centralized collection server, the container platform must queue audit records locally until communication is restored or the records are retrieved manually. If the container platform is not configured to handle audit failures appropriately, this is a finding. |
Verify that there is a prometheus rule to watch for audit events > oc get prometheusrule -o yaml --all-namespaces | grep apiserver_audit sum by (apiserver,instance)(rate(apiserver_audit_error_total{apiserver=~".+-apiserver"}[5m])) / sum by (apiserver,instance) (rate(apiserver_audit_event_total{apiserver=~".+-apiserver"}[5m])) > 0 If the output above is not displayed, this is a finding |
Apply the following prometheus rule apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: audit-errors namespace: openshift-kube-apiserver spec: groups: - name: apiserver-audit rules: - alert: AuditLogError annotations: summary: |- An API Server instance was unable to write audit logs. This could be triggered by the node running out of space, or a malicious actor tampering with the audit logs. description: An API Server had an error writing to an audit log. expr: | sum by (apiserver,instance)(rate(apiserver_audit_error_total{apiserver=~".+-apiserver"}[5m])) / sum by (apiserver,instance) (rate(apiserver_audit_event_total{apiserver=~".+-apiserver"}[5m])) > 0 for: 1m labels: severity: warning |
CAT II | ||||||
| 220 | CCI-002142 | SRG-APP-000317-CTR-000735 | The container platform must terminate shared/group account credentials when members leave the group. | Red Hat OpenShift Container Platform 4 must terminate shared/group account credentials when members leave the group. | If shared/group account credentials are not terminated when individuals leave the group, the user that left the group can still gain access even though they are no longer authorized. A shared/group account credential is a shared form of authentication that allows multiple individuals to access the application using a single account. There may also be instances when specific user actions need to be performed on the information system without unique user identification or authentication. Examples of credentials include passwords and group membership certificates. | Not Applicable | Determine if the container platform is configured to terminate shared/group account credentials when members leave the group. If the container platform does not terminated shared/group account credentials when members leave the group, this is a finding. |
CAT II | Not Applicable. Applicable to Identity Management Provider and not OCP. Only configurable check is to ensure OCP is configured for an IDP under SRG-APP-000023-CTR-000055. Verify with IdM service provider admins that the IdM meets the requirements. |
||||||||
| 221 | CCI-000382 | SRG-APP-000142-CTR-000325 | The container platform runtime must enforce ports, protocols, and services that adhere to the PPSM CAL. | Red Hat OpenShift Container Platform 4 runtime must enforce ports, protocols, and services that adhere to the PPSM CAL. | Ports, protocols, and services within the container platform runtime must be controlled and conform to the PPSM CAL. Those ports, protocols, and services that fall outside the PPSM CAL must be blocked by the runtime. Instructions on the PPSM can be found in DoD Instruction 8551.01 Policy. | Applicable - Configurable | Review the container platform documentation and deployment configuration to determine which ports and protocols are enabled. Verify the ports and protocols being used are not prohibited by PPSM CAL in accordance to DoD Instruction 8551.01 Policy and are necessary for the operations and applications. If any of the ports or protocols is prohibited or not necessary for the operation, this is a finding. |
Review the OpenShift documentation and configuration. (See for additional information: https://docs.openshift.com/container-platform/4.12/installing/installing_platform_agnostic/installing-platform-agnostic.html) 1. Interview the application administrator. 2. Identify the TCP/IP port numbers OpenShift is configured to utilize and is utilizing by using a combination of relevant OS commands and application configuration utilities. 3. Identify the network ports and protocols that are utilized by kube-apiserver by executing the following: oc get configmap kube-apiserver-pod -n openshift-kube-apiserver -o "jsonpath={ .data['pod\.yaml'] }" | jq '..|.containerPort?' | grep -v "null" oc get configmap kube-apiserver-pod -n openshift-kube-apiserver -o "jsonpath={ .data['pod\.yaml'] }" | jq '..|.hostPort?' | grep -v "null" oc get services -A --show-labels | grep apiserver | awk '{print $6,$8}' | grep apiserver 4. Identify the network ports and protocols that are utilized by kube-scheduler by executing the following: oc get configmap kube-scheduler-pod -n openshift-kube-scheduler -o "jsonpath={ .data['pod\.yaml'] }" | jq '..|.containerPort?' | grep -v "null" oc get services -A --show-labels | grep scheduler | awk '{print $6,$8}' | grep scheduler 5. Identify the network ports and protocols that are utilized by kube-controller-manager by executing the following: oc get configmap kube-controller-manager-pod -n openshift-kube-controller-manager -o "jsonpath={ .data['pod\.yaml'] }" | jq '..|.containerPort?' | grep -v "null" oc get services -A --show-labels | grep kube-controller 6. Identify the network ports and protocols that are utilized by etcd by executing the following: oc get configmap etcd-pod -n openshift-etcd -o "jsonpath={ .data['pod\.yaml'] }" | grep -Po '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}:[0-9]+' | sort -u Review the PPSM web page at: http://www.disa.mil/Network-Services/Enterprise-Connections/PPSM Review the PPSM Category Assurance List (CAL) directly at the following link: https://disa.deps.mil/ext/cop/iase/ppsm/Pages/cal.aspx Verify the ports used by the OpenShift are approved by the PPSM CAL. If the ports, protocols, and services have not be registered locally, this is a finding. |
Verify the accreditation documentation lists all interfaces and the ports, protocols, and services used. Register OpenShift's ports, protocols, and services with PPSM. |
CAT II | |||||||
| 222 | CCI-000160 | SRG-APP-000116-CTR-000235 | The container platform must use internal system clocks to generate audit record time stamps. | Understanding when and sequence of events for an incident is crucial to understand what may have taken place. Without a common clock, the components generating audit events could be out of synchronization and would then present a picture of the event that is warped and corrupted. To give a clear picture, it is important that the container platform and its components use a common internal clock. | Applicable - Configurable | Review the container platform configuration files to determine if the internal system clock is used for time stamps. If the container platform does not use the internal system clock to generate time stamps, this is a finding. |
CAT II | ||||||||||
| 223 | CCI-000160,CCI-001891 | SRG-APP-000116-CTR-000235 | The container platform must use internal system clocks to generate audit record time stamps. | Understanding when and sequence of events for an incident is crucial to understand what may have taken place. Without a common clock, the components generating audit events could be out of synchronization and would then present a picture of the event that is warped and corrupted. To give a clear picture, it is important that the container platform and its components use a common internal clock. | Applicable - Configurable | Review the container platform configuration files to determine if the internal system clock is used for time stamps. If the container platform does not use the internal system clock to generate time stamps, this is a finding. |
CAT II | ||||||||||
| 224 | CCI-002145 | SRG-APP-000318-CTR-000740 | The container platform must enforce organization-defined circumstances and/or usage conditions for organization-defined accounts. | Red Hat OpenShift Container Platform 4 must enforce organization-defined circumstances and/or usage conditions for organization-defined accounts. | Activity under unusual conditions can indicate hostile activity. For example, what is normal activity during business hours can indicate hostile activity if it occurs during off hours. Depending on mission needs and conditions, account usage restrictions based on conditions and circumstances may be critical to limit access to resources and data to comply with operational or mission access control requirements. Thus, the application must be configured to enforce the specific conditions or circumstances under which application accounts can be used (e.g., by restricting usage to certain days of the week, time of day, or specific durations of time). |
Not Applicable | Determine if the container platform is configured to enforce organization-defined circumstances and/or usage conditions for organization-defined accounts. If the container platform does not enforce organization-defined circumstances and/or usage conditions for organization-defined accounts, this is a finding. |
CAT II | Not Applicable. Applicable to Identity Management Provider and not OCP. Only configurable check is to ensure OCP is configured for an IDP under SRG-APP-000023-CTR-000055. Verify with IdM service provider admins that the IdM meets the requirements. |
||||||||
| 225 | CCI-001749 | SRG-APP-000131-CTR-000280 | The container platform must be built from verified packages. | Red Hat OpenShift Container Platform 4 must be built from verified packages. | It is important to patch and upgrade the container platform when patches and upgrades are available. More important is to get these patches and upgrades from a known source. To validate the authenticity of any patches and upgrades before installation, the container platform must check that the files are digitally signed by sources approved by the organization. | Applicable - Inherently Met | Review the container platform configuration to verify it has been built from packages that are digitally signed by known and approved sources. If the container platform was built from packages that are not digitally signed or are from unknown or non-approved sources, this is a finding. |
CAT II | Supporting evidence is in the following documentation https://github.com/openshift/machine-config-operator/blob/master/docs/OSUpgrades.md#questions-and-answers |
Integrity of the OpenShift platform is handled to start by the cluster version operator. Today the CVO will by default GPG verify the integrity of the release image before applying it. The release image contains a sha256 digest of machine-os-content which is used by the MCO for updates. On the host, the container runtime podman verifies the integrity of that sha256 when pulling the image, before the MCO reads its content. Hence, there is end-to-end GPG-verified integrity for the operating system updates (as well as the rest of the cluster components which run as regular containers). https://github.com/openshift/machine-config-operator/blob/master/docs/OSUpgrades.md#questions-and-answers |
|||||||
| 226 | CCI-001858 | SRG-APP-000360-CTR-000815 | The container platform must provide an immediate real-time alert to the SA and ISSO, at a minimum, of all audit failure events requiring real-time alerts. | Red Hat OpenShift Container Platform 4 must provide an immediate real-time alert to the SA and ISSO, at a minimum, of all audit failure events requiring real-time alerts. | It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without a real-time alert, security personnel may be unaware of an impending failure of the audit capability and system operation may be adversely affected. Alerts provide organizations with urgent messages. Real-time alerts provide these messages immediately (i.e., the time from event detection to alert occurs in seconds or less). |
Applicable - Configurable | Review the container platform configuration to determine if it is configured to provide an immediate real-time alert to the SA and ISSO of all audit failure events requiring real-time alerts. If the container platform is not configured to provide an immediate real-time alert, this is a finding. |
Verify that the AlertManager config includes a configured receiver. 1. From the Administrator perspective on the OpenShift web console, navigate to Administration->Cluster Settings -> Global Configuration -> Alertmanager 2. View the list of receivers, and inspect the configuration 3. Verify that at least one receiver is configured as either PagerDuty, Webhook, Email, or Slack according to the organizations policy. If an alert receiver is not configured according to the organizational policy this is a finding. |
Create a alert notification receiver 1. From the Administrator perspective on the OpenShift web console, navigate to Administration->Cluster Settings -> Global Configuration -> Alertmanager 2. Select Create Receiver 3. Set the name, and choose a Receiver Type 4. Complete the form as per the organizations policy Refer to the following documentation for more information https://docs.openshift.com/container-platform/latest/monitoring/managing-alerts.html#sending-notifications-to-external-systems_managing-alerts |
CAT II | Supporting documentation is in the following documentation https://docs.openshift.com/container-platform/latest/post_installation_configuration/configuring-alert-notifications.html https://kubernetes.io/docs/tasks/debug-application-cluster/audit/#parameter-tuning |
The OpenShift Container Platform provides an alert notification service to notify admins of critical events. |
|||||
| 227 | CCI-001464,CCI-000130 | SRG-APP-000092-CTR-000165 | The container platform must initiate session auditing upon startup. | When the container platform is started, container platform components and user services can also be started. It is important that the container platform begin auditing on startup in order to handle container platform startup events along with events for container platform components and services that begin on startup. | Applicable - Configurable | Review the container platform configuration for session audits. Ensure audit policy for session logging at startup is enabled. Verify events are written to the log. Validate system documentation is current. If the container platform is not configured to meet this requirement, this is a finding. |
CAT II | ||||||||||
| 228 | CCI-001464 | SRG-OS-000254-GPOS-00095,SRG-APP-000092-CTR-000165 | The container platform must initiate session auditing upon startup. | When the container platform is started, container platform components and user services can also be started. It is important that the container platform begin auditing on startup in order to handle container platform startup events along with events for container platform components and services that begin on startup. | Applicable - Configurable | Review the container platform configuration for session audits. Ensure audit policy for session logging at startup is enabled. Verify events are written to the log. Validate system documentation is current. If the container platform is not configured to meet this requirement, this is a finding. |
CAT II | ||||||||||
| 229 | CCI-000366 | SRG-APP-000516-CTR-001325 | Container platform components must be configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including SRGs, STIGs, NSA configuration guides, CTOs, and DTMs. | Container platform components must be configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including SRGs, STIGs, NSA configuration guides, CTOs, and DTMs. | Container platform components are part of the overall container platform, offering services that enable the container platform to fully orchestrate user containers. These components may fall outside the scope of this document, but they still must be secured. Examples of such components are DNS, routers, and firewalls. These and any other services offered by the container platform must follow the appropriate STIG or SRG for the technology offered. If a STIG or SRG is not available for the technology, then best practices for the technology must be used. For example, the Cloud Native Computing Foundation (CNCF) is an open-source organization that is working on container platform best practices. | Not Applicable | Review the container platform configuration to determine the services offered by the container platform and validate that any services that are offered are configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including SRGs, STIGs, NSA configuration guides, CTOs, and DTMs. If container platform services are not configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including SRGs, STIGs, NSA configuration guides, CTOs, and DTMs, this is a finding. |
CAT II | |||||||||
| 230 | CCI-000778 | SRG-APP-000158-CTR-000390 | The container platform must uniquely identify all network-connected nodes before establishing any connection. | Red Hat OpenShift Container Platform 4 must uniquely identify all network-connected nodes before establishing any connection. | A container platform usually consists of multiple nodes. It is important for these nodes to be uniquely identified before a connection is allowed. Without identifying the nodes, unidentified or unknown nodes may be introduced, thereby facilitating malicious activity. | Applicable - Inherently Met | Review the container platform configuration to determine if the container platform uniquely identifies all nodes before establishing a connection. If the container platform is not configured to uniquely identify all nodes before establishing the connection, this is a finding. |
CAT II | Supporting evidence is in the following documentation https://docs.openshift.com/container-platform/latest/security/certificate_types_descriptions/node-certificates.html |
Internal components are secured with two-way TLS. https://docs.openshift.com/container-platform/latest/security/certificate_types_descriptions/node-certificates.html Node certificates are signed by the cluster; they come from a certificate authority (CA) that is generated by the bootstrap process. Once the cluster is installed, the node certificates are auto-rotated. Node certificates are managed by the cluster and not the user |
|||||||
| 231 | CCI-000199 | SRG-APP-000174-CTR-000450 | The container platform must enforce a 60-day maximum password lifetime restriction. | Red Hat OpenShift Container Platform 4 must enforce a 60-day maximum password lifetime restriction. | Any password, no matter how complex, can eventually be cracked. Therefore, passwords need to be changed at specific intervals. One method of minimizing this risk is to use complex passwords and periodically change them. If the application does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the system and/or application passwords could be compromised. This requirement does not include emergency administration accounts that are meant for access to the application in case of failure. These accounts are not required to have maximum password lifetime restrictions. |
Not Applicable | Review the container platform configuration to determine if it enforces a 60-day maximum password lifetime restriction. If the container platform does not enforce a 60-day maximum password lifetime restriction, this is a finding. |
CAT II | Not Applicable. Applicable to Identity Management Provider and not OCP. Only configurable check is to ensure OCP is configured for an IDP under SRG-APP-000023-CTR-000055. Verify with IdM service provider admins that the IdM meets the requirements. |
||||||||
| 232 | CCI-001312 | SRG-APP-000266-CTR-000625 | The container platform must generate error messages that provide information necessary for corrective actions without revealing information that could be exploited by adversaries. | Red Hat OpenShift Container Platform 4 must generate error messages that provide information necessary for corrective actions without revealing information that could be exploited by adversaries. | The container platform is responsible for offering services to users. These services could be across diverse user groups and data types. To protect information about the container platform, services, users, and data, it is important during error message generation to offer enough information to diagnose the error, but not reveal information that needs to be protected. | Applicable - Inherently Met | Review documentation and logs to determine if the container platform writes sensitive information such as passwords or private keys into the logs and administrative messages. If the container platform writes sensitive or potentially harmful information into the logs and administrative messages, this is a finding. |
CAT II | Supporting evidence is in the following documentation: https://docs.openshift.com/container-platform/latest/logging/cluster-logging-visualizer.html https://docs.openshift.com/container-platform/latest/authentication/using-rbac.html |
In OpenShift, the logs depend greatly on the component. Some components would just write messages to stdout that the cluster administrator can retrieve logs through the use of the oc command. Some components emit events, and others emit a Prometheus metric which the API server would write into their logs. For the OCP components that run in a container (most operators), the usual RBAC rules would prevent a non-admin user from reading the container logs or events. OpenShift error message handling is designed to obscure or not log sensitive information which is contained inside Secrets. Error Messages from applications will need to be reviewed independently as the messages provided by the application hosted on the platform is outside the scope of the platform control. |
|||||||
| 233 | CCI-002605 | SRG-APP-000456-CTR-001130 | The container platform runtime must have updates installed within the time period directed by an authoritative source (e.g., IAVM, CTOs, DTMs, and STIGs). | Red Hat OpenShift Container Platform 4 runtime must have updates installed within the time period directed by an authoritative source (e.g., IAVM, CTOs, DTMs, and STIGs). | The container platform runtime must be carefully monitored for vulnerabilities, and when problems are detected, they must be remediated quickly. A vulnerable runtime exposes all containers it supports, as well as the host itself, to potentially significant risk. Organizations should use tools to look for Common Vulnerabilities and Exposures (CVEs) vulnerabilities in the runtimes deployed, to upgrade any instances at risk, and to ensure that orchestrators only allow deployments to properly maintained runtimes. | Not Applicable | Review documentation and configuration to determine if the container platform registry inspects and contains approved vendor repository latest images containing security-relevant updates within a timeframe directed by an authoritative source (IAVM, CTOs, DTMs, STIGs, etc.). If the container platform registry does not contain the latest image with security-relevant updates within the time period directed by the authoritative source, this is a finding. The container platform registry should help the user understand where the code in the environment was deployed from and must provide controls that prevent deployment from untrusted sources or registries. |
CAT II | The container platform and underlying operating system regularly release updates alongside Red Hat Security Advisories covering CVE patches. These updates are sent out at the same cadence of reliability as Red Hat Enterprise Linux. The organization must define how and when to update the container platform, including the synchronization of Red Hat provided updates that patch CVEs to the registry used for the container platform. Update Service Architecture Overview https://docs.openshift.com/container-platform/latest/architecture/architecture-installation.html#update-service-overview_architecture-installation |
||||||||
| 234 | CCI-000198 | SRG-APP-000173-CTR-000445 | The container platform must enforce 24 hours (one day) as the minimum password lifetime. | Red Hat OpenShift Container Platform 4 must enforce 24 hours (one day) as the minimum password lifetime. | Enforcing a minimum password lifetime helps prevent repeated password changes to defeat the password reuse or history enforcement requirement. Restricting this setting limits the user's ability to change their password. Passwords need to be changed at specific policy-based intervals; however, if the application allows the user to immediately and continually change their password, then the password could be repeatedly changed in a short period of time to defeat the organization's policy regarding password reuse. |
Not Applicable | Review the container platform configuration to determine if it enforces 24 hours/1 day as the minimum password lifetime. If the container platform does not enforce 24 hours/1 day as the minimum password lifetime, this is a finding. |
CAT II | Not Applicable. Applicable to Identity Management Provider and not OCP. Only configurable check is to ensure OCP is configured for an IDP under SRG-APP-000023-CTR-000055. Verify with IdM service provider admins that the IdM meets the requirements. |
||||||||
| 235 | CCI-001764 | SRG-APP-000384-CTR-000915 | CCE-90670-1 | The container platform must prevent component execution in accordance with organization-defined policies regarding software program usage and restrictions, and/or rules authorizing the terms and conditions of software program usage. | Red Hat OpenShift Container Platform 4 must prevent the installation of patches, service packs, device drivers, or operating system components without verification they have been digitally signed using a certificate that is recognized and approved by the organization. | The container platform may offer components such as DNS services, firewall services, router services, or web services that are not required by every organization to meet their needs. Container platform components may also add capabilities that run counter to the mission or that provide users with functionality that exceeds mission requirements. To meet the requirements of an organization, the container platform must have a method to remove or disable components not required to meet the organization's mission. | Applicable - Configurable | Review documentation and configuration setting to determine if policies, rules, or restrictions exist regarding usage of container platform components. If no such no restrictions are in place, this is not a finding. Identify any components the organization requires to be disabled or removed and configure the container platform according to that policy. If the container platform components are not disabled or removed according to the organization's policy, this is a finding. |
Run the following command to retrieve the Cluster Version objects in the system: > oc get clusterversion version Make sure the Cluster Version Operator is installed and the AVAILABLE is True. |
By default, the integrity of RH CoreOS is checked by cluster version operator on OpenShift platform. If the integrity is not verified, reinstall of the cluster may be necessary. | CAT II | ||||||
| 236 | CCI-001764 | SRG-APP-000384-CTR-000915 | CCE-90671-9 | The container platform must prevent component execution in accordance with organization-defined policies regarding software program usage and restrictions, and/or rules authorizing the terms and conditions of software program usage. | Red Hat OpenShift Container Platform 4 must prevent the installation of patches, service packs, device drivers, or operating system components without verification they have been digitally signed using a certificate that is recognized and approved by the organization. | The container platform may offer components such as DNS services, firewall services, router services, or web services that are not required by every organization to meet their needs. Container platform components may also add capabilities that run counter to the mission or that provide users with functionality that exceeds mission requirements. To meet the requirements of an organization, the container platform must have a method to remove or disable components not required to meet the organization's mission. | Applicable - Configurable | Review documentation and configuration setting to determine if policies, rules, or restrictions exist regarding usage of container platform components. If no such no restrictions are in place, this is not a finding. Identify any components the organization requires to be disabled or removed and configure the container platform according to that policy. If the container platform components are not disabled or removed according to the organization's policy, this is a finding. |
Run the following command to retrieve the Cluster Version objects in the system: > oc get clusterversion version -o yaml Make sure verified is true under status history for each item. If not, this is a finding. |
By default, the integrity of RH CoreOS is checked by cluster version operator on OpenShift platform. If the integrity is not verified, reinstall of the cluster may be necessary. | CAT II | ||||||
| 237 | CCI-002418 | SRG-APP-000439-CTR-001080 | The application must protect the confidentiality and integrity of transmitted information. | The application must protect the confidentiality and integrity of transmitted information. | Without protection of the transmitted information, confidentiality and integrity may be compromised since unprotected communications can be intercepted and either read or altered. This requirement applies only to those applications that either are distributed or can allow access to data non-locally. Use of this requirement will be limited to situations where the data owner has a strict requirement for ensuring data integrity and confidentiality is maintained at every step of the data transfer and handling process. When transmitting data, applications need to leverage transmission protection mechanisms, such as TLS, TLS VPNs, or IPsec. Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa. |
Applicable - Configurable | Review container platform configuration to determine if it is using a transmission method that maintains the confidentiality and integrity of information during transmission. If a transmission method is not being used that maintains the confidentiality and integrity of the data, this is a finding. |
Verify that routes and ingress are using secured transmission ports and protocols by executing the following: oc get routes --all-namespaces Review the ingress ports, if the Ingress is not using a secure TLS transport, this is a finding. |
Delete any Route or Ingress that does not use a secure transport. oc delete route <NAME> -n <NAMESPACE> or oc delete ingress <NAME> -n <NAMESPACE> |
CAT II | |||||||
| 238 | CCI-002038 | SRG-APP-000389-CTR-000925 | The container platform must require users to reauthenticate when organization-defined circumstances or situations require reauthentication. | Red Hat OpenShift Container Platform 4 must require users to reauthenticate when organization-defined circumstances or situations require reauthentication. | Controlling user access is paramount in securing the container platform. During a user's access to the container platform, events may occur that change the user's access and which require reauthentication. For instance, if the capability to change security roles or escalate privileges is implemented, it is critical the user reauthenticate. In addition to the reauthentication requirements associated with change in security roles or privilege escalation, organizations may require reauthentication of individuals in other situations, including (but not limited to) the following circumstances: (i) When authenticators change; (ii) When roles change; (iii) When security categories of information systems change; (iv) When the execution of privileged functions occurs; (v) After a fixed period of time; or (vi) Periodically. Within the DoD, the minimum circumstances requiring reauthentication are privilege escalation and role changes. |
Applicable - Inherently Met | Review documentation and configuration to determine if the container platform requires a user to reauthenticate when organization-defined circumstances or situations are met. If the container platform does not meet this requirement, this is a finding. |
CAT II | Supporting evidence is in the following documentation https://docs.openshift.com/container-platform/latest/authentication/using-rbac.html |
The OpenShift Container Platform does not required a user to re-authenticate when changes to the RBAC policy, or permissions to a service/object change in the system. These changes are applied and effective immediately and do not require the user to first logout. https://docs.openshift.com/container-platform/latest/authentication/using-rbac.html |
|||||||
| 239 | CCI-001682 | SRG-APP-000234-CTR-000590 | The container platform must never automatically remove or disable emergency accounts. | Red Hat OpenShift Container Platform 4 must never automatically remove or disable emergency accounts. | 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. |
Applicable - Inherently Met | Review the container platform to determine if emergency accounts are automatically removed or disabled. If emergency accounts are automatically removed or disabled, this is a finding. |
CAT II | Supporting evidence is in the following documentation https://docs.openshift.com/container-platform/latest/post_installation_configuration/preparing-for-users.html |
No users are ever created or removed automatically. Any manually created emergency accounts would persist, and it is recommended that normal cluster authentication be delegated to an external IdP as recommended in SRG-APP-000023-CTR-000055. |