Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spike to investigate impact of switching from env vars to rails credentials #11

Open
6 tasks
rocketnova opened this issue May 23, 2024 · 6 comments
Open
6 tasks
Assignees

Comments

@rocketnova
Copy link
Contributor

rocketnova commented May 23, 2024

The current strategy for providing secrets is to use environment variables. When hosting in AWS, the secrets are passed as secured environment variables from Parameter Store.

Rails supports providing secrets as encrypted credentials instead of environment variables or environment files. This issue is for doing a spike to investigate:

  • whether we should switch to using rails credentials
  • how we would modify the deployment config to use rails credentials

Possible references:

Tasks:

  • ADR outlining our decision
    • which includes an assessment of the approaches with pros/cons
    • which outlines the context we expect to be using the template
    • which outlines alternative contexts where selecting a different approach might be better
  • Documentation in /docs/app-rails that links to the ADR (probably in technical foundation
    • which includes directions for how someone in a different context can configure the template differently than the default
@lorenyu
Copy link

lorenyu commented May 23, 2024

What's the advantage of doing this? Seems less 12factor-y

@rocketnova
Copy link
Contributor Author

Yeah, this spike should include that evaluation. At first glance, I think one benefit is encryption.

@lorenyu
Copy link

lorenyu commented May 24, 2024

I'm not sure I understand the benefit of encryption. I would imagine that having an encrypted secrets file in source control is still less secure than not having secrets stored in source control at all. Since it's in source control it'd be in git history, so the secrets would have to be ones that are revokable, otherwise a future hacker can still hack an old version of the encrypted file (I forget what that type of attack is called)

@SammySteiner SammySteiner self-assigned this Jun 17, 2024
@SammySteiner
Copy link
Contributor

SammySteiner commented Jun 17, 2024

I'll take the ticket.

@rocketnova I want to structure the doc more like an ADR comparing the two approaches (pros and cons of each) and explaining why we went with .env vars. I'll also include a section on how to back out of this config if the folks using the template prefer to use Rails Credentials anyway. Does that work for you for this ticket?

@lorenyu I agree generally that env is a better approach than rails credentials (security, 12 factor-y, consistent with other Nava templates and repos, not to mention I was getting late night infomercial vibes from the thoughtbot article with their description of trying to set up a repo only to discover that you don't have the env vars <scareQuotes>Has this happened to you?</scareQuotes>). But I like the idea of having an ADR in the codebase for other engineers about why we're not doing it the Rails way in our Rails template.

@lorenyu
Copy link

lorenyu commented Jun 17, 2024

if i had to guess, rails does it this way because it's convenient and requires minimal infrastructure. you just need one environment variable which you could do manually rather than a infra pattern for how to inject env vars into your app dynamically. if we do have that infra pattern though, i don't see the benefit of it.

@rocketnova
Copy link
Contributor Author

@SammySteiner Thank you for outlining your approach to this ticket. It looks great. I would like to see an assessment of the options, an ADR for why we picked what we picked, and directions to support people who want to use the template with a different approach than the one we picked. I'll update the ticket with these tasks. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants