3 ms·

> The cool part about FROM scratch images is that you'll never have to update your base image to address CVEs. Only your software and its (compiled) dependencie

by xmodem 3mo ago

> The cool part about FROM scratch images is that you'll never have to update your base image to address CVEs. Only your software and its (compiled) dependencies. What's the benefit really, though? If you still need to be able to rapidly deploy a new image in response to a dependency CVE, what have you gained?

regularfry 3mo ago
You've gained that happening much less frequently. The tradeoff is making every other problem harder to diagnose.
- NewJazz 3mo ago
  Debug containers are a thing. Add an ephemeral container to an already running pod, for example to add debugging utilities without restarting the pod. https://kubernetes.io/docs/reference/kubectl/generated/kubectl_debug/ https://kubernetes.io/docs/reference/kubectl/generated/kubec...
  - xmodem 3mo ago
    Yup! They are a good solution to the massive problem you caused for yourself by implementing a different "solution" to a non-problem. And even that's only true if you assume kubernetes is the only place your container runs where you might want to also debug it.
    - NewJazz 3mo ago
      You want to ship every debug utility you will need in every image? Just seems wasteful. What about 3rd party images, you will respin images just to add your preferred toolset?
      - xmodem 3mo ago
        Nope, not my position at all. I want to have a minimal OS environment with rudimentary tools available with zero extra friction. FROM alpine:latest adds less than 10MB and covers 95% of use cases. Typically depending on the container I will often throw in curl and some other QoL tools too. For the rare cases where you find yourself needing to attach a debugger to your pods running in staging/prod, a debug container is absolutely the right tool to reach for.
      - xp84 3mo ago
        > every debug utility you will need in every image? Just seems wasteful How wasteful though? I have to admit, I envy the person whose codebase itself they have to support is so lean and space-conservative that the size of the gnu coreutils, curl, nano, etc., would show up as anything but a rounding error in the image size. I see it like putting a thermometer in a turkey before I stick it in the oven. Sure, the thermometer adds thermal mass itself, making the turkey take a few seconds longer to cook, but the value of it being there is greater than the cost imposed.
OptionOfT 3mo ago
If the base image I use is based on Debian, it comes with more than 15 binaries that I don't use. But when Docker scans my image and notices that there is a CVE in one of those binaries, my image is currently out of compliance. FROM scratch just reduces the surface.
- xmodem 3mo ago
  > FROM scratch just reduces the surface. The actual attack surface of your application? Or the attack surface of you and your team's attention from a busybody security org. It's important not to confuse the two.
  - fc417fc802 3mo ago
    Both. Many attacks take the form of an exploit to get a shell, then using available utilities to exploit the kernel to escape to the host. If your image has neither a shell nor utilities that won't get very far.
    - xmodem 3mo ago
      What percentage of CVEs can be used to obtain a shell, but can't otherwise be used to obtain some other form of code execution in a distro-less container?
      - fc417fc802 3mo ago
        I haven't run any stats and am certainly not an expert but I would expect quite a few. In the one scenario you merely need to pull off an exec with a valid path. In the other you need to either write a block of memory and mark it as executable or else write your payload out to disk and mark the file executable. So it's the difference between being able to pull off a single syscall versus most likely needing arbitrary code execution.
  - monkpit 3mo ago
    Important to whom?

by xmodem 3mo ago

regularfry 3mo ago

You've gained that happening much less frequently. The tradeoff is making every other problem harder to diagnose.

NewJazz 3mo ago
Debug containers are a thing. Add an ephemeral container to an already running pod, for example to add debugging utilities without restarting the pod. https://kubernetes.io/docs/reference/kubectl/generated/kubectl_debug/ https://kubernetes.io/docs/reference/kubectl/generated/kubec...
- xmodem 3mo ago
  Yup! They are a good solution to the massive problem you caused for yourself by implementing a different "solution" to a non-problem. And even that's only true if you assume kubernetes is the only place your container runs where you might want to also debug it.
  - NewJazz 3mo ago
    You want to ship every debug utility you will need in every image? Just seems wasteful. What about 3rd party images, you will respin images just to add your preferred toolset?
    - xmodem 3mo ago
      Nope, not my position at all. I want to have a minimal OS environment with rudimentary tools available with zero extra friction. FROM alpine:latest adds less than 10MB and covers 95% of use cases. Typically depending on the container I will often throw in curl and some other QoL tools too. For the rare cases where you find yourself needing to attach a debugger to your pods running in staging/prod, a debug container is absolutely the right tool to reach for.
    - xp84 3mo ago
      > every debug utility you will need in every image? Just seems wasteful How wasteful though? I have to admit, I envy the person whose codebase itself they have to support is so lean and space-conservative that the size of the gnu coreutils, curl, nano, etc., would show up as anything but a rounding error in the image size. I see it like putting a thermometer in a turkey before I stick it in the oven. Sure, the thermometer adds thermal mass itself, making the turkey take a few seconds longer to cook, but the value of it being there is greater than the cost imposed.

OptionOfT 3mo ago

If the base image I use is based on Debian, it comes with more than 15 binaries that I don't use. But when Docker scans my image and notices that there is a CVE in one of those binaries, my image is currently out of compliance. FROM scratch just reduces the surface.

xmodem 3mo ago
> FROM scratch just reduces the surface. The actual attack surface of your application? Or the attack surface of you and your team's attention from a busybody security org. It's important not to confuse the two.
- fc417fc802 3mo ago
  Both. Many attacks take the form of an exploit to get a shell, then using available utilities to exploit the kernel to escape to the host. If your image has neither a shell nor utilities that won't get very far.
  - xmodem 3mo ago
    What percentage of CVEs can be used to obtain a shell, but can't otherwise be used to obtain some other form of code execution in a distro-less container?
    - fc417fc802 3mo ago
      I haven't run any stats and am certainly not an expert but I would expect quite a few. In the one scenario you merely need to pull off an exec with a valid path. In the other you need to either write a block of memory and mark it as executable or else write your payload out to disk and mark the file executable. So it's the difference between being able to pull off a single syscall versus most likely needing arbitrary code execution.
- monkpit 3mo ago
  Important to whom?