4 ms·

I just used Heroku as an example to show the architecture. FWIW, it looks like Heroku is using Kubernetes these days. It's a platform built on a platform. If y

by mfer 6y ago

I just used Heroku as an example to show the architecture. FWIW, it looks like Heroku is using Kubernetes these days. It's a platform built on a platform. If you want open platforms we can talk about cloud foundry. If a base image or buildpack has a vulnerability there is a process to update it and rebuild the containers for the running application without and app dev ever needing to know about or deal with it. This is considered a feature. The idea is to look at the architecture, concerns, and how to handle different roles with different needs at different layers of the concerns. I don't mean to hold up Heroku or Cloud Foundry as some amazing thing. Just that you can have an architecture that solves for these problems with containers.

ethbr0 6y ago
Docker's security architecture problems definitely feel like a "Closed: Working as intended" / not prioritized, rather than something they see as a core feature. And why not? They're shipping benefits (immediate productivity) and externalizing costs (eventual security breaches) onto the end user.
- mfer 6y ago
  Is the docker/container model supposed to be all things to all people? I don't think so. Containers are a building block that let us handle one concern. They are a great tool for some things. But, to expect the app dev concern of "just run my code" to be solved by them well is missing the other concern. I think Docker does some things well. I think this works as intended. I just think that we need other things that use these building blocks better to create better solutions at the right level of abstraction.
  - ethbr0 6y ago
    That feels like an abrogation of responsibility. At this point in computing system complexity, secure defaults over configuration is a requirement for a sane system. As we increasingly convert infrastructure into code, this means infrastructure configuration requires secure defaults as well. That the Docker ecosystem doesn't seem overlying concerned (as a core, drop-everything, #1 priority) about a decades-hard security problem (detecting and resolving insecure dependencies) seems shortsighted. To put it another way, there are two realities: (A) No tooling support is provided to address a risk efficiently and quickly = no one addresses the risk (B) Efficient, effective tooling is built, maintained as platform evolves, and advertised to the community = everyone does what they should I realize the structure of Docker dissuades them from actually addressing (B), but it seems like an existential threat to adoption.
    - mfer 6y ago
      > That feels like an abrogation of responsibility. How often are people who deal with OS packages working on kernel level vulnerabilities or are dealing with microcode for CPUs? If someone is working on libc or libcurl are they supposed to follow and track all of the kernel level issues for every place the code would run? I would argue that someone working on libcurl is working at a different layer in the stack than someone working on a kernel. libcurl can run on multiple kernels. The same idea of layers is true when you're talking about someone working on a nodejs app and those OS layers. > To put it another way, there are two realities: > (A) No tooling support is provided to address a risk efficiently and quickly = no one addresses the risk > (B) Efficient, effective tooling is built, maintained as platform evolves, and advertised to the community = everyone does what they should I think Kelsey Hightower said it best when he said that Kubernetes is a platform for building platforms. I would argue that container systems in general are platforms for building platforms. I know people who spend a bunch of time building a platform on top of k8s at different companies. Yet, in these conversation we keep coming back to Docker or container platforms as being the platform that app developers _should_ interact with. App devs speaking out, people like Kelsey speaking up, and security issues like this all say that maybe that _should_ is wrong.

by mfer 6y ago

ethbr0 6y ago

Docker's security architecture problems definitely feel like a "Closed: Working as intended" / not prioritized, rather than something they see as a core feature. And why not? They're shipping benefits (immediate productivity) and externalizing costs (eventual security breaches) onto the end user.

mfer 6y ago
Is the docker/container model supposed to be all things to all people? I don't think so. Containers are a building block that let us handle one concern. They are a great tool for some things. But, to expect the app dev concern of "just run my code" to be solved by them well is missing the other concern. I think Docker does some things well. I think this works as intended. I just think that we need other things that use these building blocks better to create better solutions at the right level of abstraction.
- ethbr0 6y ago
  That feels like an abrogation of responsibility. At this point in computing system complexity, secure defaults over configuration is a requirement for a sane system. As we increasingly convert infrastructure into code, this means infrastructure configuration requires secure defaults as well. That the Docker ecosystem doesn't seem overlying concerned (as a core, drop-everything, #1 priority) about a decades-hard security problem (detecting and resolving insecure dependencies) seems shortsighted. To put it another way, there are two realities: (A) No tooling support is provided to address a risk efficiently and quickly = no one addresses the risk (B) Efficient, effective tooling is built, maintained as platform evolves, and advertised to the community = everyone does what they should I realize the structure of Docker dissuades them from actually addressing (B), but it seems like an existential threat to adoption.
  - mfer 6y ago
    > That feels like an abrogation of responsibility. How often are people who deal with OS packages working on kernel level vulnerabilities or are dealing with microcode for CPUs? If someone is working on libc or libcurl are they supposed to follow and track all of the kernel level issues for every place the code would run? I would argue that someone working on libcurl is working at a different layer in the stack than someone working on a kernel. libcurl can run on multiple kernels. The same idea of layers is true when you're talking about someone working on a nodejs app and those OS layers. > To put it another way, there are two realities: > (A) No tooling support is provided to address a risk efficiently and quickly = no one addresses the risk > (B) Efficient, effective tooling is built, maintained as platform evolves, and advertised to the community = everyone does what they should I think Kelsey Hightower said it best when he said that Kubernetes is a platform for building platforms. I would argue that container systems in general are platforms for building platforms. I know people who spend a bunch of time building a platform on top of k8s at different companies. Yet, in these conversation we keep coming back to Docker or container platforms as being the platform that app developers _should_ interact with. App devs speaking out, people like Kelsey speaking up, and security issues like this all say that maybe that _should_ is wrong.