Stéphane Tailland
6d020572e0
k8s/secret.yaml held the Grafana admin credentials and, since the MCP server landed, its service account token — gitignored, so deploying this stack required the right file to exist on the right laptop. It now comes from Vault through External Secrets, and nothing sensitive has to exist locally. A dedicated store rather than reusing vault-kong-v2: that one's AppRole carries kong-v2-readonly, scoped to secrets/data/kong-v2/*, so it cannot see this path — confirmed with a probe ExternalSecret that failed with "could not get secret data from provider". Widening that policy would have handed the Kong reader observability's secrets for no reason. So observability-readonly and observability-eso were created in Vault, mirroring the existing pattern exactly. The AppRole credentials stay out of git; the ClusterSecretStore comments carry the commands that mint them. dataFrom.extract pulls the whole path instead of naming each key, so a new key in Vault reaches the cluster with no edit here. The target keeps the name every consumer already uses, so neither the Grafana Deployment nor mcp-grafana changed — verified, neither pod restarted and the token in the cluster matches Vault byte for byte. secret.example.yaml no longer describes a file to create; it documents where the keys live and how the Grafana token is minted. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
24 lines
514 B
YAML
24 lines
514 B
YAML
apiVersion: kustomize.config.k8s.io/v1beta1
|
|
kind: Kustomization
|
|
namespace: observability
|
|
|
|
resources:
|
|
- namespace.yaml
|
|
# observability-secrets now comes from Vault through External Secrets;
|
|
# k8s/secret.yaml is no longer applied and can be deleted.
|
|
- secrets
|
|
- prometheus
|
|
- loki
|
|
- tempo
|
|
- alloy
|
|
- grafana
|
|
- grafana/dashboards
|
|
- mcp-grafana
|
|
- ingress
|
|
|
|
labels:
|
|
- includeSelectors: false
|
|
pairs:
|
|
app.kubernetes.io/managed-by: kustomize
|
|
app.kubernetes.io/part-of: observability
|