feat(execverb): when/deny-when argv guards in CLI vocabulary (replace opaque aws-read gate) #143

New issue

Closed

opened 2026-06-15 18:15:26 +00:00 by coilysiren · 0 comments

coilysiren commented

2026-06-15 18:15:26 +00:00

Owner

Context

The shipped ward-aws.guardfile.kdl read like a third vocabulary: can run "*" behind an opaque gate aws-read, with the actual policy (read-op detection, sensitive-resource globs) baked into cli/awsgate Go. It mirrored neither the aws CLI you invoke (aws secretsmanager get-secret-value) nor the IAM policy you'd write to forbid it.

Done in this change

Added when / deny-when argv guards to the execverb grant body, expressed in CLI vocabulary:

selector is a bare flag name (secret-id -> value of --secret-id), any-arg (every positional), or argN (Nth positional after the matched subcommand path)
{ only-reads } scopes a guard to the CLI's get-/list-/describe- read convention (reuses awsgate.IsReadOnly)
{ allow-env "VAR" } is the one-shot escape
globs reuse awsgate.GlobMatch

The gate aws-read registry path stays for back-compat; the shipped aws guardfile now spells its sensitive-read denial out as a visible deny-when any-arg matches ... { only-reads; allow-env }.

Follow-ups (separate issues)

Wildcard + named-grant coexistence. Today can run "*" must be the only grant (the funnel becomes a SkipFlagParsing leaf, which can't coexist with child subcommand routing in urfave). So the aws funnel can't yet ALSO carry precise per-op when secret-id matches grants with specific-beats-catch-all precedence. Worth a design pass.
Binary wiring of ward ops aws onto execverb is tracked by #131 (the guardfile is still a spec artifact until then).

## Context The shipped `ward-aws.guardfile.kdl` read like a third vocabulary: `can run "*"` behind an opaque `gate aws-read`, with the actual policy (read-op detection, sensitive-resource globs) baked into `cli/awsgate` Go. It mirrored neither the aws CLI you invoke (`aws secretsmanager get-secret-value`) nor the IAM policy you'd write to forbid it. ## Done in this change Added `when` / `deny-when` argv guards to the execverb grant body, expressed in CLI vocabulary: - selector is a bare flag name (`secret-id` -> value of `--secret-id`), `any-arg` (every positional), or `argN` (Nth positional after the matched subcommand path) - `{ only-reads }` scopes a guard to the CLI's get-/list-/describe- read convention (reuses `awsgate.IsReadOnly`) - `{ allow-env "VAR" }` is the one-shot escape - globs reuse `awsgate.GlobMatch` The `gate aws-read` registry path stays for back-compat; the shipped aws guardfile now spells its sensitive-read denial out as a visible `deny-when any-arg matches ... { only-reads; allow-env }`. ## Follow-ups (separate issues) - **Wildcard + named-grant coexistence.** Today `can run "*"` must be the only grant (the funnel becomes a `SkipFlagParsing` leaf, which can't coexist with child subcommand routing in urfave). So the aws funnel can't yet ALSO carry precise per-op `when secret-id matches` grants with specific-beats-catch-all precedence. Worth a design pass. - Binary wiring of `ward ops aws` onto execverb is tracked by #131 (the guardfile is still a spec artifact until then).

coilysiren referenced this issue from a commit

2026-06-15 18:16:10 +00:00

feat(execverb): add when/deny-when argv guards in CLI vocabulary

coilysiren closed this issue

2026-06-15 18:16:10 +00:00

coilysiren referenced this issue from a commit

2026-06-15 18:17:11 +00:00

refactor(ward-aws): express the read gate as a visible deny-when guard

coilysiren referenced this issue from a commit

2026-06-15 18:40:51 +00:00

refactor(ward-aws): enumerated CLI-mirror allowlist, drop the env-var escape

coilysiren referenced this issue from a commit