4 ms·

I don't know that much about the state of container systems these days, but to me it seems it's the "comfortable" way in the "security vs comfort" tradeoff. Use

by _def 7y ago

I don't know that much about the state of container systems these days, but to me it seems it's the "comfortable" way in the "security vs comfort" tradeoff. Use where applicable and hope for better days.

ThreeFx 7y ago
But there are some environments where security is (almost) the only relevant factor, e.g. banking IT-infrastructure. I don't want my bank to pull arbitrary images from Dockerhub because that increases their comfort. Conversely, if I were sysadmin at a bank I would most definitely be concerned what was running in my network.
- buzzkillington 7y ago
  >Conversely, if I were sysadmin at a bank I would most definitely be concerned what was running in my network. I've worked at a bank. It's a docker file. Running Hadoop. On top of a Linux Container. Running in Rhel 5. On top of a vmware hypervisor.
- ownagefool 7y ago
  In 2015 I was running docker containers for a Gov organisation, where: - docker containers were built from source - Dockerfile published with the code - Built in a new CI environment - Pushed, Pulled and deployed from the sha - Collecting network traffic, undertaking protective monitoring, that looks for those backdoors. Just because you can pull arbitrary bullshit doesn't mean you have to. Though for the record, the same sysadmins that whine about newer tools are generally the same ones that implicitly trust their older toolsets. Just because you can compile it, doesn't make it secure, so you need to be running monitoring solutions and hedging your bets no matter the tech.
arberavdullahu 7y ago
I don't think you should put security at any case in tradeoff, by your argument one can save passwords in plaintext because its easy and comfortable, but its just not acceptable and this would effect not only your app but every app that your users use.
- ThreeFx 7y ago
  I see the value when running e.g. home instrastructure on some old laptops or other non-critical stuff. Most people have NAT at home and thus whatever services they pull and listen in their local network aren't exposed to the outside world, and they can enjoy mopidy/NextCloud/whatever without going through a lot of hassle setting it up. Of course once we come to enterprise environments the opaque build/deployment process is atrocious.
  - BlueTemplar 7y ago
    30% of the Internet already uses IPv6. NAT is obsolete and was never supposed to be used for security anyway...
- contravariant 7y ago
  If you don't make a tradeoff you end up with passwords to long to remember and security to cumbersome to not circumvent. Security has a cost, as does the lack of it, hence the trade-off.
- x3n0ph3n3 7y ago
  The trade-off is always between security and accessibility. If you want a completely secure computer, bury it at the bottom of a mineshift and pour a few yards of concrete over it. No one is breaking into that anytime soon!
- geocar 7y ago
  This is not "the tradeoff", but too easily a straw man because bcrypt (et al) cost so very little as to effectively cost nothing at all. Think about your server consuming resources: It needs a [machine] password stored someplace in order to authenticate itself to those resources. If it stores this encrypted, then an operator must be present to decrypt it when (re)starting the server. If this is stored unencrypted, then it is not and the server can be started unattended (or autoscaled or whatever). That is a security tradeoff because there are both real benefits and risks gained and lost with each approach. If docker was ever a tradeoff, it was between taking the time to have a thoughtful architecture versus trying to get acquired, and I think we know which way they went.

by _def 7y ago

ThreeFx 7y ago

But there are some environments where security is (almost) the only relevant factor, e.g. banking IT-infrastructure. I don't want my bank to pull arbitrary images from Dockerhub because that increases their comfort. Conversely, if I were sysadmin at a bank I would most definitely be concerned what was running in my network.

buzzkillington 7y ago
>Conversely, if I were sysadmin at a bank I would most definitely be concerned what was running in my network. I've worked at a bank. It's a docker file. Running Hadoop. On top of a Linux Container. Running in Rhel 5. On top of a vmware hypervisor.
ownagefool 7y ago
In 2015 I was running docker containers for a Gov organisation, where: - docker containers were built from source - Dockerfile published with the code - Built in a new CI environment - Pushed, Pulled and deployed from the sha - Collecting network traffic, undertaking protective monitoring, that looks for those backdoors. Just because you can pull arbitrary bullshit doesn't mean you have to. Though for the record, the same sysadmins that whine about newer tools are generally the same ones that implicitly trust their older toolsets. Just because you can compile it, doesn't make it secure, so you need to be running monitoring solutions and hedging your bets no matter the tech.

arberavdullahu 7y ago

I don't think you should put security at any case in tradeoff, by your argument one can save passwords in plaintext because its easy and comfortable, but its just not acceptable and this would effect not only your app but every app that your users use.

ThreeFx 7y ago
I see the value when running e.g. home instrastructure on some old laptops or other non-critical stuff. Most people have NAT at home and thus whatever services they pull and listen in their local network aren't exposed to the outside world, and they can enjoy mopidy/NextCloud/whatever without going through a lot of hassle setting it up. Of course once we come to enterprise environments the opaque build/deployment process is atrocious.
- BlueTemplar 7y ago
  30% of the Internet already uses IPv6. NAT is obsolete and was never supposed to be used for security anyway...
contravariant 7y ago
If you don't make a tradeoff you end up with passwords to long to remember and security to cumbersome to not circumvent. Security has a cost, as does the lack of it, hence the trade-off.
x3n0ph3n3 7y ago
The trade-off is always between security and accessibility. If you want a completely secure computer, bury it at the bottom of a mineshift and pour a few yards of concrete over it. No one is breaking into that anytime soon!
geocar 7y ago
This is not "the tradeoff", but too easily a straw man because bcrypt (et al) cost so very little as to effectively cost nothing at all. Think about your server consuming resources: It needs a [machine] password stored someplace in order to authenticate itself to those resources. If it stores this encrypted, then an operator must be present to decrypt it when (re)starting the server. If this is stored unencrypted, then it is not and the server can be started unattended (or autoscaled or whatever). That is a security tradeoff because there are both real benefits and risks gained and lost with each approach. If docker was ever a tradeoff, it was between taking the time to have a thoughtful architecture versus trying to get acquired, and I think we know which way they went.