There are several layers of security and permissions to take into consideration. * Docker and how it behaves on the host system running the container which contains webhop * Tomcat and the mechanisms providing authentication of the webhop session that is shared between the tomcat server and the users' browser.
A guide for some of this would be that if there is to be a long running container that acts like a server that people want to start, stop and resume, you will want to be careful that all file writes or updates end up on a shared volume or bind mount that docker provides to the container running webhop. This means everything, from tmp, caching, logs, audit, configurations, environments and finally user content. If anything gets missed, these writes will appear as additional 'overlay' layers written to the virtual disk inside the container and usually stored in the root file system of the host computer. It will continue to grow over time until the container is completed wiped from the host. This is less of a problem if you have throw away containers where they are started with --rm where when they stop they clean up after themselves. Another thing to consider from the docker side is, which user webhop runs as inside the container. When containers move between environments, they carry over some of the traits from the environment where they were created. For example, if you have a build system where root is user 0 and then create a user called webhop with a user ID and GID of say 1001 on the build system, if you then use that user to add or create files, that user ID and GID are saved in the resultant image. When an external user picks up the image and pulls it to their host system, there may be a mismatch of that non-privileged user, which will give you all sorts of access denied behavior. That behavior is really bubbling up from the host operating system when the container runs. It might be necessary to create a user with a high user ID range and group ID that would be safe for most container users to also create on their host systems to avoid problems like that and still remain secure. Once you are sure there are no docker host / Linux related permission issues, the rest of the security with Tomcat can be handled using whatever mechanisms you think are adequate. I would think maybe some safe default modes by using internal tomcat user security that could be injected into the container at startup. The only other security framework I am familiar with is Spring from the taho days. I hope this helps. Brandon On Mon, Feb 15, 2021 at 4:33 AM Matt Casters <[email protected]> wrote: > Hello Hops, > > Now that Hiromu has been making absolutely stunning progress on merging his > Hop Web changes into the main code-line we're seeing > hiromuhota/hopweb:nightly behave like a champ. > > As a reminder you can give it a shot with: > > docker run -d -p 8080:8080 hiromuhota/hopweb:nightly > > That being said, a hop.war file is being generated in the main build now in > assemblies/web/target/hop.war You should be able to throw that into a web > server webapps folder to get it up-and-running. > > This does bring the security question around hop-web on the table though. > The requirements around this for me are essentially that we should be able > to develop data orchestration solutions in a browser with one or more > developers on the same server. This means allowing files to be changed by > multiple users, multiple git repositories and so on. I predict that things > can get problematic if we don't do something about that. > > *Security & ACLs* > > I think at some point we might want to implement some kind of mapping > between an authenticated user (say [email protected] authenticated via > OAuth) and a hop-web user. > > Now this hop-web user typically has access to all files on a server unless > we invent something to restrict that access. We could make it so that the > file dialog only allows you to browse to certain folders or more > specifically, specific project folders. > So the list of mappings could be: AuthenticationUser - HopUser - Project > > *Action based security* > > I can also see a use-case, obviously not just for hop-web, for having > action-based security with the absolute minimum being some sort of > read-only mode. > Action based security can be sprinkled throughout the GUI and runtime code > as long as we have the metadata to validate actions. > We need: > - User/Role ACL > - The subject (specific file, category, metadata object, ...) > - The action > - Allowed/Denied > - Arguments > > Example: User(matt) is Allowed to Action(execute) a Subject(pipeline) with > Argument(pipeline run configuration="local") > > Once we have this security metadata "database" somewhere we can just add > one-liner checks in the code. For example right before we run a pipeline: > > HopSecurity.validateAction( pipelineMeta, HopActionType.EXECUTE, ...); > > This could pick up the current user and validate it. If there is no > security layer defined or no user it will just be ignored. > > *Locking, messages & code review* > > Finally if you're working with multiple developers on the same project > there is a high chance that you'll be tempted to work on the same file at > some point. Having the ability to do a soft or hard lock on a pipeline or > workflow would be really nice to have (and fairly easy to implement). > If you open a file to work on you could see a message from a user > saying: "*Sorry, > I'm working on this file*". You'll open a read-only version of the file. > With a soft lock you should be able to just ignore this and edit anyway. > Messages also could be very easy to implement in the form of developer > notes on a file or project level (where it matters really). > Code-reviews finally are IMO just a variant of that with perhaps an extra > status that we keep on a file/project level. (Has remarks, partially > approved, approved) > If messages, locks and reviews are implemented as metadata objects we could > check them into the project itself. They'll become an intricate part of > the project itself. We could prevent a push to upstream in git for example > until the project review status has reached Approved status. > > Anyway, just a few ideas to discuss. Have at it. > > Cheers, > Matt > -- > Neo4j Chief Solutions Architect >
