Current issues that need to be resolved before production use can be considered. Limited to absolutely necessary, and not a feature wishlist.
- Any user can currently cause a denial of service, through:
- High CPU usage
- High memory usage
- High disk usage
- A fork bomb - intentional or otherwise
- There are no limits on the number of active projects, potentially compromising the viability of the service.
- We provide container sudo, which is good for users, but not currently recommended. (Sudo limits are more to protect the user than ensure security - any RPM can setuid root on a script to provide root shell.)
- NeCTAR VMs have very good internet connections, and the local bridges to other VMs are likely even faster. It's unclear what abuses could occur as a result.
All of these issues add up to an insecure hosting environment for the docker containers. Mitigation steps might include:
- SELinux
- Limiting container resources:
- Docker can limit CPU and Memory
- Process limits would be great, but it's not clear how they would work for UID 0.
- Splitting up compute notes:
- BYO compute nodes?
- Provide a way for researchers to spin up their own compute node on NeCTAR
- Allow multiple users per compute node for workshops
- Sandbox QEMU/Xen compute nodes?
- Per-user compute nodes using QEMU/Xen on top of NecTAR VMs.
- Performance won't be pretty
Most likely #3 has the most potential to limit damage, not by preventing issues but by ensuring users can affect only those they know. It raises a variety of maintenance issues though.