feat: add monitoring virtualservices for alertmanager / prometheus

[joelmccoy]

Description

• Adds virtualservice on admin gateway for prometheus prom.uds.dev
• Adds virtualservice on admin gateway for alertmanager alerts.uds.dev
• Exposes values that allow for custom netpols in the monitoring package (useful for allowing alertmanager to send alerts out of namespace)
• reordered k3d-standard packages so that authservice is deployed after keycloak

Related Issue

Fixes #967

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 followed

[joelmccoy]

moved this up the list in the standard bundle as it should be deployed after keycloak. and tests were failing as monitoring gets deployed before authservice if left alone.

[joelmccoy]

open to other names here 🤷

[mjnagel]

Currently we have grafana and neuvector, might suggest we keep with that pattern and just use the full product name here.

[mjnagel]

(alternatively we could try and lean more into functionality based naming like sso is, so alerts and metrics?)

[joelmccoy]

Note: I originally tried to put authservice in front of these things, but it prevents grafana from pulling from prometheus, and prevents prometheus from sending alerts to alertmanager :/. Hopefully it is just ok to put these on the admin gateway, but if not, what we might have to do is create an extra service, expose this, and put authservice in front of it (while still allowing the old service to be reached without authservice).

[mjnagel]

I definitely would prefer to put these behind authservice if possible. I know historically when working on Big Bang we were able to use authz policies to allow specific traffic, but there may have been some other caveats with that. cc @bburky if you have thoughts on how to enable this (basically looking to protect prometheus/alertmanager with authservice but also ensure services are able to communicate internal to the cluster still as expected).

[mjnagel]

Currently we have grafana and neuvector, might suggest we keep with that pattern and just use the full product name here.