Not using docker compose: Can I save and reuse an auth.json?

[mannp]

I don't use docker compose and have created my own docker build, but wondered if I am able to reuse an auth.json to keep logged in on docker reboots.

I have /data/ persistent, but it doesn't seem to contain the auth.json for some reason, that is elsewhere, so do I really need to save the data in the /data/ directory in the docker?

I use 2FA so not sure how I would enter the 2FA code if I were to add the User and password ENV variables?

[harleylang]

Hey sorry I missed this, great question,

I'm not sure hydroxide will work if you reuseauth.json but it might be worth testing.

To make auth.json persistent I believe you need to update setup.sh so it will copy over the file into /data.

Another necessary update to setup.sh is to first check if an existing auth.json file exists in the persistent directory.

Whether it is good practice to make your auth.json file persistent is another question. Likely if you are running a Docker container, you are going to build and park it somewhere to run. I don't believe you need to re-enter your password if another container is spun up; I believe it is only needed when building the initial image. You might want to protect your container by ensuring that it requires the key to make the image.

Re: 2FA, I am not sure what would be the best course of action. Have you tested this? Do you only need 2FA when authenticating or do you need to input it on each email sent?

[arichtman]

I've relaunched containers and had them successfully use an existing auth.json stored in a Docker volume. There is some discussion I think to be had around security and handling of a persisted access token stored in auth.json. Hydroxide doesn't state that there are expiries on the tokens generated - which would mean a persisted access token would mitigate 2FA to some degree (I'm not sure what APIs and permissions the token has).

[arichtman]

Re the 2FA token it's only required when generating an access token - so once on each container start unless you persist it. It's very at-odds with container/Kubernetes principles I think. For me, I'm happy to persist the access token because I need containers to be functional if restarted. I'll handle the security of the token using Linux permissions - though it would be neat to encrypt the file or volume transparently. We'll never be able to get away from root users being able to decrypt the access token I think.

[harleylang]

@arichtman these are excellent comments, thanks for lending a hand :smiley:

I've relaunched containers and had them successfully use an existing auth.json stored in a Docker volume.

That's some good intel, thank you for reporting!

There is some discussion I think to be had around security and handling of a persisted access token stored in auth.json

Re the 2FA token it's only required when generating an access token - so once on each container start unless you persist it. It's very at-odds with container/Kubernetes principles I think. For me, I'm happy to persist the access token because I need containers to be functional if restarted.

This makes a lot of sense to me as well, as it would be counter intuitive to require 2FA input each time a container is spun.

I'll handle the security of the token using Linux permissions - though it would be neat to encrypt the file or volume transparently. We'll never be able to get away from root users being able to decrypt the access token I think.

Yeah I suppose this is the trade off. If auth.json is persistent then it opens up an attack vector. Are you aware of any methods that can encrypt auth.json?

Spitballing here---not sure if this is the best solution but I'll drop it in the thread. What if auth.json is encrypted in the Hydroxide Dockerfile before being placed in /data with a key that is shared in docker-compose? That way /data/auth.json is encrypted locally on the host system, and the encryption key can be shared to the containers that need to use /data/auth.json. Thoughts???

[arichtman]

Your docker-compose shared encryption key is along the right lines as vindicated by current approachs to secrets management in cloud and Kubernetes. I think solving for secrets management should be outside of our scope for now. Also it appears the password is encrypted already https://github.com/emersion/hydroxide/blob/d16ec98f49677592d5b65039fe3d35dd4dab5f6e/auth/auth.go#L89