terraform Learn about our recommended Terraform workflow in this recommended practices guide Part 1 An Overview of Our Recommended Workflow Terraform s purpose is to provide one workflow to provision any infrastructure In this section we ll show you our recommended practices for organizing Terraform usage across a large organization This is the set of practices that we call collaborative infrastructure as code page title Part 1 Overview of Our Recommended Workflow Terraform Recommended Practices tfc only true

Answer:
---
page_title: 'Part 1: Overview of Our Recommended Workflow - Terraform Recommended Practices'
tfc_only: true
description: >-
  Learn about our recommended Terraform workflow in this recommended practices guide.
---

# Part 1: An Overview of Our Recommended Workflow

Terraform's purpose is to provide one workflow to provision any infrastructure. In this section, we'll show you our recommended practices for organizing Terraform usage across a large organization. This is the set of practices that we call "collaborative infrastructure as code."

## Fundamental Challenges in Provisioning

There are two major challenges everyone faces when trying to improve their provisioning practices: technical complexity and organizational complexity.

1. Technical complexity — Different infrastructure providers use different interfaces to provision new resources, and the inconsistency between these interfaces imposes extra costs on daily operations. These costs get worse as you add more infrastructure providers and more collaborators.

   Terraform addresses this complexity by separating the provisioning workload. It uses a single core engine to read infrastructure as code configurations and determine the relationships between resources, then uses many [provider plugins](/terraform/language/providers) to create, modify, and destroy resources on the infrastructure providers. These provider plugins can talk to IaaS (e.g. AWS, GCP, Microsoft Azure, OpenStack), PaaS (e.g. Heroku), or SaaS services (e.g. GitHub, DNSimple, Cloudflare).

   In other words, Terraform uses a model of workflow-level abstraction, rather than resource-level abstraction. It lets you use a single workflow for managing  infrastructure, but acknowledges the uniqueness of each provider instead of imposing generic concepts on non-equivalent resources.

1. Organizational complexity — As infrastructure scales, it requires more teams to maintain it. For effective collaboration, it's important to delegate ownership of infrastructure across these teams and empower them to work in parallel without conflict. Terraform and HCP Terraform can help delegate infrastructure in the same way components of a large application are delegated.

   To delegate a large application, companies often split it into small, focused microservice components that are owned by specific teams. Each microservice provides an API, and as long as those APIs don't change, microservice teams can make changes in parallel despite relying on each others' functionality.

   Similarly, infrastructure code can be split into smaller Terraform configurations, which have limited scope and are owned by specific teams. These independent configurations use [output variables](/terraform/language/values/outputs) to publish information and [remote state resources](/terraform/language/state/remote-state-data) to access output data from other workspaces. Just like microservices communicate and connect via APIs, Terraform workspaces connect via remote state.

   Once you have loosely-coupled Terraform configurations, you can delegate their development and maintenance to different teams. To do this effectively, you need to control access to that code. Version control systems can regulate who can commit code, but since Terraform affects real infrastructure, you also need to regulate who can run the code.

   This is how HCP Terraform solves the organizational complexity of provisioning: by providing a centralized run environment for Terraform that supports and enforces your organization's access control decisions across all workspaces. This helps you delegate infrastructure ownership to enable parallel development.

## Personas, Responsibilities, and Desired User Experiences

There are four main personas for managing infrastructure at scale. These roles have different responsibilities and needs, and HCP Terraform supports them with different tools and permissions.

### Central IT

This team is responsible for defining common infrastructure practices, enforcing policy across teams, and maintaining shared services.

Central IT users want a single dashboard to view the status and compliance of all infrastructure, so they can quickly fix misconfigurations or malfunctions. Since HCP Terraform is tightly integrated with Terraform's run data and is designed around Terraform's concepts of workspaces and runs, it offers a more integrated workflow experience than a general-purpose CI system.

### Organization Architect

This team defines how global infrastructure is divided and delegated to the teams within the business unit. This team also enables connectivity between workspaces by defining the APIs each workspace must expose, and sets organization-wide variables and policies.

Organization Architects want a single dashboard to view the status of all workspaces and the graph of connectivity between them.

### Workspace Owner

This individual owns a specific set of workspaces, which build a given Terraform configuration across several environments. They are responsible for the health of those workspaces, managing the full change lifecycle through dev, UAT, staging, and production. They are the main approver of changes to production within their domain.

Workspace Owners want:

* A single dashboard to view the status of all workspaces that use their infrastructure code.
* A streamlined way to promote changes between environments.
* An interface to set variables used by a Terraform configuration across environments.

### Workspace Contributor

Contributors submit changes to workspaces by making updates to the infrastructure as code configuration. They usually do not have approval to make changes to production, but can make changes in dev, UAT, and staging.

Workspace Contributors want a simple workflow to submit changes to a workspace and promote changes between workspaces. They can edit a subset of workspace variables and their own personal variables.

Workspace contributors are often already familiar with Terraform's operating model and command line interface, and can usually adapt quickly to HCP Terraform's web interface.

## The Recommended Terraform Workspace Structure

### About Workspaces

HCP Terraform's main unit of organization is a workspace. A workspace is a collection of everything Terraform needs to run: a Terraform configuration (usually from a VCS repo), values for that configuration's variables, and state data to keep track of operations between runs.

In Terraform Community edition, a workspace is an independent state file on the local disk. In HCP Terraform, they're persistent shared resources; you can assign them their own access controls, monitor their run states, and more.

### One Workspace Per Environment Per Terraform Configuration

Workspaces are HCP Terraform's primary tool for delegating control, which means their structure should match your organizational permissions structure. The best approach is to use one workspace for each environment of a given infrastructure component. Or in other words, Terraform configurations \* environments = workspaces.

This is different from how some other tools view environments; notably, you shouldn't use a single Terraform workspace to manage everything that makes up your production or staging environment. Instead, make smaller workspaces that are easy to delegate. This also means not every configuration has to use the exact same environments; if a UAT environment doesn't make sense for your security infrastructure, you aren't forced to use one.

Name your workspaces with both their component and their environment. For example, if you have a Terraform configuration for managing an internal billing app and another for your networking infrastructure, you could name the workspaces as follows:

* billing-app-dev
* billing-app-stage
* billing-app-prod
* networking-dev
* networking-stage
* networking-prod

### Delegating Workspaces

Since each workspace is one environment of one infrastructure component, you can use per-workspace access controls to delegate ownership of components and regulate code promotion across environments. For example:

* Teams that help manage a component can start Terraform runs and edit variables in dev or staging.
* The owners or senior contributors of a component can start Terraform runs in production, after reviewing other contributors' work.
* Central IT and organization architects can administer permissions on all workspaces, to ensure everyone has what they need to work.
* Teams that have no role managing a given component don't have access to its workspaces.

To use HCP Terraform effectively, you must make sure the division of workspaces and permissions matches your organization's division of responsibilities. If it's difficult to separate your workspaces effectively, it might reveal an area of your infrastructure where responsibility is muddled and unclear. If so, this is a chance to disentangle the code and enforce better boundaries of ownership.

## Next

Now that you're familiar with the outlines of the HCP Terraform workflow, it's time to assess your organization's provisioning practices. Continue on to [Part 2: Evaluating Your Current Provisioning Practices](/terraform/cloud-docs/recommended-practices/part2).

page title   Part 1  Overview of Our Recommended Workflow   Terraform Recommended Practices  tfc only  true description       Learn about our recommended Terraform workflow in this recommended practices guide         Part 1  An Overview of Our Recommended Workflow  Terraform s purpose is to provide one workflow to provision any infrastructure  In this section  we ll show you our recommended practices for organizing Terraform usage across a large organization  This is the set of practices that we call  collaborative infrastructure as code       Fundamental Challenges in Provisioning  There are two major challenges everyone faces when trying to improve their provisioning practices  technical complexity and organizational complexity   1  Technical complexity   Different infrastructure providers use different interfaces to provision new resources  and the inconsistency between these interfaces imposes extra costs on daily operations  These costs get worse as you add more infrastructure providers and more collaborators      Terraform addresses this complexity by separating the provisioning workload  It uses a single core engine to read infrastructure as code configurations and determine the relationships between resources  then uses many  provider plugins   terraform language providers  to create  modify  and destroy resources on the infrastructure providers  These provider plugins can talk to IaaS  e g  AWS  GCP  Microsoft Azure  OpenStack   PaaS  e g  Heroku   or SaaS services  e g  GitHub  DNSimple  Cloudflare       In other words  Terraform uses a model of workflow level abstraction  rather than resource level abstraction  It lets you use a single workflow for managing  infrastructure  but acknowledges the uniqueness of each provider instead of imposing generic concepts on non equivalent resources   1  Organizational complexity   As infrastructure scales  it requires more teams to maintain it  For effective collaboration  it s important to delegate ownership of infrastructure across these teams and empower them to work in parallel without conflict  Terraform and HCP Terraform can help delegate infrastructure in the same way components of a large application are delegated      To delegate a large application  companies often split it into small  focused microservice components that are owned by specific teams  Each microservice provides an API  and as long as those APIs don t change  microservice teams can make changes in parallel despite relying on each others  functionality      Similarly  infrastructure code can be split into smaller Terraform configurations  which have limited scope and are owned by specific teams  These independent configurations use  output variables   terraform language values outputs  to publish information and  remote state resources   terraform language state remote state data  to access output data from other workspaces  Just like microservices communicate and connect via APIs  Terraform workspaces connect via remote state      Once you have loosely coupled Terraform configurations  you can delegate their development and maintenance to different teams  To do this effectively  you need to control access to that code  Version control systems can regulate who can commit code  but since Terraform affects real infrastructure  you also need to regulate who can run the code      This is how HCP Terraform solves the organizational complexity of provisioning  by providing a centralized run environment for Terraform that supports and enforces your organization s access control decisions across all workspaces  This helps you delegate infrastructure ownership to enable parallel development      Personas  Responsibilities  and Desired User Experiences  There are four main personas for managing infrastructure at scale  These roles have different responsibilities and needs  and HCP Terraform supports them with different tools and permissions       Central IT  This team is responsible for defining common infrastructure practices  enforcing policy across teams  and maintaining shared services   Central IT users want a single dashboard to view the status and compliance of all infrastructure  so they can quickly fix misconfigurations or malfunctions  Since HCP Terraform is tightly integrated with Terraform s run data and is designed around Terraform s concepts of workspaces and runs  it offers a more integrated workflow experience than a general purpose CI system       Organization Architect  This team defines how global infrastructure is divided and delegated to the teams within the business unit  This team also enables connectivity between workspaces by defining the APIs each workspace must expose  and sets organization wide variables and policies   Organization Architects want a single dashboard to view the status of all workspaces and the graph of connectivity between them       Workspace Owner  This individual owns a specific set of workspaces  which build a given Terraform configuration across several environments  They are responsible for the health of those workspaces  managing the full change lifecycle through dev  UAT  staging  and production  They are the main approver of changes to production within their domain   Workspace Owners want     A single dashboard to view the status of all workspaces that use their infrastructure code    A streamlined way to promote changes between environments    An interface to set variables used by a Terraform configuration across environments       Workspace Contributor  Contributors submit changes to workspaces by making updates to the infrastructure as code configuration  They usually do not have approval to make changes to production  but can make changes in dev  UAT  and staging   Workspace Contributors want a simple workflow to submit changes to a workspace and promote changes between workspaces  They can edit a subset of workspace variables and their own personal variables   Workspace contributors are often already familiar with Terraform s operating model and command line interface  and can usually adapt quickly to HCP Terraform s web interface      The Recommended Terraform Workspace Structure      About Workspaces  HCP Terraform s main unit of organization is a workspace  A workspace is a collection of everything Terraform needs to run  a Terraform configuration  usually from a VCS repo   values for that configuration s variables  and state data to keep track of operations between runs   In Terraform Community edition  a workspace is an independent state file on the local disk  In HCP Terraform  they re persistent shared resources  you can assign them their own access controls  monitor their run states  and more       One Workspace Per Environment Per Terraform Configuration  Workspaces are HCP Terraform s primary tool for delegating control  which means their structure should match your organizational permissions structure  The best approach is to use one workspace for each environment of a given infrastructure component  Or in other words  Terraform configurations    environments   workspaces   This is different from how some other tools view environments  notably  you shouldn t use a single Terraform workspace to manage everything that makes up your production or staging environment  Instead  make smaller workspaces that are easy to delegate  This also means not every configuration has to use the exact same environments  if a UAT environment doesn t make sense for your security infrastructure  you aren t forced to use one   Name your workspaces with both their component and their environment  For example  if you have a Terraform configuration for managing an internal billing app and another for your networking infrastructure  you could name the workspaces as follows     billing app dev   billing app stage   billing app prod   networking dev   networking stage   networking prod      Delegating Workspaces  Since each workspace is one environment of one infrastructure component  you can use per workspace access controls to delegate ownership of components and regulate code promotion across environments  For example     Teams that help manage a component can start Terraform runs and edit variables in dev or staging    The owners or senior contributors of a component can start Terraform runs in production  after reviewing other contributors  work    Central IT and organization architects can administer permissions on all workspaces  to ensure everyone has what they need to work    Teams that have no role managing a given component don t have access to its workspaces   To use HCP Terraform effectively  you must make sure the division of workspaces and permissions matches your organization s division of responsibilities  If it s difficult to separate your workspaces effectively  it might reveal an area of your infrastructure where responsibility is muddled and unclear  If so  this is a chance to disentangle the code and enforce better boundaries of ownership      Next  Now that you re familiar with the outlines of the HCP Terraform workflow  it s time to assess your organization s provisioning practices  Continue on to  Part 2  Evaluating Your Current Provisioning Practices   terraform cloud docs recommended practices part2


terraform Part 2 Evaluating Your Current Provisioning Practices Practices page title Use a quiz to evaluate your current Terraform provisioning practices Learn whether your practices are mostly manual semi automated infrastructure as code or collaborative infrastructure as code tfc only true Part 2 Evaluating Your Current Provisioning Practices Terraform Recommended

Answer:
---
page_title: >-
  Part 2: Evaluating Your Current Provisioning Practices - Terraform Recommended
  Practices
tfc_only: true
description: >-
  Use a quiz to evaluate your current Terraform provisioning practices. Learn whether your practices are mostly manual, semi-automated, infrastructure-as-code, or collaborative infrastructure-as-code.
---

# Part 2: Evaluating Your Current Provisioning Practices

HCP Terraform depends on several foundational IT practices. Before you can implement HCP Terraform's collaborative infrastructure as code workflows, you need to understand which of those practices you're already using, and which ones you still need to implement.

We've written the section below in the form of a quiz or interview, with multiple-choice answers that represent the range of operational maturity levels we've seen across many organizations. You should read it with a notepad handy, and take note of any questions where your organization can improve its use of automation and collaboration.

This quiz doesn't have a passing or failing score, but it's important to know your organization's answers. Once you know which of your IT practices need the most attention, Section 3 will guide you from your current state to our recommended practices in the most direct way.

## Four Levels of Operational Maturity

Each question has several answers, each of which aligns with a different level of operational maturity. Those levels are as follows:

1. **Manual**
   * Infrastructure is provisioned through a UI or CLI.
   * Configuration changes do not leave a traceable history, and aren't always visible.
   * Limited or no naming standards in place.

1. **Semi-automated**
   * Infrastructure is provisioned through a combination of UI/CLI, infrastructure as code, and scripts or configuration management.
   * Traceability is limited, since different record-keeping methods are used across the organization.
   * Rollbacks are hard to achieve due to differing record-keeping methods.

1. **Infrastructure as code**
   * Infrastructure is provisioned using Terraform OSS.
   * Provisioning and deployment processes are automated.
   * Infrastructure configuration is consistent, with all necessary details fully documented (nothing siloed in a sysadmin's head).
   * Source files are stored in version control to record editing history, and, if necessary, roll back to older versions.
   * Some Terraform code is split out into modules, to promote consistent reuse of your organization's more common architectural patterns.

1. **Collaborative infrastructure as code**
   * Users across the organization can safely provision infrastructure with Terraform, without conflicts and with clear understanding of their access permissions.
   * Expert users within an organization can produce standardized infrastructure templates, and beginner users can consume those to follow infrastructure best practices for the organization.
   * Per-workspace access control helps committers and approvers on workspaces protect production environments.
   * Functional groups that don't directly write Terraform code have visibility into infrastructure status and changes through HCP Terraform's UI.

By the end of this section, you should have a clear understanding of which operational maturity stage you are in. Section 3 will explain the recommended steps to move from your current stage to the next one.

Answering these questions will help you understand your organization's method for provisioning infrastructure, its change workflow, its operation model, and its security model.

Once you understand your current practices, you can identify the remaining steps for implementing HCP Terraform.

## Your Current Configuration and Provisioning Practices

How does your organization configure and provision infrastructure today? Automated and consistent practices help make your infrastructure more knowable and reliable, and reduce the amount of time spent on troubleshooting.

The following questions will help you evaluate your current level of automation for configuration and provisioning.

### Q1. How do you currently manage your infrastructure?

1. Through a UI or CLI. This might seem like the easiest option for one-off tasks, but for recurring operations it is a big consumer of valuable engineering time. It's also difficult to track and manage changes.
1. Through reusable command line scripts, or a combination of UI and infrastructure as code. This is faster and more reliable than pure ad-hoc management and makes recurring operations repeatable, but the lack of consistency and versioning makes it difficult to manage over time.
1. Through an infrastructure as code tool (Terraform, CloudFormation). Infrastructure as code enables scalable, repeatable, and versioned infrastructure. It dramatically increases the productivity of each operator and can enforce consistency across environments when used appropriately.
1. Through a general-purpose automation framework (i.e. Jenkins + scripts / Jenkins + Terraform). This centralizes the management workflow, albeit with a tool that isn't built specifically for provisioning tasks.

### Q2. What topology is in place for your service provider accounts?

1. Flat structure, single account. All infrastructure is provisioned within the same account.
1. Flat structure, multiple accounts. Infrastructure is provisioned using different infrastructure providers, with an account per environment.
1. Tree hierarchy. This features a master billing account, an audit/security/logging account, and project/environment-specific infrastructure accounts.

### Q3. How do you manage the infrastructure for different environments?

1. Manual. Everything is manual, with no configuration management in place.
1. Siloed. Each application team has its own way of managing infrastructure — some manually, some using infrastructure as code or custom scripts.
1. Infrastructure as code with different code bases per environment. Having different code bases for infrastructure as code configurations can lead to untracked changes from one environment to the other if there is no promotion within environments.
1. Infrastructure as code with a single code base and differing environment variables. All resources, regardless of environment, are provisioned with the same code, ensuring that changes promote through your deployment tiers in a predictable way.

### Q4. How do teams collaborate and share infrastructure configuration and code?

1. N/A. Infrastructure as code is not used.
1. Locally. Infrastructure configuration is hosted locally and shared via email, documents or spreadsheets.
1. Ticketing system. Code is shared through journal entries in change requests or problem/incident tickets.
1. Centralized without version control. Code is stored on a shared filesystem and secured through security groups. Changes are not versioned. Rollbacks are only possible through restores from backups or snapshots.
1. Configuration stored and collaborated in a version control system (VCS) (Git repositories, etc.). Teams collaborate on infrastructure configurations within a VCS workflow, and can review infrastructure changes before they enter production. This is the most mature approach, as it offers the best record-keeping and cross-department/cross-team visibility.

### Q5. Do you use reusable modules for writing infrastructure as code?

1. Everything is manual. No infrastructure as code currently used.
1. No modularity. Infrastructure as code is used, but primarily as one-off configurations. Users usually don't share or re-use code.
1. Teams use modules internally but do not share them across teams.
1. Modules are shared organization-wide. Similar to shared software libraries, a module for a common infrastructure pattern can be updated once and the entire organization benefits.

## Your Current Change Control Workflow

Change control is a formal process to coordinate and approve changes to a product or system. The goals of a change control process include:

* Minimizing disruption to services.
* Reducing rollbacks.
* Reducing the overall cost of changes.
* Preventing unnecessary changes.
* Allowing users to make changes without impacting changes made by other users.

The following questions will help you assess the maturity of your change control workflow.

### Q6. How do you govern the access to control changes to infrastructure?

1. Access is not restricted or audited. Everyone in the platform team has the flexibility to create, change, and destroy all infrastructure. This leads to a complex system that is unstable and hard to manage.
1. Access is not restricted, only audited. This makes it easier to track changes after the fact, but doesn't proactively protect your infrastructure's stability.
1. Access is restricted based on service provider account level. Members of the team have admin access to different accounts based on the environment they are responsible for.
1. Access is restricted based on user roles. All access is restricted based on user roles at infrastructure provider level.

### Q7. What is the process for changing existing infrastructure?

1. Manual changes by remotely logging into machines. Repetitive manual tasks are inefficient and prone to human errors.
1. Runtime configuration management (Puppet, Chef, etc.). Configuration management tools let you make fast, automated changes based on readable and auditable code. However, since they don't produce static artifacts, the outcome of a given configuration version isn't always 100% repeatable, making rollbacks only partially reliable.
1. Immutable infrastructure (images, containers). Immutable components can be replaced for every deployment (rather than being updated in-place), using static deployment artifacts. If you maintain sharp boundaries between ephemeral layers and state-storing layers, immutable infrastructure can be much easier to test, validate, and roll back.

### Q8. How do you deploy applications?

1. Manually (SSH, WinRM, rsync, robocopy, etc.). Repetitive manual tasks are inefficient and prone to human errors.
1. With scripts (Fabric, Capistrano, custom, etc.).
1. With a configuration management tool (Chef, Puppet, Ansible, Salt, etc.), or by passing userdata scripts to CloudFormation Templates or Terraform configuration files.
1. With a scheduler (Kubernetes, Nomad, Mesos, Swarm, ECS, etc.).

## Your Current Security Model

### Q9. How are infrastructure service provider credentials managed?

1. By hardcoding them in the source code. This is highly insecure.
1. By using infrastructure provider roles (like EC2 instance roles for AWS).Since the service provider knows the identity of the machines it's providing, you can grant some machines permission to make API requests without giving them a copy of your actual credentials.
1. By using a secrets management solution (like Vault, Keywhis, or PAR).We recommend this.
1. By using short-lived tokens. This is one of the most secure methods, since the temporary credentials you distribute expire quickly and are very difficult to exploit. However, this can be more complex to use than a secrets management solution.

### Q10. How do you control users and objects hosted by your infrastructure provider (like logins, access and role control, etc.)?

1. A common 'admin' or 'superuser' account shared by engineers. This increases the possibility of a breach into your infrastructure provider account.
1. Individual named user accounts. This makes a loss of credentials less likely and easier to recover from, but it doesn't scale very well as the team grows.
1. LDAP and/or Microsoft Entra ID integration. This is much more secure than shared accounts, but requires additional architectural considerations to ensure that the provider's access into your corporate network is configured correctly.
1. Single sign-on through OAuth or SAML. This provides token-based access into your infrastructure provider while not requiring your provider to have access to your corporate network.

### Q11. How do you track the changes made by different users in your infrastructure provider's environments?

1. No logging in place. Auditing and troubleshooting can be very difficult without a record of who made which changes when.
1. Manual changelog. Users manually write down their changes to infrastructure in a shared document. This method is prone to human error.
1. By logging all API calls to an audit trail service or log management service (like CloudTrail, Loggly, or Splunk). We recommend this. This ensures that an audit trail is available during troubleshooting and/or security reviews.

### Q12. How is the access of former employees revoked?

1. Immediately, manually. If you don't use infrastructure as code, the easiest and quickest way is by removing access for that employee manually using the infrastructure provider's console.
1. Delayed, as part of the next release. if your release process is extremely coupled and most of your security changes have to pass through a CAB (Change Advisory Board) meeting in order to be executed in production, this could be delayed.
1. Immediately, writing a hot-fix in the infrastructure as code. this is the most secure and recommended option. Before the employee leaves the building, access must be removed.

## Assessing the Overall Maturity of Your Provisioning Practices

After reviewing all of these questions, look back at your notes and assess your organization's overall stage of maturity: are your practices mostly manual, semi-automated, infrastructure as code, or collaborative infrastructure as code?

Keep your current state in mind as you read the next section.

## Next

Now that you've taken a hard look at your current practices, it's time to begin improving them. Continue on to [Part 3: How to Evolve Your Provisioning Practices](/terraform/cloud-docs/recommended-practices/part3).

page title       Part 2  Evaluating Your Current Provisioning Practices   Terraform Recommended   Practices tfc only  true description       Use a quiz to evaluate your current Terraform provisioning practices  Learn whether your practices are mostly manual  semi automated  infrastructure as code  or collaborative infrastructure as code         Part 2  Evaluating Your Current Provisioning Practices  HCP Terraform depends on several foundational IT practices  Before you can implement HCP Terraform s collaborative infrastructure as code workflows  you need to understand which of those practices you re already using  and which ones you still need to implement   We ve written the section below in the form of a quiz or interview  with multiple choice answers that represent the range of operational maturity levels we ve seen across many organizations  You should read it with a notepad handy  and take note of any questions where your organization can improve its use of automation and collaboration   This quiz doesn t have a passing or failing score  but it s important to know your organization s answers  Once you know which of your IT practices need the most attention  Section 3 will guide you from your current state to our recommended practices in the most direct way      Four Levels of Operational Maturity  Each question has several answers  each of which aligns with a different level of operational maturity  Those levels are as follows   1    Manual        Infrastructure is provisioned through a UI or CLI       Configuration changes do not leave a traceable history  and aren t always visible       Limited or no naming standards in place   1    Semi automated        Infrastructure is provisioned through a combination of UI CLI  infrastructure as code  and scripts or configuration management       Traceability is limited  since different record keeping methods are used across the organization       Rollbacks are hard to achieve due to differing record keeping methods   1    Infrastructure as code        Infrastructure is provisioned using Terraform OSS       Provisioning and deployment processes are automated       Infrastructure configuration is consistent  with all necessary details fully documented  nothing siloed in a sysadmin s head        Source files are stored in version control to record editing history  and  if necessary  roll back to older versions       Some Terraform code is split out into modules  to promote consistent reuse of your organization s more common architectural patterns   1    Collaborative infrastructure as code        Users across the organization can safely provision infrastructure with Terraform  without conflicts and with clear understanding of their access permissions       Expert users within an organization can produce standardized infrastructure templates  and beginner users can consume those to follow infrastructure best practices for the organization       Per workspace access control helps committers and approvers on workspaces protect production environments       Functional groups that don t directly write Terraform code have visibility into infrastructure status and changes through HCP Terraform s UI   By the end of this section  you should have a clear understanding of which operational maturity stage you are in  Section 3 will explain the recommended steps to move from your current stage to the next one   Answering these questions will help you understand your organization s method for provisioning infrastructure  its change workflow  its operation model  and its security model   Once you understand your current practices  you can identify the remaining steps for implementing HCP Terraform      Your Current Configuration and Provisioning Practices  How does your organization configure and provision infrastructure today  Automated and consistent practices help make your infrastructure more knowable and reliable  and reduce the amount of time spent on troubleshooting   The following questions will help you evaluate your current level of automation for configuration and provisioning       Q1  How do you currently manage your infrastructure   1  Through a UI or CLI  This might seem like the easiest option for one off tasks  but for recurring operations it is a big consumer of valuable engineering time  It s also difficult to track and manage changes  1  Through reusable command line scripts  or a combination of UI and infrastructure as code  This is faster and more reliable than pure ad hoc management and makes recurring operations repeatable  but the lack of consistency and versioning makes it difficult to manage over time  1  Through an infrastructure as code tool  Terraform  CloudFormation   Infrastructure as code enables scalable  repeatable  and versioned infrastructure  It dramatically increases the productivity of each operator and can enforce consistency across environments when used appropriately  1  Through a general purpose automation framework  i e  Jenkins   scripts   Jenkins   Terraform   This centralizes the management workflow  albeit with a tool that isn t built specifically for provisioning tasks       Q2  What topology is in place for your service provider accounts   1  Flat structure  single account  All infrastructure is provisioned within the same account  1  Flat structure  multiple accounts  Infrastructure is provisioned using different infrastructure providers  with an account per environment  1  Tree hierarchy  This features a master billing account  an audit security logging account  and project environment specific infrastructure accounts       Q3  How do you manage the infrastructure for different environments   1  Manual  Everything is manual  with no configuration management in place  1  Siloed  Each application team has its own way of managing infrastructure   some manually  some using infrastructure as code or custom scripts  1  Infrastructure as code with different code bases per environment  Having different code bases for infrastructure as code configurations can lead to untracked changes from one environment to the other if there is no promotion within environments  1  Infrastructure as code with a single code base and differing environment variables  All resources  regardless of environment  are provisioned with the same code  ensuring that changes promote through your deployment tiers in a predictable way       Q4  How do teams collaborate and share infrastructure configuration and code   1  N A  Infrastructure as code is not used  1  Locally  Infrastructure configuration is hosted locally and shared via email  documents or spreadsheets  1  Ticketing system  Code is shared through journal entries in change requests or problem incident tickets  1  Centralized without version control  Code is stored on a shared filesystem and secured through security groups  Changes are not versioned  Rollbacks are only possible through restores from backups or snapshots  1  Configuration stored and collaborated in a version control system  VCS   Git repositories  etc    Teams collaborate on infrastructure configurations within a VCS workflow  and can review infrastructure changes before they enter production  This is the most mature approach  as it offers the best record keeping and cross department cross team visibility       Q5  Do you use reusable modules for writing infrastructure as code   1  Everything is manual  No infrastructure as code currently used  1  No modularity  Infrastructure as code is used  but primarily as one off configurations  Users usually don t share or re use code  1  Teams use modules internally but do not share them across teams  1  Modules are shared organization wide  Similar to shared software libraries  a module for a common infrastructure pattern can be updated once and the entire organization benefits      Your Current Change Control Workflow  Change control is a formal process to coordinate and approve changes to a product or system  The goals of a change control process include     Minimizing disruption to services    Reducing rollbacks    Reducing the overall cost of changes    Preventing unnecessary changes    Allowing users to make changes without impacting changes made by other users   The following questions will help you assess the maturity of your change control workflow       Q6  How do you govern the access to control changes to infrastructure   1  Access is not restricted or audited  Everyone in the platform team has the flexibility to create  change  and destroy all infrastructure  This leads to a complex system that is unstable and hard to manage  1  Access is not restricted  only audited  This makes it easier to track changes after the fact  but doesn t proactively protect your infrastructure s stability  1  Access is restricted based on service provider account level  Members of the team have admin access to different accounts based on the environment they are responsible for  1  Access is restricted based on user roles  All access is restricted based on user roles at infrastructure provider level       Q7  What is the process for changing existing infrastructure   1  Manual changes by remotely logging into machines  Repetitive manual tasks are inefficient and prone to human errors  1  Runtime configuration management  Puppet  Chef  etc    Configuration management tools let you make fast  automated changes based on readable and auditable code  However  since they don t produce static artifacts  the outcome of a given configuration version isn t always 100  repeatable  making rollbacks only partially reliable  1  Immutable infrastructure  images  containers   Immutable components can be replaced for every deployment  rather than being updated in place   using static deployment artifacts  If you maintain sharp boundaries between ephemeral layers and state storing layers  immutable infrastructure can be much easier to test  validate  and roll back       Q8  How do you deploy applications   1  Manually  SSH  WinRM  rsync  robocopy  etc    Repetitive manual tasks are inefficient and prone to human errors  1  With scripts  Fabric  Capistrano  custom  etc    1  With a configuration management tool  Chef  Puppet  Ansible  Salt  etc    or by passing userdata scripts to CloudFormation Templates or Terraform configuration files  1  With a scheduler  Kubernetes  Nomad  Mesos  Swarm  ECS  etc        Your Current Security Model      Q9  How are infrastructure service provider credentials managed   1  By hardcoding them in the source code  This is highly insecure  1  By using infrastructure provider roles  like EC2 instance roles for AWS  Since the service provider knows the identity of the machines it s providing  you can grant some machines permission to make API requests without giving them a copy of your actual credentials  1  By using a secrets management solution  like Vault  Keywhis  or PAR  We recommend this  1  By using short lived tokens  This is one of the most secure methods  since the temporary credentials you distribute expire quickly and are very difficult to exploit  However  this can be more complex to use than a secrets management solution       Q10  How do you control users and objects hosted by your infrastructure provider  like logins  access and role control  etc     1  A common  admin  or  superuser  account shared by engineers  This increases the possibility of a breach into your infrastructure provider account  1  Individual named user accounts  This makes a loss of credentials less likely and easier to recover from  but it doesn t scale very well as the team grows  1  LDAP and or Microsoft Entra ID integration  This is much more secure than shared accounts  but requires additional architectural considerations to ensure that the provider s access into your corporate network is configured correctly  1  Single sign on through OAuth or SAML  This provides token based access into your infrastructure provider while not requiring your provider to have access to your corporate network       Q11  How do you track the changes made by different users in your infrastructure provider s environments   1  No logging in place  Auditing and troubleshooting can be very difficult without a record of who made which changes when  1  Manual changelog  Users manually write down their changes to infrastructure in a shared document  This method is prone to human error  1  By logging all API calls to an audit trail service or log management service  like CloudTrail  Loggly  or Splunk   We recommend this  This ensures that an audit trail is available during troubleshooting and or security reviews       Q12  How is the access of former employees revoked   1  Immediately  manually  If you don t use infrastructure as code  the easiest and quickest way is by removing access for that employee manually using the infrastructure provider s console  1  Delayed  as part of the next release  if your release process is extremely coupled and most of your security changes have to pass through a CAB  Change Advisory Board  meeting in order to be executed in production  this could be delayed  1  Immediately  writing a hot fix in the infrastructure as code  this is the most secure and recommended option  Before the employee leaves the building  access must be removed      Assessing the Overall Maturity of Your Provisioning Practices  After reviewing all of these questions  look back at your notes and assess your organization s overall stage of maturity  are your practices mostly manual  semi automated  infrastructure as code  or collaborative infrastructure as code   Keep your current state in mind as you read the next section      Next  Now that you ve taken a hard look at your current practices  it s time to begin improving them  Continue on to  Part 3  How to Evolve Your Provisioning Practices   terraform cloud docs recommended practices part3


terraform ServiceNow Service Graph Connector for Terraform Setup Note Follow the Configure ServiceNow Service Graph Connector for HCP Terraform terraform tutorials it saas servicenow sgc tutorial for hands on instructions on how to import an AWS resource deployed in your HCP Terraform organization to the ServiceNow CMDB by using the Service Graph Connector for Terraform ServiceNow Service Graph Connector for Terraform integrates with HCP Terraform and offers two modes of import for Terraform resources page title Overview ServiceNow Service Graph Connector for Terraform Integration summary of the setup process

Answer:
---
page_title: Overview - ServiceNow Service Graph Connector for Terraform Integration - summary of the setup process
description: >-
  ServiceNow Service Graph Connector for Terraform integrates with HCP Terraform and offers two modes of import for Terraform resources.
---

# ServiceNow Service Graph Connector for Terraform – Setup

-> **Note:** Follow the [Configure ServiceNow Service Graph Connector for HCP Terraform](/terraform/tutorials/it-saas/servicenow-sgc) tutorial for hands-on instructions on how to import an AWS resource deployed in your HCP Terraform organization to the ServiceNow CMDB by using the Service Graph Connector for Terraform.

The ServiceNow Service Graph Connector for Terraform is a certified scoped application available in the ServiceNow Store. Search for ”Service Graph Connector for Terraform” published by ”HashiCorp Inc” and click **Install**.

## Prerequisites

To start using the Service Graph Connector for Terraform, you must have:

- An administrator account on a Terraform Enterprise instance or within an HCP Terraform organization.
- An administrator account on your ServiceNow vendor instance.

The Service Graph Connector for Terraform supports the following ServiceNow server versions:

- Utah
- Vancouver
- Washington DC
- Xanadu

The following ServiceNow plugins are required dependencies:

- ITOM Discovery License
- Integration Commons for CMDB
- Discovery and Service Mapping Patterns
- ServiceNow IntegrationHub Standard Pack

Additionally, you can install the IntegrationHub ETL application if you want to modify the default CMDB mappings.

-> **Note:** Dependent plugins are installed on your ServiceNow instance automatically when the app is downloaded from the ServiceNow Store. Before installing the Service Graph Connector for Terraform, you must activate the ITOM Discovery License plugin in your production instance.

## Connect ServiceNow to HCP Terraform

-> **ServiceNow roles:** `admin`, `x_hashi_service_gr.terraform_user`

Once the integration is installed, you can proceed to the guided setup form where you will enter your Terraform credentials. This step will establish a secure connection between HCP Terraform and your ServiceNow instance.

### Create and scope Terraform API token

In order for ServiceNow to connect to HCP Terraform, you must give it an HCP Terraform API token. The permissions of this token determine what resources the Service Graph Connector will import into the CMDB. While you could use a user API token, it could import resources from multiple organizations. By providing a team API token, you can scope permissions to only import resources from specified workspaces within a single organization.

Visit your organization’s **Settings** > **Teams** page. Scroll down to the **Team API Token** section and click **Create a team token**.
Save this token in a safe place since HCP Terraform only displays it once. You will use it to configure ServiceNow in the next section.

![ServiceNow Service Graph Connector Configure Team API token in HCP Terraform](/img/docs/service-now-service-graph-team-token-gen.png)

### Configure Service Graph Connector for Terraform API token

In the top navigation of your ServiceNow instance's control panel, click on **All**, search for **Service Graph Connector for Terraform**, and click **SG-Setup**. Next, click **Get Started**.

Next, in the **Configure the Terraform connection** section, click **Get Started**.

In the **Configure Terraform authentication credentials** section, click **Configure**.

If you want to route traffic between your HCP Terraform and the ServiceNow instance through a MID server acting as a proxy, change the **Applies to** dropdown to "Specific MID servers" and select your previously configured MID server name. If you don't use MID servers, leave the default value.

Set the **API Key** to the HCP Terraform team API token that you created in the previous section and click **Update**.

![ServiceNow Service Graph Connector API Key Credentials configuration screen. The API key is provided, then saved by clicking the Update button](/img/docs/service-now-service-graph-apikey.png)

In the **Configure Terraform authentication credentials** section, click **Mark as Complete**.

### Configure Terraform Webhook Notification token

To improve security, HCP Terraform includes an HMAC signature on all "generic" webhook notifications using a user-provided **token**. This token is an arbitrary secret string that HCP Terraform uses to sign each webhook notification. ServiceNow uses the same token to verify the request authenticity. Refer to [Notification Authenticity](/terraform/cloud-docs/api-docs/notification-configurations#notification-authenticity) for more information.

Create a token and save it in a safe place. This secret token can be any value but should be treated as sensitive.

In the **Configure Terraform Webhook token** section, click **Configure**. In the **Token** field, enter the secret token that will be shared between the HCP Terraform and your ServiceNow instance and click **Update**.

![ServiceNow Service Graph Connector Webhook token configuration screen. The Token is provided, then saved by clicking the Update button](/img/docs/service-now-service-graph-webhook-token.png)

In the **Configure Terraform Webhook token** section, click **Mark as Complete**.

### Configure Terraform connection

In the **Configure Terraform connection** section, click **Configure**.

If you are using Terraform Enterprise, set the **Connection URL** to the URL of your Terraform Enterprise instance. If you are using HCP Terraform, leave the **Connection URL** as the default value of `https://app.terraform.io`.

![ServiceNow Service Graph Connector HTTP Connection configuration screen. A Terraform Enterprise URL may be provided in the Connection URL field, the saved by clicking the Update button](/img/docs/service-now-service-graph-tfconn.png)

If you want to use a MID server, check **Use MID server** box, change **MID Selection** dropdown to "Specific MID sever" and select your previously configured and validated MID server.

Click **Update** to save these settings. In the **Configure Terraform connection** section, click **Mark as Complete**.

## Import Resources

Refer to the documentation explaining the difference between the [two modes of import](/terraform/cloud-docs/integrations/service-now/service-graph#import-methods) offered by the Service Graph Connector for Terraform. Both options may be enabled, or you may choose to enable only the webhook or scheduled import.

### Configure scheduled import

In the **Set up scheduled import job** section of the setup form, proceed to **Configure the scheduled jobs** and click **Configure**.

You can use the **Execute Now** option to run a single import job, which is useful for testing. The import set will be displayed in the table below the scheduled import form, after refreshing the page. Once the import is successfully triggered, click on the **Import Set** field of the record to view the logs associated with the import run, as well as its status.

Activate the job by checking the **Activate** box. Set the **Repeat Interval** and click **Update**. Note that the import processing time depends of the number of organizations and workspaces in your HCP Terraform. Setting the import job to run frequently is not recommended for big environments.

![ServiceNow Service Graph Connector scheduled import screen](/img/docs/service-now-service-graph-scheduled-import.png)

You can also access the scheduler interface by searching for **Service Graph Connector for Terraform** in the top navigation menu and selecting **SG-Import Schedule**.

### Configure Terraform Webhook

In the top navigation, click on **All**, search for **Scheduled Imports**, and click on **Scheduled Imports**.

Select the **SG-Terraform Scheduled Process State** record, then click **To edit the record click here**.

Click the **Active** checkbox to enable it. Leave the default value for the **Repeat Interval** of 5 seconds. Click **Update**.

![ServiceNow Service Graph Connector scheduled import screen showing the Active checkbox enabled](/img/docs/service-now-service-graph-webhook-schedule.png)

Next, create the webhook in HCP Terraform. Select a workspace and click **Settings > Notifications**. Click **Create a Notification**.

Keep the **Destination** as the default option of **Webhook**. Choose a descriptive name **Name**.

Set the **Webhook URL** enter `https://<SERVICENOW_HOSTNAME>/api/x_hashi_service_gr/sg_terraform_webhook` and replace `<SERVICENOW_HOSTNAME>` with the hostname of your ServiceNow instance.

In the **Token** field, enter the same string you provided in **Terraform Webhook token** section the of the Service Graph guided setup form.

Under **Health Events** choose **No events**.

Under **Run Events** choose **Only certain events** and enable notifications only on **Completed** runs. Click **Create Notification**.

![HCP Terraform notification creation screen, showing a webhook pointing to ServiceNow which is only triggered on completed runs](/img/docs/service-now-service-graph-webhook-tfc.png)

Trigger a run in your workspace. Once the run is successfully completed, a webhook notification request will be sent to your ServiceNow instance.

### Monitor the import job

By following these steps, you can track the status of import jobs in ServiceNow and verify the completion of the import process before accessing the imported resources in the CMDB.

For scheduled imports, navigate back to the **SG-Import Schedule** interface. For webhook imports, go to the **SG-Terraform Scheduled Process State** interface.

Under the form, you will find a table containing all registered import sets. Locate and select the relevant import set record.

Click on the **Import Set** field to open it and view its details. The **Outbound Http Requests** tab lists all requests made by your ServiceNow instance to HCP Terraform in order to retrieve the latest Terraform state.

Monitor the state of the import job. Wait for it to change to **Complete**, indicated by a green mark.
Once the import job is complete, you can access the imported resources in the CMDB.

![ServiceNow Service Graph Connector: import set with successfully completed status](/img/docs/service-now-service-graph-import-set.png)

You can also access all import sets, regardless of the import type, by navigating to **All** and selecting **Import Sets** under the **Advanced** category.

### View resources in ServiceNow CMDB

In the top navigation of ServiceNow, click on **All** and search for **CMDB Workspace**, and click on **CMDB Workspace**.

Perform a search by entering a Configuration Item (CI) name in the **Search** field (for example, **Virtual Machine Instance**). CI names supported by the application are listed on the [resource mapping page](/terraform/cloud-docs/integrations/service-now/service-graph/resource-coverage).

page title  Overview   ServiceNow Service Graph Connector for Terraform Integration   summary of the setup process description       ServiceNow Service Graph Connector for Terraform integrates with HCP Terraform and offers two modes of import for Terraform resources         ServiceNow Service Graph Connector for Terraform   Setup       Note    Follow the  Configure ServiceNow Service Graph Connector for HCP Terraform   terraform tutorials it saas servicenow sgc  tutorial for hands on instructions on how to import an AWS resource deployed in your HCP Terraform organization to the ServiceNow CMDB by using the Service Graph Connector for Terraform   The ServiceNow Service Graph Connector for Terraform is a certified scoped application available in the ServiceNow Store  Search for  Service Graph Connector for Terraform  published by  HashiCorp Inc  and click   Install        Prerequisites  To start using the Service Graph Connector for Terraform  you must have     An administrator account on a Terraform Enterprise instance or within an HCP Terraform organization    An administrator account on your ServiceNow vendor instance   The Service Graph Connector for Terraform supports the following ServiceNow server versions     Utah   Vancouver   Washington DC   Xanadu  The following ServiceNow plugins are required dependencies     ITOM Discovery License   Integration Commons for CMDB   Discovery and Service Mapping Patterns   ServiceNow IntegrationHub Standard Pack  Additionally  you can install the IntegrationHub ETL application if you want to modify the default CMDB mappings        Note    Dependent plugins are installed on your ServiceNow instance automatically when the app is downloaded from the ServiceNow Store  Before installing the Service Graph Connector for Terraform  you must activate the ITOM Discovery License plugin in your production instance       Connect ServiceNow to HCP Terraform       ServiceNow roles     admin    x hashi service gr terraform user   Once the integration is installed  you can proceed to the guided setup form where you will enter your Terraform credentials  This step will establish a secure connection between HCP Terraform and your ServiceNow instance       Create and scope Terraform API token  In order for ServiceNow to connect to HCP Terraform  you must give it an HCP Terraform API token  The permissions of this token determine what resources the Service Graph Connector will import into the CMDB  While you could use a user API token  it could import resources from multiple organizations  By providing a team API token  you can scope permissions to only import resources from specified workspaces within a single organization    Visit your organization s   Settings       Teams   page  Scroll down to the   Team API Token   section and click   Create a team token    Save this token in a safe place since HCP Terraform only displays it once  You will use it to configure ServiceNow in the next section     ServiceNow Service Graph Connector Configure Team API token in HCP Terraform   img docs service now service graph team token gen png       Configure Service Graph Connector for Terraform API token  In the top navigation of your ServiceNow instance s control panel  click on   All    search for   Service Graph Connector for Terraform    and click   SG Setup    Next  click   Get Started     Next  in the   Configure the Terraform connection   section  click   Get Started     In the   Configure Terraform authentication credentials   section  click   Configure      If you want to route traffic between your HCP Terraform and the ServiceNow instance through a MID server acting as a proxy  change the   Applies to   dropdown to  Specific MID servers  and select your previously configured MID server name  If you don t use MID servers  leave the default value   Set the   API Key   to the HCP Terraform team API token that you created in the previous section and click   Update       ServiceNow Service Graph Connector API Key Credentials configuration screen  The API key is provided  then saved by clicking the Update button   img docs service now service graph apikey png   In the   Configure Terraform authentication credentials   section  click   Mark as Complete         Configure Terraform Webhook Notification token  To improve security  HCP Terraform includes an HMAC signature on all  generic  webhook notifications using a user provided   token    This token is an arbitrary secret string that HCP Terraform uses to sign each webhook notification  ServiceNow uses the same token to verify the request authenticity  Refer to  Notification Authenticity   terraform cloud docs api docs notification configurations notification authenticity  for more information   Create a token and save it in a safe place  This secret token can be any value but should be treated as sensitive   In the   Configure Terraform Webhook token   section  click   Configure    In the   Token   field  enter the secret token that will be shared between the HCP Terraform and your ServiceNow instance and click   Update        ServiceNow Service Graph Connector Webhook token configuration screen  The Token is provided  then saved by clicking the Update button   img docs service now service graph webhook token png   In the   Configure Terraform Webhook token   section  click   Mark as Complete         Configure Terraform connection  In the   Configure Terraform connection   section  click   Configure     If you are using Terraform Enterprise  set the   Connection URL   to the URL of your Terraform Enterprise instance  If you are using HCP Terraform  leave the   Connection URL   as the default value of  https   app terraform io      ServiceNow Service Graph Connector HTTP Connection configuration screen  A Terraform Enterprise URL may be provided in the Connection URL field  the saved by clicking the Update button   img docs service now service graph tfconn png   If you want to use a MID server  check   Use MID server   box  change   MID Selection   dropdown to  Specific MID sever  and select your previously configured and validated MID server   Click   Update   to save these settings  In the   Configure Terraform connection   section  click   Mark as Complete        Import Resources  Refer to the documentation explaining the difference between the  two modes of import   terraform cloud docs integrations service now service graph import methods  offered by the Service Graph Connector for Terraform  Both options may be enabled  or you may choose to enable only the webhook or scheduled import       Configure scheduled import  In the   Set up scheduled import job   section of the setup form  proceed to   Configure the scheduled jobs   and click   Configure      You can use the   Execute Now   option to run a single import job  which is useful for testing  The import set will be displayed in the table below the scheduled import form  after refreshing the page  Once the import is successfully triggered  click on the   Import Set   field of the record to view the logs associated with the import run  as well as its status   Activate the job by checking the   Activate   box  Set the   Repeat Interval   and click   Update    Note that the import processing time depends of the number of organizations and workspaces in your HCP Terraform  Setting the import job to run frequently is not recommended for big environments     ServiceNow Service Graph Connector scheduled import screen   img docs service now service graph scheduled import png   You can also access the scheduler interface by searching for   Service Graph Connector for Terraform   in the top navigation menu and selecting   SG Import Schedule         Configure Terraform Webhook  In the top navigation  click on   All    search for   Scheduled Imports    and click on   Scheduled Imports      Select the   SG Terraform Scheduled Process State   record  then click   To edit the record click here     Click the   Active   checkbox to enable it  Leave the default value for the   Repeat Interval   of 5 seconds  Click   Update       ServiceNow Service Graph Connector scheduled import screen showing the Active checkbox enabled   img docs service now service graph webhook schedule png   Next  create the webhook in HCP Terraform  Select a workspace and click   Settings   Notifications    Click   Create a Notification     Keep the   Destination   as the default option of   Webhook    Choose a descriptive name   Name     Set the   Webhook URL   enter  https    SERVICENOW HOSTNAME  api x hashi service gr sg terraform webhook  and replace   SERVICENOW HOSTNAME   with the hostname of your ServiceNow instance   In the   Token   field  enter the same string you provided in   Terraform Webhook token   section the of the Service Graph guided setup form   Under   Health Events   choose   No events     Under   Run Events   choose   Only certain events   and enable notifications only on   Completed   runs  Click   Create Notification       HCP Terraform notification creation screen  showing a webhook pointing to ServiceNow which is only triggered on completed runs   img docs service now service graph webhook tfc png   Trigger a run in your workspace  Once the run is successfully completed  a webhook notification request will be sent to your ServiceNow instance       Monitor the import job  By following these steps  you can track the status of import jobs in ServiceNow and verify the completion of the import process before accessing the imported resources in the CMDB   For scheduled imports  navigate back to the   SG Import Schedule   interface  For webhook imports  go to the   SG Terraform Scheduled Process State   interface   Under the form  you will find a table containing all registered import sets  Locate and select the relevant import set record   Click on the   Import Set   field to open it and view its details  The   Outbound Http Requests   tab lists all requests made by your ServiceNow instance to HCP Terraform in order to retrieve the latest Terraform state   Monitor the state of the import job  Wait for it to change to   Complete    indicated by a green mark  Once the import job is complete  you can access the imported resources in the CMDB     ServiceNow Service Graph Connector  import set with successfully completed status   img docs service now service graph import set png   You can also access all import sets  regardless of the import type  by navigating to   All   and selecting   Import Sets   under the   Advanced   category       View resources in ServiceNow CMDB  In the top navigation of ServiceNow  click on   All   and search for   CMDB Workspace    and click on   CMDB Workspace      Perform a search by entering a Configuration Item  CI  name in the   Search   field  for example    Virtual Machine Instance     CI names supported by the application are listed on the  resource mapping page   terraform cloud docs integrations service now service graph resource coverage


terraform Google Cloud Platform This page provides details on how Google Cloud resources set up using Terraform are corresponded to the classes within the ServiceNow CMDB ServiceNow Service Graph integration allows to import selected resources from Google Cloud Platform into ServiceNow CMDB page title ServiceNow Service Graph Connector for Terraform Integration GCP Coverage

Answer:
---
page_title: ServiceNow Service Graph Connector for Terraform Integration - GCP Coverage
description: >-
  ServiceNow Service Graph integration allows to import selected resources from Google Cloud Platform into ServiceNow CMDB.
---

# Google Cloud Platform

This page provides details on how Google Cloud resources, set up using Terraform, are corresponded to the classes within the ServiceNow CMDB.

## Mapping of Terraform resources to CMDB CI Classes

| Google resource            | Terraform resource name                                               | ServiceNow CMDB CI Class        | ServiceNow CMDB Category Name |
|----------------------------|-----------------------------------------------------------------------|---------------------------------|-------------------------------|
| Project ID                 | N/A                                                                   | `cmdb_ci_cloud_service_account` | Cloud Service Account         |
| Region (location)          | N/A                                                                   | `cmdb_ci_google_datacenter`     | Google Datacenter             |
| Virtual Machine Instance   | `google_compute_instance`                                             | `cmdb_ci_vm_instance`           | Virtual Machine Instance      |
| Kubernetes Cluster         | `google_container_cluster`                                            | `cmdb_ci_kubernetes_cluster`    | Kubernetes Cluster            |
| Google Storage             | `google_storage_bucket`                                               | `cmdb_ci_cloud_storage_account` | Cloud Storage Account         |
| Google BigQuery            | `google_bigquery_table`                                               | `cmdb_ci_cloud_database`        | Cloud DataBase                |
| Google SQL                 | `google_sql_database`                                                 | `cmdb_ci_cloud_database`        | Cloud DataBase                |
| Google Compute Firewall    | `google_compute_firewall`                                             | `cmdb_ci_compute_security_group`| Compute Security Group        |
| Cloud Function             | `google_cloudfunctions_function` or `google_cloudfunctions2_function` | `cmdb_ci_cloud_function`        | Cloud Function                |
| Load Balancer              | `google_compute_forwarding_rule`                                      | `cmdb_ci_cloud_load_balancer`   | Cloud Load Balancer           |
| VPC                        | `google_compute_network`                                              | `cmdb_ci_network`               | Cloud Network                 |
| Tags                       | N/A                                                                   | `cmdb_key_value`                | Key Value                     |

## Resource relationships

| Child CI Class                                             | Relationship type      | Parent CI Class                                           |
|------------------------------------------------------------|------------------------|-----------------------------------------------------------|
| Google Datacenter 1 (`cmdb_ci_google_datacenter`)          | Hosted On::Hosts       | Cloud Service Account 4 (`cmdb_ci_cloud_service_account`) |
| Google Datacenter 2 (`cmdb_ci_google_datacenter`)          | Hosted On::Hosts       | Cloud Service Account 4 (`cmdb_ci_cloud_service_account`) |
| Virtual Machine Instance 4 (`cmdb_ci_vm_instance`)         | Hosted On::Hosts       | Google Datacenter 1 (`cmdb_ci_google_datacenter`)         |
| Virtual Machine Instance 4 (`cmdb_ci_vm_instance`)         | Reference              | Key Value 13 (`cmdb_key_value`)                           |
| Cloud Network 3 (`cmdb_ci_network`)                        | Hosted On::Hosts       | Google Datacenter 1 (`cmdb_ci_google_datacenter`)         |
| Cloud Network 3 (`cmdb_ci_network`)                        | Reference              | Key Value 18 (`cmdb_key_value`)                           |
| Compute Security Group 3 (`cmdb_ci_compute_security_group`)| Hosted On::Hosts       | Google Datacenter 1 (`cmdb_ci_google_datacenter`)         |
| Compute Security Group 3 (`cmdb_ci_compute_security_group`)| Reference              | Key Value 21 (`cmdb_key_value`)                           |
| Kubernetes Cluster 3 (`cmdb_ci_kubernetes_cluster`)        | Hosted On::Hosts       | Google Datacenter 1 (`cmdb_ci_google_datacenter`)         |
| Kubernetes Cluster 3 (`cmdb_ci_kubernetes_cluster`)        | Reference              | Key Value 22 (`cmdb_key_value`)                           |
| Cloud DataBase 3 (`cmdb_ci_cloud_database` )               | Hosted On::Hosts       | Google Datacenter 1 (`cmdb_ci_google_datacenter`)         |
| Cloud DataBase 2 (`cmdb_ci_cloud_database` )               | Reference              | Key Value 24 (`cmdb_key_value`)                           |
| Cloud Function 3 (`cmdb_ci_cloud_function`)                | Hosted On::Hosts       | Google Datacenter 1 (`cmdb_ci_google_datacenter`)         |
| Cloud Function 3 (`cmdb_ci_cloud_function`)                | Reference              | Key Value 25 (`cmdb_key_value`)                           |
| Cloud Load Balancer 2 (`cmdb_ci_cloud_load_balancer`)      | Hosted On::Hosts       | Google Datacenter 1 (`cmdb_ci_google_datacenter`)         |
| Cloud Load Balancer 2 (`cmdb_ci_cloud_load_balancer`)      | Reference              | Key Value 26 (`cmdb_key_value`)                           |
| Cloud Storage Account 2 (`cmdb_ci_cloud_storage_account`)  | Hosted On::Hosts       | Google Datacenter 2 (`cmdb_ci_google_datacenter`)         |
| Cloud Storage Account 2 (`cmdb_ci_cloud_storage_account`)  | Reference              | Key Value 23 (`cmdb_key_value`)                           |

## Field attributes mapping

### Cloud Service Account (`cmdb_ci_cloud_service_account`)

| CMDB field        | Terraform state field                                          |
|-------------------|----------------------------------------------------------------|
| Source Native Key | `project`                                                      |
| Account Id        | `project`                                                      |
| Datacenter Type   | Defaults to `google`                                           |
| Object ID         | `project`                                                      |
| Name              | `project`                                                      |
| Operational Status| Defaults to "1" ("Operational")                                |

### Google Datacenter (`cmdb_ci_google_datacenter`)

| CMDB field        | Terraform state field                                          |
|-------------------|----------------------------------------------------------------|
| Source Native Key | Concatenation of `project` and region extracted from `id`      |
| Object Id         | Region extracted from `id`                                     |
| Region            | Region extracted from `id`                                     |
| Name              | Region extracted from `id`                                     |
| Operational Status| Defaults to "1" ("Operational")                                |

### Virtual Machine Instance (`cmdb_ci_vm_instance`)

| CMDB field        | Terraform state field                                          |
|-------------------|----------------------------------------------------------------|
| Source Native Key | `id`                                                           |
| Object Id         | `id`                                                           |
| Name              | `name`                                                         |
| Category          | `machine_type`                                                 |
| Operational Status| Defaults to "1" ("Operational")                                |

### Cloud Network (`cmdb_ci_network`)

| CMDB field        | Terraform state field                                          |
|-------------------|----------------------------------------------------------------|
| Source Native Key | `id`                                                           |
| Object Id         | `id`                                                           |
| Name              | `name`                                                         |
| Operational Status| Defaults to "1" ("Operational")                                |

### Compute Security Group (`cmdb_ci_compute_security_group`)

| CMDB field        | Terraform state field                                          |
|-------------------|----------------------------------------------------------------|
| Source Native Key | `id`                                                           |
| Object Id         | `id`                                                           |
| Name              | `name`                                                         |
| Operational Status| Defaults to "1" ("Operational")                                |

### Kubernetes Cluster (`cmdb_ci_kubernetes_cluster`)

| CMDB field        | Terraform state field                                          |
|-------------------|----------------------------------------------------------------|
| Source Native Key | `arn`                                                          |
| IP Address        | `endpoint`                                                     |
| Port              | Defaults to "6443"                                             |
| Name              | `name`                                                         |
| Operational Status| Defaults to "1" ("Operational")                                |

### Cloud Object Storage (`cmdb_ci_cloud_object_storage`)

| CMDB field        | Terraform state field                                          |
|-------------------|----------------------------------------------------------------|
| Source Native Key | `arn`                                                          |
| Object Id         | `id`                                                           |
| Cloud Provider    | Resource cloud provider extracted from `arn`                   |
| Name              | `bucket`                                                       |
| Operational Status| Defaults to "1" ("Operational")                                |

### Cloud Storage Account (`cmdb_ci_cloud_storage_account`)

| CMDB field        | Terraform state field                                          |
|-------------------|----------------------------------------------------------------|
| Source Native Key | `id`                                                           |
| Object Id         | `id`                                                           |
| Name              | `name`                                                         |
| Name              | `location`                                                     |
| Operational Status| Defaults to "1" ("Operational")                                |

### Cloud DataBase (`cmdb_ci_cloud_database`)

| CMDB field        | Terraform state field                                          |
|-------------------|----------------------------------------------------------------|
| Source Native Key | `id`                                                           |
| Object Id         | `id`                                                           |
| Name              | Name extracted from `id`                                       |
| Operational Status| Defaults to "1" ("Operational")                                |

### Cloud Function (`cmdb_ci_cloud_function`)

| CMDB field        | Terraform state field                                          |
|-------------------|----------------------------------------------------------------|
| Source Native Key | `id`                                                           |
| Object Id         | `id`                                                           |
| Name              | `name`                                                         |
| Operational Status| Defaults to "1" ("Operational")                                |

### Cloud Load Balancer (`cmdb_ci_cloud_load_balancer`)

| CMDB field        | Terraform state field                                          |
|-------------------|----------------------------------------------------------------|
| Source Native Key | `id`                                                           |
| Object Id         | `id`                                                           |
| Name              | `name`                                                         |
| Operational Status| Defaults to "1" ("Operational")

page title  ServiceNow Service Graph Connector for Terraform Integration   GCP Coverage description       ServiceNow Service Graph integration allows to import selected resources from Google Cloud Platform into ServiceNow CMDB         Google Cloud Platform  This page provides details on how Google Cloud resources  set up using Terraform  are corresponded to the classes within the ServiceNow CMDB      Mapping of Terraform resources to CMDB CI Classes    Google resource              Terraform resource name                                                 ServiceNow CMDB CI Class          ServiceNow CMDB Category Name                                                                                Project ID                   N A                                                                      cmdb ci cloud service account    Cloud Service Account             Region  location             N A                                                                      cmdb ci google datacenter        Google Datacenter                 Virtual Machine Instance      google compute instance                                                 cmdb ci vm instance              Virtual Machine Instance          Kubernetes Cluster            google container cluster                                                cmdb ci kubernetes cluster       Kubernetes Cluster                Google Storage                google storage bucket                                                   cmdb ci cloud storage account    Cloud Storage Account             Google BigQuery               google bigquery table                                                   cmdb ci cloud database           Cloud DataBase                    Google SQL                    google sql database                                                     cmdb ci cloud database           Cloud DataBase                    Google Compute Firewall       google compute firewall                                                 cmdb ci compute security group   Compute Security Group            Cloud Function                google cloudfunctions function  or  google cloudfunctions2 function     cmdb ci cloud function           Cloud Function                    Load Balancer                 google compute forwarding rule                                          cmdb ci cloud load balancer      Cloud Load Balancer               VPC                           google compute network                                                  cmdb ci network                  Cloud Network                     Tags                         N A                                                                      cmdb key value                   Key Value                           Resource relationships    Child CI Class                                               Relationship type        Parent CI Class                                                                                Google Datacenter 1   cmdb ci google datacenter              Hosted On  Hosts         Cloud Service Account 4   cmdb ci cloud service account       Google Datacenter 2   cmdb ci google datacenter              Hosted On  Hosts         Cloud Service Account 4   cmdb ci cloud service account       Virtual Machine Instance 4   cmdb ci vm instance             Hosted On  Hosts         Google Datacenter 1   cmdb ci google datacenter               Virtual Machine Instance 4   cmdb ci vm instance             Reference                Key Value 13   cmdb key value                                 Cloud Network 3   cmdb ci network                            Hosted On  Hosts         Google Datacenter 1   cmdb ci google datacenter               Cloud Network 3   cmdb ci network                            Reference                Key Value 18   cmdb key value                                 Compute Security Group 3   cmdb ci compute security group    Hosted On  Hosts         Google Datacenter 1   cmdb ci google datacenter               Compute Security Group 3   cmdb ci compute security group    Reference                Key Value 21   cmdb key value                                 Kubernetes Cluster 3   cmdb ci kubernetes cluster            Hosted On  Hosts         Google Datacenter 1   cmdb ci google datacenter               Kubernetes Cluster 3   cmdb ci kubernetes cluster            Reference                Key Value 22   cmdb key value                                 Cloud DataBase 3   cmdb ci cloud database                    Hosted On  Hosts         Google Datacenter 1   cmdb ci google datacenter               Cloud DataBase 2   cmdb ci cloud database                    Reference                Key Value 24   cmdb key value                                 Cloud Function 3   cmdb ci cloud function                    Hosted On  Hosts         Google Datacenter 1   cmdb ci google datacenter               Cloud Function 3   cmdb ci cloud function                    Reference                Key Value 25   cmdb key value                                 Cloud Load Balancer 2   cmdb ci cloud load balancer          Hosted On  Hosts         Google Datacenter 1   cmdb ci google datacenter               Cloud Load Balancer 2   cmdb ci cloud load balancer          Reference                Key Value 26   cmdb key value                                 Cloud Storage Account 2   cmdb ci cloud storage account      Hosted On  Hosts         Google Datacenter 2   cmdb ci google datacenter               Cloud Storage Account 2   cmdb ci cloud storage account      Reference                Key Value 23   cmdb key value                                   Field attributes mapping      Cloud Service Account   cmdb ci cloud service account      CMDB field          Terraform state field                                                                                Source Native Key    project                                                           Account Id           project                                                           Datacenter Type     Defaults to  google                                                Object ID            project                                                           Name                 project                                                           Operational Status  Defaults to  1    Operational                                         Google Datacenter   cmdb ci google datacenter        CMDB field          Terraform state field                                                                                Source Native Key   Concatenation of  project  and region extracted from  id           Object Id           Region extracted from  id                                          Region              Region extracted from  id                                          Name                Region extracted from  id                                          Operational Status  Defaults to  1    Operational                                         Virtual Machine Instance   cmdb ci vm instance      CMDB field          Terraform state field                                                                                Source Native Key    id                                                                Object Id            id                                                                Name                 name                                                              Category             machine type                                                      Operational Status  Defaults to  1    Operational                                         Cloud Network   cmdb ci network       CMDB field          Terraform state field                                                                                Source Native Key    id                                                                Object Id            id                                                                Name                 name                                                              Operational Status  Defaults to  1    Operational                                         Compute Security Group   cmdb ci compute security group      CMDB field          Terraform state field                                                                                Source Native Key    id                                                                Object Id            id                                                                Name                 name                                                              Operational Status  Defaults to  1    Operational                                         Kubernetes Cluster   cmdb ci kubernetes cluster      CMDB field          Terraform state field                                                                                Source Native Key    arn                                                               IP Address           endpoint                                                          Port                Defaults to  6443                                                  Name                 name                                                              Operational Status  Defaults to  1    Operational                                         Cloud Object Storage   cmdb ci cloud object storage      CMDB field          Terraform state field                                                                                Source Native Key    arn                                                               Object Id            id                                                                Cloud Provider      Resource cloud provider extracted from  arn                        Name                 bucket                                                            Operational Status  Defaults to  1    Operational                                         Cloud Storage Account   cmdb ci cloud storage account       CMDB field          Terraform state field                                                                                Source Native Key    id                                                                Object Id            id                                                                Name                 name                                                              Name                 location                                                          Operational Status  Defaults to  1    Operational                                         Cloud DataBase   cmdb ci cloud database      CMDB field          Terraform state field                                                                                Source Native Key    id                                                                Object Id            id                                                                Name                Name extracted from  id                                            Operational Status  Defaults to  1    Operational                                         Cloud Function   cmdb ci cloud function      CMDB field          Terraform state field                                                                                Source Native Key    id                                                                Object Id            id                                                                Name                 name                                                              Operational Status  Defaults to  1    Operational                                         Cloud Load Balancer   cmdb ci cloud load balancer      CMDB field          Terraform state field                                                                                Source Native Key    id                                                                Object Id            id                                                                Name                 name                                                              Operational Status  Defaults to  1    Operational