feat: add UDS Operator and consolidate UDS Policies

[jeff-mccoy]

Description

This PR consolidates all Pepr capabilities into the folder src/pepr. This PR also introduces the UDS Operator, which manages a new CRD packages under the group uds.dev/v1alpha1.

The UDS Operator manages the lifecycle of UDS Package CRs and their corresponding resources (e.g. NetworkPolicies, Istio VirtualServices, etc.). The operator uses Pepr to bind the watch operations to the enque and reconciler. The operator is responsible for:

• enabling Istio sidecar injection in namespaces where the CR is deployed
• establishing default-deny ingress/egress network policies
• creating a layered allow-list based approach on top of the default deny network policies including some basic defaults such as Istio requirements and DNS egress
• providing targeted remote endpoints network policies such as KubeAPI and CloudMetadata to make policies more DRY and provide dynamic bindings where a static definition is not possible
• creating Istio Virtual Services & related ingress gateway network policies

Key Files and Folders

.
├── controllers          # Core business logic called by the reconciler
│   ├── istio            # Manages Istio VirtualServices and sidecar injection for UDS Packages/Namespace
│   └── network          # Manages default and generated NetworkPolicies for UDS Packages/Namespace
├── crd
│   ├── generated        # Type files generated by `uds run -f src/pepr/tasks.yaml gen-crds`
│   ├── sources          # CRD source files
│   ├── register.ts      # Registers the UDS Package CRD with the Kubernetes API
│   └── validator.ts     # Validates UDS Package CRs with Pepr
├── enque.ts             # Serializes UDS Package CRs for processing by the reconciler
├── index.ts             # Entrypoint for the UDS Operator
└── reconciler.ts        # Reconciles UDS Package CRs via the controllers

[bburky]

What is the plan for the lifecycle of the CR? I see you set ownerReferences, which should cleanup created resources in the namespace on deletion. But what about updates? K8s.apply() is SSA, so I think it will update whole resources on changes, right? (Will it update/replace every field on a second apply, or does it merge with the old changes?)

The scenario I'm most worried about is this doesn't handle deletion on CR change. If you change the network config (but don't delete the CR), some of the old NetworkPolicies will need to be deleted.

You could consider an approach like Flux's kustomize-controller: they store a list of all the created resources in .status. On each change compare the new list of resources to the old ones and delete any that no longer should exist (perhaps have things like networkPolicies() and virtualService() return the list of resources they created or updated as an array of strings). Listing created resources in .status is also really nice for debuggability by users.

feedback addressed

[mjnagel]

LGTM at this point. I did modify the loki policies and add a Package CR for prometheus-stack so might be good to get @mikevanhemert / @zachariahmiller to confirm those pieces at least as a validation I didn't mess things up too much.