Open timothysmith0609 opened 1 year ago
Thanks for opening your first issue here! Be sure to follow the issue template!
Neat idea! You could probably do it right after each auditor runs here where you have access to the audit result and the Kubernetes resource (in-memory)
where you have access to the audit result and the Kubernetes resource (in-memory)
That's great! The only thing I'm not sure about is how best to pass the configuration flag in, since it will have to modelled as a global flag, which goes into rootConfig
. I haven't quite figured out I want to push the configuration down to the individual auditor level, but initKubeaudit
seems like the right place: I have access to rootConfig
and I'll only have to declare it in a single spot.
FEATURE IDEA
ISSUE TYPE
Proposal
It would be great if we could have kubeaudit return additional metadata about resources as part of its structured response. For example, useful, platform-specific, information is often stored in annotations, but other metadata such as
ownerReferences
can be useful when trying to understand where a particular resource is coming from.For a flexible solution, we could provide a new flag,
--metadata=[comma,separated,JSONPath expr]
. These JSONPath expressions can then be used to traverse themetadata
of each resource and add the results to the audit response.From a quick look through the code, it looks like we maintain an in-memory representation of resources, and have some ability to traverse its metadata (though I have to look more closely at the overall implementation). I'm not sure how easy/hard it will be to implement this across all auditors, or if this can be done at a more abstract level. If the former, likely we will need to split this up into several PRs as we build this out for all auditors.