Domain admin considerations

  • Release version: Yokohama
  • Updated January 30, 2025
  • 8 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 Domain Admin Considerations

    This guidance outlines critical considerations for Service Providers managing domain separation within the Cloud Provisioning and Governance (CPG) application. It focuses on the responsibilities and best practices for domain administrators, ensuring secure, efficient management and provisioning of cloud resources across multiple customer domains.

    Show full answer Show less

    Domain Administrator Responsibilities

    • Set up service and cloud accounts in the Cloud Admin Portal, mapping service accounts to appropriate cloud accounts per domain.
    • Create pre-provisioning operations to configure cloud resources before users provision or perform lifecycle operations.
    • Maintain strict governance by restricting the domain admin role exclusively to Service Provider (SP) users—not customer Cloud Admin users—to prevent unauthorized cross-domain access and data leakage.
    • Perform discovery and administration actions using users with rootadmin or cloudadmin roles, selecting the correct domain context via the domain picker.

    Cloud Account and Service Account Management

    • Ensure each domain has unique management keys and credentials; avoid sharing these across domains.
    • Service accounts securely store credentials for cloud providers; cloud accounts logically represent managed cloud infrastructure and can include multiple service accounts.
    • Follow Day 1 setup guides specific to each cloud provider (AWS, Azure, Google Cloud, VMware) to correctly configure accounts.

    Cloud API (CAPI) and Cloud Scripts

    • CAPI operates globally (not domain-separated); therefore, scripts must not contain hard-coded sensitive information.
    • Cloud scripts and templates facilitate automation and resource management but must be carefully managed to maintain security across domains.

    Discovery and Event Management

    • SPs control top-level domains and retain administrative control without delegated administration to child domains.
    • Discovery should be run from leaf domains by impersonating domain admins to maintain domain-specific visibility.
    • Event Management visibility aligns with the service account domain; users only see events linked to their domain’s accounts.
    • Set up event integrations with cloud providers (AWS Config, Azure Alert, Google Cloud Logging, VMware Events) to auto-update the CMDB and monitor health.

    Configuration Management and Catalog Sharing

    • Integrate with continuous delivery tools like Ansible and Terraform by creating configuration management providers and discovering their resources.
    • For Terraform catalogs shared across domains, perform module listing in the global domain and use a global MID Server with only Terraform capability to avoid cross-domain issues.

    Automation and Workflow Integration

    • Use ServiceNow AI Platform rules and workflows to automate Day 2 operations, including communication with cloud APIs and resource management.
    • Ensure workflows execute in the correct domain context by invoking impersonation scripts that set user context based on service account or order user.

    Budgeting, Tagging, and Billing

    • Domain-separated budgets allow assignment to groups or users, sending notifications when thresholds are reached.
    • Tags are used for resource categorization and billing but are not domain-separated; visibility depends on associated CI or billing record domains.
    • Billing data is domain-specific and configurable to generate reports per domain; scheduled jobs use MID Servers to retrieve and update billing information.

    Next Steps and Best Practices

    • When creating custom operations or workflows related to resource blocks, always set the proper domain context to ensure security and correct resource targeting.
    • Review related documentation on lifecycle operations, discovery patterns, and Day 2 setup to fully leverage domain separation capabilities.

    Before configuring domain separation for customers, ensure that you review the following considerations ahead of provisioning cloud resources for each domain you are managing in the Cloud Provisioning and Governance application.

    Domain administrator activities in a Service Provider's organization

    The following section lists activities that a domain's administrator performs for the company that a Service Provider manages. Set up service accounts and cloud accounts using the Cloud Admin Portal. Create pre-provisioning operations that you can configure for cloud resources before your users provision them or perform life-cycle operations.

    Strong universal process standards, data-driven process design, strict governance, and centralized administration maximize the benefits of domain separation in Cloud Provisioning and Governance in a single instance. The domain admin role must strictly be restricted to users in the Service Provider's organization, and not be assigned to the Cloud Admin users from the customer's organization. This restriction enables the SP to ensure that a customer does not get full access to other domain's data. Since data is often shared across multiple clients, as domain admins, don't expose or provide permissions that could result in data leakage.

    Provisioning Cloud resources

    • Ensure that you map relevant service accounts to cloud accounts in each domain. For instance, discovering a primary subscription from Azure cloud creates one or more child service accounts and are created in the same domain. This means that all service accounts in a master subscription from Azure cloud must belong to a single company and domain alone.

      Log in using a user with a root_admin or cloud_admin role, while setting up cloud and service accounts and running discovery for any domain. Use the domain picker while performing actions such as discovery or cloud and service account creation and mapping.

      Note:
      • Cloud Provisioning and Governance does not support the expand and collapse domain scope capability.
      • For more information on what a user can and cannot access, see Domain Scope

      A service account is a secure record on your instance that stores the credential and access information for your provider account. Discovery uses the information to access your provider account to get data on each resource in each specified datacenter. A cloud account is the logical representation in Cloud Provisioning and Governance of all or part of your managed cloud infrastructure. A cloud account can include multiple service accounts — even service accounts from different providers. For each service account, you specify which datacenters to include in the cloud account.

      Ensure that management keys and service account credentials are unique to each domain and are not shared. To set up cloud accounts and service accounts for multiple cloud providers, perform Day 1 Setup actions:
    • Cloud API (CAPI) and Cloud scripts and cloud script templates

      CAPI is not domain separated as, domain separation support in Cloud Provisioning and Governance. Since CAPI is set up at a global domain and shared across leaf domains, ensure that scripts do not contain hard-coded sensitive information such as account details, credentials, or names even in comments or annotations.

      CAPI enables you to integrate Cloud Provisioning and Governance with cloud providers using REST APIs. Cloud scripts are simple java scripts that use platform features. In the Cloud Provisioning and Governance application, script execution is divided into cloud scripts and cloud script templates. Use scripts in templates, resource blocks, OS profiles, and use policy scripts to set request form attributes. Policy scripts cannot override user data. Cloud script templates are actual executables which are passed to target a virtual machine for execution. Create a cloud template first and then associate it with a cloud script.

    • Cloud Discovery

      Service Providers (SPs) use domain separation to segregate data for each customer. Users in a given domain have visibility only to the data in their own domains or in child domains. SPs typically control the top-level domain, which gives them visibility to data associated with all domains. Though domain separation support for Discovery is considered Level 2, there is no delegated administration to the child domains in Cloud Provisioning and Governance. The SPs must retain administrative control. As a SP, always run discovery from a leaf domain by logging in as or impersonating a domain administrator to discover your cloud resources.

      Cloud Discovery provides a wizard that allows you to create and run cloud schedules in a single interface. When you create a schedule with the Discovery Manager, you select the accounts to discover, the credentials for accessing these accounts, and the MID Servers to scan the resources. You can then view the results in the Discovery Home page and track any errors that might have occurred.

      For more information see,
    • Set up and configure event management to receive external events and generates alerts based on event and alert management rules. The visibility of events depends on the associated service account's domain. Only users belonging that domain can see the event details for processed events. Events that are not associated to a service account are visible to all domains.

      Monitor the health of business services and infrastructure using a single management console and respond appropriately to any issues that come up. Event Management provides intelligent event and alert analysis to ensure continuity of your business service performance. Event Management receives and processes events via the MID Server.

      For more information, see

    • The Cloud Provisioning and Governance application supports integration with continuous delivery solutions (also known as configuration management). Create an Ansible or Terraform configuration management provider and then run Discovery on the provider to find its resources. For more information, see Support for continuous delivery (configuration management) and Create a workload provider type for each new configuration management provider. This information appears in the order catalog form as management attributes that your users can select when provisioning a virtual resource through a configuration management provider.

    • If you are creating catalogs based on terraform templates and sharing the catalog with multiple domains. Perform module listing (config discovery) in the global domain. The MID Server should be created in the global domain and should only be assigned with Terraform capability for its discovery. This allows SPs to share catalogs with multiple domains.

      Warning:

      Don't create a global MID Server with any other capability other than configuration management for Terraform.

      Create a common terraform catalog and share it with multiple customers:

    • Cloud Provisioning and Governance supports using ServiceNow AI Platform rules with workflows. Rules are collections of conditions and actions. ​If all conditions of a rule evaluate to true, the system performs the actions. If any condition evaluates to false, the system does not perform the actions. Creating rules helps you track activities and more quickly respond to and resolve issues. Take advantage of the workflows' framework to automate your Day 2 operations. Quickly write a workflow that communicates with a Cloud API or a particular resource. Use SSH, PowerShell, or a similar tool, to access and then extend the workflow capabilities. For more information, see Day 2 operations using workflows.

    • Budget-based notification and approval

      Domain Separation in Cloud Provisioning and Governance supports data separation of budgets. You can assign domain-specific budgets. Assign a budget for a group and a user within the group. When the user or group reaches the budget limit threshold, notifications are sent alerting them about it. For more information, see Configure budgets

      • Create Tags for cloud resources

        Tags categorize cloud resources to provide richer and more detailed tracking and billing report data. Tag keys are not domain separated and are shown to users of other domains. Tag visibility depends on the associated CI domain or associated billing record domain. Tags that are not associated to any CI or billing record are visible to all domain admins. When a tag is created, it shows up in any new catalog that you create. The cloud admin has to choose the tags they want for their catalog.

      • Billing data can be viewed separately for each domain. Billing jobs use the domain of service account configured. Configure the Billing setup to enable cloud admins and cloud users to view reports like cloud billing data and cloud tag usage on the billing dashboard.

        Define the scheduled job that regularly uses a MID Server to download billing data from the provider. Cloud Provisioning and Governance saves the data in a cost table and uses the information to generate reports.

        For more information on setting up billing schedules and downloading billing reports, see:

    Next Steps

    Important:

    While creating custom operations invoking workflows on resource blocks, ensure that you change the context to the appropriate domain.

    To change the context to the right domain, edit the Workflow Activity to call the following script from within the workflow. Ensure that an appropriate user is obtained from the Service Account creator, or the order user. Invoking this impersonation script enables the workflow to be executed in the correct context and choose the right MID Server belonging to the associated domain.
    //var orderContext = json.decode(workflow.inputs.ordercontext) ;
new CMPDomainSeparationUtil() .impersonateUser(current.request.requested_for);

    For more information on performing Cloud Provisioning and Governance life-cycle operations that are available for each domain that you are managing in your instance, see Cloud User Portal.