🔒
Security
Defensive practices for trust and security at every step.
When dealing with information about your cloud posture, as well as Terraform State files, security needs to be at the forefront. That is why dragondrop has engineered security and trust into every step of ensuring that your cloud is represented fully, and accurately, as code.
The dragondrop.cloud workflow is engineered for security and trust at every step
- dragondrop is a container that is self-hosted by all customers within their cloud.
- No information about your cloud posture or Terraform state ever touches our servers.
- After container execution, all visualizations and identified new resources are exposed through a pull request within your existing VCS.
When generating service principals for dragondrop to be able to complete the requisite cloud scanning, only read-only permissions should be granted.
The dragondrop container will never directly make changes to your Terraform code base. It will only open a Pull Request in your VCS containing recommended changes and import migration statements.
- Like all other code, your developers have final sign-off and approval into whether or not to merge the suggestions.
- Comments, discussions and changes to the original dragondrop suggestions are all recorded within your VCS.
No more running migrations through the CLI. With dragondrop, all Terraform import migration statements are saved as code within your code base, adding documentation and visibility to state file changes alongside your Terraform code.
- In order for the
planto succeed (and as a result, the merging in of dragondrop's suggested changes), no changes outside of Terraform migrations can be set to occur, and specified migrations must be valid. - In order for the
applyto succeed, no changes outside of Terraform migrations can be set to occur, and specified migrations must be valid.
Last modified 2mo ago