Include violating image in logs produced by pod_trusted_repository policy

[David Young]

Hey guys!

We're relying on pod_trusted_repository to enforce usage of our local images on all pods across many namespaces. Sometimes we'll deploy a fresh helm chart, and find that k-rail blocks an initContainer (or something we weren't able to override) due to pod_trusted_repository (which is good!)

Finding out which image the pod attempted to use is hard though - some cases requiring us to make a policy exception for the matching workload in order to let the daemonset controller create the replicaset, so that we can then interrogate it and reverse-engineer the necessary image (which is bad)

It'd be really helpful if the k-rail log output from pod_trusted_repository policy enforcement could include the details of the image which was blocked.

Thanks :)
D

[Frenchie]

Hey @funkypenguin

Thanks for raising this issue, I can definitely understand the need for knowing which image was triggering the policy enforcement from the logs.

Here's a draft PR with one way we could attempt this, by adding it to the violation text.
#79 -- reading that again now I don't think the addIfUnique function is necessary, but it was a quick hack :)

Another option could be to change the ResourceViolation struct but I suspect that will involve broader changes.

[Dustin Decker]

I merged @frenchi's change, released in v2.2.0.

Eventually I'd like to add support for custom fields though, and then we can include the image name and registry in distinct fields that can be queried on easily.