Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.quiverstone.io/llms.txt

Use this file to discover all available pages before exploring further.

A Role in Quiverstone is a saved AWS IAM role configuration — an ARN, an optional External ID, session name, and (for chained setups) an intermediate role ARN. Roles are the building block that lets your users jump from the Quiverstone console into real AWS sessions with scoped permissions. Roles are attached to Groups, not to users directly. When a user is in a Group that includes a Role and an Account, clicking Assume Role on that Account issues temporary AWS credentials from the configured IAM role.
This page is about Quiverstone Role records — the saved IAM role configurations inside Quiverstone. For information about the underlying AWS IAM roles themselves and how to deploy them, see the IAM Roles reference.

​
What a Role record contains

FieldDescription
NameShort, descriptive identifier (e.g. ProdReadOnly, AcmeSupport).
DescriptionOptional longer explanation of what the role is for.
Target role ARNThe AWS IAM role ARN to assume (e.g. arn:aws:iam::123456789012:role/QuiverstoneProdReadOnly).
External IDThe External ID required by the target role’s trust policy, if one is configured.
Session nameOptional session identifier that appears in CloudTrail logs for the assume-role call.
Intermediate role ARNFor chained access only — the intermediate role Quiverstone assumes before assuming the target role.
Intermediate External IDThe External ID for the intermediate role, if configured.
Permission metadataHuman-readable label describing the scope of the role (read-only, administrator, support, etc.).

​
Direct vs chained Roles

Quiverstone supports two assume-role patterns. Which one you use is driven by how you deployed the underlying AWS IAM role.

​
Direct Roles

Quiverstone’s production account assumes the target role in one hop. This is the most common pattern and works for any IAM role whose trust policy allows the Quiverstone production account (684035162433). Fill in:
  • Target role ARN — the role to assume
  • External ID — if the target role requires one (strongly recommended)

​
Chained Roles

Quiverstone first assumes an intermediate role in a trusted account you control, then uses that role to assume the target role in the destination account. Use this when security policy prohibits direct external trust into your destination accounts, or when you want a single audit point for all Quiverstone access. Fill in:
  • Intermediate role ARN — the role in your trusted intermediate account
  • Intermediate External ID — if the intermediate role requires one
  • Target role ARN — the role in the destination account
  • External ID — if the target role requires one
For the full guide to deploying the AWS-side IAM roles behind these patterns, see the Access Roles Reference and the Intermediate Roles Reference.

​
Creating a Role record

1

Deploy the AWS-side IAM role first

Before creating a Role record in Quiverstone, deploy the IAM role in the target AWS account. Follow the Access Roles quickstart and copy the role ARN and External ID from the CloudFormation outputs.
2

Open Roles and click Create Role

Navigate to Roles in the main navigation and click Create Role.
The Roles navigation item is only visible to SETTINGS team members on Pro and Enterprise. If you don’t see it, you either aren’t on a SETTINGS team or your subscription is Free or Consultant.
3

Enter the role details

Paste in the target role ARN and External ID from the CloudFormation outputs. Give the Role a descriptive name that will read well when it appears in a Group later.For chained setups, also enter the intermediate role ARN and External ID.
4

Save

The Role record is now available to attach to Groups.

​
Attaching a Role to a Group

Roles on their own do nothing — they only take effect when attached to a Group alongside one or more Accounts and users.
  1. Open the Group that should use the Role (or create a new Group).
  2. In the Roles picker, select the Role record.
  3. Save the Group.
Every user in the Group — directly or via an ACCESS team — can now assume the Role on any Account referenced by the Group.

​
Assuming a Role

Once a Role is attached to a Group and a user is a member of that Group, assuming it from the UI is a single click:
1

Open the Account detail page

Navigate to Accounts and click into the Account you want to access.
2

Click Assume Role

The Assume Role button shows every Role that is attached to a Group linking you and this Account.
3

Pick the Role

Select the Role you want to assume. Quiverstone validates your access, performs the STS AssumeRole call (or the intermediate-then-target chain for chained Roles), and opens an AWS console session with the assumed credentials.
Every assume-role request is logged for audit purposes, both in Quiverstone and in the AWS account’s CloudTrail.

​
Who can create and manage Roles

TierTeam typeCan create / edit / delete Role records
Free—Subscription owner only
ConsultantACCESSTeam owner only
Pro / EnterpriseSETTINGSYes — any SETTINGS member
Pro / EnterpriseACCESSNo — ACCESS team members cannot create or edit Role records
This keeps AWS access configuration under the control of a small, trusted group of administrators. For the complete capability matrix, see the Capability reference.