For people in non-cloud native infrastructures, it would be really helpful to provide the connect-server as compiled binaries or even as packages (rpm/deb).
Also system service files in the examples would be nice.
I had to put in some trial and error to get this running, but it's totally possible and I think the simplicity of SystemD is sometimes better than the docker/k8s/ecs configuration for smaller environments.
[!NOTE]
The cli binaries can be extracted from the docker images like so:
[!IMPORTANT]
Of course we also need to create the same connect-server in the web-ui
or via the 1password-cli to get the credentials.json
And the file needs to be placed in the created service directory, similar to the other deployments.
I also noticed that the currently compiled binaries are build using go1.20.6,
which is about 7 months old and will be EOL once go1.22 releases - I expect that to be soon.
I think going for #37 is a bit too much, since we can still inspect the image and find the versions by other means,
but it would be much appreciated if this information is not "hidden", but shown clearly. Maybe even a warning is appropriate here.
When building Connect we've taken a great deal in care in making sure to provide you with the same level of security that you have come to expect with 1Password.
For people in non-cloud native infrastructures, it would be really helpful to provide the connect-server as compiled binaries or even as packages (rpm/deb). Also system service files in the examples would be nice.
I had to put in some trial and error to get this running, but it's totally possible and I think the simplicity of SystemD is sometimes better than the docker/k8s/ecs configuration for smaller environments.
Now all that is missing are the service files:
Files can be copied into
/etc/systemd/system/
and then startedI also noticed that the currently compiled binaries are build using
go1.20.6
, which is about 7 months old and will be EOL oncego1.22
releases - I expect that to be soon.I think going for #37 is a bit too much, since we can still inspect the image and find the versions by other means, but it would be much appreciated if this information is not "hidden", but shown clearly. Maybe even a warning is appropriate here.
I mean, the docker image on docker-hub is 6 months old now, which does not convey "we take security seriously".