Access setup for AWS service accounts

  • Release version: Zurich
  • Updated September 3, 2025
  • 5 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Access setup for AWS service accounts

    ServiceNow’s Cloud Discovery and Cloud Provisioning and Governance capabilities require access to AWS service accounts to discover and manage cloud resources. Access is established through MID Servers that communicate with AWS resources, requiring proper configuration of inbound traffic rules on Amazon EC2 instances.

    Show full answer Show less

    There are two main credential types for AWS access: permanent credentials and temporary credentials generated via AWS Security Token Service (STS) using IAM roles. Choosing between these depends on your security preferences and organizational structure.

    Key Features

    • Permanent Credentials: Direct AWS credentials added to ServiceNow’s Connections and Credentials module. Easier to manage initially but require manual updates.
    • Temporary Credentials: Generated by AWS STS when MID Server assumes configured IAM roles (default is OrganizationAccountAccessRole). This method enhances security and scalability, especially in large AWS organizations.
    • Role Customization: You can define custom IAM roles and permissions to restrict and tailor access beyond the default OrganizationAccountAccessRole.
    • Trust Relationships: AWS accounts can be configured as trusting or trusted accounts to streamline access management:
      • Trusting accounts rely on trusted accounts for access via IAM role trust policies.
      • Trusted accounts provide credentials or roles used by trusting accounts.
    • Multiple Access Setup Methods:
      • Single account access using permanent credentials.
      • Access via trusted accounts with AWS credentials.
      • Access via trusted accounts without AWS credentials (credential-less access) using role trust relationships.
      • Member accounts accessing AWS resources via management accounts using trust chains.
    • Credential Caching: Temporary credentials are cached by default for 60 minutes to optimize discovery operations, configurable via MID Server properties.

    How Cloud Discovery Determines Credentials

    Cloud Discovery selects credentials for accessing member AWS accounts based on the following priority:

    1. Use permanent credentials if defined in the Cloud Service Account [cmdbcicloudserviceaccount] table.
    2. If no permanent credentials, check for special AssumeRole parameters for the member account in the Cloud Service Account AWS Org Assume Role Params table and use corresponding temporary credentials.
    3. If none for member account, check the management account for AssumeRole parameters and use those temporary credentials.
    4. If no specific parameters are found, default to the OrganizationAccountAccessRole temporary credentials.

    When member or management accounts trust accessor accounts, a similar logic applies, but using the Cloud Service Account AWS Cross Assume Role Params table for temporary credential parameters.

    Practical Implications for ServiceNow Customers

    Understanding these access setup options allows you to:

    • Choose between permanent and temporary AWS credentials based on your security policies and scale.
    • Leverage IAM role trust relationships to reduce credential management overhead and improve security posture.
    • Configure MID Server and AWS security groups properly to enable seamless communication for discovery and provisioning.
    • Customize IAM roles and permissions to restrict access as needed, supporting least-privilege principles.
    • Apply caching settings to optimize discovery performance and reduce API calls to AWS.

    This structured approach ensures efficient and secure access to AWS resources for ServiceNow’s cloud management capabilities.

    Cloud Discovery and Cloud Provisioning and Governance need access to resources in the Amazon Web Services (AWS) service accounts. Learn about different methods of configuring such access.

    Cloud Discovery and Cloud Provisioning and Governance access resources in AWS service accounts through MID Servers. You must authorize inbound traffic to Amazon EC2 instances from the MID Server for setting up initial communication. For more information, see Configure security group inbound rules using the AWS Management Console.

    Types of AWS credentials

    There are permanent and temporary AWS credentials that you can use for configuring access to AWS service accounts.
    Permanent
    The permanent credentials are the actual AWS credentials for the service account that you add to the Connections and Credentials module of ServiceNow AI Platform. While it might be time consuming to manage credentials on ServiceNow AI Platform, you avoid the complex configurations involved in using temporary credentials.
    Temporary

    The temporary credentials are generated by the AWS Security Token Service (AWS STS) for IAM roles. After you configure IAM roles for AWS accounts, the MID Server accesses AWS resources with these temporary credentials. You can use the default IAM role, OrganizationAccountAccessRole, or create custom IAM roles.

    Assuming IAM roles in a large AWS organization is more convenient and offers better security than using large numbers of permanent credentials for all AWS accounts. Temporary credentials are only acquired on behalf of a service account when there’s no permanent credential specified for that service account in the Service Accounts [cmdb_ci_cloud_service_account] table.

    The MID Server uses the AssumeRole action in the AWS Security Token Service API to assume a member account role. Parameters passed to this API determine which additional security restrictions are applied to the role when it accesses the AWS resources.

    By default, the MID Server is configured to assume the OrganizationAccountAccessRole, which grants temporary credentials to all the members of a primary account. This action occurs automatically if no permanent credentials exist for the member accounts. This configuration doesn't apply any additional security or restrict access to any resources in member accounts.

    By default, the ServiceNow instance caches temporary credentials for member accounts for 60 minutes. This interval enables the horizontal discovery process to run multiple times without generating new credentials during each discovery. You can avoid credential caching or modify the caching period using MID Server properties.

    IAM roles and permissions

    To enhance security provided by the default AWS OrganizationAccountAccessRole role, you can customize the AWS roles that MID Servers can assume to receive temporary credentials for member accounts. You can configure additional permissions to improve security and customize the way that the member account’s role is assumed when discovering cloud resources.

    Methods of granting access

    For the purposes of configuring access for AWS accounts, the following terms are used:
    Trusting accounts
    The trusting accounts don't have permanent AWS credentials. You configure the trust relationship for IAM roles in these accounts to rely on other accounts for access.
    Trusted accounts
    The trusted accounts are used by the trusting accounts for access. The ServiceNow UI refers to the trusted accounts as accessor accounts.
    Typically, you set up access to the AWS accounts in your organization using the following methods:
    Configuring access for a single account
    Configuring access for an account that trusts an accessor account with AWS credentials
    Figure 1. Setting up any AWS account to rely on a trusted account with AWS credentials

    Set up the IAM role of the trusting AWS account to trust the user of the trusted AWS account for access
    • Configure any type of account—discrete (independent), management, or member—to rely on a trusted account with AWS credentials for access.
    • Configuring an IAM role belonging to the trusting accounts to trust the user of the trusted account enables using only one set of AWS credentials for providing access to multiple AWS accounts.
    For more information, see Configure temporary credential access for trusted AWS accounts.
    Configuring access for an account that trusts an accessor account without AWS credentials
    Figure 2. Setting up any AWS account to rely on a trusted account without AWS credentials

    Set up the IAM role of the trusting AWS account to trust the IAM role of the trusted AWS account for access
    • Configure any type of account—discrete (independent), management, or member—to rely on a trusted account without AWS credentials for access.
    • Configure an account without AWS credentials using an IAM role and permissions to access the trusting service account.
    • Set up the IAM role of the trusting account to grant access to the IAM role of the trusted account.
    For more information, see Configure credential-less access using trusted AWS accounts.
    Configuring access for AWS member accounts by using a trust chain from the accessor through the management account.
    Figure 3. Configuring member accounts to use their management account for access

    Set up the IAM role of the trusting member accounts to trust their management account

    How Cloud Discovery determines which credentials to use

    Member account trusts management account
    Cloud Discovery uses the following logic to determine which credentials to use to discover AWS cloud resources in member accounts:
    1. If permanent credentials are defined for the member account in the Cloud Service Account [cmdb_ci_cloud_service_account] table, Discovery uses those credentials. The Cloud Service Accounts [cmdb_ci_cloud_service_account] table contains the information on the service account types, like management or member, and their credentials.
    2. If no permanent credentials are defined for the member account, Discovery checks the Cloud Service Account AWS Org Assume Role Params [cloud_service_account_aws_org_assume_role_params] table for any special parameters associated with the member account. If parameters exist in that table, Discovery uses the temporary credentials acquired from specifying a role and its parameters in the AWS Security Token Service API AssumeRole action.
    3. If no special parameters are associated with the member account in the [cloud_service_account_aws_org_assume_role_params] table, Discovery checks that table for parameters associated with the management account. If parameters exist that define a role for the management account, Discovery uses the temporary credentials provided by that role.
    4. If no special parameters are present in the [cloud_service_account_aws_org_assume_role_params] table for either management or member accounts, Discovery uses the defaults defined for the OrganizationAccountAccessRole role.
    Member or management account trusts accessor account
    1. If permanent credentials are defined for the member or management account in the Cloud Service Account [cmdb_ci_cloud_service_account] table, Discovery uses those credentials. The Cloud Service Accounts [cmdb_ci_cloud_service_account] table contains the information on the service account types, like management or member, and their credentials.
    2. If no permanent credentials are defined for the account, Discovery checks the Cloud Service Account AWS Cross Assume Role Params [cloud_service_account_aws_cross_assume_role_params] table for any special parameters associated with the account. If parameters exist in that table, Discovery uses the temporary credentials acquired from specifying a role and its parameters in the AWS Security Token Service API AssumeRole action.