dragondrop docs
dragondrop.cloud
  • Welcome
  • Getting Started
    • How dragondrop Works
    • 🔒Security
    • Self-Hosted Runners
    • Cloud Perch - Cloud Footprint Visualizations
    • Jobs
      • What is a Job?
      • How Many Jobs Should We Use?
      • Creating a Job
      • Running a Job
      • Managed Drift Only Mode
      • Job Output
    • Setting Up CI/CD
    • Supported Tech Stack
    • Signing Up
    • Schedule a Demo
  • Deploying To Your Cloud
    • Infrastructure Requirements
      • Requirements
      • AWS
      • Azure
      • GCP
    • Environment Variables
    • Updating HTTPS Job Endpoints
    • FAQs
  • Setting Up CI/CD
    • GitHub Action
  • Pricing & Plans
    • Plans
    • FAQs
  • Trouble Shooting
    • Resource Coverage
      • AWS
      • Azure
      • GCP
    • Contact Support
Powered by GitBook
On this page
  • Structure of Usage
  • Steps in Job Execution
Edit on GitHub
  1. Getting Started

How dragondrop Works

Scan, recommend, import, and repeat.

PreviousWelcomeNextSecurity

Last updated 1 year ago

Structure of Usage

The core of dragondrop usage is a . A Job references a single, uniquely configured, instance of the cloud-concierge container hosted within your public cloud environment.

Jobs are triggered either on a user-specified, dragondrop-managed Chron Schedule, or triggered manually through the dragondrop web application. Each time a Job runs, it will search for resources in your cloud environment that are outside of Terraform control, and if any are present, will open a Pull Request in your Version Control System with the code needed to import those resources into Terraform Control.

Steps in Job Execution

1) cloud-concierge hosted in your cloud clones a Version Control repository of your choice, creates a representation of your designated cloud environment subset in Terraform, and pulls down the current state of Terraform by downloading remote state files. All data is stored ephemerally in a volume attached to the cloud-concierge container instance.

2) Identify drift within resources managed by Terraform and new resources outside of Terraform control to codify.

3) Identify the IAM accounts that made these changes to your cloud environment outside of your Terraform workflow.

4) Run cost estimation and static security analysis over the Terraform files representing the current cloud environment state.

5) Aggregrate results from previous steps and output via a Pull Request.

These steps exactly match a developer's workflow when using in isolation:

cloud-concierge
Job