Using Red Hat Advanced Cluster Security for Kubernetes you can view policy violations, drill down to the actual cause of the violation, and take corrective actions.
Red Hat Advanced Cluster Security for Kubernetes built-in policies identify a variety of security findings, including vulnerabilities (CVEs), violations of DevOps best practices, high-risk build and deployment practices, and suspicious runtime behaviors. Whether you use the default out-of-box security policies or use your own custom policies, Red Hat Advanced Cluster Security for Kubernetes reports a violation when an enabled policy fails.
Violations record all of the specific times where a policy criteria has been met by any of the objects in your cluster - images and their components, deployments, runtime activity.
Think of it as the “stream” of events that have occurred, although we don’t want this to just be a “to-do” list for incident response folks.
Click on a Violation of the "Fixable Severity at least Important". You may have to look for one! The violation details appear on the right.
Here’s an example of the details recorded for a policy violated at deployment time.
You’ll see that it’s the same information presented in a CI/CD tool or developer console when using the build-time integration.
Click on a Violation of the "Netcat Execution Detected" in Image policy. Again, you may have to look or search (filter) for it. The violation details appear on the right.
This violation is a runtime incident - so it has a different set of details and actions available.
The forensic data recorded will be familiar to most incident response team - the “who, what, when, where, and why” of the activity, including process names, arguments, UIDs, container IDs
In this case, for our demo, there’s been no enforcement of the action, just a notification, and the team has options to resolve or suppress these notifications in the future.
|The violations are per Deployment, not per pod!|
What happens if you not resolve a Violation in a Deployment, or if the same violation happened again (with the same parameters)?
A unique violation is not always generated per event, but those events and details are summarized in the violation details itself.
This behavior is expected. Since it is the same running deployment that you are updating through your pipeline, and this first violation is not resolved. If new CVEs present themselves, those are of course updated based on any changes to the image.
But a violation will not trigger if we have already analyzed it is currently violating that policy from the original time stamp of when it was detected, and nothing else has changed
If the change to the deployment represented new violations, then those would appear. Or, if you deleted the deployment and redeployed a new one for example.
For example, "Ubuntu Package Manager Execution". If I had an outstanding violation present from Time X, when it was first detected, and the same pod executes 24 hours later at time Y, the result would be additive, where I would see the details of those executions (First Occurrence, Last Occurrence and then each individual event execution) under the same violation summary
RHACS has a number of built-in policies to detect activity that’s related to attacker goals: gain a foothold, maintain a presence, move laterally, and exfiltrate data. The continuous runtime monitoring observes all container activity and will automatically respond to events with appropriate enforcement and notification
In the right hand side details of the Violation, click on the Policy tab
But that would be missing out on an opportunity - RHACS wants to go one step further, to take advantage of the ephemeral, immutable nature of containers to improve security in a measurable way going forward.
We are, essentially, using runtime incidents as a learning opportunity to improve security going forward by constraining how our containers can act.