Security and compliance

This section of our lab will focus on making use of the OpenShift Compliance Operator to configure security scans in your OpenShift cluster. The compliance operator can help ensure that the hosts in your OpenShift environment meet specific security standards, and are deployed to meet those standards.

Figure 1. Compliance overview

1. Select Operators and then Installed Operators from the left side navigation menu. Confirm that you have selected All Projects and select the Compliance Operator.

Figure 2. Compliance operator

2. This takes you to the Operator details page. Use the horizontal scrollbar to move across and locate the ScanSetting tab.

Figure 3. Compliance details

3. Click the Create ScanSetting button.

Figure 4. Create ScanSetting button

4. On the Create ScanSetting page, set the name of the scan to scan01. Then click the YAML view radio button.

Figure 5. Create Scansetting

5. In the ScanSetting YAML details, make note of the following values that are set by default:
   • The autoApplyRemediations field is set to false.
   • The roles to be scanned by default include entries for master and worker nodes.
   • The name field is set to scan01 which you entered on the form view.
6. Delete the entry for master to ensure we don’t scan or remediate control plane nodes.
7. Click the Create button to create this simple scansetting definition that will only scan worker nodes.

Figure 6. ScanSetting details

8. Now click on the Profile tab where there are a number of pre-defined scanning profiles.
9. In the search box, type rhcos4 and locate the FedRamp moderate profile rhcos4-moderate in the list.

Figure 7. Profiles detail

10. Click on rhcos4-moderate and then on the YAML. Scroll down the output to browse the rules that are enforced as a part of this scan. A quick glimpse at the side panel shows that there are quite a few of them.

Figure 8. RHCOS4-Moderate rules

11. When you are done reviewing the rules, return to the Operator details page by clicking your browser’s back button twice.
12. Next we want to create a ScanSettingBinding, pairing a Profile with our ScanSetting definition we created. We do this by navigating to the Scan Setting Binding tab, and clicking the Create ScanSettingBinding button.

Figure 9. Create ScanSettingBinding

13. In the ScanSettingBinding YAML details, let us make a few changes:
    • The metadata.name value should be set to fedramp01
    • The settingsRef.name field is set to scan01 which we created earlier.

14. Click the Create button.

    Note: The profile is set to rhcos4-moderate (the fedramp moderate profile) by default.

Figure 10. ScanSettingBinding details

15. After the ScanSettingBinding is created, the fedramp01 scan will be run automatically. You can view this on the Compliance Suite tab.

Figure 11. Compliance Suite

16. This Compliance Suite runs the defined scans against the specified nodes, in our case the worker nodes defined in scan01.
17. For more detailed information you can click on the Compliance Scan tab. There you can watch as the scan proceeds through the steps of RUNNING, AGGREGATING, and DONE.

Figure 12. Compliance Scan

18. Once the scan completes (3-5 minutes on average) you can check your results by clicking on the ComplianceCheckResult tab. It will list all of the scans that were a part of the compliance suite we chose and their results.
19. Change the search bar to Label and apply the following labels:
    • compliance.openshift.io/check-status=FAIL
    • compliance.openshift.io/check-severity=high

Figure 13. Compliance check results

20. Six high-severity checks have a failed status:

When it comes to remediation, it can be performed in one of two ways. Automatically, which may seem simple and the easiest way to do it, but can lead to unexpected results. Or manually, which can be tedious, but allows you to canary test each application, and later automate through a tool like GitOps that checks for failures before proceeding.

In this section, we are going to choose one of our failures from the previous scan and remediate it manually.

1. Starting from the list above we are going to choose to remediate the following scan result: rhcos4-moderate-worker-coreos-pti-kernel-arguments as required by our audit.

   Note: The rhcos4-moderate-worker-coreos-pti-kernel-argument is required to isolate kernel and userspace page tables to prevent attacks.

   Click on the Compliance Remediation tab, and in the Name search bar type the term pti-kernel to find the suggested remediation for rhcos4-moderate-worker-coreos-pti-kernel-argument. When the result appears, click the three-dot menu on the right, then select Edit ComplianceRemediation from the menu that appears.

Figure 14. Compliance remediation

2. This will launch the ComplianceRemediation details page with a YAML block describing the current status.
3. Under the spec section you will see that the current apply state is false, and the kernelArugument that will be applied is that pti=on. Under the status section we see that the remediation state is NotApplied.

Figure 15. Compliance remediation details

4. Under the spec section change the apply field to true and click the Save button.

Figure 16. Compliance remediation “true”

5. You will be prompted with a message that lets you know that this is a managed resource. Click the Save button to start the remediation process.

Figure 17. Managed resource prompt

6. Once applied, a MachineConfig will be generated to provide the remediation, and each node in the cluster will be cordoned, drained, and remediated in sequence.
7. On the left side menu, click on Compute and Nodes to observe the process.

Figure 18. Node 3 cordoned

8. You will see a node enter the SchedulingDisabled state to begin its remediation. Click on that node for its Node details page, and notice that the event log shows the node was cordoned to apply the update. You can also see CPU and Memory utilization drop off as the node was successfully drained.

Figure 19. Node 3 Updating

9. After several minutes the MachineConfig will be applied to each of the worker nodes in our cluster, and we can recheck our Compliance Scan results.
10. Return to the Compliance Operator configuration by clicking on Operators and Installed Operators in the left side menu.

Figure 20. OpenShift Compliance Operator

11. Click on the Compliance Scan tab, where you will see the scan we completed earlier. Click the three-dot menu, and select the option to delete the current scan.

Figure 21. Delete compliance scan

12. You will be prompted to be sure that you want to delete the current compliance scan. Click the Delete button.

Figure 22. Delete scan prompt

13. The Compliance Suite object defined earlier will automatically kick off a new scan which you will see appear on your screen.

Figure 23. New compliance scan

14. As before this scan will take a few minutes to complete. Once it is finished, the results can be viewed by clicking on the ComplianceCheckResult tab and then searching for the rhcos4-moderate-worker-coreos-pti-kernel-argument and noticing that its label is now check-status=PASS instead of FAIL.

Figure 24. Check status pass

With the completion of these sections we have created a compliance scan and successfully remediated an identified vulnerability using the OpenShift Compliance Operator.

One of the notable features that OpenShift is known for compared to vanilla Kubernetes is its rich set of role-based access controls for separate user accounts and cluster roles that define what each user is able to do when logged into the cluster. In this section of the module, we are going to create a read-only account for our auditor and explore the limitations by which they are bound.

1. Start by clicking on User Management and Users in the left side menu.
2. You will see the current admin user that you are logged in as listed, and you will see that the identity is provided by the htpasswd_provider:admin authenticator.

Figure 25. User list

Create a group

1. Now click on Groups in the left menu, then click the button for Create Group.

Figure 26. Create group

2. In the Create Group YAML dialog, set the name of the group to auditor_readonly and add the users auditor1 and auditor2. Click the Create button.

Figure 27. Create group settings

3. You will be presented with the Group details screen where you can see the two user accounts listed, and we can define permissions by assigning the group a role binding. Click on the RoleBindings menu.

Figure 28. Group details

4. After clicking on RoleBindings, click the Create binding button.

Figure 29. Create binding

5. This will bring you to the Create RoleBinding page. On this page, select the following to create a read-only role binding for the auditor, and then click the Create button:
   • Binding type: Cluster-wide role binding
   • Name: cluster_readonly
   • Role name: view

Figure 30. RoleBinding details

Create the user accounts

1. With the role binding created, we now need to add our two auditor accounts to our group.
2. In the left side menu, click Administration and CustomResourceDefinitions and use the search bar to look for the OAuth entry. When you find it, click it.

Figure 31. CRDs OAuth

3. This will load the details page for the OAuth custom resource definition. On this page, click on Instances and then click on cluster.

Figure 32. OAuth instances

4. On the cluster configuration page you will see where the htpasswd_provider is already currently configured, but there will also be a dropdown menu that has the word Add. You can select another provider from that list. Click and select HTPasswd as the option.

Figure 33. Add authentication

5. You will be presented with a page that allows you to add in an HTPasswd file or supply usernames and hashed credentials for that purpose. Set the name of the identity provider to auditor_login and paste the following syntax into the text box before clicking the Add button.

   auditor1:$apr1$VtSYSShP$CikLVoVy5sobCaHCvuxCv.
   
   auditor2:$apr1$4Vpe3O5u$OhjtFGDNHnl2RWiNnhlhZ0

Figure 34. Add identity provider

6. Once added you will be returned to the Cluster OAuth details page and you will now see two identity providers listed, along with a blue notice that OAuth is being reconfigured. Click on the link provided for View authentication conditions for reconfiguration status.

Figure 35. OAuth reconfiguration

7. You will be brought to a page that shows the progress as the authentication cluster operator is reconfigured. Once all the pods are restarted, the status will change to Available and the message will say All is well.

Figure 36. OAuth reconfiguration progressing

Figure 37. OAuth reconfiguration complete

Test the configuration

1. With the OAuth configuration complete, we can now test our auditor login and the limits of their account.
2. Log out of OpenShift by clicking on admin at the top, and selecting Log out from the dropdown menu.

Figure 38. Log out of OpenShift

3. There is now an option to login with the auditor_login identity provider on the main OpenShift page.

Figure 39. Log in to OpenShift

4. Click on auditor_login and when presented use the following username and password combination:
   • Username: auditor1
   • Password: auditor1pass!

Figure 40. Auditor 1 login

5. When the auditor logs in with the read-only permissions, they will be able to see only a limited view of the OpenShift console from the Admin perspective.

Figure 41. Auditor 1 admin view

6. If the auditor needs to validate our virtual machine environment, they can still access that by clicking on Virtualization and VirtualMachines in the left side menu.
7. They can see all virtual machines in each project, and their current status.
8. The auditor can even click on a specific machine and get additional details. In this case, they want to test the database server in the webapp-vms namespace.

Figure 42. Auditor 1 VM view

9. Once they are on the VirtualMachine details page, they can see the information about the virtual guest, including its CPU and memory utilization. However, they are prevented from launching the VNC console or manipulating the machine state in any way, as the buttons are greyed out.

Figure 43. Auditor 1 database ReadOnly

10. At your leisure, you may explore the UI and confirm that the Auditor1 account is read-only. When you are finished, proceed to the next module.

In this section of our lab we created a limited read-only account with view permissions for the auditors that will be examining our infrastructure.

In this module we were preparing for our company’s annual security audit. We can tighten our OpenShift Virtualization security by using the Compliance Operator to automate standard-setting scans and applications. We further strengthen this posture by configuring RBAC to limit access to specific individuals.

In the next lesson, we’ll cover advanced networking and security tasks.

• Troubleshoot with Red Hat support