How to set up TLS for 1Password Connect?

Will I break Connect if I try to change the UID in the container instead, using this?

Hmm, I am not sure if that works if the user is not created in Connect first. And I don't think the image has any other users configured.

Also, technically it should work if the user already exists. The only drawback is that any process running as that user will also have access to the files.

Changing the user in the container seems to fail indeed:


Mar 17 17:40:16 pi-hb docker-compose[3137]: 1password-connect-api | {"log_message":"(I) no database found, will retry in 1s","timestamp":"2022-03-17T16:40:16.350449714Z","level":3}


That's quite unfortunate: this user 999 is already used for software with third-party plugins, so I'd rather not give it access to the *.pem files.

I might try "swapping" users/UIDs later (if that is possible at all).

It only now occurs to me that my existing user 999 is already using the exact same *.pem files...

However, I'm still not comfortable with it now also getting access to 1password-credentials.json.

Is there no way to configure the user/group used by your containers? (feature request?)

However, I'm still not comfortable with it now also getting access to 1password-credentials.json.

That is understandable.

One final thing you can give a try is the following:
1. Create a directory containing those files (e.g. secrets/)
2. Move the credential and .pem to this directory.
3. sudo chown root secrets/: to make the directory owned by root.
4. sudo chmod 744 secrets/ to only give root execute permission on this directory.
5. sudo chmod 644 secrets/<file> for all files in the secrets/ directory.

This should make the files readable in Docker containers, without granting every user on the system access. Why? Only root has the execute permission on the directory, https://unix.stackexchange.com/a/317446. So only root can read the files. At least on Linux, Docker is run as root and can therefore open the directory and mount the files. Because the files themselves are still readable by all users (the last 4 in step 5), the containers can still read the files after they are mounted, even though they are not running as root.

I have tested this on my Fedora Linux system and there it seems to work. Give it a try on your RasPi to see if it also works on there. You can verify access is denied to regular users by running cat secrets/1password-credentials.json. Note that this will probably not work on macOS or Windows because of the way Docker runs on there.

I will also also record a feature request for some more flexibility in configuring this. If I understand you correctly, having a way to use Docker's user: configuration option would work for you?

Joris

Nice "trick"! Seems to work on my Pi.

I'm new to Docker, so don't know whether user: would be a (good) solution.

PS: Is the https:// scheme in HTTP_CONNECT_HOST needed, or can I achieve using HTTPS in another way?


OP_CONNECT_HOST=https://1password.domain.com:18843

vs

OP_CONNECT_HOST=1password.domain.com:18843


Because all plugins and SDK's can be used over either HTTP or HTTPS, the protocol must be specified in OP_CONNECT_HOST. That means that specifying either https:// or http:// is a requirement.

Thanks.

I had some trouble "waiting for" the service at ${OP_CONNECT_HOST} (if it contains the https:// scheme), but it looks like I found a tool to achieve this:

https://1password.community/discussion/comment/633552/#Comment_633552

That's great to hear.