search

me-box-archive / databox-netdev

Old Dev version Databox OS container manager and dashboard server (do not use)
MIT License
3 stars 6 forks source link

Start the databox export service #42

Closed Toshbrown closed 7 years ago

Toshbrown commented 7 years ago

The DATABOX_EXPORT_SERVICE_ENDPOINT environment variable is set in all apps from now on.

sevenEng commented 7 years ago

One point about the Https certificate and private key. The environment variables actually store the cert and key content right? In the export service code, I was assuming they are the file names pointing to the cert and private key files (mainly because the library's API asks for file names instead of actual contents). Could this be taken care of in CM? Or I could write some interfacing code in export node to deal with this (basically by creating tmp files and storing the contents in them).

Other than this, all LGTM.

yousefamar commented 7 years ago

It's the content as you said. I've actually done exactly what you described for the Java library because it also needs the certs as files, and I couldn't be bothered to figure out how/if I can circumvent it. Lines in question here: https://github.com/me-box/databox-app-template-java/blob/master/Databox.java#L38

When doing that I was thinking if it would be better to give containers the certs as files, by writing them to a directory then mounting that as a volume for any given container. I think that the environment variable method is slightly less of a hassle though (for the system, rather than the app) especially since it would in addition need to manage certs on the host and clean up afterwards. Not to mention there may be a bit of attack surface there if not done right; if something on the host steals the certs and spoofs container UIs or whatever.

Definitely a possibility though, but since we currently don't mount volumes on any container, I personally tend to prefer the environment variable route.

Toshbrown commented 7 years ago

Also, apps and drivers currently do not have any volume mounts. This is to prevent them storing data between restarts, apart from in sanctioned databox stores. This keeps all data in stores, so when we start encrypting data at rest we will only have to manage this in the datastores keeping the apps and drivers simple.

The workaround to wire the environment variables to a file inside the container is not complex. Therefore, I would suggest sticking with the current way of doing this until we have more time to think about the consequences of giving apps and drivers a volume mount.

yousefamar commented 7 years ago

Exactly, we'd have to make sure to constantly be cleaning up between restarts. Technically we could mount volumes as read-only (read-only in the container, but read/write on the host) but even if they can't be used to leak data, they can still leak certs, so either way I agree that we should stick to environment variables.

sevenEng commented 7 years ago

Alright, thanks for the feedback guys. So I will figure out the workaround to patch the export service and let's stick to environment variables for now.

Toshbrown commented 7 years ago

this had the same issue. The fix is here https://github.com/me-box/databox-local-registry/blob/master/docker-entrypoint.sh