Provider Credentials

Note

Scalr provider credentials will be replaced by provider configurations in the future, the date is TBD and ample notice will be given before the deprecation happens. Provider configurations are currently supported in the Scalr API and Terraform provider, UI support will be released soon. See more info on Provider Configurations.

The Scalr provider credential feature is an easy and secure (encrypted using AES 256) way to automatically pass provider credentials to your workspaces from a centrally managed location. Like most objects in Scalr, credentials are managed at the account scope and then assigned to environments. You can add as many credentials per provider as you want and the credentials need to be assigned to an environment where all workspaces within that environment will inherit the credentials. Credentials can be shared across one or more environments, but only one credential per provider type can be used in each environment. Users at the workspace level will see that credentials exist, but cannot view them. When a Terraform run is executed within a workspace the provider credential will automatically be passed to the run as a shell variable.

If you are using a provider in which Scalr does not have a provider credential option for, you can use the shell variable option to achieve similar functionality.

Configuring Credentials

Configuring provider credentials in Scalr is a three step process:

  1. Create the provider credentials at the account scope by clicking on manage account:

_images/manage_account_creds.png

  1. Click on the Scalr icon on the top left and select provider credentials:

_images/cloud_creds.png

  1. Lastly, link the provider credentials to the required environments by clicking on the environments and then the provider credentials tab:

_images/link_creds.png

Environments can be linked to multiple providers, but there can only one set of credentials per provider type per environment. Scalr currently supports credentials for the following providers. Click the links for guidance on configuring access in these clouds.

Credentials for other providers can be added manually to workspaces by adding shell variables via the variables tab.

Using Provider Credentials

You will see the credentials automatically shared with workspaces once they have been linked to the environment that the workspace is in:

_images/ws_provider_vars.png

The credential parameters can now be omitted from the Terraform configuration as seen in this AWS example:

provider "aws" {
  region     = var.region
}

Other Methods

Scalr ensures that your credentials are safe, but we understand that everyone has different security standards. In the event that you cannot store credentials on scalr.io, you have a few other options for credential management. Because credentials are passed as shell variables to the Terraform run, you have flexibility in how they are created and passed. Here are a few other options:

  • If you are using Self Hosted Agent Pools, you have the ability to store the credentials on the agent rather than in scalr.io. Scalr.io will never need network access to the agent, the Self Hosted Agent Pools always pull from scalr.io giving you full control over your security. You have the ability to set the credentials as OS level variables on the agent and the run will pick the variables up as it executes. We do not recommend hardcoding the credentials, but rather use existing scripts or integrations that pull the credentials in real time.

  • Another option with the Self Hosted Agents is to use the credentials of the instance profile linked to the server running the agent. For example, the Scalr agent will pick up the credentials of the instance profile assigned to an ec2 (or any cloud) instance that the agent is running on. See more information on authentication here. By doing this, neither scalr.io or the agent are actually holding the keys.

  • Lastly, it is possible to use the Custom Hooks feature to pull credentials from an external source right before the run executes. In this scenario, you might call an external vault to dynamically generate or checkin/out credentials and set them in the run as part of the pre-plan hook and then revoke the credentials as part of the post-apply hook.