You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 30, 2024. It is now read-only.
If the maintainers agree with the feature as described here, I intend to submit a Pull Request myself.1
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 the metadata 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.
The text was updated successfully, but these errors were encountered:
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
Bug Report
Feature Idea
If the maintainers agree with the feature as described here, I intend to submit a Pull Request myself.1
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.
The text was updated successfully, but these errors were encountered: