A storage workspace should not ask customers to paste long term AWS access keys into a settings form. Cross account IAM roles provide a better trust boundary.

BucketDesk can assume a customer role only when the trust policy permits it and the request includes the expected external ID.

The connection flow

  • Generate a unique external ID for the connection.
  • Provide a reviewed CloudFormation or Terraform template.
  • Create a least privilege role in the customer account.
  • Call STS AssumeRole when authorized work begins.
  • Use the temporary session only for its approved actions and prefixes.
  • Allow the credentials to expire and request a fresh session when needed.

Separate viewing from processing

A customer should be able to grant listing and reading without granting extraction, restoration, cache writes or deletion. Processing permissions can use a separate role or a narrower session policy.

Enforce scope twice

The product must authorize the organization, workspace, bucket, prefix and action before requesting AWS credentials. IAM then enforces the permitted AWS operations. Application authorization and provider authorization protect different boundaries; neither replaces the other.

Keep secrets out of ordinary telemetry

  • Do not log temporary credentials or session tokens.
  • Do not log signed file URLs.
  • Do not include document contents in audit events.
  • Record the role, action, resource reference, actor and result instead.
THE DECISION

Use temporary role sessions, narrow provider permissions and server side product authorization. Long term customer access keys should never become a product dependency.

Primary sources