## Summary

The koku-metrics-operator CostManagementMetricsConfig CRD exposes `spec.prometheus_config.service_address` as a free-form string with no host validation. The operator reads its own Kubernetes service-account token from `/var/run/secrets/kubernetes.io/serviceaccount/token` and configures it as the `BearerToken` for PromQL queries sent to this user-supplied address. The service-account token carries the `manager-role` ClusterRole, which grants `get` on all Secrets cluster-wide.

## Impact

A principal with `create`/`update` permission on `costmanagementmetricsconfigs` in the operator namespace can harvest the operator's Kubernetes service-account token by redirecting Prometheus queries to an attacker-controlled endpoint. This token grants read access to every named Secret in any namespace across the cluster.

## Affected Code

- `api/v1beta1/metricsconfig_types.go:198` — `service_address` field definition (no validation)
- `internal/collector/prometheus.go:95-117` — token read and client configuration
- `config/rbac/role.yaml:18-22` — ClusterRole grants `secrets:get` cluster-wide

## Remediation

Restrict `service_address` to in-cluster Prometheus/Thanos endpoints via CRD CEL validation:

```yaml
x-kubernetes-validations:
- rule: "url(self.service_address).getHostname().endsWith('.openshift-monitoring.svc') || url(self.service_address).getHostname().endsWith('.openshift-monitoring.svc.cluster.local')"
  message: "service_address must target the in-cluster monitoring service"
```

Or use a `TokenRequest` API call with audience bound to `prometheus-k8s` so the token is not replayable against `kube-apiserver`.