[compose] Use Docker secrets

[sumanthratna]

• poetry run python manage.py createsecrets should work
• docker-compose -f docker-compose.yml -f docker-compose.dev.yml up --force-recreate --build should work
• docker-compose -f docker-compose.yml -f docker-compose.prod.yml up --force-recreate --build should work
• update start_live script
• update docs
• update gh actions

closes #38

[smayya337]

@sumanthratna I've got to be doing something wrong, aren't I? This is the end result of docker-compose -f docker-compose.yml -f docker-compose.dev.yml up --force-recreate --build on Ubuntu 20.04.

WARNING: Service "postgres" uses secret "postgres_user" which is external. External secrets are not available to containers created by docker-compose.
WARNING: Service "postgres" uses secret "postgres_password" which is external. External secrets are not available to containers created by docker-compose.
WARNING: Service "postgres" uses secret "postgres_db" which is external. External secrets are not available to containers created by docker-compose.
WARNING: Service "django" uses secret "secret_key" which is external. External secrets are not available to containers created by docker-compose.
WARNING: Service "django" uses secret "django_superuser_username" which is external. External secrets are not available to containers created by docker-compose.
WARNING: Service "django" uses secret "django_superuser_password" which is external. External secrets are not available to containers created by docker-compose.
WARNING: Service "django" uses secret "django_superuser_email" which is external. External secrets are not available to containers created by docker-compose.
WARNING: Service "django" uses secret "postgres_user" which is external. External secrets are not available to containers created by docker-compose.
WARNING: Service "django" uses secret "postgres_password" which is external. External secrets are not available to containers created by docker-compose.
WARNING: Service "django" uses secret "postgres_db" which is external. External secrets are not available to containers created by docker-compose.
WARNING: Service "django" uses secret "sendgrid_api_key" which is external. External secrets are not available to containers created by docker-compose.

[smayya337]

Update: Docker secrets don't work with Compose, apparently. From Docker's own documentation:

Note: Docker secrets are only available to swarm services, not to standalone containers. To use this feature, consider adapting your container to run as a service. Stateful containers can typically run with a scale of 1 without changing the container code.

Am I supposed to be using Swarm?

[sumanthratna]

@sumanthratna I've got to be doing something wrong, aren't I? This is the end result of docker-compose -f docker-compose.yml -f docker-compose.dev.yml up --force-recreate --build on Ubuntu 20.04.

WARNING: Service "postgres" uses secret "postgres_user" which is external. External secrets are not available to containers created by docker-compose.
WARNING: Service "postgres" uses secret "postgres_password" which is external. External secrets are not available to containers created by docker-compose.
WARNING: Service "postgres" uses secret "postgres_db" which is external. External secrets are not available to containers created by docker-compose.
WARNING: Service "django" uses secret "secret_key" which is external. External secrets are not available to containers created by docker-compose.
WARNING: Service "django" uses secret "django_superuser_username" which is external. External secrets are not available to containers created by docker-compose.
WARNING: Service "django" uses secret "django_superuser_password" which is external. External secrets are not available to containers created by docker-compose.
WARNING: Service "django" uses secret "django_superuser_email" which is external. External secrets are not available to containers created by docker-compose.
WARNING: Service "django" uses secret "postgres_user" which is external. External secrets are not available to containers created by docker-compose.
WARNING: Service "django" uses secret "postgres_password" which is external. External secrets are not available to containers created by docker-compose.
WARNING: Service "django" uses secret "postgres_db" which is external. External secrets are not available to containers created by docker-compose.
WARNING: Service "django" uses secret "sendgrid_api_key" which is external. External secrets are not available to containers created by docker-compose.

@smayya337 yeah that's expected; it's because we need to add the secrets as external in the base compose config so that it doesn't think the secrets don't exist. the override configs link to the files (i.e., the warning doesn't apply to us)

Update: Docker secrets don't work with Compose, apparently. From Docker's own documentation:

Note: Docker secrets are only available to swarm services, not to standalone containers. To use this feature, consider adapting your container to run as a service. Stateful containers can typically run with a scale of 1 without changing the container code.

Am I supposed to be using Swarm?

I think that's referring to external docker secrets; we should be able to use secrets with Compose as long as the secrets point to plaintext files. https://docs.docker.com/engine/swarm/secrets/#use-secrets-in-compose

[smayya337]

@sumanthratna ah, I see. The current issue for me is that I'm getting a psycopg2.OperationalError: FATAL: password authentication failed for user "'live_postgres'". Everything seems to be working fine (I can login from inside the postgres container and the django container can read the information from the secret files), so the breakage is admittedly a bit puzzling.

[sumanthratna]

The current issue for me is that I'm getting a psycopg2.OperationalError: FATAL: password authentication failed for user "'live_postgres'". Everything seems to be working fine (I can login from inside the postgres container and the django container can read the information from the secret files), so the breakage is admittedly a bit puzzling.

yeah I had that error too which is why I handed this PR off to you lol

@smayya337 do you get that error with the dev config? or is it just the prod config?

[smayya337]

Got it on dev - haven't tested prod yet. I'll look into it some more tomorrow; maybe I'm just too tired at the moment.

[sumanthratna]

@smayya337 any chance you can take another look at this?

[smayya337]

Looking at it now - the cause of the 'live_postgres' thing is pretty obvious, I had .env lying around and it read from that first (so just don't use both .env and secrets) - now it's not reading the Postgres secrets, so I'll need to debug that.

[smayya337]

@sumanthratna yeah, I honestly don't know why it's refusing to read the files... is there a meaningful advantage to doing it this way? To me, it looks similarly insecure to the old .env method - both of them rely on putting data in plaintext.

[sumanthratna]

is there a meaningful advantage to doing it this way? To me, it looks similarly insecure to the old .env method - both of them rely on putting data in plaintext.

IIRC the security benefits are:

• env vars are not encrypted by Docker
• docker inspect doesn't display the secrets
• allows distributing secrets individually (useful b/c redis doesn't need postgres creds, for example)
• I think env vars can be read from PID using <pid>/environ or <pid>/env

let's leave this PR on hold; if it becomes too outdated with main I'll close it later