Rename escalation mechanism labels

[ajwdev]

Summary

Rename the escalation mechanism labels produced by mechanism_for in src/smt/access.rs:

• pods/exec -> pod-exec
• pods create -> pod-create

token and impersonate are unchanged. The Mangle rules and examples that refer to the real Kubernetes pods/exec subresource are untouched.

Behavior change

Both the displayed labels (::smt reaches, ::smt cluster-admin text output) and the mechanism field in --format ndjson output change from pods/exec / pods create to pod-exec / pod-create. Anything matching the old strings needs updating.

Why: pods/exec doubles as the real RBAC resource name, so a hop label could be read as a permission. pods create contains a space, which is awkward in the comma-joined list (pods/exec, token, pods create, impersonate) and harder to split or grep.

Consistency caveat: this is a modest improvement, not full uniformity. The other labels are single words (token is a noun, impersonate a bare verb), so the set is still mixed. The old labels were arguably fine as plain English; the gain here is mainly avoiding the clash with the RBAC resource name and having space-free labels. Also note pod-exec covers pods/attach grants too (exec_reachable_sa in rules/escalation.mg), as pods/exec did before.

Before / after

::smt cluster-admin on testdata/ alone does not show a pod-exec or pod-create hop for a user principal (only kube-system:default and pallograph-test:admin-sa chains). The output below uses testdata/ plus a small extra fixture (SA demo:target with cluster-admin and a pod running as it; exec-user with pods/exec create in demo; create-user with pods create in demo).

Before (text):

via system:serviceaccount:demo:target [pods/exec]
via system:serviceaccount:demo:target [pods create]
via system:serviceaccount:kube-system:default [pods/exec, token, pods create, impersonate]

After (text):

via system:serviceaccount:demo:target [pod-exec]
via system:serviceaccount:demo:target [pod-create]
via system:serviceaccount:kube-system:default [pod-exec, token, pod-create, impersonate]

After (--format ndjson, jq -c '[.principal, .paths[0].via]'):

["exec-user",[{"identity":"system:serviceaccount:demo:target","mechanism":"pod-exec"}]]
["create-user",[{"identity":"system:serviceaccount:demo:target","mechanism":"pod-create"}]]

The "before" labels come from a prebuilt binary without this change (same fixture); the code path is the one-line strings in mechanism_for.

Testing

Added pod_exec_and_pod_create_hops_use_hyphenated_mechanism_labels in src/smt/access.rs. It loads the fixture above through load_engine_with, calls paths_for_principal, and asserts the hop mechanism is exactly pod-exec / pod-create. No existing test asserted on these strings (tests/smt_ndjson.rs does not check mechanisms).

cargo fmt --check
cargo clippy --all-targets --locked -- -D warnings
cargo test --all-targets --locked

All pass.

🤖 Generated with Claude Code