Provide Kubernetes Admission Controller

An 'Admission Controller' is a Kubernetes procedure that is run on each API call. Admission controllers can validate API calls, or modify (mutate) the call. See https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/ for more information.

ThreatMapper logic should be provided as a validating Admission Controller. This capability could be used by the administrator to prevent the deployment of pods if their constituent containers fail to meet security standards:

* Container has too many high-severity, network-exploitable vulnerabilities
* Container has exposed secrets that are not allow-listed

# Detailed Requirements

## Logging

We MUST consider how this functions in a 'lights-out' environment where the primary interaction is with Kubernetes logs. Not all affected parties will have access to the ThreatMapper console or logs. Kubernetes logs should contain all of the information necessary to monitor and troubleshoot the admission controller, including the vulnerabilities/secret rules that caused a pod deployment to be blocked.

We MUST implement a 'log only' mode that can be used to test the admission controller. This mode should inspect and score pod deployments in the standard manner, but log a high-priority alert ("Pod that fails to meet security standards is being deployed") rather than blocking the deployment. This mode will be critical for users to test the admission controller before enabling blocking. In a simple implementation, the 'log or block' mode could be a simple global setting for the admission controller (see 'fine tuning' below).

## Exceptions

Some of the threats detected by ThreatMapper may be legitimate false positives. Examples:

* Organisation has a policy to use certain software dependencies, even though they have known vulnerabilities and are detected by the threatmapper vulnerability scan
* SecretScanning can identify high-severity issues e.g. AWS token that may be necessary in certain circumstances and should not be blocked

We MUST allow administrators to define an allow-list of exceptions. If an exception is allowed, we SHOULD log this for audit and troubleshooting purposes.

## In emergency, break glass

We SHOULD allow an administrator to enable an 'in emergency, break glass' process. If a pod deployment is blocked, a user should be able to invoke this process to override the admission controller.

For example, an administrator may define a policy that pods with the label "deepfenceoptions=donotblock' are scanned, logged but the deployment is not blocked.

This would allow a user to force-deploy a pod (an exceptional event).

The 'break glass' procedure MUST NOT be enabled by default. It MUST be implemented with a custom (admin-defined) label, not with a default label, so that only users in-the-know are able to invoke this procedure.

## Fine Tuning

We COULD offer a fine degree of control, whereby administrators can define multiple thresholds (number of critical or high vulnerabilities, total severity etc) and corresponding actions (BLOCK, LOG, Custom Log Message (required for routing)).

We COULD further tune these rules by associating them with selectors, so an administrator can control which rules apply to which pod deployments.

We COULD allow an administrator fine-grained control over the exceptions that are allowed, for example, by associating lists of exceptions with selectors.