OCP 4.21 Compliance Status

Ensure that application Namespaces have Network Policies defined.
Use network policies to isolate traffic in your cluster network.

Configure System Cryptography Policy
To configure the system cryptography policy to use ciphers only from the DEFAULT:NO-SHA1 policy, create a MachineConfig as follows:

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
labels:
machineconfiguration.openshift.io/role: master
name: 50-master-configure-crypto-policy
spec:
config:
ignition:
version: 3.1.0
systemd:
units:
- name: configure-crypto-policy.service
enabled: true
contents: |
[Unit]
Before=kubelet.service
[Service]
Type=oneshot
ExecStart=update-crypto-policies --set DEFAULT:NO-SHA1 RemainAfterExit=yes
[Install]
WantedBy=multi-user.target

This will configure the crypto policy appropriately in all the nodes labeled with the "master" role.

Note that this needs to be done for each MachineConfigPool

For more information on how to configure nodes with the Machine Config Operator see the relevant documentation ( https://docs.openshift.com/container-platform/4.6/post_installation_configuration/machine-configuration-tasks.html ).

The rule checks if settings for selected crypto policy are configured as expected. Configuration files in the /etc/crypto-policies/back-ends are either symlinks to correct files provided by Crypto-policies package or they are regular files in case crypto policy customizations are applied. Crypto policies may be customized by crypto policy modules, in which case it is delimited from the base policy using a colon.

Prevent Login to Accounts With Empty Password
If an account is configured for password authentication but does not have an assigned password, it may be possible to log into the account without authentication. Remove any instances of the nullok in /etc/pam.d/system-auth and /etc/pam.d/password-auth to prevent logins with empty passwords.

Configure System Cryptography Policy
To configure the system cryptography policy to use ciphers only from the DEFAULT:NO-SHA1 policy, create a MachineConfig as follows:

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
labels:
machineconfiguration.openshift.io/role: master
name: 50-master-configure-crypto-policy
spec:
config:
ignition:
version: 3.1.0
systemd:
units:
- name: configure-crypto-policy.service
enabled: true
contents: |
[Unit]
Before=kubelet.service
[Service]
Type=oneshot
ExecStart=update-crypto-policies --set DEFAULT:NO-SHA1 RemainAfterExit=yes
[Install]
WantedBy=multi-user.target

This will configure the crypto policy appropriately in all the nodes labeled with the "master" role.

Note that this needs to be done for each MachineConfigPool

For more information on how to configure nodes with the Machine Config Operator see the relevant documentation ( https://docs.openshift.com/container-platform/4.6/post_installation_configuration/machine-configuration-tasks.html ).

The rule checks if settings for selected crypto policy are configured as expected. Configuration files in the /etc/crypto-policies/back-ends are either symlinks to correct files provided by Crypto-policies package or they are regular files in case crypto policy customizations are applied. Crypto policies may be customized by crypto policy modules, in which case it is delimited from the base policy using a colon.

Prevent Login to Accounts With Empty Password
If an account is configured for password authentication but does not have an assigned password, it may be possible to log into the account without authentication. Remove any instances of the nullok in /etc/pam.d/system-auth and /etc/pam.d/password-auth to prevent logins with empty passwords.

Configure the Encryption Provider Cipher
When you enable etcd encryption, the following OpenShift API server and Kubernetes API server resources are encrypted:

* Secrets
* ConfigMaps
* Routes
* OAuth access tokens
* OAuth authorize tokens

When you enable etcd encryption, encryption keys are created. These keys are rotated on a weekly basis. You must have these keys in order to restore from an etcd backup.

To ensure the correct cipher, set the encryption type to aescbc or aesgcm in the apiserver object which configures the API server itself.

spec:
encryption:
type: aescbc

For more information, follow the relevant documentation ( https://docs.openshift.com/container-platform/latest/security/encrypting-etcd.html ).

Ensure that Audit Log Forwarding Is Enabled
OpenShift audit works at the API server level, logging all requests coming to the server. Audit is on by default and the best practice is to ship audit logs off the cluster for retention. The cluster-logging-operator is able to do this with the

ClusterLogForwarders

resource. The forementioned resource can be configured to logs to different third party systems. For more information on this, please reference the official documentation: https://docs.openshift.com/container-platform/latest/observability/logging/logging-6.0/log6x-clf.html

Ensure that the cluster's audit profile is properly set
OpenShift can audit the details of requests made to the API server through the standard Kubernetes audit capabilities.

In OpenShift, auditing of the API Server is on by default. Audit provides a security-relevant chronological set of records documenting the sequence of activities that have affected system by individual users, administrators, or other components of the system. Audit works at the API server level, logging all requests coming to the server. Each audit log contains two entries:

The request line containing:

* A Unique ID allowing to match the response line (see #2)
* The source IP of the request
* The HTTP method being invoked
* The original user invoking the operation
* The impersonated user for the operation (self meaning himself)
* The impersonated group for the operation (lookup meaning user's group)
* The namespace of the request or none
* The URI as requested

The response line containing:

* The aforementioned unique ID
* The response code

For more information on how to configure the audit profile, please visit the documentation ( https://docs.openshift.com/container-platform/latest/security/audit-log-policy-config.html )

Configure An Identity Provider
For users to interact with OpenShift Container Platform, they must first authenticate to the cluster. The authentication layer identifies the user associated with requests to the OpenShift Container Platform API. The authorization layer then uses information about the requesting user to determine if the request is allowed. Understanding authentication | Authentication | OpenShift Container Platform ( https://docs.openshift.com/container-platform/4.6/logging/cluster-logging-external.html )

The OpenShift Container Platform includes a built-in OAuth server for token-based authentication. Developers and administrators obtain OAuth access tokens to authenticate themselves to the API. It is recommended for an administrator to configure OAuth to specify an identity provider after the cluster is installed. User access to the cluster is managed through the identity provider. Understanding identity provider configuration | Authentication | OpenShift Container Platform ( https://docs.openshift.com/container-platform/4.6/authentication/understanding-identity-provider.html )

OpenShift includes built-in role based access control (RBAC) to determine whether a user is allowed to perform a given action within the cluster. Roles can have cluster scope or local (i.e. project) scope. Using RBAC to define and apply permissions | Authentication | OpenShift Container Platform ( https://docs.openshift.com/container-platform/4.6/authentication/using-rbac.html )

Ensure that the Ingress Controller only makes use of Strong Cryptographic Ciphers
Ensure that the Ingress Controller is configured to only use strong cryptographic ciphers.

Ensure that the kubeadmin secret has been removed
The kubeadmin user is meant to be a temporary user used for bootstrapping purposes. It is preferable to assign system administrators whose users are backed by an Identity Provider.

Make sure to remove the user as described in the documentation ( https://docs.openshift.com/container-platform/latest/authentication/remove-kubeadmin.html )

Allowed registries are configured
The configuration registrySources.allowedRegistries determines the permitted registries that the OpenShift container runtime can access for builds and pods. This configuration setting ensures that all registries other than those specified are blocked. You can set the allowed repositories by applying the following manifest using

oc patch

, e.g. if you save the following snippet to

/tmp/allowed-registries-patch.yaml

spec:
registrySources:
allowedRegistries:
- my-trusted-registry.internal.example.com

you would call

oc patch image.config.openshift.io cluster --patch="$(cat /tmp/allowed-registries-patch.yaml)" --type=merge

Allowed registries for import are configured
The configuration allowedRegistriesForImport limits the container image registries from which normal users may import images. This is important to control, as a user who can stand up a malicious registry can then import content which claims to include the SHAs of legitimate content layers. You can set the allowed repositories for import by applying the following manifest using

oc patch

, e.g. if you save the following snippet to

/tmp/allowed-import-registries-patch.yaml

spec:
allowedRegistriesForImport:
- domainName: my-trusted-registry.internal.example.com
insecure: false

you would call

oc patch image.config.openshift.io cluster --patch="$(cat /tmp/allowed-import-registries-patch.yaml)" --type=merge

Configure the Encryption Provider Cipher
When you enable etcd encryption, the following OpenShift API server and Kubernetes API server resources are encrypted:

* Secrets
* ConfigMaps
* Routes
* OAuth access tokens
* OAuth authorize tokens

When you enable etcd encryption, encryption keys are created. These keys are rotated on a weekly basis. You must have these keys in order to restore from an etcd backup.

To ensure the correct cipher, set the encryption type to aescbc or aesgcm in the apiserver object which configures the API server itself.

spec:
encryption:
type: aescbc

For more information, follow the relevant documentation ( https://docs.openshift.com/container-platform/latest/security/encrypting-etcd.html ).

Allowed registries are configured
The configuration registrySources.allowedRegistries determines the permitted registries that the OpenShift container runtime can access for builds and pods. This configuration setting ensures that all registries other than those specified are blocked. You can set the allowed repositories by applying the following manifest using

oc patch

, e.g. if you save the following snippet to

/tmp/allowed-registries-patch.yaml

spec:
registrySources:
allowedRegistries:
- my-trusted-registry.internal.example.com

you would call

oc patch image.config.openshift.io cluster --patch="$(cat /tmp/allowed-registries-patch.yaml)" --type=merge

Allowed registries for import are configured
The configuration allowedRegistriesForImport limits the container image registries from which normal users may import images. This is important to control, as a user who can stand up a malicious registry can then import content which claims to include the SHAs of legitimate content layers. You can set the allowed repositories for import by applying the following manifest using

oc patch

, e.g. if you save the following snippet to

/tmp/allowed-import-registries-patch.yaml

spec:
allowedRegistriesForImport:
- domainName: my-trusted-registry.internal.example.com
insecure: false

you would call

oc patch image.config.openshift.io cluster --patch="$(cat /tmp/allowed-import-registries-patch.yaml)" --type=merge

Record Events that Modify the System's Discretionary Access Controls - chmod
At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix.rules in the directory /etc/audit/rules.d :

-a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod

Record Events that Modify the System's Discretionary Access Controls - chown
At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix.rules in the directory /etc/audit/rules.d :

-a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

Record Any Attempts to Run chcon
At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix.rules in the directory /etc/audit/rules.d :

-a always,exit -F path=/usr/bin/chcon -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules :

-a always,exit -F path=/usr/bin/chcon -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run restorecon
At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix.rules in the directory /etc/audit/rules.d :

-a always,exit -F path=/usr/sbin/restorecon -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules :

-a always,exit -F path=/usr/sbin/restorecon -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run semanage
At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix.rules in the directory /etc/audit/rules.d :

-a always,exit -F path=/usr/sbin/semanage -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules :

-a always,exit -F path=/usr/sbin/semanage -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run setfiles
At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix.rules in the directory /etc/audit/rules.d :

-a always,exit -F path=/usr/sbin/setfiles -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules :

-a always,exit -F path=/usr/sbin/setfiles -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run setsebool
At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix.rules in the directory /etc/audit/rules.d :

-a always,exit -F path=/usr/sbin/setsebool -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules :

-a always,exit -F path=/usr/sbin/setsebool -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run seunshare
At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix.rules in the directory /etc/audit/rules.d :

-a always,exit -F path=/usr/sbin/seunshare -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules :

-a always,exit -F path=/usr/sbin/seunshare -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on Kernel Module Unloading - delete_module
To capture kernel module loading and unloading events, use the following line, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:

-a always,exit -F arch= ARCH -S delete_module -F key=modules

Place to add the line depends on a way auditd daemon is configured. If it is configured to use the augenrules program (the default), add the line to a file with suffix.rules in the directory /etc/audit/rules.d. If the auditd daemon is configured to use the auditctl utility, add the line to file /etc/audit/audit.rules.

Ensure auditd Collects Information on Kernel Module Loading and Unloading - finit_module
To capture kernel module loading and unloading events, use the following line, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:

-a always,exit -F arch= ARCH -S finit_module -F key=modules

Place to add the line depends on a way auditd daemon is configured. If it is configured to use the augenrules program (the default), add the line to a file with suffix.rules in the directory /etc/audit/rules.d. If the auditd daemon is configured to use the auditctl utility, add the line to file /etc/audit/audit.rules.

Ensure auditd Collects Information on Kernel Module Loading - init_module
To capture kernel module loading and unloading events, use the following line, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:

-a always,exit -F arch= ARCH -S init_module -F key=modules

Place to add the line depends on a way auditd daemon is configured. If it is configured to use the augenrules program (the default), add the line to a file with suffix.rules in the directory /etc/audit/rules.d. If the auditd daemon is configured to use the auditctl utility, add the line to file /etc/audit/audit.rules.

Record Attempts to Alter Logon and Logout Events
The audit system already collects login information for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix.rules in the directory /etc/audit/rules.d in order to watch for attempted manual edits of files involved in storing logon events:

-w /var/log/tallylog -p wa -k logins
-w /var/run/faillock -p wa -k logins
-w /var/log/lastlog -p wa -k logins

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file in order to watch for unattempted manual edits of files involved in storing logon events:

-w /var/log/tallylog -p wa -k logins
-w /var/run/faillock -p wa -k logins
-w /var/log/lastlog -p wa -k logins

Record Attempts to Alter Logon and Logout Events - faillock
The audit system already collects login information for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix.rules in the directory /etc/audit/rules.d :

-w /var/run/faillock -p wa -k logins

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules :

-w /var/run/faillock -p wa -k logins

Record Attempts to Alter Logon and Logout Events - lastlog
The audit system already collects login information for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix.rules in the directory /etc/audit/rules.d :

-w /var/log/lastlog -p wa -k logins

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules :

-w /var/log/lastlog -p wa -k logins

Record Attempts to Alter Logon and Logout Events - tallylog
The audit system already collects login information for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix.rules in the directory /etc/audit/rules.d :

-w /var/log/tallylog -p wa -k logins

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules :

-w /var/log/tallylog -p wa -k logins

Record Events that Modify the System's Network Environment
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix.rules in the directory /etc/audit/rules.d , setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:

-a always,exit -F arch=ARCH -S sethostname,setdomainname -F key=audit_rules_networkconfig_modification
-w /etc/issue -p wa -k audit_rules_networkconfig_modification
-w /etc/issue.net -p wa -k audit_rules_networkconfig_modification
-w /etc/hosts -p wa -k audit_rules_networkconfig_modification

-w /etc/sysconfig/network -p wa -k audit_rules_networkconfig_modification

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:

-a always,exit -F arch=ARCH -S sethostname,setdomainname -F key=audit_rules_networkconfig_modification
-w /etc/issue -p wa -k audit_rules_networkconfig_modification
-w /etc/issue.net -p wa -k audit_rules_networkconfig_modification
-w /etc/hosts -p wa -k audit_rules_networkconfig_modification
-w /etc/sysconfig/network -p wa -k audit_rules_networkconfig_modification

Ensure auditd Collects System Administrator Actions
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix.rules in the directory /etc/audit/rules.d :

-w /etc/sudoers -p wa -k actions

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules :

-w /etc/sudoers -p wa -k actions

If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix.rules in the directory /etc/audit/rules.d :

-w /etc/sudoers.d/ -p wa -k actions

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules :

-w /etc/sudoers.d/ -p wa -k actions

Record attempts to alter time through adjtimex
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix.rules in the directory /etc/audit/rules.d :

-a always,exit -F arch=b32 -S adjtimex -F key=audit_time_rules

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S adjtimex -F key=audit_time_rules

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S adjtimex -F key=audit_time_rules

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S adjtimex -F key=audit_time_rules

The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls:

-a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=audit_time_rules

Record Attempts to Alter Time Through clock_settime
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix.rules in the directory /etc/audit/rules.d :

-a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=time-change

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=time-change

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=time-change

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=time-change

The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls:

-a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=audit_time_rules

Record attempts to alter time through settimeofday
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix.rules in the directory /etc/audit/rules.d :

-a always,exit -F arch=b32 -S settimeofday -F key=audit_time_rules

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S settimeofday -F key=audit_time_rules

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S settimeofday -F key=audit_time_rules

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S settimeofday -F key=audit_time_rules

The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls:

-a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=audit_time_rules

Record Attempts to Alter Time Through stime
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix.rules in the directory /etc/audit/rules.d for both 32 bit and 64 bit systems:

-a always,exit -F arch=b32 -S stime -F key=audit_time_rules

Since the 64 bit version of the "stime" system call is not defined in the audit lookup table, the corresponding "-F arch=b64" form of this rule is not expected to be defined on 64 bit systems (the aforementioned "-F arch=b32" stime rule form itself is sufficient for both 32 bit and 64 bit systems). If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file for both 32 bit and 64 bit systems:

-a always,exit -F arch=b32 -S stime -F key=audit_time_rules

Since the 64 bit version of the "stime" system call is not defined in the audit lookup table, the corresponding "-F arch=b64" form of this rule is not expected to be defined on 64 bit systems (the aforementioned "-F arch=b32" stime rule form itself is sufficient for both 32 bit and 64 bit systems). The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined system calls:

-a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=audit_time_rules

Record Attempts to Alter the localtime File
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix.rules in the directory /etc/audit/rules.d :

-w /etc/localtime -p wa -k audit_time_rules

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules :

-w /etc/localtime -p wa -k audit_time_rules

Record Events that Modify User/Group Information
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix.rules in the directory /etc/audit/rules.d , in order to capture events that modify account changes:

-w /etc/group -p wa -k audit_rules_usergroup_modification
-w /etc/passwd -p wa -k audit_rules_usergroup_modification
-w /etc/gshadow -p wa -k audit_rules_usergroup_modification
-w /etc/shadow -p wa -k audit_rules_usergroup_modification
-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file, in order to capture events that modify account changes:

-w /etc/group -p wa -k audit_rules_usergroup_modification
-w /etc/passwd -p wa -k audit_rules_usergroup_modification
-w /etc/gshadow -p wa -k audit_rules_usergroup_modification
-w /etc/shadow -p wa -k audit_rules_usergroup_modification
-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

Set type of computer node name logging in audit logs
To configure Audit daemon to use a unique identifier as computer node name in the audit events, set name_format to hostname in /etc/audit/auditd.conf.

Disable GSSAPI Authentication
Unless needed, SSH should not permit extraneous or unnecessary authentication mechanisms like GSSAPI.

The default SSH configuration disallows authentications based on GSSAPI. The appropriate configuration is used if no value is set for GSSAPIAuthentication.

To explicitly disable GSSAPI authentication, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf :

GSSAPIAuthentication no

Disable SSH Support for User Known Hosts
SSH can allow system users to connect to systems if a cache of the remote systems public keys is available. This should be disabled.

To ensure this behavior is disabled, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf :

IgnoreUserKnownHosts yes

Enable Randomized Layout of Virtual Address Space
To set the runtime status of the kernel.randomize_va_space kernel parameter, run the following command:

$ sudo sysctl -w kernel.randomize_va_space=2

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d :

kernel.randomize_va_space = 2

Disable Access to Network bpf() Syscall From Unprivileged Processes
To set the runtime status of the kernel.unprivileged_bpf_disabled kernel parameter, run the following command:

$ sudo sysctl -w kernel.unprivileged_bpf_disabled=1

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d :

kernel.unprivileged_bpf_disabled = 1

Restrict usage of ptrace to descendant processes
To set the runtime status of the kernel.yama.ptrace_scope kernel parameter, run the following command:

$ sudo sysctl -w kernel.yama.ptrace_scope=1

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d :

kernel.yama.ptrace_scope = 1

Harden the operation of the BPF just-in-time compiler
To set the runtime status of the net.core.bpf_jit_harden kernel parameter, run the following command:

$ sudo sysctl -w net.core.bpf_jit_harden=2

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d :

net.core.bpf_jit_harden = 2

Record Events that Modify the System's Discretionary Access Controls - chmod
At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix.rules in the directory /etc/audit/rules.d :

-a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod

Record Events that Modify the System's Discretionary Access Controls - chown
At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix.rules in the directory /etc/audit/rules.d :

-a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

Record Any Attempts to Run chcon
At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix.rules in the directory /etc/audit/rules.d :

-a always,exit -F path=/usr/bin/chcon -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules :

-a always,exit -F path=/usr/bin/chcon -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run restorecon
At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix.rules in the directory /etc/audit/rules.d :

-a always,exit -F path=/usr/sbin/restorecon -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules :

-a always,exit -F path=/usr/sbin/restorecon -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run semanage
At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix.rules in the directory /etc/audit/rules.d :

-a always,exit -F path=/usr/sbin/semanage -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules :

-a always,exit -F path=/usr/sbin/semanage -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run setfiles
At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix.rules in the directory /etc/audit/rules.d :

-a always,exit -F path=/usr/sbin/setfiles -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules :

-a always,exit -F path=/usr/sbin/setfiles -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run setsebool
At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix.rules in the directory /etc/audit/rules.d :

-a always,exit -F path=/usr/sbin/setsebool -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules :

-a always,exit -F path=/usr/sbin/setsebool -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run seunshare
At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix.rules in the directory /etc/audit/rules.d :

-a always,exit -F path=/usr/sbin/seunshare -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules :

-a always,exit -F path=/usr/sbin/seunshare -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on Kernel Module Unloading - delete_module
To capture kernel module loading and unloading events, use the following line, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:

-a always,exit -F arch= ARCH -S delete_module -F key=modules

Place to add the line depends on a way auditd daemon is configured. If it is configured to use the augenrules program (the default), add the line to a file with suffix.rules in the directory /etc/audit/rules.d. If the auditd daemon is configured to use the auditctl utility, add the line to file /etc/audit/audit.rules.

Ensure auditd Collects Information on Kernel Module Loading and Unloading - finit_module
To capture kernel module loading and unloading events, use the following line, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:

-a always,exit -F arch= ARCH -S finit_module -F key=modules

Place to add the line depends on a way auditd daemon is configured. If it is configured to use the augenrules program (the default), add the line to a file with suffix.rules in the directory /etc/audit/rules.d. If the auditd daemon is configured to use the auditctl utility, add the line to file /etc/audit/audit.rules.

Ensure auditd Collects Information on Kernel Module Loading - init_module
To capture kernel module loading and unloading events, use the following line, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:

-a always,exit -F arch= ARCH -S init_module -F key=modules

Place to add the line depends on a way auditd daemon is configured. If it is configured to use the augenrules program (the default), add the line to a file with suffix.rules in the directory /etc/audit/rules.d. If the auditd daemon is configured to use the auditctl utility, add the line to file /etc/audit/audit.rules.

Record Attempts to Alter Logon and Logout Events
The audit system already collects login information for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix.rules in the directory /etc/audit/rules.d in order to watch for attempted manual edits of files involved in storing logon events:

-w /var/log/tallylog -p wa -k logins
-w /var/run/faillock -p wa -k logins
-w /var/log/lastlog -p wa -k logins

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file in order to watch for unattempted manual edits of files involved in storing logon events:

-w /var/log/tallylog -p wa -k logins
-w /var/run/faillock -p wa -k logins
-w /var/log/lastlog -p wa -k logins

Record Attempts to Alter Logon and Logout Events - faillock
The audit system already collects login information for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix.rules in the directory /etc/audit/rules.d :

-w /var/run/faillock -p wa -k logins

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules :

-w /var/run/faillock -p wa -k logins

Record Attempts to Alter Logon and Logout Events - lastlog
The audit system already collects login information for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix.rules in the directory /etc/audit/rules.d :

-w /var/log/lastlog -p wa -k logins

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules :

-w /var/log/lastlog -p wa -k logins

Record Attempts to Alter Logon and Logout Events - tallylog
The audit system already collects login information for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix.rules in the directory /etc/audit/rules.d :

-w /var/log/tallylog -p wa -k logins

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules :

-w /var/log/tallylog -p wa -k logins

Record Events that Modify the System's Network Environment
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix.rules in the directory /etc/audit/rules.d , setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:

-a always,exit -F arch=ARCH -S sethostname,setdomainname -F key=audit_rules_networkconfig_modification
-w /etc/issue -p wa -k audit_rules_networkconfig_modification
-w /etc/issue.net -p wa -k audit_rules_networkconfig_modification
-w /etc/hosts -p wa -k audit_rules_networkconfig_modification

-w /etc/sysconfig/network -p wa -k audit_rules_networkconfig_modification

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:

-a always,exit -F arch=ARCH -S sethostname,setdomainname -F key=audit_rules_networkconfig_modification
-w /etc/issue -p wa -k audit_rules_networkconfig_modification
-w /etc/issue.net -p wa -k audit_rules_networkconfig_modification
-w /etc/hosts -p wa -k audit_rules_networkconfig_modification
-w /etc/sysconfig/network -p wa -k audit_rules_networkconfig_modification

Ensure auditd Collects System Administrator Actions
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix.rules in the directory /etc/audit/rules.d :

-w /etc/sudoers -p wa -k actions

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules :

-w /etc/sudoers -p wa -k actions

If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix.rules in the directory /etc/audit/rules.d :

-w /etc/sudoers.d/ -p wa -k actions

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules :

-w /etc/sudoers.d/ -p wa -k actions

Record attempts to alter time through adjtimex
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix.rules in the directory /etc/audit/rules.d :

-a always,exit -F arch=b32 -S adjtimex -F key=audit_time_rules

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S adjtimex -F key=audit_time_rules

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S adjtimex -F key=audit_time_rules

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S adjtimex -F key=audit_time_rules

The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls:

-a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=audit_time_rules

Record Attempts to Alter Time Through clock_settime
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix.rules in the directory /etc/audit/rules.d :

-a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=time-change

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=time-change

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=time-change

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=time-change

The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls:

-a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=audit_time_rules

Record attempts to alter time through settimeofday
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix.rules in the directory /etc/audit/rules.d :

-a always,exit -F arch=b32 -S settimeofday -F key=audit_time_rules

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S settimeofday -F key=audit_time_rules

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S settimeofday -F key=audit_time_rules

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S settimeofday -F key=audit_time_rules

The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls:

-a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=audit_time_rules

Record Attempts to Alter Time Through stime
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix.rules in the directory /etc/audit/rules.d for both 32 bit and 64 bit systems:

-a always,exit -F arch=b32 -S stime -F key=audit_time_rules

Since the 64 bit version of the "stime" system call is not defined in the audit lookup table, the corresponding "-F arch=b64" form of this rule is not expected to be defined on 64 bit systems (the aforementioned "-F arch=b32" stime rule form itself is sufficient for both 32 bit and 64 bit systems). If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file for both 32 bit and 64 bit systems:

-a always,exit -F arch=b32 -S stime -F key=audit_time_rules

Since the 64 bit version of the "stime" system call is not defined in the audit lookup table, the corresponding "-F arch=b64" form of this rule is not expected to be defined on 64 bit systems (the aforementioned "-F arch=b32" stime rule form itself is sufficient for both 32 bit and 64 bit systems). The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined system calls:

-a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=audit_time_rules

Record Attempts to Alter the localtime File
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix.rules in the directory /etc/audit/rules.d :

-w /etc/localtime -p wa -k audit_time_rules

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules :

-w /etc/localtime -p wa -k audit_time_rules

Record Events that Modify User/Group Information
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix.rules in the directory /etc/audit/rules.d , in order to capture events that modify account changes:

-w /etc/group -p wa -k audit_rules_usergroup_modification
-w /etc/passwd -p wa -k audit_rules_usergroup_modification
-w /etc/gshadow -p wa -k audit_rules_usergroup_modification
-w /etc/shadow -p wa -k audit_rules_usergroup_modification
-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file, in order to capture events that modify account changes:

-w /etc/group -p wa -k audit_rules_usergroup_modification
-w /etc/passwd -p wa -k audit_rules_usergroup_modification
-w /etc/gshadow -p wa -k audit_rules_usergroup_modification
-w /etc/shadow -p wa -k audit_rules_usergroup_modification
-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

Set type of computer node name logging in audit logs
To configure Audit daemon to use a unique identifier as computer node name in the audit events, set name_format to hostname in /etc/audit/auditd.conf.

Disable GSSAPI Authentication
Unless needed, SSH should not permit extraneous or unnecessary authentication mechanisms like GSSAPI.

The default SSH configuration disallows authentications based on GSSAPI. The appropriate configuration is used if no value is set for GSSAPIAuthentication.

To explicitly disable GSSAPI authentication, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf :

GSSAPIAuthentication no

Disable SSH Support for User Known Hosts
SSH can allow system users to connect to systems if a cache of the remote systems public keys is available. This should be disabled.

To ensure this behavior is disabled, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf :

IgnoreUserKnownHosts yes

Enable Randomized Layout of Virtual Address Space
To set the runtime status of the kernel.randomize_va_space kernel parameter, run the following command:

$ sudo sysctl -w kernel.randomize_va_space=2

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d :

kernel.randomize_va_space = 2

Disable Access to Network bpf() Syscall From Unprivileged Processes
To set the runtime status of the kernel.unprivileged_bpf_disabled kernel parameter, run the following command:

$ sudo sysctl -w kernel.unprivileged_bpf_disabled=1

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d :

kernel.unprivileged_bpf_disabled = 1

Restrict usage of ptrace to descendant processes
To set the runtime status of the kernel.yama.ptrace_scope kernel parameter, run the following command:

$ sudo sysctl -w kernel.yama.ptrace_scope=1

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d :

kernel.yama.ptrace_scope = 1

Harden the operation of the BPF just-in-time compiler
To set the runtime status of the net.core.bpf_jit_harden kernel parameter, run the following command:

$ sudo sysctl -w net.core.bpf_jit_harden=2

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d :

net.core.bpf_jit_harden = 2

Restrict Access to Kernel Message Buffer
To set the runtime status of the kernel.dmesg_restrict kernel parameter, run the following command:

$ sudo sysctl -w kernel.dmesg_restrict=1

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d :

kernel.dmesg_restrict = 1

Restrict Access to Kernel Message Buffer
To set the runtime status of the kernel.dmesg_restrict kernel parameter, run the following command:

$ sudo sysctl -w kernel.dmesg_restrict=1

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d :

kernel.dmesg_restrict = 1

Restrict Automounting of Service Account Tokens
Service accounts tokens should not be mounted in pods except where the workload running in the pod explicitly needs to communicate with the API server. To ensure pods do not automatically mount tokens, set automountServiceAccountToken to false.

Ensure Usage of Unique Service Accounts
Using the default service account prevents accurate application rights review and audit tracing. Instead of default , create a new and unique service account with the following command:

$ oc create sa service_account_name

where service_account_name is the name of a service account that is needed in the project namespace.

Apply Security Context to Your Pods and Containers
Apply Security Context to your Pods and Containers

The default namespace should not be used
Kubernetes provides a default namespace, where objects are placed if no namespace is specified for them. Placing objects in this namespace makes application of RBAC and other controls more difficult.

Ensure Seccomp Profile Pod Definitions
Enable default seccomp profiles in your pod definitions.

Create administrative boundaries between resources using namespaces
Use namespaces to isolate your Kubernetes objects.

Ensure that the RBAC setup follows the principle of least privilege
Role-based access control (RBAC) objects determine whether a user is allowed to perform a given action within a project. 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

Ensure that the cluster-admin role is only used where required
The RBAC role cluster-admin provides wide-ranging powers over the environment and should be used only where and when needed.

Limit Access to Kubernetes Secrets
The Kubernetes API stores secrets, which may be service account tokens for the Kubernetes API or credentials used by workloads in the cluster. Access to these secrets should be restricted to the smallest possible group of users to reduce the risk of privilege escalation. To restrict users from secrets, remove get , list , and watch access to unauthorized users to secret objects in the cluster.

Minimize Access to Pod Creation
The ability to create pods in a namespace can provide a number of opportunities for privilege escalation. Where applicable, remove create access to pod objects in the cluster.

Minimize Wildcard Usage in Cluster and Local Roles
Kubernetes Cluster and Local Roles provide access to resources based on sets of objects and actions that can be taken on those objects. It is possible to set either of these using a wildcard * which matches all items. This violates the principle of least privilege and leaves a cluster in a more vulnerable state to privilege abuse.

Drop Container Capabilities
Containers should not enable more capabilities than needed as this opens the door for malicious use. To disable the capabilities, the appropriate Security Context Constraints (SCCs) should set all capabilities as * or a list of capabilities in requiredDropCapabilities.

Limit Access to the Host IPC Namespace
Containers should not be allowed access to the host's Interprocess Communication (IPC) namespace. To prevent containers from getting access to a host's IPC namespace, the appropriate Security Context Constraints (SCCs) should set allowHostIPC to false.

Limit Use of the CAP_NET_RAW
Containers should not enable more capabilities than needed as this opens the door for malicious use. CAP_NET_RAW enables a container to launch a network attack on another container or cluster. To disable the CAP_NET_RAW capability, the appropriate Security Context Constraints (SCCs) should set NET_RAW in requiredDropCapabilities.

Limit Access to the Host Network Namespace
Containers should not be allowed access to the host's network namespace. To prevent containers from getting access to a host's network namespace, the appropriate Security Context Constraints (SCCs) should set allowHostNetwork to false.

Limit Containers Ability to Escalate Privileges
Containers should be limited to only the privileges required to run and should not be allowed to escalate their privileges. To prevent containers from escalating privileges, the appropriate Security Context Constraints (SCCs) should set allowPrivilegeEscalation to false.

Limit Privileged Container Use
Containers should be limited to only the privileges required to run. To prevent containers from running as privileged containers, the appropriate Security Context Constraints (SCCs) should set allowPrivilegedContainer to false.

Limit Access to the Host Process ID Namespace
Containers should not be allowed access to the host's process ID namespace. To prevent containers from getting access to a host's process ID namespace, the appropriate Security Context Constraints (SCCs) should set allowHostPID to false.

Limit Container Running As Root User
Containers should run as a random non-privileged user. To prevent containers from running as root user, the appropriate Security Context Constraints (SCCs) should set.runAsUser.type to MustRunAsRange.

Consider external secret storage
Consider the use of an external secrets storage and management system, instead of using Kubernetes Secrets directly, if you have more complex secret management needs. Ensure the solution requires authentication to access secrets, has auditing of access to and use of secrets, and encrypts secrets. Some solutions also make it easier to rotate secrets.

Do Not Use Environment Variables with Secrets
Secrets should be mounted as data volumes instead of environment variables.

Ensure that the cluster-admin role is only used where required
The RBAC role cluster-admin provides wide-ranging powers over the environment and should be used only where and when needed.

Minimize Access to Pod Creation
The ability to create pods in a namespace can provide a number of opportunities for privilege escalation. Where applicable, remove create access to pod objects in the cluster.

Minimize Wildcard Usage in Cluster and Local Roles
Kubernetes Cluster and Local Roles provide access to resources based on sets of objects and actions that can be taken on those objects. It is possible to set either of these using a wildcard * which matches all items. This violates the principle of least privilege and leaves a cluster in a more vulnerable state to privilege abuse.

Limit Containers Ability to Escalate Privileges
Containers should be limited to only the privileges required to run and should not be allowed to escalate their privileges. To prevent containers from escalating privileges, the appropriate Security Context Constraints (SCCs) should set allowPrivilegeEscalation to false.

Limit Privileged Container Use
Containers should be limited to only the privileges required to run. To prevent containers from running as privileged containers, the appropriate Security Context Constraints (SCCs) should set allowPrivilegedContainer to false.

Limit Container Running As Root User
Containers should run as a random non-privileged user. To prevent containers from running as root user, the appropriate Security Context Constraints (SCCs) should set.runAsUser.type to MustRunAsRange.