Cross-account access - Bucket policy should follow least privilege

[bhuffman-incy]

Problem

The bucket policy generated by quiltx should follow least privilege. quiltx should determine the minimum access required from the Quilt control account—including both IAM principals and S3 actions—and generate the policy accordingly.

Current behavior

The original concern has been partially mitigated:

• Generated policies use a fixed S3 action allowlist rather than s3:*.
• quiltx bucket add --principal ARN allows operators to restrict access to one or more explicitly selected IAM roles.
• Policy reconciliation replaces the quiltx-managed statement while preserving unrelated statements.

However, least privilege is not yet the default:

• If --principal is omitted, quiltx trusts the entire control-account root.
• All selected principals receive the same bucket-wide read, write, delete, version, tagging, and metadata permissions.
• Principal selection is manual; quiltx does not discover the Quilt service roles that require access.
• Policies cannot currently be scoped by capability, such as read-only versus read/write, or by object prefix.
• Unregistering a bucket deliberately leaves the generated policy and related access plumbing in place.

Proposed scope

• Discover or derive the authoritative Quilt service principals that need bucket access.
• Generate capability-based action sets, at minimum distinguishing read-only from read/write access.
• Support optional object-prefix scoping where practical.
• Avoid granting control-account-root access when narrower service principals can be determined safely.
• Define cleanup behavior for quiltx-managed policy statements when a bucket is unregistered, including an explicit preserve option if needed.
• Preserve unrelated statements when updating or removing quiltx-managed policy entries.

Acceptance criteria

• The default generated policy uses only the principals and actions required for the selected Quilt functionality.
• Broader control-account-root access requires an explicit opt-in or a documented fallback when service principals cannot be determined.
• Operators can choose at least read-only and read/write policy profiles.
• Generated policies remain idempotent and preserve unrelated bucket-policy statements.
• Tests cover principal narrowing, action profiles, optional prefix scope, fallback behavior, and cleanup.

Thanks,
Brian