Manage an existing PingOne DaVinci environment

The following guide walks you through the process of using the Ping CLI Terraformer plugin to:

Export and generate Terraform HCL configuration from an existing PingOne DaVinci environment.
Review and apply generated configuration.
Begin establishing a continuous configuration management workflow using version control.

Prerequisites

Before you begin, ensure you have:

An existing PingOne environment with the DaVinci service enabled and configuration applied.
A worker application with at least the DaVinci Admin Read Only role to read the live configuration.
The pingcli-terraformer command-line tool installed. Refer to the Ping CLI Terraformer plugin repository for installation instructions.
Terraform 1.5 or later installed.
Git for version control (optional, but recommended).

You will need a higher role, such as DaVinci Admin or a custom role with write access to the flow export endpoint, on the worker application to generate DaVinci Variable dependencies within DaVinci Flows. If the pingcli-terraformer tool can’t access the endpoint, a warning will be returned and generation of the dependency will be skipped.

Set up authentication

Configure your worker application credentials for use by the pingcli-terraformer tool:

export PINGCLI_PINGONE_ENVIRONMENT_ID="<your-environment-id>"
export PINGCLI_PINGONE_CLIENT_CREDENTIALS_CLIENT_ID="<your-client-id>"
export PINGCLI_PINGONE_CLIENT_CREDENTIALS_CLIENT_SECRET="<your-client-secret>"
export PINGCLI_PINGONE_REGION_CODE="NA"  # or EU, AP, CA, AU

Export Terraform configuration

Use the export command to generate Terraform HCL from your live environment. The export:

Reads all Terraform-supported resources in the live environment.
Converts API responses to a reusable Terraform module.
Abstracts environment-specific values to variables.
Maps dependencies between resources for deployment ordering.

For managing an existing environment, run the export with the --include-imports and --include-values flags:

pingcli-terraformer export \
  --include-imports \
  --include-values

Command flags

Flag Description --include-imports

Flag	Description	`--include-imports`
Generates import blocks for each identified resource, enabling you to bring existing infrastructure under Terraform management	`--include-values`	Produces a `terraform.tfvars` file populated with actual values from the live environment

Generates import blocks for each identified resource, enabling you to bring existing infrastructure under Terraform management

--include-values

Produces a terraform.tfvars file populated with actual values from the live environment

The export creates a version-control-ready module that can be used standalone or composed into a larger root module.

Review and apply generated configuration

Next, you will review the generated configuration to prepare for what will occur in a subsequent apply.

Configure provider

The export generates a versions.tf file that specifies the expected PingOne Terraform provider version. You can add provider authentication directly to this file or supply credentials through environment variables. You can find details in the Provider Authentication documentation.

Run terraform init to initialize the provider and download dependencies:

terraform init

Update secret values

PingOne DaVinci has secret attributes (such as client application secrets) that are not readable using APIs. You must update these manually before importing:

Open the generated ping-export-terraform.auto.tfvars file.
Locate and update all fields marked as # Secret value - provide manually.

All of the variable values in the ping-export-terraform.auto.tfvars could be considered sensitive or environment specific. This file should not be committed to version control. For automated Terraform deployments, the values to these secrets should be managed through the deployment tool or secrets manager.

Generate a plan

Output the plan to a file for review:

terraform plan -no-color > tfplan-1.txt 2>&1

What to expect in the plan

The size of your Terraform plan will correspond to the size of your live infrastructure. The initial terraform plan and terraform apply process can produce the described actions.

Resources to be imported

The majority of the resources will show as items that will be brought under Terraform management without any interaction with the live infrastructure. This indicates that the defined HCL for the resource matches what would be stored in state exactly. For example, module.ping-export.pingone_davinci_variable.pingcli__myVar_flowInstance will be imported.

The generated ping-export-imports.tf file includes an import block and a commented-out terraform import command for each discovered resource. The import commands can be run in a terminal prior to terraform apply to minimize the size of the Terraform plan and focus on items that can indicate live infrastructure interactions. For an environment with around 100 resources, this sequential import process takes approximately 5 minutes.

Configuration updates

Resources that show will be updated in-place typically indicate that there will be an API call made to the live infrastructure. Some updates might be considered non-functional changes, even though there’s an API call made to the live infrastructure. There could be cases where functional and non-functional changes are identified on the same resource, so you should carefully review all planned changes before moving forward.

Common planned changes include:

Default values: The Terraform provider includes default values for certain attributes to maintain consistency in continuous management. For example, the DaVinci Flow resource schema expects a default_log_level of 4, so this value is injected in the generated HCL, even if it’s not found on the API read. This change will run an API PUT to update the flow to bring the live infrastructure into alignment with the defined configuration.
Deploy triggers: If there is an update to a flow, the current version and published version will be out of sync, so the generated configuration will also look to deploy the flow for realignment.
Computed values: Changes marked with ~ and ending in (known after apply) represent computed attributes updating to their refreshed state. These are non-functional. A resource whose plan shows only computed updates will not appear as an item to change.
Resources with secret values: The PingOne API doesn’t allow reading values of attributes that are considered secrets. For these values, the Terraform provider only looks for mismatches between what is stored in state and what is defined in configuration, rather than refreshing state against live infrastructure. If a terraform import command was run prior to this step, an obfuscated value will show in Terraform state. The identified change directs the Terraform provider to run an API PUT to bring the resource into alignment. This is a common case for Connector Instances that include client secrets as values. The properties attribute of a Connector Instance is considered sensitive, and child values are grouped together. You must be careful to ensure that your defined configuration on such resources is exact before running terraform apply.

The following is an example of a terraform plan output after running terraform import commands:

# module.davinci.pingone_davinci_flow.my_flow will be updated in-place
  ~ resource "pingone_davinci_flow" "pingcli__OOTB-0020---0020-Account-0020-Recovery-0020-by-0020-Email" {
    ...
      ~ current_version   = 1 -> (known after apply)
      ~ settings          = {
          + log_level = 4
        }
        # (4 unchanged attributes hidden)
    }

  # module.ping-export.pingone_davinci_flow_enable.pingcli__OOTB-0020---0020-Account-0020-Recovery-0020-by-0020-Email will be updated in-place
  ~ resource "pingone_davinci_flow_enable" "pingcli__OOTB-0020---0020-Account-0020-Recovery-0020-by-0020-Email" {
      ~ enabled        = true -> (known after apply)
        id             = "01af583c6b951086992eb3c37aed7af5"
        # (2 unchanged attributes hidden)
    }

Apply the configuration

After you’re satisfied with the plan:

terraform apply

After approving the plan, your PingOne DaVinci environment is fully managed by Terraform.

Establish continuous development

With your existing environment under Terraform management, you can adopt a continuous configuration management workflow.

Development lifecycle

The typical development lifecycle:

Build features or changes in the PingOne UI.
Export those changes using pingcli-terraformer export.
View changes with your IDE or using git diff --unified=0.
Validate in Terraform. terraform plan should refresh state against the live environment and result in no changes required.
Commit to version control so changes can be picked up by automated pipelines.
Promote to higher environments through your CI/CD pipeline.

Initialize version control

If you haven’t already, initialize a Git repository:

git init

Create a .gitignore to exclude sensitive and generated files:

# Terraform
.terraform/
.terraform.lock.hcl
*.tfstate
*.tfstate.*
tfplan*

# Sensitive or environment-specific
.env
.env.*
*.tfvars
*imports.tf

Commit your configuration

git add .
git commit -m "Initial Terraform configuration for DaVinci environment"

Next steps

Set up a CI/CD pipeline to automate terraform apply for higher environments
Establish branching strategies for development, staging, and production
Document your team’s workflow and approval processes
Consider using Terraform workspaces or separate state files per environment

Troubleshooting

Import failures

Verify that your Terraform provider worker application has the correct DaVinci Admin role
Check that the resource IDs in the generated imports file are correct
Ensure Terraform 1.5 or later is installed

Secret value errors

Confirm that all fields marked # Secret value - provide manually in the generated terraform.tfvars file have been updated
Verify that secret values are correctly formatted (no extra spaces or newlines)

Plan shows unexpected changes

Review the diff carefully: some resources might receive default values on first apply
Check whether API responses have changed since the export was generated
Re-run the export if the environment was modified during the import process

Configuration Automation - Terraform