3 ms·
Having code running in a container is still harder to exploit than just having full ssh access to the boxes? I am not a security expert by any means, and this
by friendly_chap 10y ago
Having code running in a container is still harder to exploit than just having full ssh access to the boxes?
I am not a security expert by any means, and this workflow was not created with security as a priority in any means, but the latter still rubs me in a worse way. It might be just an ignorant hunch though.
- geggam 10y agohttps://benchmarks.cisecurity.org/tools2/docker/CIS_Docker_1.6_Benchmark_v1.0.0.pdf https://benchmarks.cisecurity.org/tools2/docker/CIS_Docker_1...
- alsadi 10y agoYou might as well drop privileges and tell the kernel to disallow any future privileges even with sudo/su or vulnerabilities. You can do this by using oneway in your docker entry point https://github.com/muayyad-alsadi/oneway/blob/master/README.md https://github.com/muayyad-alsadi/oneway/blob/master/README....
- friendly_chap 10y agoThat's something really interesting, and it comes handy for a side project I have, but I don't think it fixes the problem with people hijacking the docker repo - they will just change the Dockerfile itself, right?
- alsadi 10y agoYes I agree. There are some things you can do for example you can have client certificates, only trusted clients can talk to your ci, and onlt trusted clients can push images. Only dev with ssh keys can push code. Your ci and registry are locked down (a container). All that might help.