feat : Alert Throttling

[Prateeknandle]

Purpose of PR?:

Requirement of Alert Throttling:

When excessive alerts are generated and a particular user's use case does not require all the alerts but needs an overview of the alerts generated, then throttling is required. Since every user would have their own requirements, the conditions for the throttling are configurable.

NOTE : Throttling is done per container, it's not system wide.

Users can configure the throttling condition through the config map or KubeArmorConfig in case of operator deployment.

Configuration:

In KubeArmorConfig we can add:

spec:
  alertThrottling: true  // enables throttling functioning
  maxAlertPerSec: 10      // Number of maximum alerts that could be generated per sec
  throttleSec: 30        // Number of seconds for which subsequent alerts would be dropped

maxAlertPerSec and throttleSec are configurable, their default values are 10 and 30, respectively.

If we set maxAlertPerSec = 10 and throttleSec = 30, then maximum 10 alerts would be generated in a second per container and if this condition is crossed for any particular container then for that container a throttled condition alert would be generated and then for next 30 seconds there won't be any alert generated for that container.

Throttling Alert:

ClusterName: default
HostName: prateek
NamespaceName: wordpress-mysql
PodName: wordpress-586468bf4f-8bf6x
Labels: app=wordpress
ContainerName: wordpress
ContainerID: a4e3d52aeda8a0256d3c8ad819ec1bc6b61e4fa6f6d68858196d5195b5765d9f
ContainerImage: docker.io/library/wordpress:4.8-apache@sha256:6216f64ab88fc51d311e38c7f69ca3f9aaba621492b4f1fa93ddf63093768845
Type: SystemEvent
Operation: AlertThreshold
Enforcer: BPFLSM
Result: Passed
DroppingAlertsInterval: 30
MaxAlertsPerSec: 2
Owner: map[Name:wordpress Namespace:wordpress-mysql Ref:Deployment]
PPID: 0
UID: 0

This alert provides the information regarding throttling condition.

Fixes #

Does this PR introduce a breaking change?

If the changes in this PR are manually verified, list down the scenarios covered:: Yes,

1. tested with operator for BPFLSM enforcer
2. tested for apparmor enforcer
3. tested for audit alerts

Additional information for reviewer? : Mention if this PR is part of any design or a continuation of previous PRs

1. BPFLSM Enforcement: We created a new eBPF map named kubearmor_alert_throttle which is required to hold the state of alerts throttling state per container. We add the containers entry in kernel-space itself. We remove the containers data in user-space for which the enforcement policies are removed. PS : We tried to handle deletion of used containers data in kernel-space itself but currently it's not possible.
2. Apparmor Enforcement: We used the same eBPF map kubearmor_alert_throttle to store the containers state wrt throttling. We add and delete this state data in kernel-space itself. PS : here we delete the conatiners state when the container is being deleted, which is different for BPFLSM, where we delete the state data when there is no enforcement policy further exist for container.
3. Audit based policies: For audit alerts we handle the throttling in Feeder (completely in user-space). We created a golang map to handle throttling state per container. This map is updated in core package based on the CRI used.

Checklist:

• [ ] Bug fix. Fixes #
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [x] This change requires a documentation update
• [x] PR Title follows the convention of <type>(<scope>): <subject>
• [ ] Commit has unit tests
• [x] Commit has integration tests