I am following this guide to get model attachments stored in S3. I am curious as to why the AWS key and secret and bucket name need to be stored in config/environments/production.rb AS WELL AS set using
heroku config:set AWS_ACCESS_KEY_ID=your_access_key_id
I thought it would be one or the other. For obvious reasons, I would rather not store the key and secret in a file in a repo.
I misread the steps. I now see that the production and development file are not supposed to contain the API Key and Secret. Just reference the environment variable.
Related
Until now I was handling my app secrets the usual way :
In development: my secrets are stored unencrypted in my secrets.yml file. The secrets.yml file is not commited to Github and
stays on my computer.
As per AWS reccomendations I have roles that allow me to have development specific keys. This allows to restrain my development keys to certain functions that have a different scope than production keys.
In production: My keys are stored on Heroku and called like ENV["AWS_SES_KEY"] inconfig/environments/production.rb.
I quite liked it because in case my computer is stolen, the development keys which then become corrupt can be erased at AWS without having to touch the production keys. And because the development keys can be limited to a certain scope of actions at AWS, it prevents any dangerous alterations (full bucket erasing ...)
Now we have credentials, if I am not mistaken, all keys (development and production) are inside the same encrypted file. The master key is the only environment key that is now seeded to Heroku. Though I still need this key locally to access the credentials. Then if my computer is stolen both development and production keys are corrupt and can generate a higher risk for my production app.
Is there something I am missing on the new credentials feature ? any way to avoid the above issue ?
What would be great is still using secrets.yml for dev keys and credentials.yml.enc for production keys, is it how it is intended ?
As the release notes for Rails 5.2.0 states, the future intent is to replace secrets.yml and secrets.yml.enc with credentials.yml.enc:
This will eventually replace Rails.application.secrets and the encrypted secrets introduced in Rails 5.1.
There's a very clear sense that credentials.yml.enc is meant to contain production credentials only because the Rails recommendation is to not have environment specific keys in it; i.e.,
# don't do this
development:
# ...
production:
# ...
As for the config/master.key "corruption" risk, I'm not sure how to answer that. The master key is only required when running in production mode. You can also store the master key in the RAILS_MASTER_KEY environment variable. In development, you'd only need the master key if you wanted to edit credentials.yml.enc.
Im using asset_sync gem to upload assets to Amazon S3 bucket. I used dotenv to store my keys and secret keys and deployed using capistrano to Amazon EC2. Everything was fine.
But when I moved the keys to .bash_profile on my server and added an initializer, asset upload failed with this error.
rake aborted!
Fog directory can't be blank, Aws access key can't be blank, Aws secret access key can't be blank
Please help me to figure out why the keys/secrets are not found.
Basically means you've not set the ENV vars for your shell session. I guarantee if you run rake assets:precompile FOG_DIRECTORY=[your_dir] AWS_ACCESS_KEY_ID=[your_access_key] AWS_SECRET_ACCESS_KEY=[secret_access] you'll be able to perform the operation
The best recommendation I can give right now is to look in the
/etc/environment file on your VM. If you have this file, you'll be
able to set the system-wide variables which will get used each time
you load your app
The problem is an issue between the assigning of ENVIRONMENT & SHELL variables - SHELL vars are only available in a specific shell session, whilst ENVIRONMENT vars are available throughout the system
I have not found how to declare shell-specific variables on the fly yet, by putting all the env vars inside /etc/environment it works for us
Just pushed my first app to Heroku using Git and straight away got an Interanl Server Error.
You must set config.secret_key_base in your app's config.
This is because on my .gitignore file the following file is included:
config/initializers/secret_token.rb
I am using a standard template for my .gitignore file found here: https://github.com/github/gitignore/blob/master/Rails.gitignore
My Question: Should I set this key via Heroku directly for added security and if so how?
OR
should I just remove this line from my .gitignore file?
In addition to setting the secret token as an ENV variable on Heroku, as outlined by Nick Ginanto, you also need the following to make this work.
Remove the config/initializers/secret_token.rb from .gitignore
Change the line in this file to:
MyApp::Application.config.secret_token = ENV['SECRET_TOKEN']
This will then pick up the secret token you have set with Heroku's config vars.
In order for the token to be picked up in your local environment you will need to add it. There are a number of options here but the one closest to Heroku is to use the foreman gem along with a .env file in your project root. The .env will need to have the secret_token
SECRET_TOKEN=NKUd7gisd7fueAISDfg....
You can use the rake secret command to generate tokens. Make sure your .env file is added to .gitignore.
With all this in place you will have different tokens for Heroku and local and your token will not be in your source control.
Set it as a Heroku environment variable, & provide a fallback for development
Remove the hardcoded secret, check the secret initialiser into version control, set an environment variable on Heroku, and provide a fallback for development and stage.
1. Remove the hardcoded secret, and optionally provide a fallback:
Edit your config/initializers/secure_random.rb to remove the hardcoded secret for production. Optionally include a fallback for non-production environments if you'd rather not change the way you start your server.
secret = Rails.env.production? ? ENV['SECRET_TOKEN'] : "top_secret_token"
YourApp::Application.config.secret_key_base = secret
2. Check config/initializers/secure_random.rb into git
Edit .gitignore and remove the line:
config/initializers/secret_token.rb
Now commit the file.
3. Set the secret key for Heroku
Run:
rake secret
to generate a random alphanumeric string. I like to make doubly sure by mixing the key up a little by hand as well, just in case a future weakness is discovered in the key generation algorithm, as happened for Debian not so long ago. Probably this is unnecessary.
Next run:
heroku config:set SECRET_TOKEN=paste_random_string_here
to set the secret as a Heroku environment variable. Deploy to Heroku and you're done.
Its best to use an ENV variable for this..
This way you can invalidate all the cookies quickly if needed, have a separate secret per environment and no need to deal with the file in a special way
heroku config:set SECRET_TOKEN=ertbs45tnsb3aw5bsxdrt54...
if you duplicated the app or have another app setup in heroku, each app will have its own secret_token.
on your localmachine just setup the same variable
How do I securely store my p12 file in rails? My production web app will be in Heroku. The file is used to sign some documents dynamically.
Storing the p12 contents in an environment variable should be sufficiently secure on Heroku. This way it's at least not available in your code base or through your database.
You can setup Heroku environment variables like this:
heroku config:add P12_CONTENTS="$(cat /path/to/file.p12)"
I have a number of Rails apps hosted on GitHub. They are all currently private, and I often will deploy them from their GitHub repository. I'd like to be able to make some of them open source, just like the ones you can find on http://opensourcerails.com.
My question is: How can I make these repositories public without giving away super secret credentials?
For example, I can look in /config/initializers/cookie_verification_secret.rb and see the cookie secret for nearly every one of them. I don't understand how this is acceptable. Are these users all changing these values in their deploy environments somehow?
Some users even expose their AWS secret and key! Others will instead set their AWS secret to something like:
ENV['aws-secret']
although I'm not sure at what point they're setting that value.
So, what are the best practices for open sourcing your Rails app without compromising your app's security.
I recently went through this with one of my own apps. My solution was to store anything secret in a git-ignored YAML config file, and then to access that file using a simple class in the initializers directory. The config file is stored in the 'shared' folder for the Capistrano deployment and copied to config at each deploy.
Config store: http://github.com/tsigo/jugglf/blob/master/config/initializers/juggernaut.rb
Example usage: https://github.com/tsigo/jugglf/blob/6b91baae72fbe4b1f7efa2759bb472541546f7cf/config/initializers/session_store.rb
You may also want to remove from source control all history of the file that used these secret values. Here's a guide for doing this in Git that I used: http://help.github.com/removing-sensitive-data/
If you're using foreman, put an .env file in the root of your app. (foreman docs)
.env will have
AWS_SECRET=xxx
AWS_ACCESS=yyy
Then when you need to use the keys, insert:
ENV['AWS_SECRET']
ENV['AWS_ACCESS']
Though it's important that you don't commit this .env to your version control. So if you're using git, add the .env to your .gitignore.
Bonus round! - Heroku
If deploying to Heroku, these environment variables need to be configured in the Heroku environment, too. There are two options:
Manually add the keys through the heroku config:add command
Use the heroku-config gem to synchronize your local environment variables, both ways.
Not storing any secret value at all. At any point in the history of a Git repo.
Those values should be stored elsewhere, leaving only template config files versioned, along with a script able:
to read the right values from the external repo
and build the final config file complete (with the secret values in it)
By keeping the tow set of data separate (sources on one side, secret values on the other), you can then open source the sources repo without comprising any secrets.
I actually took a hint from your question, using ENV.
I had three different secret values that I didn't want made available. They're the app's secret token of course, and Twitter's consumer key and secret. In my secret token initializer:
KinTwit::Application.config.secret_token = ENV['SECRET_TOKEN']
Twitter.consumer_key = ENV['CONSUMER_KEY']
Twitter.consumer_secret = ENV['CONSUMER_SECRET']
I'm hosting my project on Heroku, so I added these as configuration variables to Heroku.
[03:07:48] [william#enterprise ~/dev/rwc/kintwit]$ heroku config:add CONSUMER_KEY=ub3rs3cr3tk3y
Adding config vars and restarting app... done, v7
CONSUMER_KEY => ub3rs3cr3tk3y
[03:08:40] [william#enterprise ~/dev/rwc/kintwit]$ heroku config:add CONSUMER_SECRET=ub3rs3cr3tk3y
Adding config vars and restarting app... done, v8
CONSUMER_SECRET => ub3rs3cr3tk3y
[03:08:57] [william#enterprise ~/dev/rwc/kintwit]$ heroku config:add SECRET_TOKEN=ub3rs3cr3tk3y
Adding config vars and restarting app... done, v9
SECRET_TOKEN => ub3rs3cr3tk3y
Now, the values are ready on my next push. But, what if you aren't using Heroku? I'm obviously not an expert on every single rails deployment (jeesh, not even a Heroku pro), but an example of this would be doing a db:migrate for testing.
$ RAILS_ENV=test rake db:migrate
The KEY=value pair before the command sets the environment variable, so running this command, echo ENV['RAILS_ENV'] would print test. So however this is set up in your environment is how you would do it. But, the environment variables aren't in your code, so that's the trick.
[EDIT - The following method has the annoyance of having to switch to the Production branch to run "rails server" in order to include necessary cookies. Thus, making edits while the server is difficult... and I'm still looking for a good solution]
After further investigation, I think the solution I was looking for was to exclude anything that stored a secret value from my Git repo's master branch (just as #VonC said). But instead of then reading from those files in a separate repo, I simply create a new "production" branch and add them to that.
This way they're excluded from Master and I can push that to Github or some other public repo just fine. When I'm ready to deploy, I can checkout the Production branch and merge Master into it and deploy Production.
I need to be able to do this because Heroku and other hosts require a single git repo to be pushed to their servers.
More information here:
http://groups.google.com/group/heroku/browse_thread/thread/d7b1aecb42696568/26d5249204c70574