Skip to main content
Access roles provide varying levels of permissions to AWS accounts, from read-only to full administrative access. Deploy these roles to enable Quiverstone to access and manage your AWS accounts.

​
When to Use Access Roles

  • Grant Quiverstone access to individual AWS accounts
  • Configure specific permission levels (read-only, administrator, power user, etc.)
  • Enable browser-based console access for interactive operations
  • Deploy roles across multiple accounts using StackSets
  • Provide day-to-day operational access to member accounts

​
Browser Session Deployment

Browser Session is a deployment method where Quiverstone generated the AWS Console Switch Role link for your accounts..
1

Launch CloudFormation Template

Click the button below to launch the direct access role template in your AWS account: Launch Stack
2

Configure Essential Parameters

Role Name (pRoleName): Name for the access role (Default: QuiverstoneBrowserAccess)
Security Best Practice: Change the default role name to a custom value unique to your organization. Using default role names makes it easier for unauthorized parties to discover and potentially target your roles.
External ID: Cannot be used with a browser switch role sessionPermissions: Enable the access levels you need (default is Read-Only)
  • pIsReadOnlyAccess: View all resources without making changes
  • pIsAdministratorAccess: Full administrative access
  • pIsPowerUserAccess: Full access except IAM and Organizations
  • Additional permission levels available in the template
Role Visibility Protection: When deploying support or access roles, consider adding a deny policy to prevent non-administrative roles from viewing role permissions, trust policies, and External ID configurations. This prevents privilege escalation by limiting who can inspect role configurations. See the security recommendations section below for an example policy.
3

Create Stack

Review the parameters and create the CloudFormation stack. Wait for the stack to reach CREATE_COMPLETE status.
4

BONUS: Launch CloudFormation STACKSET

Click the button below to launch the browser access role StackSet template to deploy to all accounts in your organization. Launch Stack
For detailed deployment information including StackSets and all template variants, see the Access Roles Reference.

​
Direct Access Deployment

Direct access is the simplest deployment method where Quiverstone directly assumes roles in your accounts.
1

Launch CloudFormation Template

Click the button below to launch the direct access role template in your AWS account: Launch Stack
2

Configure Essential Parameters

Role Name (pRoleName): Name for the access role (Default: QuiverstoneDirectAccess)
Security Best Practice: Change the default role name to a custom value unique to your organization. Using default role names makes it easier for unauthorized parties to discover and potentially target your roles.
External ID (pExternalId): Security token for role assumption
Required for Production: Always configure an External ID for production deployments. This prevents confused deputy attacks and unauthorized role assumptions.
  • Generate a unique random string (minimum 32 characters)
  • Store securely - you’ll need this when configuring Quiverstone
  • Never share or commit External IDs to version control
Permissions: Enable the access levels you need (default is Read-Only)
  • pIsReadOnlyAccess: View all resources without making changes
  • pIsAdministratorAccess: Full administrative access
  • pIsPowerUserAccess: Full access except IAM and Organizations
  • Additional permission levels available in the template
Role Visibility Protection: When deploying support or access roles, consider adding a deny policy to prevent non-administrative roles from viewing role permissions, trust policies, and External ID configurations. This prevents privilege escalation by limiting who can inspect role configurations. See the security recommendations section below for an example policy.
3

Create Stack

Review the parameters and create the CloudFormation stack. Wait for the stack to reach CREATE_COMPLETE status.
4

Copy Role ARN

From the stack Outputs tab, copy the role ARN (e.g., arn:aws:iam::123456789012:role/QuiverstoneDirectAccess)
5

Configure Quiverstone

In Quiverstone, add the account using:
  • Role ARN from the previous step
  • External ID you configured in the template
6

BONUS: Launch CloudFormation STACKSET

Click the button below to launch the direct access role StackSet template to deploy to all accounts in your organization. Launch Stack
For detailed deployment information including StackSets and all template variants, see the Access Roles Reference.

​
Chained Access Deployment

Chained access adds an intermediate security layer by routing role assumptions through a trusted account you control. Use this when security policies require additional controls beyond direct access.
Chained access requires two deployments: first the intermediate role, then the destination access role. Deploy in this order.
1

Deploy Intermediate Role (First)

Deploy the intermediate role to your trusted/intermediate account: Launch StackEssential Parameters:
  • Role Name (pIntermediateRoleName): Default is QuiverstoneTrustedIntermediate
    Change this to a custom role name for enhanced security
  • External ID (pExternalId): Generate unique random string (minimum 32 characters)
    Required for production - never use default or empty values
  • Assume Role Scope (pAssumeRoleScope): Use specific-role-any-account (recommended)
  • Destination Role Name (pDestinationRoleName): QuiverstoneChainedAccess
    Change this to match your custom destination role name
If you already have an intermediate role deployed, you can reuse it. Skip to Step 2.
Copy the intermediate role ARN and External ID from the stack outputs.
2

Deploy Chained Access Role (Second)

Deploy the chained access role to your target account(s): Launch StackEssential Parameters:
  • Role Name (pChainedAccessRoleName): Default is QuiverstoneChainedAccess
    Change this to a custom role name for enhanced security
  • External ID (pExternalId): Generate unique random string (can be different from intermediate)
    Required for production - use a different value than the intermediate role External ID
  • Intermediate Account ID (pIntermediateAccountId): Account ID where intermediate role is deployed
  • Intermediate Role Name (pIntermediateRoleName): Name of intermediate role (default: QuiverstoneTrustedIntermediate)
    Update this if you changed the intermediate role name
  • Trust Principals (pTrustPrincipals): Use Named for enhanced security (recommended)
  • Permissions: Enable the access levels you need (default is Read-Only)
Role Visibility Protection: When deploying support or access roles, consider adding a deny policy to prevent non-administrative roles from viewing role permissions, trust policies, and External ID configurations. This prevents privilege escalation by limiting who can inspect role configurations. See the security recommendations section below for an example policy.
Copy the chained access role ARN from the stack outputs.
3

Configure Quiverstone

In Quiverstone, configure chained access using:
  • Intermediate role ARN and External ID (from Step 1)
  • Destination role ARN and External ID (from Step 2)
4

BONUS: Launch CloudFormation STACKSET

Click the button below to launch the chained access role StackSet template to deploy to all accounts in your organization. Launch Stack
For detailed deployment information including StackSets and all template variants, see the Access Roles Reference.

​
Stand-Alone Account Inventory Deployment

Stand-Alone account inventory is a deployment method where Quiverstone can invnetory details about a single account
1

Launch CloudFormation Template

Click the button below to launch the direct access role template in your AWS account: Launch Stack
2

Configure Essential Parameters

Role Name (pRoleName): Name for the access role (Default: QuiverstoneStandaloneAccountInventory)External ID: Cannot be used with a browser switch role sessionPermissions: Enable the access levels you need (default is Read-Only)
  • pIsReadOnlyAccess: View all resources without making changes
3

Create Stack

Review the parameters and create the CloudFormation stack. Wait for the stack to reach CREATE_COMPLETE status.
For detailed deployment information including StackSets and all template variants, see the Access Roles Reference.

​
Next Steps

  • Configure additional accounts: Repeat the deployment process for other accounts
  • Adjust permissions: Modify permission levels as needed for different accounts
  • Review security: Ensure External IDs are stored securely
  • Test access: Verify Quiverstone can assume the roles successfully

​
Comprehensive Reference

For detailed information about all access role templates, deployment methods, security considerations, and troubleshooting, see the Access Roles Reference Documentation.

​
Security Recommendations

​
Protecting Role Configurations from Inspection

When deploying support or access roles, it’s important to prevent non-administrative roles from viewing role permissions, trust policies, and External ID configurations. This prevents tiered support teams and other roles from potentially escalating their own privileges by inspecting role configurations.
Privilege Escalation Risk: If support or operational roles can view IAM role trust policies and permissions, they may be able to identify External IDs, understand trust relationships, and potentially escalate their privileges. Implementing role visibility restrictions is a critical security control.

​
Example Deny Policy

Apply this policy to roles that should NOT be able to view sensitive role configurations: 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRoleInspection",
      "Effect": "Deny",
      "Action": [
        "iam:GetRole",
        "iam:GetRolePolicy",
        "iam:ListRolePolicies",
        "iam:ListAttachedRolePolicies"
      ],
      "Resource": [
        "arn:aws:iam::*:role/Quiverstone*",
        "arn:aws:iam::*:role/*Access*",
        "arn:aws:iam::*:role/*Support*"
      ]
    }
  ]
}
YAML Format (for CloudFormation): 
DenyRoleInspectionPolicy:
  Type: AWS::IAM::Policy
  Properties:
    PolicyName: DenyRoleInspection
    PolicyDocument:
      Version: '2012-10-17'
      Statement:
        - Sid: DenyRoleInspection
          Effect: Deny
          Action:
            - iam:GetRole
            - iam:GetRolePolicy
            - iam:ListRolePolicies
            - iam:ListAttachedRolePolicies
          Resource:
            - arn:aws:iam::*:role/Quiverstone*
            - arn:aws:iam::*:role/*Access*
            - arn:aws:iam::*:role/*Support*
    Roles:
      - TieredSupportRole
      - OperationsRole

​
Policy Explanation

  • DenyRoleInspection: Prevents viewing role details, trust policies, and attached policies
  • Resource Patterns: Adjust the patterns to match your custom role names
    • Quiverstone*: Matches all roles starting with “Quiverstone”
    • *Access*: Matches roles containing “Access”
    • *Support*: Matches roles containing “Support”
  • Actions Denied:
    • iam:GetRole: Prevents viewing role details including trust policy
    • iam:GetRolePolicy: Prevents viewing inline policies
    • iam:ListRolePolicies: Prevents listing inline policies
    • iam:ListAttachedRolePolicies: Prevents listing managed policies

​
Implementation Recommendations

  1. Apply to Support Roles: Attach this deny policy to all tiered support and operational roles
  2. Customize Resource Patterns: Update the resource ARN patterns to match your custom role names
  3. Exclude Administrative Roles: Do NOT apply this policy to roles that legitimately need to manage IAM
  4. Test Thoroughly: Verify the policy doesn’t block legitimate operations
  5. Document Exceptions: Clearly document which roles are exempt and why

​
Additional Security Controls

  • Use Custom Role Names: Change default role names to make discovery harder
  • Rotate External IDs: Periodically rotate External IDs according to your security policy
  • Monitor Role Assumptions: Set up CloudWatch alarms for unusual role assumption patterns
  • Implement SCPs: Use Service Control Policies to enforce organizational security requirements
  • Regular Access Reviews: Periodically review who has access to view IAM roles