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

Unable to manually set secrets #220

Closed
joshdentremont opened this issue Feb 8, 2022 · 6 comments
Closed

Unable to manually set secrets #220

joshdentremont opened this issue Feb 8, 2022 · 6 comments

Comments

@joshdentremont
Copy link
Contributor

joshdentremont commented Feb 8, 2022

There doesn't seem to be a way to create your own secrets. When running make local it will generate random secrets, and if USE_SECRETS=true it will set the passwords to those secrets, otherwise it sets them to 'password'. Changing the secrets files, or changing USE_SECRETS after this initialization doesn't seem to do anything.

The biggest issue that I see with this is that if you follow the instructions for installing a production server it tells you to make local, then set USE_SECRETS=true, but if you do it in that order your passwords will all be 'password' because that's what they were originally set to when you ran make local.

I think the best solution would be to have a make command that changes all the passwords in our containers to the contents of secrets/live. Then we could just put a note in the sample.env that turning on USE_SECRETS requires running that command.

@noahwsmith
Copy link
Contributor

@Tristaan built the secrets generation engine here, I think. Any thoughts, Tristan ?

@DonRichards
Copy link
Member

From the tech call: I believe this is already doable and is just an order of operations problem. I'll test my theory really quick this afternoon and get back to you.

@DonRichards
Copy link
Member

Just tested this and it doesn't seem to be working now.

@joshdentremont
Copy link
Contributor Author

@DonRichards I couldn't find a way to do it either. It seems to be baked into make local to create and then use the secrets.

Another possible solution I am thinking about would be to remove USE_SECRETS (have it always be true) and instead add a variable called MANUAL_SECRETS. If manual secrets is set to true then it should not automatically generate them, but instead the user would have to copy the secrets/template folder into secrets/live. That way they could leave them all as "password" if they wanted to, or could manually update them before running make local.

My biggest concern with this is having someone go live with a production site that initially wasn't using secrets, and not realize that some of their passwords are "password" because they were not updated when turning on USE_SECRETS.

@DonRichards
Copy link
Member

@joshdentremont I just pushed an pull request on this to address most of this (I think) #226

@jjakob
Copy link

jjakob commented Mar 4, 2022

I was @Tristaan 's supervisor at the company where he was tasked to create this. He's no longer employed at our company (as of 4 months ago) so I've taken over his duties. When this was PR'd, my intention was to incorporate a secrets-generating script that I had already written, that already did work correctly (it checks if live secrets already existed and didn't overwrite them, and supports random or template secrets types), it's also much simpler. Unfortunately his code was never confirmed by me, but was made into a PR anyway, which I didn't approve of. After his absence I didn't have time to immediately continue his work so it got put on hold.

I didn't have time to work on this project so didn't have time to look at this issue sooner, but now that someone else has already made a PR for secrets handling that seems to be pretty far along, I don't know if it would be good for me to ask you to replace it with my script. I haven't evaluated that PR yet, to see if it's equivalent to my code or not.

I can make a PR just to compare after I get the time and get back to this (hopefully next week)

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

4 participants