feat: uds monitor pepr

[jeff-mccoy]

Description

Introduces the uds monitor command tree, with the first command being uds monitor pepr. This provides the same capabilities as npx pepr monitor from Pepr, and many more capabilities specific to UDS. Commands:

uds monitor pepr
Aggregates all admission and operator logs into a single stream

uds monitor pepr operator
Stream UDS Operator actions (Package processing, status updates, and errors)

uds monitor pepr policies
Stream UDS Policy logs (Allow, Deny, Mutate)

uds monitor pepr allowed
Stream UDS Policy allow logs

uds monitor pepr denied
Stream UDS Policy deny logs

uds monitor pepr mutated
Stream UDS Policy mutation logs

uds monitor pepr failed
Stream UDS Policy deny logs and UDS Operator error logs

Flags:

-n, --namespace - Namespace to monitor. Default is all namespaces

-f, --follow - Follow the logs

-t, --timestamps - Show timestamps in logs. Default is false

--since - Only return logs newer than a relative duration like 5s, 2m, or 3h. Defaults to all logs

--json - Return the raw JSON output that would be processed the command (extra log lines filtered out)

With timestamps

Without timestamps

Related Issue

Fixes #

Relates to #

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Other (security config, docs update, etc)

Checklist before merging

• Test, docs, adr added or updated as needed
• Contributor Guide Steps followed

[UncleGedd]

@jeff-mccoy I've looked through this PR and everything is generally easy to follow/understand. My only real callout is the tight coupling between the stream logic and Pepr logs (example). Understood this is a necessary evil (we are streaming logs after all 😅 ), just want to ensure @defenseunicorns/pepr are tracking this coupling as well

[jeff-mccoy]

For sure that's why I broke out the code into a pepr-specific implementation of the stream.Reader interface. It also is very tied to how we log things with Pepr in UDS Core, so we'll need to be aware of that, but there's not really a way around that.

[UncleGedd]

@jeff-mccoy I went through this code with @TristanHoladay and @decleaver, and discussed with some of the UDS Core folks as well, TLDR: we're g2g

I have some nits that can be addressed in a follow-up ticket along with adding some e2e tests (would be good for the UDS CLI team to get some more practice with those Package CRs anyway). I'll also address the test linting + adding docs in that follow-on issue

[jeff-mccoy]

All comments resolved, requested changes made

[UncleGedd]

🚀

Follow up ticket to add docs + e2e tests: #701