Skip to content
This repository has been archived by the owner on Oct 30, 2024. It is now read-only.

CLI flag to add arbitrary metadata fields to audit results #509

Open
2 of 3 tasks
timothysmith0609 opened this issue Nov 24, 2022 · 3 comments
Open
2 of 3 tasks

CLI flag to add arbitrary metadata fields to audit results #509

timothysmith0609 opened this issue Nov 24, 2022 · 3 comments

Comments

@timothysmith0609
Copy link

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 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.

@github-actions
Copy link

Thanks for opening your first issue here! Be sure to follow the issue template!

@genevieveluyt
Copy link
Contributor

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)

@timothysmith0609
Copy link
Author

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants