bug: ConfigMap cache scope prevents operator from reading SPIRE trust bundle

[Schimuneck]

Problem

The controller-runtime manager scopes ConfigMap caching to specific label selectors (cmd/main.go, lines 213–227). This is intentional — without it, the controller would cache every ConfigMap cluster-wide.

The SPIRE trust bundle ConfigMap (typically spire-bundle in spire-system) doesn't match any of these selectors, so the operator's cached client returns "ConfigMap not found" even though the ClusterRole grants read access.

trust bundle unavailable: initial trust bundle load failed: failed to get trust bundle configmap spire-system/spire-bundle: ConfigMap "spire-bundle" not found

The SPIRE trust bundle is an external dependency managed by SPIRE, not by kagenti. Requiring users to label it with a kagenti-specific label is fragile — it won't survive a SPIRE Helm upgrade that recreates the ConfigMap.

Impact

Signature verification silently fails on any deployment where SPIRE is installed via the standard Helm chart. SignatureVerified stays False and Bound stays False.

Reproduction

helm install spire spiffe/spire -n spire-system --set global.spire.trustDomain=example.org

# Deploy operator with --require-a2a-signature=true and trust bundle flags
# Check logs:
kubectl logs -n kagenti-operator-system deployment/kagenti-operator-controller-manager | grep trust
# "failed to get trust bundle configmap spire-system/spire-bundle: ConfigMap not found"

Workaround

kubectl label configmap spire-bundle -n spire-system kagenti.io/defaults=true

Then restart the operator. This label may be lost on SPIRE upgrades.

Found during

E2E walkthrough of all 4 AgentCard demo scenarios on both Kind and OpenShift 4.19 (ROSA).

[ChristianZaccaria]

/claim

[rubambiza]

Thanks for claiming this issue! If you get stuck or need to step away, comment /unassign or ask a maintainer.