Securing and Sharing Cloud Credentials for Terraform in Scalr IaCP

Peter Gale
Peter Gale Senior Consultant, Solution Architecture June 8, 2020

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 ID’s.

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

Azure RM

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

ARM

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 organisations, 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 Infrastructure as Code Platform (IaCP). IaCP 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

Azure credentials configuration in IaCP

Credentials

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

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

Code

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 utilise the power of Terraform without the added complexity or concern of handling security parameters.

Note: Scalrs 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 IaCP 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 IaCP.

Give it a try

Learn more here