Sandbox credential masking can fake JWTs, mask single claims, and re-sign AWS requests after swapping keys.
What's wrong with this entry?
Credential entries under sandbox.credentials can now use decode: "jwt" to swap a real token for a structurally valid fake so client-side parsing still works, and maskClaims to mask only named claims and rebuild the token. A new awsPairs setting groups masked environment variables into access-key, secret and session-token trios so the proxy can re-sign AWS SigV4 requests, and a new sigv4 block sets deny or passthrough policy for streaming uploads, presigned URLs and SigV4A.
- For environment variables, combining
decodewithextract, or with a fail-closedonExtractNoMatch, is rejected at validation time. - SigV4A signatures are asymmetric, so there is no shared key to recompute; the
sigv4block decides what happens to them. awsPairsandsigv4are only honored from user settings, managed/policy settings, or the CLI--settingsflag, and are now forwarded into the proxy's credential block.- At startup, a masked environment variable whose name uses the reserved synthesized-placeholder prefix produces a warning and degrades to
deny.
Policy for SigV4A (AWS4-ECDSA-P256-SHA256) asymmetric signatures: there is no shared-key HMAC to recompute., awsPairs
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.221
Sandbox proxy re-signs AWS SigV4 requests made with masked credentials
Both mention sandbox credential sigv4