Docker Compose option to generate random passwords #76
Conversation
docker-compose.yml
Outdated
There was a problem hiding this comment.
Was this committed by accident? At a glance, this looks like the generated passwords Compose file was used to overwrite the regular Compose file.
There was a problem hiding this comment.
Don't think so...here are the last commits to docker-compose.yml:
There was a problem hiding this comment.
Sorry, I meant, was it added into this PR (committed to this branch) by accident?
Based on the other feedback, it seems like the auto-generated passwords will be the default behavior in the future, so presumably this comment is moot anyways.
There was a problem hiding this comment.
Ah OK, if you look at the README in the PR you will see the instructions:
At the moment you need to explicitly override the docker-compose.yml file when wanting to use more secure passwords, however after the Dev meeting this afternoon it was decided that secure passwords will be the default when this is merged
generate_passwords.py
Outdated
|
|
||
| with open(fn, 'w') as f: | ||
| f.truncate(0) | ||
| for pwvar in pwvars: |
There was a problem hiding this comment.
Probably better to use https://docs.python.org/3/library/secrets.html#secrets.token_urlsafe secrets.token_urlsafe, as /dev/urandom is somewhat platform dependent.
generate_passwords.py
Outdated
| f.write(f"CKAN_DATASTORE_WRITE_URL=postgresql://{CKAN_DB_USER}:{CKAN_DB_PASSWORD}@{POSTGRES_HOST}/{DATASTORE_DB}\n") | ||
| f.write(f"CKAN_DATASTORE_READ_URL=postgresql://{DATASTORE_READONLY_USER}:{DATASTORE_READONLY_PASSWORD}@{POSTGRES_HOST}/{DATASTORE_DB}\n") | ||
|
|
||
| print("[setup_passwords] password file: '.pw' created successfully") |
There was a problem hiding this comment.
Should probably print out the ckan sysadmin password on the console, and note where it's actually saved.
| - redisnet | ||
| env_file: | ||
| - .env | ||
| - .pw |
There was a problem hiding this comment.
This isn't safe.
This is passing in the database superuser password into the CKAN instance, where it should only have access to the specific urls that are needed to connect to the database.
|
Also mentioned in the call -- Out of the box, this should use the random PWs. If someone wants to use old static passwords on new installs, they need to work at it. |
.env.use-generated-passwords
Outdated
| CKAN_PORT_HOST=5000 | ||
| CKAN___BEAKER__SESSION__SECRET=CHANGE_ME | ||
| # See https://docs.ckan.org/en/latest/maintaining/configuration.html#api-token-settings | ||
| CKAN___API_TOKEN__JWT__ENCODE__SECRET=string:CHANGE_ME |
|
Thanks @EricSoroos for helping me here. I've pretty much got it all working with the new changes however I'm thinking it might be best to have one generated password file (locked down) to pass through to the ckan container and one to pass through to the db container... |
|
@kowh-ai I'm not sure if this is the best place to note this, so do tell me if there is another better, location: If we are doing this work on random passwords, to bypass having passwords in .env files, perhaps it is worth exploring the docker solution for secrets, which works with docker compose: |
|
@pwalsh - I had gone through secrets in Docker documentation plus examples people had written about and thought you could only use secrets when you had set up Docker to run in swarm mode. I'm very interested in pursuing this |
|
@kowh-ai ok. I was sure it worked with compose, but must be my misreading. I was researching this for some of my own projects but have not implemented it yet. |
Fixes: #65
In the past passwords have been included in the
.envfile and therefore included as Docker Compose variables when building and running Docker images and containersThis PR includes a new option to generate randomised, secure passwords for the following users:
POSTGRES_USERCKAN_DB_USERDATASTORE_READONLY_USERCKAN_SYSADMIN_NAMEThese passwords are kept in a new file:
.pwand added toenv_file:in the Docker Compose yml fileThe README has been updated with a new section on the steps involved for using this new option
I could include all the steps in the
generate_passwords.shscript rather than have people explicitly overriding and saving filesUpdate: The random password generator will now be the default option. There will also be an option to opt-out so passwords will be referenced from the
.envfile. This option is how passwords were implemented previouslyAlso, other variables (secrets) will be included as well. These are as follows:
CKAN___BEAKER__SESSION__SECRETCKAN___API_TOKEN__JWT__ENCODE__SECRETCKAN___API_TOKEN__JWT__DECODE__SECRET