feat(telemetry): the edge Collector, Class A only, shipping inert (backend#1906)

[LukasWodka]

Implements the bulk of backend#1906 — RFC-BACKEND-1872 D6 + D7. An OpenTelemetry Collector DaemonSet that reads Class A container stdout with filelog and forwards to the backend's ingest endpoint.

It ships disabled, and that's the decision to check first

The exporter authenticates with a token this chart does not create — jobs-manager writes it into a Secret and doesn't do so yet. Enabling the Collector before that Secret exists would put a DaemonSet on every customer node spooling to disk with nothing it can deliver, filling toward the 1 GiB cap per node for no benefit. That is precisely the "telemetry must never be the reason a node fills" risk D7 exists to bound. Same posture as egressProxy.routeWorkloads: ships inert, flipped per fleet once the prerequisite lands.

So this PR does not close #1906. The jobs-manager half is client-runtime work and needs its own ticket.

Class A only, and the narrow scope is the protection

The filelog include globs name the four control-plane containers this chart owns. A bare wildcard would sweep in training and ingestion pods — Class B, gated on backend#1908. Today's bounding is secret redaction, not content redaction, and raw customer cell values have already reached central telemetry once (backend#1879). A test asserts no wildcard include exists, because widening this is not a config tweak: it changes what leaves a customer's cluster.

The redaction floor is relocated, not re-invented

D6 precondition 2. Reading stdout through filelogbypassescontroller.py's app-side handler, so without this the move would silently remove a protection that exists today.

All six _LOG_REDACTIONS patterns are carried (client-runtime@45006ec), translated Python → RE2 deliberately: \1 → $1, (?i)/(?m) kept, and no pattern uses lookaround or in-pattern backreferences, which RE2 rejects. Checked rather than assumed — a silently-invalid regex in OTTL is a processor that starts and scrubs nothing. I compiled all six as RE2 and ran them against sample secrets; every one redacts, and the SharedAccessKeyName carve-out controller.py documents survives.

This is a cross-repo second copy and it cannot be machine-checked from here. The producer is Python in another repository; Helm can't import it and no test in this repo can detect drift. If controller.py's set grows, this won't, and nothing will say so. Stated in the file rather than implied — it's a real residual risk, and it's why each pattern names what it's for.

D7's bounds, all three

byte cap	1 GiB via sizer: bytes — expressible as bytes at all only because that sizer exists
one bound	max_elapsed_time: 0. A second time-based bound silently overrides the cap, because a batch past it is dropped rather than requeued
survives restart	disk-backed file_storage on a hostPath, not an emptyDir — the restart is the common case during an outage

block_on_overflow: false is drop-newest, per D7's 2026-08-20 amendment (rfcs#36): exporterhelper sheds at the entrance and has no evict-oldest option. That's why the Collector's own metrics are exposed on 8888 — under drop-newest the drop count (otelcol_exporter_enqueue_failed_log_records) is the only signal separating a quiet edge from a shedding one.

Two things verified rather than assumed

scheme: Token, not the extension's default Bearer. The edge holds a DRF user token (jobs_manager.py sends Authorization: Token <key>) and the ingest endpoint accepts it via TokenAuthentication under IsAuthenticatedEdge. Bearer is the other credential type (ClientAccessToken) and would 401 silently.

The token file is watched. #1906's rationale says "a projected update needs no restart", which depends on bearertokenauth reloading. The README doesn't mention reloading — so I read the extension's source: it builds a credentialsfile.ValueResolver with WithOnChange → updateAuthorizationValues(). It does reload. The README's silence wasn't evidence either way.

Also logs_endpoint, not endpoint — otlphttp appends /v1/logs to the latter, and the ingest boundary is a versioned path of ours.

A defect rendering caught that reading wouldn't

Helm parses 1073741824 from values.yaml as a float64 and emitted queue_size: 1.073741824e+09 — a YAML float where the Collector wants an integer. The Collector would have started and the cap would not have been the number written in values.yaml. | int64 fixes it, and a test asserts no scientific notation appears.

Test plan

helm lint	clean
whole chart suite	510/510 across 34 suites — nothing else moved
new suite	19/19
chart-version-guard.bats	23/23, after bumping versionandappVersion to 1.9.51 (the guard requires a bump when chart content changes)
RE2 check	all 6 patterns compile and redact; SharedAccessKeyName preserved

15 mutations, all killed: enabling by default · widening filelog to a wildcard · dropping redaction from the pipeline · losing a redaction pattern · losing int64 · reverting sizer · adding a second time bound · falling back to memory · reverting to Bearer · using endpoint · mounting host logs writable · making the Secret required · moving the queue to an emptyDir · removing the config checksum · granting a ClusterRole.

One test-quality note: three of my assertions initially failed for reasons unrelated to the code — helm-unittest renders .Release.Namespace as the literal NAMESPACE placeholder unless you set it, and \* in its regex patterns doesn't behave like Go's. Fixed by setting the namespace explicitly (which makes the assertion test the real scoping) and using [*]. Worth naming because an assertion that fails for the wrong reason is one you're tempted to weaken.

Deliberately not in scope

Retiring the two App Insights entries from the squid ACL. That cuts client-runtime's live AzureLogHandler path, and the RFC is explicit that App Insights cannot be switched off before edges have another route. It belongs to #1910's cutover.

RBAC: none. It reads files off the node and never calls the Kubernetes API, so it gets a ServiceAccount and nothing else — a Role here would be privilege this workload has no use for, on a DaemonSet running on every node of a customer's cluster.

🤖 Generated with Claude Code

---

Note

High Risk
Introduces a per-node DaemonSet that runs as root with hostPath log and queue mounts, plus a new OpenShift SCC (RunAsAny). It also ships log redaction and tenant-scoped collection that, if mis-gated, can leak Class A logs across releases.

Overview
Adds an opt-in OpenTelemetry Collector DaemonSet (contrib 0.159.0) that reads Class A container stdout via filelog and posts JSON to telemetry/v1/records/. It ships disabled: the ingest token Secret is not created by this chart, and --reuse-values upgrades from older releases nil-guard so the feature cannot appear by accident.

The pipeline is filelog → secret redaction (six controller.py patterns, RE2) → batch → otlphttp with Token auth, a 1 GiB disk queue, persisted read offsets, and retry-forever so the byte cap is the only bound. Collection is scoped to named control-plane containers; node-agents globs are release-prefixed to avoid cross-tenant ingest in the shared namespace.

tracebloc.nodeAgentsInUse now gates the node-agents namespace, mirrored pull Secret, and auto-upgrade/image-refresh Roles so a Collector-only install still gets those resources. OpenShift gets a separate SCC (RunAsAny, hostPath) rather than widening resource-monitor’s. Chart version 1.9.58. Drift guards cover Class A glob agreement, SCC coverage, offset persistence, and tenancy.

^{Reviewed by Cursor Bugbot for commit 452d147. Bugbot is set up for automated code reviews on this repo. Configure here.}

[LukasWodka]

bugbot run

[LukasWodka]

bugbot run

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 3152dda. Configure here.}

[aptracebloc]

Reviewed. Adds an OpenTelemetry Collector as a per-node DaemonSet in the nodeAgents namespace, reading the four Class-A control-plane containers' stdout off /var/log/pods and forwarding to the backend's versioned ingest path over otlphttp with a Token-scheme DRF token. Relocates controller.py's six secret-redaction patterns (Python→RE2) as a pre-export redaction floor, bounds a 1 GiB disk-backed queue, and ships disabled; Class-A-only scoping keeps Class-B customer training data from leaving the cluster.

The three Bugbot findings from the prior pass are all verified genuinely fixed in the templated code at HEAD 3152dda (not just marked resolved):

• crashloop: a lookup-based install-time gate now fails the release with an actionable message if the token Secret is absent, so no DaemonSet is created and the crashloop is unreachable — correct fail-soft posture, and lookup stays empty under helm template so offline renders still work.
• mirror registry: the image now resolves global.imageRegistry via the same precedence as the chart's other self-registry images; mutation-proof tests pin both the mirror and the fallback.
• namespace/pull-secret gate: both are now created under the widened (or (ne resourceMonitor false) $tc.enabled) gate.

CI fully green (40+ checks), all 5 Bugbot threads resolved, MERGEABLE. Two non-blocking test-coverage follow-ups (not merge blockers): the pull-secret gate isn't mutation-pinned (the namespace gate is), and the pre-flight fail is inherently un-pinnable by helm-unittest since lookup returns empty there.

— drafted with Claude Code

[LukasWodka]

@aptracebloc — heads up that your approval was dismissed, and by me: resolving the merge conflict required a push, and this branch dismisses stale reviews on new commits. Nothing about the review was wrong; it needs re-approving once CI settles. Sorry for the round-trip.

Since it cost no extra review cycle, I took both of your non-blocking follow-ups:

The pull-secret gate is now mutation-pinned. You were right that the namespace gate was and this one wasn't — I had verified it by hand (render diff: 4 node-agents resources with the fix, 3 without) and a by-hand check leaves nothing behind. That was the gap, not the fix. Pinned in both directions now: narrowing the gate reddens the positive test, widening it to true reddens the negative one.

The pre-flight fail — agreed, un-pinnable, so I asserted the inverse instead.lookup returns empty under helm template, so the guard can't fire in a unit test. But the failure that would actually hurt is the opposite one: a pre-flight that fired offline would break every helm template, every CI render and every --dry-run in the fleet. That property is now asserted directly rather than resting on the guard's own comment.

On the conflict itself, one thing worth your eye: the MakefileDRIFT_GUARDS collision was a union, not a side. develop's #764 added k3s-components-agreement.sh and this branch added collector-class-a-agreement.sh — taking either side would have silently deleted the other guard. Resolved to 8 with develop's ordering kept, and I assert both names are present rather than eyeballing the line, because a resolution that drops a check looks identical to a clean merge afterwards.

Chart is 1.9.53 (one patch above develop's 1.9.51 after the merge). 519/519 chart tests, make drift green on all 8.

[LukasWodka]

bugbot run

[LukasWodka]

bugbot run

[saadqbal]

The telemetry work is careful and the D7 implementation matches the RFC as amended — I reviewed rfcs#36 this morning and this lands block_on_overflow: false with the drop-count-as-only-signal consequence stated, which is exactly Consequence 2 of that amendment. But Bugbot's High is one instance of a three-instance gap, so requesting changes.

The class: everything reaching into node-agents must be gated on both tenants

This PR correctly widened two gates to (resourceMonitor || telemetryCollector.enabled) — the namespace itself and the mirrored pull Secret. Three more still gate on resourceMonitor alone while granting something in nodeAgents.namespace.name. I verified each directly rather than trusting a count:

file	gate	what it grants in node-agents
auto-upgrade-rbac.yaml:173	and (ne .Values.resourceMonitor false) (ne …)	Role :189 + RoleBinding :205 ← Bugbot's finding
image-refresh-rbac.yaml:60	if ne .Values.resourceMonitor false	Role :86 + RoleBinding :105 ← not flagged
secrets.yaml:112	and (ne .Values.resourceMonitor false) (ne …)	Secret :121 ← not flagged

So with resourceMonitor: false and telemetryCollector.enabled: true — the exact configuration this PR exists to make possible — the namespace is created and the Collector lands in it, while:

• auto-upgrade has no Role there, so the next helm upgrade --atomic --wait 403s and rolls back. Bugbot is right that this is backend#953's failure mode, and --atomic makes it a rollback rather than a partial apply, which is the expensive version.
• image-refresh has no Role there, so pull-secret refresh and rollout for the Collector DaemonSet fail — silently until an image needs re-pulling.
• whatever secrets.yaml:112 mirrors is absent from the namespace entirely.

auto-upgrade-rbac.yaml:179 makes the first one unambiguous, because it already says the release-namespace Role "does NOT reach" the node-agents namespace — so that Role is the only thing granting access there, and its condition is now wrong.

Fix it once, not three times

Three more edits leaves the same trap for the next tenant of that namespace. _helpers.tpl already carries nodeAgents.namespace.name logic, so it's the natural home for one predicate:

{{/* True when anything the chart owns lands in the node-agents namespace. */}}
{{- define "client.nodeAgentsInUse" -}}
{{- $tc := default (dict) .Values.telemetryCollector -}}
{{- if or (ne .Values.resourceMonitor false) $tc.enabled }}true{{ end -}}
{{- end -}}

then five call sites read if and (include "client.nodeAgentsInUse" .) (ne .Values.nodeAgents.namespace.name .Release.Namespace). That's the same "one parser, not N readers" shape this fleet keeps converging on, and it means adding a third tenant is one line rather than an audit.

Whichever way you go, carry the nil-guard.node-agents-namespace.yaml:34 gets this right with $tcNs := default (dict) .Values.telemetryCollector, and it's load-bearing: a bare .Values.telemetryCollector.enabled crashes templating with "nil pointer evaluating interface {}.enabled" for anyone running helm upgrade --reuse-values from a chart that predates the key — which is a very common operator habit and would fail before any resource lands. A helper centralises that guard instead of repeating it five times.

The rest is good, and two things are better than good

Shipping inert is the right call and the reasoning is the right reasoning."Enabling the Collector before that Secret exists would put a DaemonSet on every customer node spooling to disk with nothing it can deliver, filling toward the 1 GiB cap per node for no benefit — precisely the 'telemetry must never be the reason a node fills' risk D7 exists to bound." That's the failure mode reasoned from the decision rather than discovered later.

The redaction-drift caveat is the most honest thing in the PR. Carrying all six _LOG_REDACTIONS patterns because filelog bypasses controller.py's handler is the non-obvious half — without it the move removes a protection that exists today. And stating plainly that it's a cross-repo second copy that Helm cannot machine-check, in the file rather than only in the PR, is what makes it a known residual instead of a latent surprise. Compiling all six as RE2 and running them against sample secrets rather than assuming the Python→RE2 translation held is the verification I'd have asked for — "a silently-invalid regex in OTTL is a processor that starts and scrubs nothing" is exactly the failure that would otherwise look like success.

Worth noting Cursor Bugbot reports neutral here with a High open beneath it — fourth PR today with that combination.

[LukasWodka]

Fixed in 4743b96, and centralised the way you asked — tracebloc.nodeAgentsInUse in _helpers.tpl, five call sites reading it, the nil-guard living there once instead of five times.

Confirmed, with the render rather than by reading gates:

rm=true, tc=true node-agents: SA×2, Secret t-secrets, ConfigMap, Role×3, RoleBinding×3, DaemonSet×2
rm=false, tc=true node-agents: SA, ConfigMap, DaemonSet

Two corrections to the table, in both directions.

There is a fourth you didn't list:rbac.yaml:183, jobs-manager's node-agents Role/RoleBinding. It disappears in the same configuration. I only found it by diffing the two renders — reading gates found three, twice.

And two of the three must NOT be widened. I started to and stopped:

• secrets.yaml:112 mirrors CLIENT_ID/CLIENT_PASSWORD there, and its comment says why: "so the resource-monitor DaemonSet can read CLIENT_ID / CLIENT_PASSWORD via secretKeyRef". The Collector authenticates with its own telemetry token from a different Secret and never reads these. Widening this gate would copy customer credentials into a namespace for a workload that has no use for them. Its absence with resource-monitor off is correct, not a gap.
• rbac.yaml:183 grants daemonsets get/list/watch so jobs-manager can read resource-monitor's version for the heartbeat inventory — read-only, about one specific workload, and nothing asks it for the Collector's version. Correctly absent. It will need widening under backend#2274, when jobs-manager starts writing the Collector's token Secret in that namespace — but that is a Secret write, and it belongs to that ticket's chart half rather than being pre-granted here.

So: auto-upgrade and image-refresh widened (both mutate DaemonSets there, and the Collector is one), the other two deliberately left.

Guarded, because "fix it once" is only half of it. Three careful readings produced three different counts — that is the argument for a machine check rather than a fourth careful reading. scripts/tests/node-agents-tenancy.sh renders the chart twice and asserts that the Roles which mutate DaemonSets in that namespace don't depend on which DaemonSet is there. Deliberately narrower than "the two renders must match", since the mirrored Secret and the read-only Role should differ and a stricter check would have to be wrong about them.

Writing it caught a defect in the guard itself, which I'd rather record than quietly fix: matching the literals apps/daemonsetsmissed auto-upgrade's Role, because it is apiGroups: ["*"], resources: ["*"], verbs: ["*"] — the very Role Bugbot flagged. A guard that cannot see the finding it was written for is worse than none. Wildcards count now.

Mutation-proven, anchors asserted applied: auto-upgrade gate reverted → guard KILLED + 1 unit test; image-refresh reverted → guard KILLED; predicate hardcoded true → 7 unit tests; nil-guard removed → 1 failed, 1 errored.

That last row survived at first, and it is the most useful thing in this round. Go's or short-circuits, so my "survives an explicit null" test set resourceMonitor: true — the second operand was never evaluated, and the test passed happily with the nil-guard deleted. It sets resourceMonitor: false now, which is the whole test. Without the mutation I would have shipped an assertion that could not fail, in the fix for a review about gates that don't gate.

On your last point — Cursor Bugbot reporting neutral with a High open beneath it: I've seen the same on #782 today. Worth a ticket if it holds, since a neutral conclusion is not a blocking check and the required-status mapping is what decides whether that High can merge red.

529/529 chart tests, 11/11 drift guards. Re-requesting review.

[LukasWodka]

bugbot run

[saadqbal]

One of my three was a false positive, and you were right to leave it. Correcting that first.

secrets.yaml — my finding was wrong

I flagged secrets.yaml:112 as a third instance of the node-agents gate gap. It isn't. That block mirrors CLIENT_ID/CLIENT_PASSWORDfor the resource-monitor DaemonSet specifically — the comment says so, and the Secret is labelled app: {{ include "tracebloc.resourceMonitorName" . }}. The Collector uses a different secret entirely (telemetry-collector-daemonset.yaml:181, tracebloc-telemetry-token). So gating it on resourceMonitor alone is correct and widening it would mirror a credential the Collector has no use for.

I reached that finding by pattern-matching — gated on resourceMonitor, targets node-agents, therefore needs widening — and never checked what the object was for. That's confirming the half that supports the finding and skipping the half that would refute it, which is the exact failure I've flagged in other people's reasoning twice this week. Two of three, not three.

The two real ones are fixed, and via the helper

tracebloc.nodeAgentsInUse now exists at _helpers.tpl:875, with auto-upgrade-rbac and image-refresh-rbac both reading through it. That's the shape worth having: the next tenant of that namespace changes one definition, not an audit.

Bugbot's new Medium is real, and the premise is in the helper it cites

The node-agents glob is:

/var/log/pods/<nodeAgents.namespace.name>_*/<container>/*.log

and _helpers.tpl documents the design it collides with:

tracebloc.telemetryCollectorName … Same shape as tracebloc.resourceMonitorName: release-scoped, so two releases on one cluster do not collide in the shared node-agents namespace.

So two releases sharing that namespace is an anticipated shape, not a hypothetical — and release A's Collector matches release B's tracebloc-resource-monitor pod, shipping B's Class A logs under A's ingest token.

The precise reason it's easy to miss is worth stating in the fix: the release-namespace glob three lines above uses the same bare * for the pod segment and is perfectly safe, because there the namespace segment carries the release identity. In the node-agents glob the namespace is shared by design, so the pod name is the only discriminator — and it's the segment that got wildcarded. Identical printf, opposite safety.

Scoping the pod segment to the release-scoped DaemonSet name closes it:

{{- printf "%s/%s_%s-*/%s/*.log" $logs $.Values.nodeAgents.namespace.name (include "tracebloc.resourceMonitorName" $) . | quote }}

Worth a test asserting the node-agents include contains a release-scoped prefix rather than a bare _*, alongside the existing no-wildcard-include assertion — the two are the same property ("widening this is not a config tweak: it changes what leaves a customer's cluster") applied to different segments of the same path.

And this is the fix-for-a-fix worth noticing. The node-agents glob exists because an earlier Bugbot round found the Collector "healthy and blind to a whole Class A component" — scoping every path to .Release.Namespace missed the DaemonSet. Correcting that blindness over-corrected into matching other releases' components. Not a criticism; just the sort of thing that argues for the test, because the next person widening a glob here will be fixing a blind spot too.

The offset-persistence comment is a good catch of the same kind, incidentally — "the comment that used to sit here asserted the opposite, which is worse than no comment: it described a persistence this config did not have."

[LukasWodka]

Filed the Bugbot-gating point as tracebloc/backend#2284 — measured rather than asserted: Cursor Bugbot reported NEUTRAL on #779 with a High open, is not in develop's required contexts, and NEUTRAL would satisfy a required context anyway. So its verdict gates nothing today; what actually blocks is unresolved-conversation protection, which doesn't distinguish a High from a nit. Nothing has merged red because of it — the human reviews caught everything on both PRs — so it's the missing gate, not damage done.

[LukasWodka]

Thanks for the correction on secrets.yaml — and for saying so explicitly rather than letting it sit. Agreed on all three points.

Bugbot's cross-release glob is fixed in accf218 (reply on the thread). That one is the same shape as your review's finding, one layer down: the node-agents namespace is shared on purpose, and I'd scoped the workloads to the release but not the log globs that read them.

Current state: 529/529 chart tests, 11/11 drift guards, all threads resolved. Also filed the Bugbot-gating point as tracebloc/backend#2284 — measured: Cursor Bugbot is not in develop's required contexts, and NEUTRAL would satisfy it anyway.

[LukasWodka]

bugbot run

[LukasWodka]

bugbot run

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 452d147. Configure here.}

[saadqbal]

Approving. All checks green, zero open threads, MERGEABLE. Everything from three rounds is closed, and the glob fix is better than what I proposed.

The node-agents glob is now release-scoped, and more generally than I suggested. I'd said to thread include "tracebloc.resourceMonitorName" into the pod segment. You used $.Release.Name:

/var/log/pods/<nodeAgents.namespace.name>_<Release.Name>-*/<container>/*.log

That's the better call. Since every node-agent resource name in that namespace is release-scoped by construction — which is the design tracebloc.telemetryCollectorName's own comment states — prefixing with the release name discriminates correctly for resource-monitorand for whatever release-scoped node-agent this chart grows next, without threading a specific DaemonSet name through the template. My version would have needed editing the day a second Class A node-agent appeared; this one doesn't.

And you correctly left the release-namespace glob alone.:67 still uses a bare * for the pod segment, which is right — there the namespace carries release identity, so there's nothing to disambiguate. Not over-applying the fix is the part that shows the reason landed rather than the pattern.

Both RBAC gates still read through tracebloc.nodeAgentsInUse, so the two real findings from my first pass stay closed at the source rather than in two places.

And secrets.yaml is unchanged, which is correct — my flagging it was the error. Restating that here so the record is unambiguous: that block mirrors CLIENT_ID/CLIENT_PASSWORD for the resource-monitor DaemonSet specifically, the Collector uses tracebloc-telemetry-token instead, and widening the gate would have mirrored a credential the Collector has no use for. I pattern-matched from "gated on resourceMonitor, targets node-agents" without checking what the object was for. Two of my three were real; that one wasn't.

Net across the rounds: the RBAC gap was real and is now closed by a helper rather than three edits, the cross-release log-mixing glob was real and is now closed more generally than proposed, and the third thing I raised wasn't a thing. The Collector ships inert with the token secret it depends on still unwritten, so the remaining precondition is the client-runtime jobs-manager half — which the body correctly says this PR doesn't close.

[aptracebloc]

seLinuxContext: RunAsAny is necessary but, as templated, not sufficient — on an Enforcing OpenShift node the Collector will still be admitted and blind.

RunAsAny only permits an unconfined context; it does not select one. Unlike the runAsUser widening three lines up — where the SCC widens AND the pod pins runAsUser: 0 — the DaemonSet's pod securityContext sets no seLinuxOptions, and this SCC sets allowPrivilegedContainer: false. So CRI-O still assigns the container a default container_t domain with a per-container MCS level. By the exact mechanism this comment describes (container_log_t with per-container MCS categories), that context cannot dominate another pod's categories, so the include globs still take EACCES — the same "healthy, ships zero records" failure the change means to close.

Reading container_log_t under /var/log/pods requires the pod to actively assume spc_t (SystemHigh), which is why OpenShift's own node log collectors (Vector / Fluentd / fluent-bit) run privileged or with seLinuxOptions.type: spc_t. The runAsUser half works precisely because the pod chooses the value; the SELinux half widens the SCC but the pod never chooses the context, so nothing changes at runtime. Suggest adding seLinuxOptions: { type: spc_t } to the DaemonSet pod securityContext (this SCC's RunAsAny already admits it) and pinning it in the OpenShift test — the new test asserts only seLinuxContext.type: RunAsAny, which restates the template rather than proving a read can occur.

Inert-by-default and OpenShift-gated, so not a blocker for what ships — flagging before the Collector is ever enabled on OpenShift.

— drafted with Claude Code

[LukasWodka]

/fr-pass