How to prevent hard-coding cloud credentials in IaC configuration scripts

PUBLISHED
August 9, 2023
READ TIME
10 min

Due to some recent news in the cybersecurity world, a lot of us at the Quali team have been talking about how our users can limit the risk of exposing cloud account credentials within configuration scripts. 

To be clear, this is a common threat for any teams that handle infrastructure. Infrastructure as Code (IaC) is fundamental to modern developer and DevOps workflows. The fact is that software developers and architects will require frequent access to cloud accounts and other sensitive parameters like encryption keys and certificates. Hard coding credentials and other secrets into configuration scripts can sometimes be a short term fix, though it creates vulnerabilities inherently.  

And scripts are only as valuable as they are repeatable, so it may come as no surprise that they’d be shared on an unprotected folder or share accessible to anyone who accesses the company network—including bad actors if they are able to breach into your network.  

Here are a few steps that our users can take to avoid this. 

1. Ingest all scripts into a control plane 

The first step is to establish control over all your team’s IaC scripts. 

First, you simply connect your asset repositories (GitHub, GitLab, or Bitbucket) to your Torque account and import the select the scripts you need into a repeatable and sharable blueprint for that environment. 

With governance centralized at the blueprint level, all secrets—including account credentials, certificates, and keys—are stored centrally, encrypted, and protected by Torque’s secrets management tools. Role-based access controls mean your admins can prevent unauthorized access or modifications to any of these secrets. 

Now you no longer need to connect cloud accounts to new environments individually, nor do you need to copy/paste your infrastructure scripts the next time someone needs them. You can just deploy the complete environment with secrets embedded and invisible.  

2. Create self-service access to deploy environments based on role-based access controls 

With your repeatable blueprint, you can now grant self-service access for your developers, testers, and other end users to deploy fully configured environments on demand. 

You can also integrate your CI/CD tool so these environments launch automatically within the pipeline, then shutdown when that stage is complete. 

Permissions dictate who can alter configurations and who can just deploy the environments. 

This means your teams can deploy the environments they need without waiting on a DevOps expert to fulfill each request, and no longer need to hard-code secrets into the infrastructure configurations and tools that they use. 

Of course, cybersecurity involves a lot of complex layers. But any step you can take to reduce the risk that human error leads to a security incident is a helpful one. Torque provides the tools needed to help mitigate risk with integrated secrets management o securely provision environments for the users that need them.  

Get started with a trial account of Torque today.