Rails encrypted credentials on 6.2

Facebook
Twitter
LinkedIn

Any rails program would have secrets to be stored, for at least the secret key base with tokens for third-party APIs.  Post  version updates, handling secrets has become easier.

Initially, there were two methods to handle secrets. 

  • The first method stored secrets in the environment variable (secret_key_base) and committed the secrets.yml file to the repository.  This had many safety constraints in place. 
  • The alternate method saved secrets in the secrets.yml file and avoided committing it to the repository.

In the 5.1 version, encrypted secrets were introduced, and were handled by the secrets.yml.enc file along with the encryption key control. The encryption key enabled us to commit the secrets to the repository safely. 

With rails 5.2, the plain text credentials became obsolete. Since then, only encrypted credentials were in place and the same were stored and accessed by two files: credential.yml.enc and master.key .

Credentials were stored in config/credentials.yml.enc and the key was stored on config/master.key. This feature enabled deploying code and credentials together and also storing all credentials in one place.

Scale performance. Not price. Try Engine Yard today and enjoy our great support and huge scaling potential for 14 days.
Deploy your app for free with Engine Yard.

Handling multi-environment credentials before rails 6

Before rails 6, credentials and configurations corresponding to all environments were saved in a one-way file, with the environment as a major key and multi-environment credentials were handled by specifying explicitly.

 Development:

 aws: 

access_key_id: 123

 secret_access_key: 345 

and the configuration was accessed by mentioning the access_key_id.

Handling multi-environment credentials in rails 6

The Rails 6 version has taken further steps to improve the scalability of the rails framework by including multi-environment credentials.  Instead of keeping one credential file to handle the secrets for all environments, separate credential files for each environment and point of deliveries are created. Though this necessitates separate encryption keys per environment, this feature brings more safety and clarity. The in-built feature of multi-environment credentials also facilitates one-way-time uploading of the encryption/decryption key to the server.

You might also like:   Evolution of Encrypted Credentials in Rails 6.2

With this update, a global credential file is enough for multiple environments. And when the environment is passed, two files were created – 

config/credentials/#{environment}.yml.enc and 

config/credentials/#{env}.key. 

Let us consider an example.  The below command 

rails credentials:edit –environment prod 

would create the credential files for the production environment as 

config/credential/prod.yml.enc and 

config/credentials/prod.key 

and if the environment file is missing or not created, the default file credentials.yml.enc file will be used. 

Also, the config/credential/prod.yml.enc file would be committed to the repository, and the config/credential/prod.key file would not be committed.

Credentials in rails

Rails understands the credential files to be used in a specific environment. If the environment-specific credentials are defined, this will be considered over the global credentials.

As for the above example, 

rails.application.credentials.config {:aws=>{:access_key_id=>’123′, :secret_access_key=>’345′} }} rails.application.credentials.aws[:access_key_id]=> ‘123’

Added features in rails 6

Rails 6 also added a feature to explicitly specify the location where the credential file is stored. Committing to a known path in the repository would make handling these files easier. To save the files in a specific path of your choice, config.credentials.content_path and config.credentials.key_path are used.  While using this, one must make sure to upload the valid key as well as credentials to avoid errors/interruptions. If the respective key is not available on the path, the encrypted credentials would remain as a bunch of meaningless characters.

To handle local environment credentials, config/credentials/environment.key and simple config/master.key are to be used.  The scenario varies in the production environment.  For such a scenario, the rails_master_key can be used and the encryption keys from the .key file are stored here. 

You might also like:   The Ruby Unbundled Series: Services vs. Objects - The Battle for Decomposition and Reuse

The below command tells rails to search the credentials file in path config/credentials/local.yml.enc instead of config/credentials/development.yml.enc

 config.credentials.content_path = ‘config/credentials/local.yml.enc’ 

Conclusion

The Rails family puts constant effort into improving the efficiency and scalability of the framework.  With the multi-environment credentials enabled, applications used in multiple platforms and pods find it easier to keep the codes simple and accessible.

You can use Engine Yard to connect to your database enabling the Rails credentials for improved security.  Click hereto learn how to proceed.

Want more posts like this?

What you should do now:

Facebook
Twitter
LinkedIn

Easy Application Deployment to AWS

Focus on development, not on managing infrastructure

Deploying, running and managing your Ruby on Rails app is taking away precious resources? Engine Yard takes the operational overhead out of the equation, so you can keep innovating.

  • Fully-managed Ruby DevOps
  • Easy to use, Git Push deployment
  • Auto scaling, boost performance
  • Private, fully-configured Kubernetes cluster
  • Linear pricing that scales, no surprises
  • Decades of Ruby and AWS experience

14 day trial. No credit card required.

Sign Up for Engine Yard

14 day trial. No credit card required.

Book a Demo