Best way to handle secrets.yml in rails 4.1 with capistrano?

[Bruno Sutic]

Versions:

• Ruby 2.1.0
• Capistrano 3.2.1
• Rails 4.1 (basic blog app)

Files:

• config/secrets.yml

I have been playing with rails 4.1 and I wanted to deploy it with capistrano.

All went smooth till the end - the deployed app had hiccups because I didn't provide it with SECRET_KEY_BASE environment variable (see secrets.yml file above).

The problem was easy to manually fix, but I have the question: what is the best general way to handle secrets.yml in rails 4.1?

I can think of 2 approaches and can't decide which one is right:

1. - put the secrets.yml in version control
   - development and test secrets are visible and set in the file
   - handle production secrets with environment variables
   - set production env vars with capistrano somehow (values also must not get into version control)
   DOWNSIDES:
   - too much hassle around env variables?
   - development, test secrets still visible in git: problem when API keys for other services are used (eg S3)
   
   
2. - do NOT put secrets.yml in version control
   - have all the secrets (both dev,test and prod) inside the secrets.yml file
   - capistrano's job would be only to upload the config/secrets.yml file
   DOWNSIDES:
   - server secrets stored in a file (not an issue myb?)
   - config is not in the environement according to 12 factor

Looking at the steps above, the approach #2 seems less work and less chance for a failure.

Any other opinions on this?

Thanks

[Irish]

At the security talk at this years RailsConf it was suggested to put secrets and other similar items, API keys etc.. Into a separate git repo with very limited access. During deploy your scripts can pull from this repo and set all the necessary ENV variables for your app dynamically. I have tried this personally but I like the approach

[Robert Kuzelj]

Hi Chris,

I am having the same question just right now.

which talk was that? is it available online already?

ciao robertj

[Irish]

It was this one:

Tales from the Crypt

Aaron Bedra, Justin Collins, Matt Konda

I don't believe it's online yet.

[Bruno Sutic]

@mbrictson has a nice writeup about this here:

http://blog.55minutes.com/2014/03/upgrading-to-rails-4-with-capistrano/#comment-1360973298

[Robert Kuzelj]

thx for sharing the link

[Bruno Sutic]

Here's another interesting writeup on this topic:

http://blog.intercityup.com/deploying-app-env-variables-with-rbenv-passenger-and-capistrano/

Found it on hacker news today.

[Hassan Schroeder]

On Fri, May 9, 2014 at 9:23 AM, Bruno Sutic <bruno...@gmail.com> wrote:
> Here's another interesting writeup on this topic:
> http://blog.intercityup.com/deploying-app-env-variables-with-rbenv-passenger-and-capistrano/

I really don't understand the point of all this futzing around. Per the
above, now you have a file 'shared/.rbenv-vars' which needs to be
symlinked into your app.

Why not just symlink 'shared/secrets.yml' into your app to start with?

Either way, all of your "secret sauce" is in a file in a directory on the
server.

Or am I missing something?
--
Hassan Schroeder ------------------------ hassan.s...@gmail.com
http://about.me/hassanschroeder
twitter: @hassan

[Bruno Sutic]

Hi,

what you say is true and that workflow might work for you.

Here's how the tricky scenario might look:

• you *want* to have `secrets.yml` stored in git. That way a new developer on the team, can just clone the repo and start working without worrying about development secrets
• on the other hand, even though `secrets.yml` for development are in git and "visible", you don't ever want to store production secrets. So it seems, rails suggests keeping production secrets in environment vars.

With this approach, the tutorial from a couple posts back makes sense.

Now I'm not completely sure this is the best approach too. What if, for example, you want to keep development S3 credentials in `secrets.yml`?

Even for development, that leaves a lot of opportunity for abuse if keys are stored in git and the repo is public.

With all this talk, and circling around, maybe the simplest solution is the best, so as Hassan said:

- do not keep `secrets.yml` in your version control

- just symlink `shared/secrets.yml` for remote server/production

[Steve Smith]

I have to ask:  What are the downsides to regenerating the production secret_key_base during every deploy of the application?  How are the end users impacted?

[Lee Hambley]

I have to ask:  What are the downsides to regenerating the production secret_key_base during every deploy of the application?  How are the end users impacted?

I'd imagine it'd invalidate all session keys

Lee Hambley

--

http://lee.hambley.name/

+49 (0) 170 298 5667

--
You received this message because you are subscribed to the Google Groups "Capistrano" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capistrano+...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/capistrano/5984604b-aa64-4ccb-8cd7-381d76ce3729%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Steve Smith]

Wait a minute. It would be bad if deployed across multiple servers, load balanced, etc.  All the keys would be different.  Can't do that.  right?

[Bruno Sutic]

Just in case anyone is still looking for a solution to this, I created a capistrano-secrets-yml gem: https://github.com/capistrano-plugins/capistrano-secrets-yml

It handles secrets.yml in the simplest possible way.

[Jonathan Rochkind]

Neat.

I will admit, however, that it has never been clear to me what the
security improvement is supposed to be of having a secrets.yml that you
copy to all your servers, but don't put in your version control. If
you're going to have it on possibly multiple production servers, why not
in version control too? It adds another level of management complexity
to do this, and I've never been clear on the benefit.

But I'm clearly in the minority, so there's probably something I'm missing!

On 10/7/14 1:52 PM, Bruno Sutic wrote:
> Just in case anyone is still looking for a solution to this, I created a
> capistrano-secrets-yml
> gem: https://github.com/capistrano-plugins/capistrano-secrets-yml
> It handles secrets.yml in the simplest possible way.
>
> On Friday, April 25, 2014 4:56:44 PM UTC+2, Bruno Sutic wrote:
>
> Versions:
>

> * Ruby 2.1.0
> * Capistrano 3.2.1
> * Rails 4.1 (basic blog app)
>
> Files:
>
> * config/secrets.yml <http://pastie.org/9107297>

>
> I have been playing with rails 4.1 and I wanted to deploy it with
> capistrano.
> All went smooth till the end - the deployed app had hiccups because
> I didn't provide it with SECRET_KEY_BASE environment variable (see
> secrets.yml file above).
>
> The problem was easy to manually fix, but I have the question: what
> is the best general way to handle secrets.yml in rails 4.1?
>
> I can think of 2 approaches and can't decide which one is right:
>

> 1. - put the secrets.yml in version control

> - development and test secrets are visible and set in the file
> - handle production secrets with environment variables
> - set production env vars with capistrano somehow (values also
> must not get into version control)
> DOWNSIDES:
> - too much hassle around env variables?
> - development, test secrets still visible in git: problem when
> API keys for other services are used (eg S3)
>

> 2. - do NOT put secrets.yml in version control

> - have all the secrets (both dev,test and prod) inside the
> secrets.yml file
> - capistrano's job would be only to upload the
> config/secrets.yml file
> DOWNSIDES:
> - server secrets stored in a file (not an issue myb?)
> - config is not in the environement according to 12 factor

> <http://12factor.net/config>

>
> Looking at the steps above, the approach #2 seems less work and less
> chance for a failure.
> Any other opinions on this?
>
> Thanks
>

> --
> You received this message because you are subscribed to the Google
> Groups "Capistrano" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to capistrano+...@googlegroups.com

> <mailto:capistrano+...@googlegroups.com>.

> To view this discussion on the web, visit

> https://groups.google.com/d/msgid/capistrano/4dafc4a2-d612-4f40-bd51-fe499c91ed4b%40googlegroups.com
> <https://groups.google.com/d/msgid/capistrano/4dafc4a2-d612-4f40-bd51-fe499c91ed4b%40googlegroups.com?utm_medium=email&utm_source=footer>.