docs: widen iam:GetRole scope and add missing organizations: actions in Identity Center setup - #150
Conversation
…in Identity Center setup (CXP-865) The Identity Center setup policy scoped iam:GetRole to SSO-provisioned roles only, but the connector calls GetRole for every IAM role returned by ListRoles — silently dropping grants for non-SSO-provisioned roles. Also adds organizations:DescribeAccount, organizations:DescribeOrganization, and organizations:ListParents, which are declared in baton_capabilities.json and called by the connector but were missing from the documented policy. Mirrors the fix proposed in ConductorOne/docs#442 in the source-of-truth docs/connector.mdx, and brings README.md's Identity Center policy in line with it (organizations:DescribeAccount was missing there too). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Connector PR Review: docs: widen iam:GetRole scope and add missing organizations: actions in Identity Center setupBlocking Issues: 0 | Suggestions: 0 | Threads Resolved: 0 Review SummaryThis is a docs-only PR ( Security IssuesNone found. Correctness IssuesNone found. SuggestionsNone. Note: the machine-readable review-state marker could not be emitted from this run because the sandbox rejected the required literal sequence; the next review will therefore run in full mode against head |
- Drop the now-redundant iam:GetRole from the AccessToSSOProvisionedRoles statements (JSON + Terraform in connector.mdx, footnote in README.md) now that Section 1 grants it at Resource:* — leaving it in both places contradicted the new explanatory note. - Drop the duplicate organizations:DescribeAccount added to README.md's provisioning policy; that policy already grants it via the dedicated AccountStatusValidationForProvisioning statement, which also carries the "Recommended" framing this duplicate would have undermined. - Split the new organizations: bullet in connector.mdx so ListParents/DescribeAccount are documented as Recommended-but-optional (matching their actual graceful-degradation behavior in account.go) rather than lumped in as hard requirements alongside ListAccounts. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
It's only called from verifyAccountStatus (account.go:571), which runs exclusively from provisionAssignment/deprovisionAssignment — never during sync. Adding it to the sync-only policy granted a provisioning-only permission outside least-privilege; it's already covered by the dedicated AccountStatusValidationForProvisioning statement in the provisioning policy. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Terraform ConductorOneReadAccess statement was missing organizations:ListRoots and organizations:ListOrganizationalUnitsForParent, unlike the JSON policy above it. Without both, granting only ListParents with the hierarchy opt-in enabled would parent accounts to Root/OU resources that organization.go skips creating. - organizations:DescribeOrganization is granted in every policy block but never called anywhere in pkg/ (only declared in capability metadata). Reworded its bullet to say so instead of claiming it's used to "retrieve organization details." - iam:GetRole was lumped into the same bullet as iam:List.../iam:GetGroup as if needed to "identify resources." It's actually only used in the Grants phase to read a role's trust policy (role.go:166) and degrades gracefully on failure. Split it into its own Recommended/fail-soft bullet, consistent with how ListParents and DescribeAccount are already documented. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
… parity with JSON The Terraform policy's ConductorOneReadAccess and ConductorOneProvisionAccess statements were missing several iam:* actions present in the equivalent JSON policy (iam:GetAccessKeyLastUsed, iam:GetUser, iam:ListAccessKeys, iam:ListSigningCertificates, iam:ListSSHPublicKeys, iam:ListServiceSpecificCredentials, iam:ListMFADevices, iam:ListUserPolicies, iam:ListAttachedUserPolicies, iam:ListGroupsForUser, iam:CreateUser, and the iam:Delete*/iam:Deactivate*/iam:TagUser cleanup actions used for full IAM user deprovisioning). Users following the Terraform path got a strictly weaker role than the console/JSON path for the same features. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Summary
The Identity Center setup policy in
docs/connector.mdx(and the matching block inREADME.md) scopediam:GetRoleto SSO-provisioned roles only (arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/*), but the connector callsGetRoleon every IAM role returned byListRoles. A reader who follows the Identity Center walkthrough verbatim gets a connector that silently omits grants for every non-SSO-provisioned role.This mirrors the fix proposed in ConductorOne/docs#442 (currently open/unmerged), applied here to the source of truth that regenerates the published page.
Changes
docs/connector.mdx(JSON + Terraform Identity Center policy blocks):iam:GetRoletoConductorOneReadAccess(Resource: "*")organizations:DescribeAccount,organizations:DescribeOrganization,organizations:ListParents— all declared inbaton_capabilities.jsonand called by the connector, but missing from the documented policyREADME.md: addsorganizations:DescribeAccountto the two Identity Center policy blocks —iam:GetRole,organizations:DescribeOrganization, andorganizations:ListParentswere already present here, onlyDescribeAccountwas missingWhy organizations:DescribeAccount belongs here
Verified against the code, not just the ticket's claim — it's used at
pkg/connector/account.go:572(account status checks during provisioning) and declared atpkg/connector/resource_types.go:236. Its absence degrades to a warn-and-skip with a less-clear error message (account.go:713,:880), the same silent-degradation failure class as theiam:GetRolegap.Test plan
jsonencode) blocks still parse as valid JSON/HCL after the editsorganizations:DescribeAccountverified as a real, called permission via source inspection, not assumed from the ticketRefs CXP-865.
🤖 Generated with Claude Code