5 ms·

We use CircleCI, and since all our environments are on a VPN we opted for a pull based solution instead of CircleCI notifying/pushing anything to our servers.

We use CircleCI, and since all our environments are on a VPN we opted for a pull based solution instead of CircleCI notifying/pushing anything to our servers. The way it works, Circle pushes the containers built to Google Container Registry and there is a super simple tool I built (https://github.com/crufter/puller https://github.com/crufter/puller) pulls those images. This introduces a couple of minutes of delay but we find that acceptable. I guess we are still exposed to the possibility of someone breaking into Circle, using the keys there to push to our GCR repos, but at least they won't have full access to our servers...

mhluongo 10y ago
What's the difference, if they can initiate a pull to load whatever code they want onto your server?
- 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 ago
    https://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 ago
    You 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 ago
      That'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 ago
        Yes 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.

mhluongo 10y ago

What's the difference, if they can initiate a pull to load whatever code they want onto your server?

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 ago
  https://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 ago
  You 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 ago
    That'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 ago
      Yes 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.