fix(policy): trim the memory service prefix from condition key names - #252
Conversation
A condition key's service prefix is stripped before it looks up the request value, so "s3:prefix" reads "prefix". "memory" was missing from that set, so memory:prefix kept its whole name and read a value nothing populates. The key parsed, validated and appeared in the action map, but evaluated false against a real request -- so every statement carrying it granted nothing. A condition that looks like it scopes a listing and instead silently voids the grant is worse than not having the key. Tests assert the request-name mapping for every service-prefixed key and evaluate memory:prefix against real request values, including that an absent prefix does not satisfy a scoped condition.
|
Warning Review limit reached
Next review available in: 30 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
This PR fixes policy condition evaluation for memory:-prefixed condition keys by ensuring the service prefix is trimmed before request-argument lookup, making memory:prefix and memory:max-keys effective rather than inert.
Changes:
- Add
memoryto the set of service prefixes trimmed from condition key names. - Add unit tests intended to guard the key-name → request-argument mapping and to verify
memory:prefixconditions evaluate against the real requestprefixvalue.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
policy/condition/keyname.go |
Adds "memory" to the toTrim prefix set so memory:* keys resolve to request argument names. |
policy/condition/keyname_test.go |
Introduces tests for service-prefixed key name resolution and for memory:prefix condition evaluation behavior. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
The test asserted six hand-picked keys, which does not deliver what it claimed: a key added for a new service without extending toTrim would still ship inert. It now sweeps AllSupportedKeys, so the next one fails here and the message names the prefix to add. Rewrite the Name doc comment to point at toTrim rather than enumerate prefixes, which had already drifted -- it listed four of the seven.
Follow-up to #251, which added
memory:prefixandmemory:max-keys. Both wereinert as shipped.
A condition key's service prefix is stripped before it looks up the request
value —
toTrimcoversaws,jwt,ldap,sts,svc,s3,s3tables—so
s3:prefixreads the request'sprefix.memorywas missing:The key parsed, validated, and appeared in the action condition map, so a policy
using it loaded cleanly — and then granted nothing, because the condition never
matched. That is the failure mode the key was added to prevent: a grant that
looks scoped and silently isn't.
After the fix:
Tests assert the request-name mapping for every service-prefixed key, not just
the memory ones, so the next service added here fails loudly rather than
shipping inert. Mutation-checked: removing
memoryfromtoTrimfails both.