Skip to main content

Support access to AWS

DoiT International provides complete transparency and access control when accessing your Amazon Web Services (AWS) account.

When you open a technical support request with DoiT International, we may occasionally need to access your AWS account to help you most effectively. This document describes how to enable access and how access control works.

Key points

  • We only access your AWS account to provide technical support per our contractual obligations. We never access your AWS account for any other reason.
  • Support engineers never have write-access to your AWS account. The only exception to this rule is that we are able to raise AWS support requests on your behalf.
  • AWS CloudTrail can provide a complete log of every action that we perform on your account.

When you grant an access request, the individual staff member will not have write-access to your account.

However, the CMP requires an automated management role with tightly-scoped write access to create individual read-only support roles in the securest way possible. DoiT staff members have no access to the management role, and the management role does not have write-access to any other part of your AWS account. See below for more details.

Grant access

DoiT International uses secure Identity Providers (IdP) to provide support engineers with read-only access to your AWS account. The IdP uses AWS CloudHSM to generate a unique cryptographic key pair for every support role. As a result, each key can only be used by one staff member to access a single AWS account.

When you request technical support and create a new service request with DoiT International, you will be prompted to grant DoiT International access to your AWS account.

To grant access, you must configure an AWS CloudFormation stack which allows our system to interact with your account. We have prepared a template configuration for you to install.

Technical details

Below is the template YAML file in full.


If you are installing this CloudFormation template manually, be sure to set your AWS region to us-east-1.

AWSTemplateFormatVersion: '2010-09-09'
Description: >
This template deploys the IAM Policies and Roles
needed for AWS Ops. It takes a parameter to define
if we need the payer roles as well.
Type: String
Description: Account number AWS Ops runs in
Type: String
Description: Service Token to notify on execution
Type: AWS::IAM::Role
RoleName: DoiT_Management_Role_DO-NOT-DELETE
Version: 2012-10-17
- Effect: Allow
- !Ref AccountNumberParameter
- 'sts:AssumeRole'
Type: AWS::IAM::Policy
PolicyName: DoiT_Customer_Policy_DO-NOT-DELETE
Version: 2012-10-17
# We allow List on all resources, this allows
# us to know what we need to update/do
- Effect: Allow
- 'iam:ListAttachedRolePolicies'
- 'iam:ListEntitiesForPolicy'
- 'iam:ListOpenIDConnectProviders'
- 'iam:ListPolicies'
- 'iam:ListPoliciesGrantingServiceAccess'
- 'iam:ListPolicyVersions'
- 'iam:ListRolePolicies'
- 'iam:ListRoles'
- '*'
# We only allow updating on our own resources
# which limits our ability to delete anything.
- Effect: Allow
- 'iam:AttachRolePolicy'
- 'iam:CreateOpenIDConnectProvider'
- 'iam:CreatePolicy'
- 'iam:CreatePolicyVersion'
- 'iam:CreateRole'
- 'iam:CreateSAMLProvider'
- 'iam:DeleteOpenIDConnectProvider'
- 'iam:DeletePolicy'
- 'iam:DeletePolicyVersion'
- 'iam:DeleteRole'
- 'iam:DetachRolePolicy'
- 'iam:GetOpenIDConnectProvider'
- 'iam:GetPolicy'
- 'iam:GetPolicyVersion'
- 'iam:GetRole'
- 'iam:PutRolePolicy'
- 'iam:SetDefaultPolicyVersion'
- 'iam:UpdateOpenIDConnectProviderThumbprint'
- 'iam:UpdateRole'
- 'iam:UpdateRoleDescription'
- !Sub 'arn:${AWS::Partition}:iam::${AWS::AccountId}:oidc-provider/*'
- !Sub 'arn:${AWS::Partition}:iam::${AWS::AccountId}:policy/DoiT-*'
- !Sub 'arn:${AWS::Partition}:iam::${AWS::AccountId}:role/DoiT-Support*'
- !Ref AssumeableRole
Type: Custom::Hook
Version: '1.0'
ServiceToken: !Ref ServiceToken
RoleArn: !GetAtt AssumeableRole.Arn
AccountId: !Ref 'AWS::AccountId'
- CustomerPolicy
Value: !Ref AssumeableRole
Value: !GetAtt AssumeableRole.Arn

Please note:

  • CloudFormation will create a management role that allows us to create, update, and delete individual support roles.

    For each support role, we use the management role to generate a unique cryptographic key pair. Because key creation has to be done by your IdP, the management role itself requires some limited write permissions. However:

    • The CMP has automated access to the management role, and this is how our systems interact with your account. DoiT staff members do not have access to the management role.

    • The management role's write permissions are tightly scoped and only grant what is necessary to perform key generation and the management of DoiT support roles.

    Crucially, the management role can only modify the IAM policies and roles that it creates itself. The management role does not have write-access to any of your other IAM policies or roles.

  • We create an IAM Policy and IAM Role for each staff member with the SecurityAudit policy attached to each role.