Metrics to identify and peg count key usage and alerts

[crawdaddy1]

Describe the feature
As a member of a team that is utilizing Connaissuer, I would like to make sure I can peg count the occurances a key is used against an image and track the number of successes failures for sending a particular alert. Further, I would like to track which keys are successful in admission and which keys are causing rejections. Today we have pod metrics, but expanding this to application specific metrics will enhance the capability of the overall solution.

Optional: Is your feature request related to a problem? Please describe.
In order to understand how often a key is used, we would like to understand the peg count on a particular image signature admission, and would additionally like to understand rejection based on keys that do not exist. The work will require determining the best way to map multiple metrics (a key and its success/failure peg count) - as most metrics are singular. The information will help teams identify keys used that are not in the configuration of the solution. Second this will help understand if organizations are using the same key, when a singular key should be mapped on a by organization or application basis.

Additionally, lets peg count the alert types and how often the alerts are sent successfully, versus a failed alert - this will help determine the SLIs and overall SLO of the service.

Optional: Implementation ideas
Additional code will be needed in the admission request object to help peg count the occurrences (rejections/admissions) and in the alert object to peg count the alert type and the alert functions successes and failures.

Optional: Additional context

[Starkteetje]

Hi @crawdaddy1
I think that's a reasonable idea. Two questions:

would additionally like to understand rejection based on keys that do not exist

I don't see how this would be possible. Connaisseur does verification based on a set of pattern/validators/keys pre-configured, so the only context we have is "the image matched pattern X that uses validator Y and uses key X". So for X, Y and Z, we can record fail/success metrics. However, on a failure we can't detect non-existant keys, we can just deny invalid signature data. Am I misunderstanding your intention here?

Second question would be whether you'd want to have these metrics actually on keys? Keys could belong to multiple patterns, so knowing which key fails/succeeds doesn't necessarily narrow down the problem, whereas a metric on the pattern would (and would also allow generating the metric for the key as the key is a function of the pattern). As such, I'd actually implement the metric on patterns (and maybe additionally for validators/keys for convenience). Would that fit your use case?