Guard iam_policy grant emission behind WillSyncResourceType#142
Guard iam_policy grant emission behind WillSyncResourceType#142laurenleach wants to merge 2 commits into
Conversation
iamUser, role, iamGroup, and permissionSet each emit cross-type
iam_policy "attached" grants as a sync optimization, but did so
unconditionally -- even when a customer's sync filter excludes
iam_policy. Gate each emission on
cli.ConnectorOpts.WillSyncResourceType("iam_policy"), following the
pattern in ConductorOne/baton-linear#55. Same-type grants (role
trust-policy principals, group membership) remain unconditional.
Co-authored-by: c1-squire-dev[bot] <c1-squire-dev[bot]@users.noreply.github.com>
…ions For iamUser and permissionSet -- whose Grants() methods emit only the cross-type iam_policy grants, with no entitlements or same-type grants of their own -- express the sync-filter gating as an SDK-level annotation on ResourceType() instead of an in-Grants() early return. When iam_policy is being synced, return the resource type unchanged (already carries the static SkipEntitlements annotation); when it isn't, return a cloned copy annotated with SkipEntitlementsAndGrants so the SDK skips calling Entitlements()/Grants() for that type entirely. role and iamGroup keep their existing in-Grants() partial gating unchanged, since both emit legitimate same-type grants (trust-policy principals; group membership) alongside the cross-type iam_policy grants -- a whole-resource-type annotation would incorrectly suppress that real data for those two. Verified baton_capabilities.json is unaffected: the capabilities-doc generation path passes syncIAMPolicyGrants=true, which returns the resource type unchanged (byte-identical output, confirmed via diff). Co-authored-by: c1-squire-dev[bot] <c1-squire-dev[bot]@users.noreply.github.com>
Connector PR Review: Guard iam_policy grant emission behind WillSyncResourceTypeBlocking Issues: 0 | Suggestions: 0 | Threads Resolved: 0 Review SummaryScanned the full PR diff for security and correctness. This gates the cross-type iam_policy attached grants emitted by iamUser, role, iamGroup, and permissionSet behind ConnectorOpts.WillSyncResourceType(iam_policy), threaded from New() as syncIAMPolicyGrants. The nil-safe default (a nil opts means sync everything) matches the SDK WillSyncResourceType semantics, so existing installs and the capabilities-generation path are unaffected. The two mechanisms are sound: role and iamGroup gate only the iam_policy-emitting portion in place while keeping same-type grants (trust-policy principals, group membership) unconditional; iamUser and permissionSet attach SkipEntitlementsAndGrants on a proto.Clone-d resource type so the SDK skips their entitlements/grants entirely (shared package-level resource-type vars are not mutated, and tests assert this). All builder call sites were updated and unit tests cover both gate states. No new issues found. Security IssuesNone found. Correctness IssuesNone found. SuggestionsNone. |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
1 participant
Summary
iamUser,role,iamGroup, andpermissionSeteach emit cross-typeiam_policy"attached" grants as a sync optimization (their API responses already include attached-policy info), but did so unconditionally — even when a customer's sync filter excludesiam_policy.cli.ConnectorOpts.WillSyncResourceType("iam_policy")(nil-safe: a missingoptsis treated as "no filter", i.e. sync everything), computed once inconnector.New()and threaded into all four builders assyncIAMPolicyGrants bool— following the pattern in Only emit user grants (where we emit the role grants) if role resource type is enabled baton-linear#55.roleandiamGroupalso emit legitimate same-type grants (trust-policy-principal grants; group membership grants) alongside the cross-typeiam_policygrants. For these, only theiam_policy-emitting portion ofGrants()is gated in place — the same-type grants stay unconditional.iamUserandpermissionSetexist solely to emit cross-typeiam_policygrants (no entitlements, no same-type grants of their own). For these, the gating is expressed as an SDK-level annotation onResourceType()instead: wheniam_policyis being synced, the resource type is returned unchanged (already carries a staticSkipEntitlementsannotation); when it isn't, aproto.Clone'd copy is returned annotated withSkipEntitlementsAndGrants, so the SDK skips callingEntitlements()/Grants()for that type entirely rather than the connector short-circuiting internally.defaultCapabilitiesBuilder, noConnectorOptsavailable) passes a literaltrue, sobaton_capabilities.jsonis unaffected — confirmed viadiffagainst a freshly rebuilt connector'scapabilitiesoutput (no diff).Test plan
go build ./...go vet ./...go test ./...— full suite passesrole/iamGroup:Grants()output with the gate on/offiamUser/permissionSet:ResourceType()annotations with the gate on/off, plus assertions that the shared package-level resource-type vars are never mutated by the clonebaton_capabilities.jsonagainst freshcapabilitiesoutput — no diffCo-authored-by: c1-squire-dev[bot] <c1-squire-dev[bot]@users.noreply.github.com>