Scalr
Scalr
June 1, 2021

Securing and Sharing Cloud Credentials for Terraform in Scalr

By
Ryan Fee

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"
  susbcription_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.

Whichever method is used the credential values must be made available to the user running the template, either directly, or through a key vault system (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 all your DevOps teams the cloud API access they need is fraught with management challenges and security risks. You could be exposing your cloud accounts and you have little or no visibility into who is using which cloud credential for what purpose.

You want to scale the use of Terraform but a fundamental gap in handling security parameters is inhibiting progress.

Take Terraform to the Keys

What if instead of sharing the keys across various systems that run Terraform, you could run Terraform through a single central system that automatically and securely makes the keys available to Terraform?

Or put another way, instead of taking the keys to Terraform, you take Terraform to the keys!

This is a key security benefit of using Scalr. Scalr implements a Terraform Enhanced Remote Backend that allows you to run all Terraform operations through a central system that stores state and applies access controls and deployment policies.

IaCP allows you to set up your credentials securely and automatically publish them as sensitive (hidden value) environment variables to selected workspaces.

Azure Credentials Configuration in Scalr
Credentials exported to workspace as environment variables

This enables templates running from any source (VCS integration, CLI, Template registry) to 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 don’t need to worry about having access to keys or coding access to key vaults, and as an administrator you can be sure the right keys are being used in the right places.

You will even be able to include Open Policy Agent policies in 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.

Using Scalr credentials combined with environment variables you can greatly simplify the management and publication of access keys, allowing your devops teams to fully utilize the power of Terraform without the added complexity or concern of 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

Securely storing cloud credentials in Scalr overcomes the many challenges of making cloud API access keys available to large numbers of Terraform developers. Access keys are held in a single place and controlled and managed by administrators. Key rotation becomes easy and control of key distribution and usage can be handled through access controls and policy built in to Scalr.

Start using the Terraform platform of the future.

A screenshot of the modules page in the Scalr Platform