Managing cloud infrastructure at scale requires complete visibility into every change.
But what happens when someone bypasses Terraform and modifies resources directly in the GCP console?

These untracked console changes, AKA ClickOps, can lead to drifts, misconfigurations, compliance violations, and security risks. Without visibility into these actions, teams are left troubleshooting unexpected issues instead of proactively managing their cloud.

Today, we’re excited to introduce ClickOps Scanner for GCP, a new capability for Google Cloud users that tracks and detects console operations across your GCP projects, ensuring that all infrastructure changes stay accounted for.

ClickOps Scanner for GCP

With ClickOps Scanner for GCP, ControlMonkey users can now:

• Monitor every change in real-time across GCP projects, whether intentional or unexpected.
• Resolve Terraform Drifts faster by quickly detecting the Cloud Event (ClickOps) that caused the configuration drift and shorten investigation and resolution times.
• Ensure compliance and security by keeping a complete audit trail of all infrastructure changes made through code or the console.
• Speed up debugging and root cause analysis. Quickly trace changes back to their source and understand the impact of every action.

Bring Total Cloud Control to your GCP Environment

Untracked console operations can create security risks and disrupt infrastructure stability.
With ClickOps Scanner for GCP, you get a complete insight into every manual change, so nothing slips through the cracks.

Ready to take control of your infrastructure?
Meet with our Terraform experts for a 30-minute technical call to learn more.

At ControlMonkey, we understand that every infrastructure deployment is unique. That’s why we built Custom Flow, a core feature of our Terraform CI/CD solution that allows you to integrate custom scripts before and after every phase of your Terraform deployment, from ‘terraform init to ‘terraform apply.’

With Custom Flow, DevOps teams can define pre- and post-execution step and automate essential tasks across their Terraform stacks.

Today, we are happy to announce that we’re taking it a step further by introducing Failure Behavior, which will give teams even more control over how deployments react to failing steps.

Custom Flow – Failure Behavior: Stop, Continue, or Ignore

Failures are inevitable when running complex infrastructure deployments.
But how your workflow responds to those failures makes all the difference.

With Failure Behavior, you can precisely define what happens when a custom script fails, ensuring a safer, more predictable deployment process.

Here’s what you can configure:

• stop: The run will stop if the custom step fails. (the default behavior)

• continue: The run will continue even if the custom step fails. However, the overall run will be considered failed when it ends.

• ignore: The run will continue even if the custom step fails. In this case, the overall run will be considered successful when it ends.

Without failure management, DevOps teams are forced to intervene manually when something goes wrong, leading to delays and uncertainty.

Failure Behavior is an additional automation layer on top of ‘Custom Flows,’ allowing ControlMonkey users to run Terraform with greater deployment confidence by defining clear failure-handling rules

Bringing Total Cloud Control with Terraform

With the addition of Failure Behavior, Custom Flow now gives you even more precision and automation in how your deployments handle unexpected scenarios.

ControlMonkey’s Terraform CI/CD solution provides all the tools to run your deployments with complete control on your terms.

Ready to take control of your infrastructure?
Meet with our Terraform experts for a 30-minute technical call to learn more.

Today, we are happy to announce the upgrade of our Stack Auto-Discovery solution, with the option to exclude specific folders or paths from the discovery process.

As a recap, ‘Stack Auto-Discovery’ detects new folders and branches in your Git repositories and automatically creates stacks in the ControlMonkey platform.

New folders or paths in the Git repository will be detected by ControlMonkey, which will automatically create the corresponding Stack rather than the user creating one manually.
Any new Terraform code will be included in the infrastructure CI/CD approval and testing process, ensuring resource alignment with organizational standards.

With the latest exclusion enhancement, ControlMonkey users gain total control over which folders or paths should be included or excluded from the ‘Stack Auto-discovery’ process.

‘Stack auto-discovery’ adds a new level of automation to your GitOps. It guarantees that all Terraform code is tested and validated before deployment, which minimizes the chances of misconfigurations and human mistakes.

Today, with the option to exclude specific folders or paths, ControlMonkey users can fully customize their stack discovery process to make their day-to-day operations even more efficient and controlled.
This feature request came from one of our customers, and we’re thrilled to bring this enhancement to life.

ControlMonkey’s Terraform Automation Platform transforms how infrastructure teams automate and govern large-scale cloud environments.
Our Terraform experts are ready for a technical discussion whenever you are.

Today, we are happy to announce the latest enhancement to our Terraform CI/CD solution – “Stack Auto-discovery.”
This capability detects new folders and branches in your Git repositories and automatically creates stacks in the ControlMonkey platform.

ControlMonkey’s Terraform CI/CD solution helps cloud engineering teams. It offers a simple way to validate, plan, and deploy infrastructure changes. All of this comes from a central source of truth. With ControlMonkey, engineers can easily apply cloud policies. This includes tagging, security, and compliance in the infrastructure CI/CD process.
By proactively standardizing their cloud environments, they can prevent misconfigurations from reaching production.

Until today, ControlMonkey users had to create Stacks manually for new folders or paths in their Git repository. This was necessary for those Stacks to be part of the infrastructure CI/CD process.

New: Automatic Detection and Creation of Terraform Stacks

Now, with “Stack Auto-discovery,” ControlMonkey will find any new folder or path in the Git repository. It will then automatically create the Stack for it.
Any new Terraform code created will automatically be incorporated into the infrastructure CI/CD approval and testing process, ensuring that all resources align with the organization’s standard.

A classic use case is when a new DevOps engineer is onboarded and tasked with creating cloud environments. They create a new branch and a new folder. They also make a PR. ControlMonkey gives them instant feedback on the following:

• Which resources are going to be created if this PR will be merged.
• Which of the organization’s Cloud Policies have passed or failed, and what is the reason behind it.

TL;DR – Terraform Stacks and ControlMonkey 

To summarize, “Stack auto-discovery” provides an additional layer of automation to your GitOps. It makes sure that all your Terraform code is tested and checked before it goes to production. This reduces the chance of mistakes and misconfigurations.
Automating the whole process makes daily tasks easier. It also boosts the overall efficiency of the Cloud Engineering team. The new capability supports Terraform, OpenTofu, and Terragrunt.

ControlMonkey’s Terraform Automation Platform dramatically changes how engineering teams standardize and deploy their cloud infrastructure.
Our Terraform experts are ready for a technical discussion whenever you are.

We are happy to announce that we have reinforced our Terraform Knowledge Hub solution, giving you full visibility into your Terraform Git repository tree.

Since its initial release, we have upgraded our Terraform Explorer Dashboard with many awesome capabilities, such as the Terraform Modules Explorer and the Terraform Providers Explorer.

We often encounter customers who manage large-scale Terraform codebases across multiple Git repositories and various version control systems (GitHub, GitLab, BitBucket, Azure DevOps). These customers struggle to track where their Terraform code resides and determine which code is managed with GitOps methodologies or has drift detection mechanisms in place.

Today, we have added a new view to our Terraform Explorer Dashboard called ‘Code Tree.’
Code Tree scans your Git repos in your version Control System and provides a birds-eye view of:

• Where ControlMonkey detected Terraform/Terragrunt/OpenTofu Code:

• Which sub-directories of code are managed by ControlMonkey Stacks and benefits from Terraform CI/CD, Security Policies, Drift Detection & Remediation and more:

• Which sub-directories are currently not managed by ControlMonkey (aka potential stacks) but can be with a 1-Click:

With Code Tree, ControlMonkey users gain a 30,000-foot view of their entire code-base and understand exactly which parts of their environment are not yet managed by ControlMonkey.

Managing Terraform stacks with ControlMonkey provides the advanced layer of Terraform Automation:

1. Infrastructure CI/CD with Control Policies to enforce security and compliance standards
2. Drift Detection and remediation capabilities to quickly resolve any code discrepancies.

If you have a large-scale Terraform Codebase and you find yourself struggle to manage it efficiently we would love to chat!

Terraform Modules  are a great way to reduce the amount of code engineers write for similar infrastructure resources and are considered an efficient way to replicate cloud services across environments.

An essential aspect of using modules is versioning, which enables cloud teams to systematically release module upgrades. This ensures the use of a more secure and compliant infrastructure by keeping the modules up-to-date.

However, controlling strictly which Module versions and sources engineers are allowed to use becomes a massive challenge at scale.
An everyday use case is if, for example, I upgrade a few of my Terraform Modules with extra security measures and want to ensure that engineers are using the latest version.

To tackle this challenge, we proudly announce the latest enhancement to our Terraform CI/CD engine, Terraform Modules – Restrict Versions control policies.

ControlMonkey users can now easily create Control Policies that allow or restrict Terraform Modules Sources or Versions as part of the Infrastructure CI/CD.

Terraform Modules – Restrict Versions consists of 3 types of policies:

Terraform Allowed Module Sources Policy

This policy enforces that all the Terraform Modules used in the code reside in a pre-approved Registry or an organization’s GitHub repo.

Terraform Restricted Module Versions Policy

This policy enforces the Terraform Modules versions that can be used in the code.
The value can be a specific version, a range of versions, or from a particular version and above.

Terraform Denied Modules Policy

This policy ensures that Terraform Modules from unauthorized sources are not used.
For instance, if there is a folder in your Git repository containing legacy modules that should not be used, you can designate these as ‘Denied.’ This provides immediate feedback to all users, preventing accidental usage

Summary

In case one of these policies is violated, ControlMonkey will warn the user who issues a PR that either their Terraform Module version is outdated, the Terraform Module path they are trying to use is restricted, or the specific Terraform Module they wish to use is restricted.

Managing and Governing Terraform Modules at scale is a massive challenge for infrastructure teams and, in some instances, poses a risk to the organization.
With ControlMonkey, you can create policies that strengthen your control over Terraform Modules and ensure they remain an efficiency driver rather than an operational burden with just a few clicks.

Are you looking for the best way to stay on top of your Terraform Modules?
Our Terraform experts can’t wait to show you around .

Today, we are pleased to announce the release of ‘Remote Plan from Local Machine,’ the latest enhancement to our Terraform CI/CD engine.

How do your cloud engineers properly test their Terraform code changes before committing to Git and getting feedback without running a PR?
There are a few challenges there:

• The Secrets and variables their code requires are unavailable on their local machine and shouldn’t be for security reasons.
• They don’t have the organization’s guardrails and policies to test their local code.

Up until now, users had to commit the code, create a PR, and then get the needed feedback from their centralized Terraform pipeline. This process, of course, slowed down the pace of development and created a lot of “waiting time” between each code update and PR inspection.

Today, we’re happy to announce our “Remote Plan from Local Machine” capability, where cloud engineers can test their Terraform Code changes locally without initiating a full PR and pushing the GIT code.

Remote Plan enables you to run your ‘Terraform plan’ locally by triggering a plan simulation remotely on ControlMonkey and getting feedback on the plan’s output.

The integration is pretty easy. All you have to do is run the ‘terraform login api.controlmonkey.io’ command:

And then you can work as you’re used to, running ‘terraform plan’ commands on your local machine:

It uses your local Terraform files but actually runs it remotely in ControlMonkey, using the shared state and your environment’s variables and secrets. Every Remote Plan triggers a Plan in ControlMonkey, so you will have the full audit also on the ControlMonkey console:

By running a remote plan, your engineers can build faster and test their changes locally before committing to them.

Are you managing Terraform at scale?
Our Experts are available for a quick call so you can learn more about the future of Terraform Automation and how it can benefit your team.

A few months ago, we released ControlMonkey ‘Approval Policies ,’ a validation mechanism that requires reviewing and approving any infrastructure change before ‘Terraform Apply’ is executed.

Today, we are pleased to announce the latest enhancement to these policies – ‘Teams Approval.’
Starting today, ControlMonkey users can require deployment reviews and approvals from specific teams, adding an additional layer of granularity.

Example: If I have a stack managing my production DBs and I want to update one of them, I can define that the DBA team must review and approve the change in the stack before ‘Terraform Apply’ is executed.

So if your organization’s infrastructure approval policy is by teams (DevOps, SRE, Security, Networking, etc.), with ControlMonkey, you can apply these guardrails automatically, straight out of the box.

Changes to production are always risky, but with ControlMonkey Approved Policies, you can add an extra layer of control and prevent costly misconfigurations before every ‘Terraform Apply’ is executed.

Are you interested in learning how ControlMonkey streamlines every infrastructure change  and helps companies like yours fully govern their cloud with Terraform?
Our team is waiting to speak with you!

ControlMonkey’s resource explorer is a simplified dashboard that is part of our Terraform Insights product. It helps DevOps teams discover and easily investigate all of their cloud resources and the corresponding Terraform code in their Git repo.

Until now, Our Resource Explorer has supported only AWS & Azure Terraform Providers, but today, we are happy to announce that it supports ALL Terraform Providers.

The Terraform Provider view serves as your Terraform knowledge base, providing your team with an easy way to locate Terraform code across your Git repositories regardless of specific team member seniority or tenure within the organization.

It provides a one-click link for each cloud resource that opens the corresponding line of code in your GIT repository.

Imagine a scenario where a new engineer joins the team and needs to modify an Azure Vnet or GCP SQL Database. They need to understand where the resource is located in the Terraform code.
What would be the best way to locate that resource in a large environment with thousands of lines of code?

Not manually, that’s for sure.

So, if you need a clear mapping between your resource infrastructure provider (Datadog, Azure, Okta, or GCP, etc) and the exact location in your Terraform code, you can do it seamlessly with ControlMonkey.

It doesn’t matter which Terraform Provider you are using, ControlMonkey provides a clear one-to-one mapping between your infrastructure resources and the Terraform code.

Don’t let your team waste time searching for needles in a haystack.

Book a 30-minute Intro Call with our experts and learn how ControlMonkey changes the Terraform Automation game.

We are pleased to announce the latest enhancement to our Terraform CI/CD solution for infrastructure – ControlPolicy Groups.

Our Terraform CI/CD solution for infrastructure enables ControlMonkey users to define proactive policies that will be enforced at the Pull Request level and prevent security, cost, and compliance misconfigurations.
Starting today, our users can group together control policies and apply them to specific environments by namespaces or stacks.

This allows for custom-made policy packages that meet your organization’s guardrails. For example, if your organization requires each resource to be tagged with specific keys and all data volumes to be encrypted, you can now group these two policies together to create your own custom compliance.
You can enforce these groups on a specific ControlMonkey namespace or stack, providing the granularity you need.

Your development environment has its own requirements, while your production environment likely requires more rigid policies to be enforced. Unlike account-level policy mechanisms (e.g., AWS SecurityHub), with ControlMonkey policies, you can mix and match the appropriate policies for the relevant infrastructure stacks

You can select the severity level for each policy, which is then translated to an enforcement level (Warning, Hard/Soft Mandatory).

ControlMonkey also makes it super easy to granularly apply a policy group to a certain namespace or stack. For example, you can group together all of your SOC2 compliance policies and enforce those policies only in production environments that are required to be SOC-compliant.

Enforce the guardrails of your cloud environment with our out-of-the-box policy manager and prevent costly misconfigurations.