forgejo-storage reaches kubectl outside the kubectl allowlist, and runs against whatever context is active #1350

New issue

Open

opened 2026-08-28 18:46:42 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-28 18:46:42 +00:00

Owner

What it is

aosguard ops forgejo-storage is exec python3 over an embedded forgejo_storage_measure.py. That script shells the kubectl binary directly:

("kubectl", "config", "current-context"),
("kubectl", "-n", NAMESPACE, "get", "pvc,pods", "-o", "wide"),

So it never passes through aosguard ops kubectl, and none of that wrap's allowlist applies to it. Its bound is the embedded script's fixed operations, which is the stated design in docs/aosguard.md ("fixed kubectl exec operations from an embedded script invoked by absolute path"), and the script is read-only and bounded. This is not an escape.

Why it is still worth recording

Two things follow from it that are not obvious from either guardfile.

The cluster is ambient. The script passes no --context, so it measures whatever context happens to be active. After #1349 the generic wrap refuses to run without a named cluster, so the two surfaces now disagree: one cannot move without naming its target, the other silently inherits one. A measurement attributed to the wrong Forgejo is a wrong answer that looks like a right one, and #1344 is a live example of how expensive an ambient-target assumption gets.

The allowlist is not the boundary here, the script is. That is fine while the script stays fixed and read-only. It is worth stating out loud in the guardfile, because a reader who knows aosguard ops kubectl denies exec may reasonably assume every kubectl path in aosguard inherits that, and docs/forgejo-ops.md already has to say the generic surface "continues to deny exec" precisely because the two are easy to conflate.

Suggested fix

Pass an explicit --context in the embedded script rather than inheriting the active one, so the measurement names the cluster it measured.
Say in forgejo-storage.kdl that this path is bounded by the embedded script rather than by the kubectl allowlist, so nobody has to infer it.

Neither is urgent. Both are cheap.

#1348 / #1349 - the generic wrap's exec target, now closed.
#1344 - the outage where an ambient target assumption cost real time.

Found while closing #1348 in #1349. Not fixed there, because it is a different wrap and the same class of defect one layer over. Vera asked that it be an issue rather than a paragraph in a message, and she is right. ## What it is `aosguard ops forgejo-storage` is `exec python3` over an embedded `forgejo_storage_measure.py`. That script shells the **`kubectl` binary directly**: ```python ("kubectl", "config", "current-context"), ("kubectl", "-n", NAMESPACE, "get", "pvc,pods", "-o", "wide"), ``` So it never passes through `aosguard ops kubectl`, and none of that wrap's allowlist applies to it. Its bound is the embedded script's fixed operations, which **is** the stated design in `docs/aosguard.md` ("fixed `kubectl exec` operations from an embedded script invoked by absolute path"), and the script is read-only and bounded. This is not an escape. ## Why it is still worth recording Two things follow from it that are not obvious from either guardfile. **The cluster is ambient.** The script passes no `--context`, so it measures whatever context happens to be active. After #1349 the generic wrap refuses to run without a named cluster, so the two surfaces now disagree: one cannot move without naming its target, the other silently inherits one. A measurement attributed to the wrong Forgejo is a wrong answer that looks like a right one, and #1344 is a live example of how expensive an ambient-target assumption gets. **The allowlist is not the boundary here, the script is.** That is fine while the script stays fixed and read-only. It is worth stating out loud in the guardfile, because a reader who knows `aosguard ops kubectl` denies `exec` may reasonably assume every kubectl path in aosguard inherits that, and `docs/forgejo-ops.md` already has to say the generic surface "continues to deny `exec`" precisely because the two are easy to conflate. ## Suggested fix 1. Pass an explicit `--context` in the embedded script rather than inheriting the active one, so the measurement names the cluster it measured. 2. Say in `forgejo-storage.kdl` that this path is bounded by the embedded script rather than by the kubectl allowlist, so nobody has to infer it. Neither is urgent. Both are cheap. ## Related * #1348 / #1349 - the generic wrap's exec target, now closed. * #1344 - the outage where an ambient target assumption cost real time.

coilyco-ops referenced this issue

2026-08-28 19:02:52 +00:00

#1349 breaks 65 existing aosguard ops kubectl call sites at rebuild, including two live-mutation scripts #1352

coilyco-ops added the

labels

2026-08-29 07:02:46 +00:00