Securing and Sharing Cloud Credentials for Terraform in Scalr

Terraform providers require various parameters to enable them to connect to the cloud API. These vary from simple username and password combinations to complex access keys, subscriptions, and other IDs.

These parameters can be passed directly to the provider through Terraform variables like this azurerm example.

provider "azurerm" {
  version                     = "1.44.0"
  subscription_id             = var.subscription_id
  client_id                   = var.client_id
  client_certificate_path     = var.client_certificate_path
  client_certificate_password = var.client_certificate_password
  tenant_id                   = var.tenant_id
}

Or they can be provided through environment variables that are set in the workspace where Terraform is being run.

Either way, the credential values have to reach the user running the template. That happens directly, or through a key vault system, which means extra coding.

Credential Management Challenges

Even in small organizations, with more than one person working with Terraform, the handling of cloud API credentials presents security risks.

• Sharing the keys creates security and access management challenges
• Keys could be accidentally disclosed/published in a git repo
• Key rotation becomes a complex management problem
• Using key vaults is common practice but if your organization does not use one then how do you safely and securely manage the keys?

Inhibited by Security

Giving every DevOps team the cloud API access they need is hard to manage and easy to get wrong. You may be exposing cloud accounts, and you have little visibility into who is using which credential for what.

You want more teams using Terraform, but the way you hand out security parameters keeps getting in the way.

Take Terraform to the Keys

Instead of copying the keys out to every system that runs Terraform, you can run Terraform through one central system that hands the keys to it automatically. Put another way, you take Terraform to the keys instead of taking the keys to Terraform.

That is one of the security reasons to use Scalr. Scalr implements a Terraform Enhanced Remote Backend, so every Terraform operation runs through a central system that stores state and applies access controls and deployment policies.

There you set up your credentials once. Scalr publishes them as sensitive (hidden value) environment variables to the workspaces you choose.

Azure Credentials Configuration in Scalr

Credentials exported to workspace as environment variables

Templates running from any source (VCS integration, CLI, Template registry) then consume the access keys invisibly.

provider "azurerm" {
  version = "=1.44.0"
}

You can configure multiple sets of credentials for different use cases, e.g. production, development, etc.

DevOps engineers no longer have to hold keys or write code to reach a key vault, and as an administrator you can be sure the right keys are used in the right places.

You can also add Open Policy Agent policies to your deployment pipelines to check that credentials are being used correctly.

package terraform
import input.tfplan as tfplan
import input.tfrun as tfrun
 
deny[reason] {
  r = tfplan.resource_changes[_]
  r.change.actions[_] == "delete"
  tfrun.credentials.aws == "asde2342fef"
  reason := sprintf("Delete denied on %q account", [tfrun.credentials.aws])
}

Cloud credentials are stored with encryption in Scalr's secure internal database and can only be set up and managed by authorised administrators.

Scalr credentials and environment variables together make access keys much easier to manage and publish. Your DevOps teams get on with Terraform and stop worrying about handling security parameters.

Note: Scalr's future implementation of sensitive environment variables will enable it to be a general secrets management system for all aspects of cloud deployments, including kubernetes cluster credentials, simple SSH keys and more.

Conclusion

Storing cloud credentials in Scalr solves the problem of getting cloud API access keys to large numbers of Terraform developers. The keys live in one place, where administrators control and manage them. Rotation gets easy, and the access controls and policies built into Scalr handle how keys are distributed and used.