Skip to main content

Support access to AWS (deprecated)

Warning

The method on this page is deprecated. Please follow the new AWS support access instructions.

DoiT provides complete transparency when accessing your Amazon Web Services (AWS) account.

When you open a technical support request with DoiT, we may occasionally need access to your AWS account to help you effectively. This document describes how to grant 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 do not have write access to your AWS account. The only exception is that we are able to raise AWS support requests on your behalf.

  • You can use AWS CloudTrail for a complete log of every action that we perform on your account.

Note

Granting an access request doesn't give the individual DoiT employee write access to your account.

Grant access

DoiT generates a unique cryptographic key pair via AWS KMS to provide support engineers with read-only access to your AWS account. Each key can access only a single AWS account.

You must configure a new support role to grant support access to your AWS account:

  1. Log in to the DoiT console, select Billing from the top navigation bar, and then select Assets.

  2. Locate the asset that is missing the support role, and then select configure.

    A screenshot showing the Assets page

  3. Follow the on-screen instructions to create a CloudFormation stack from the template configuration we provide.

Management role

CloudFormation will create a management role that allows DoiT to create, update, and delete the support role and its identity provider.

Because we use a unique cryptographic key pair (generated via AWS KMS) for the identity provider, the management role needs to set details specific to your IAM identity provider, the management role itself requires limited write permissions.

  • The DoiT Platform has automated access to the management role, and this is how DoiT systems interact with your AWS account. The management role has no write access to any other part of your account, and DoiT employees 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 the DoiT support role.

  • The management role can only modify the IAM policies and roles created by itself. The management role does not have write access to any of your other IAM policies or roles.

CloudFormation template

This section provides the details of how we use the AWS CloudFormation stack to create a new support role, the specific AWS roles and permissions, and the security precautions we take.

Below is the template YAML file.

Caution

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.
Parameters:
AccountNumberParameter:
Type: String
Description: Account number AWS Ops runs in
ServiceToken:
Type: String
Description: Service Token to notify on execution
Resources:
AssumeableRole:
Type: AWS::IAM::Role
Properties:
RoleName: DoiT_Management_Role_DO-NOT-DELETE
AssumeRolePolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Principal:
AWS:
- !Ref AccountNumberParameter
Action:
- 'sts:AssumeRole'
CustomerPolicy:
Type: AWS::IAM::Policy
Properties:
PolicyName: DoiT_Customer_Policy_DO-NOT-DELETE
PolicyDocument:
Version: 2012-10-17
Statement:
# We allow List on all resources, this allows
# us to know what we need to update/do
- Effect: Allow
Action:
- 'iam:ListAttachedRolePolicies'
- 'iam:ListEntitiesForPolicy'
- 'iam:ListOpenIDConnectProviders'
- 'iam:ListPolicies'
- 'iam:ListPoliciesGrantingServiceAccess'
- 'iam:ListPolicyVersions'
- 'iam:ListRolePolicies'
- 'iam:ListRoles'
Resource:
- '*'
# We only allow updating on our own resources
# which limits our ability to delete anything.
- Effect: Allow
Action:
- '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'
Resource:
- !Sub 'arn:${AWS::Partition}:iam::${AWS::AccountId}:oidc-provider/oidc.aws-ops.doit-intl.com*'
- !Sub 'arn:${AWS::Partition}:iam::${AWS::AccountId}:policy/DoiT-*'
- !Sub 'arn:${AWS::Partition}:iam::${AWS::AccountId}:role/DoiT-Support*'
Roles:
- !Ref AssumeableRole
Hook:
Type: Custom::Hook
Version: '1.0'
Properties:
ServiceToken: !Ref ServiceToken
RoleArn: !GetAtt AssumeableRole.Arn
AccountId: !Ref 'AWS::AccountId'
DependsOn:
- CustomerPolicy
Outputs:
RoleName:
Value: !Ref AssumeableRole
RoleArn:
Value: !GetAtt AssumeableRole.Arn