Study about konnectors isolation solutions #308
Conversation
Codecov Report
@@ Coverage Diff @@
## master #308 +/- ##
==========================================
+ Coverage 72.75% 72.88% +0.13%
==========================================
Files 74 74
Lines 5891 5890 -1
==========================================
+ Hits 4286 4293 +7
+ Misses 1098 1094 -4
+ Partials 507 503 -4
Continue to review full report at Codecov.
|
docs/konnectors.md
Outdated
|
|
||
| ### NsJail | ||
|
|
||
| NsJail is a lightweight process isolation tool, making use of Linux namespaces and seccomp-bpf syscall filters. It is not a container tool like docker. Its features are quiet extensive regarding isolation. The [README](https://github.com/google/nsjail) gives the full list of options available. Although available in the google github, it is not an official google tool. |
There was a problem hiding this comment.
s/quiet/quite/
s/options available/available options/
docs/konnectors.md
Outdated
|
|
||
| NsJail is: | ||
|
|
||
| - easy to install : juste a make away with standard build tools |
| Rkt is : | ||
| - easy to install : debian, rpm package available, archlinux community package : https://github.com/coreos/rkt/releases | ||
| - has network isolation like docker | ||
| - offers CPU, memory limitation, seccomp isolation (but the set of rules to use is out of my understanding) |
There was a problem hiding this comment.
Is it possible to customize the set of seccomp rules?
There was a problem hiding this comment.
Yes, directly in the creation of the image, or by patching it afterwards or at runtime with cli option to the run command. More detailed info : https://coreos.com/rkt/docs/latest/seccomp-guide.html
|
|
||
| I managed to run a nodejs container with just the following commands : | ||
|
|
||
| rkt run --insecure-options=image --interactive docker:https://node:slim --name nodeslim -- -v |
There was a problem hiding this comment.
Can a non-root user launch rkt run?
There was a problem hiding this comment.
Yes, if they belong to the rkt group. I will add the information in the document
docs/konnectors.md
Outdated
|
|
||
| ### Choice | ||
|
|
||
| The best choice would be Rkt for it's ease of use (which is good for contribution) and wide range of isolation features + access to the big docker echosystem without beeing a burden for the host administrator. |
docs/konnectors.md
Outdated
| rkt export --app=nodeslim `cat uuid` nodeslim.aci && rm uuid | ||
|
|
||
|
|
||
| The node:slim image weights 84M at this time. The node:alpine image also exists and is way lighter (19M) but I had problems with DNS with this, which could be solved with more time. |
There was a problem hiding this comment.
Alpine is not a good idea. It uses a libc that is not the glibc, and it has some nasty side effects: it introduces some bugs that are difficult to track.
cc: @aeris for more on this subject
There was a problem hiding this comment.
Ok, I will add this information about alpine
docs/konnectors.md
Outdated
|
|
||
| This script can be run like this : | ||
|
|
||
| ./rkt.sh mynewkonnector.js COZY_STACK_CREDENTIALS |
There was a problem hiding this comment.
The credentials must be passed in env variables, not on the command-line. Else, they appear on ps aux and can be easily stolen by another user on the server.
There was a problem hiding this comment.
We should also give the URL of the cozy instance to the konnector.
There was a problem hiding this comment.
Ok, will update the script
docs/konnectors.md
Outdated
| If the mynewkonnector.js file is available in the container_dir_template directory. | ||
|
|
||
| Pros : no breach regarding localhost network, more secure | ||
| Cons: a file communication protocol with the stack need to be defined (any other idea ?), it may be more difficult to migrate the existing connectors. |
There was a problem hiding this comment.
I'm not sure to understand this part. The cozy-syack has a REST API for files, and the konnectors will use it the same way they will use the REST API for data.
There was a problem hiding this comment.
Ok, I was just trying to propose a solution to more completely isolate the konnectors. If the konnectors must use the REST-API, then the second solution is the only one. I will remove the first solution.
docs/konnectors.md
Outdated
| Cons : must forbid acces to port 5984 and 6060 + SMTP server | ||
|
|
||
| For both solutions, the limitation of time, CPU and memory will avoid most DOS attacks (to my knowledge). For memory use, I still don't see a way to prevent the excessive use of swap from the container. | ||
| To prevent the connectors from listening to each other, they should be run one by one in their own container and not at the same time. |
There was a problem hiding this comment.
Does it mean that we can't parallelize the konnectors by running several containers at the same time? If yes, it's a very serious inconvenient.
There was a problem hiding this comment.
No, we can absolutely run many containers at the same time. But in that case, they could spy other konnectors to get some credentials, except if the other connectors use https.
To much detail, not enough. Remarks are welcome!