I would be more interested in knowing what share of the top 10k or so docker images have critical vulnerabilities.
The vast majority of those 4M docker images are stale and probably never pulled anymore.
For example I probably have a good 100-200 public docker images on my account, virtually all of them will have critical vulnerabilities as I don't maintain them. Those are images I used for past personal projects, or testing something quickly, demo projects, iterating quickly on something etc.
As soon as I am done with them, I forget about them and will never invest the time to maintain them, probably no one will ever pull them either (why would you pull an undocumented `randomuser/test-ml-my-shitty-project:latest` image?) I suspect a huge share of the 4M docker images analysed fall in that category.
Since I started looking at images I've seen a lot of issues.
Artifact Hub (which lets you find Helm charts, OLM operators, etc) will show scan details when it has enough information. If we look at the operators (and these are available in openshift today and considered curated by Red Hat) we can see a lot of operators with images that have issues... https://artifacthub.io/packages/search?page=1&ts_query_web=d...
I know this doesn't directly deal with Docker Hub but does highlight the cultural problem with addressing security.
Lots of Ds and Fs in that list you linked. It says that it's the Community Operator that put it out there, so I'm kind of scared that a base image from people who should know is so insecure.
Just remember, this is not limited to official images, and it's not weighted in any way based on usage/downloads. So a crypto image that's pushed and never downloaded has equal weight with the ubuntu:18.04 image
which is not a vulnerability or malicious if people are looking for that
didn’t realize crypto ignorance was still that pervasive and discriminatory
I can see “potentially harmful” to a place the image was deployed on without authorization or against terms of use, or if the image contained a miner and didnt tell the user.
Yes, I think if you offer e.g. auditing of all containers a company runs flagging even above-board crypto miners as "potentially harmful" is fair (I doubt very many companies intentionally deploy those parallel to other workloads, and if they do it's easily cleared), but otherwise it would make sense to differentiate between them and maliciously hidden ones.
I hate the "hacking tools" category. I can't have a copy of netcat on my work machine because it gets flagged as a "hacking tool" and automatically deleted.
Every few months I get a new tool blacklisted and purged from my work machine. So far I've lost netcat, telnet, nmap, process hacker, several packers, cheatengine, and a few other re tools. And probably more that I haven't noticed yet. My favorite category is "program manipulator/riskware"
Can you build from source? This is often enough to get around automatic detection and/or will be in you're whitelisted development folder. It is also often not against any company policy that would get you in trouble.
This is terrible, terrible advice and it's going to get someone fired. I got fired for similar behavior back in 2016. If your company's device policy is preventing you from doing your work, talk to your manager, talk about the work on your plate and the way in which the device policy is slowing you down, make sure your manager understands in concrete terms how this affects your estimates, and then -- either you'll come to a solution, or you'll have to deal with a device policy that slows you down, or you can line up a job elsewhere and resign. Unilaterally breaking the device policy will get you fired, which is a lot more stressful than resigning on a date of your choosing.
I'll add that if you're doing work on managed hardware, you really want IT to be your friends, and this is not a good way to accomplish that. Certainly talk to them too about the impact the device policy is having on you, but don't treat them as the source of your problems, treat them as colleagues who are themselves under various regulatory/policy restrictions and who may be able to help you.
> talk to your manager, talk about the work on your plate and the way in which the device policy is slowing you down, make sure your manager understands in concrete terms how this affects your estimates,
Maybe if you’ve got a sympathetic manager. Otherwise you might just get a reputation as a whiny trouble maker.
No shit, a mechanism to bake pinned shared libs into a static archive to counter version dependencies on Ubuntu/Debian vs RedHat Linuxen grows stale, fossilized images? Who would've thought!
As much as I love Docker for development, going all-in on containers for prod was a huge mistake. Which is becoming clearer now that RedHat pulls free CentOS images, after taking the so-called Linux community further and further away from POSIX and other portability means with systemd, namespaces, oci, and whatnot.
Docker images should be treated the same way as you'd treat any library you use or any package you create.
Do you think Java .jars in Maven repos or .NET .dlls in Nuget are faring any better?
Find solid dependencies, don't use too many of them, make sure you update them, use static analysis tools and dependency scanners, etc. Same drill as for anything.
>Find solid dependencies, don't use too many of them, make sure you update them, use static analysis tools and dependency scanners, etc. Same drill as for anything.
That's hilarious simply because most heavy Docker users I've interacted with basically use it as a way to build houses of cards which glue-sticked piles and piles of dependencies together rapidly.
This is largely because application complexity in some domains and expectations of development pace have ballooned to insanity but there are plenty of heavy Docker users that do this even when these sort of pressures don't exist.
I think as software progresses and more development techniques become easier to leverage and automated (correctly and incorrectly), we're getting to a point advanced statistical software packages have been at for quite some time: no matter what data you throw at the software for analysis and what analysis you choose, the software has so much experience baked into it that you'll get some result that makes assumptions what you're doing is valid that may look like reasonable outputs even if they aren't. If you do need to do some preprocessing, much of that is even automated so it's incredibly easy to do something very wrong if you dont know what you're doing but not realize it. Automation has made it much easier to fail late instead of fail early.
The trouble is finding balance between simple DIY implementations or cobbling together a house of cards.
"Allow CRUD of names" ok, you'll have it next sprint.
"Allow upload of their resumé docs" no problem, two more weeks.
"Parse the docx and PDF files users upload and extract the contents and fill our db schema with relevant data". Well shit. The specs to understand either of those formats are gigantic and now I'm forced to cobble together something using more dependencies if you want it done in less than two year's time.
Is it really that troublesome to strike a balance between implementing something yourself and using a library when the difference is two weeks versus two years?
If, for example, a file format is really complex, it has most likely one implementation that almost everyone uses. If there is a problem with it, you will hear about it. Use that.
On the other hand, if a file format is really simple or you only need a simple subset of it, rolling your own could avoid you getting 0-dayed when the most popular implementation has a vulnerability.
Of course, who could rule out that a crappy little domain-specific parser turns into a trillion dollar industry? One should let that remote possibility guide the decision making at all times.
Hum... Docker automatically adds an entire OS as static dependency to anything. How does that goes with "not using too many dependencies" rule?
Also, good luck doing static analysis on binary tools.
There's an entire area of work people call "ops" that specializes on managing that dependency. But they can only do that if it's dynamic and loosely coupled.
Docker doesn’t add anything as a dependency, you do. Use “FROM scratch” if you want to run a process with nothing but the Linux kernel. You won’t even get libc.
Realistically a lot of Java apps are shipped as fat JARs that do in fact include the (Java) world.
Hot-patching apps to use newer versions of JARs because of security bugs, outside of the update stream of the actual app itself, is not really a good idea due to the risk of regressions. Docker has basically codified the failure of dynamic linking in the real world.
I think it was Kelsey Hightower who said that Kubernetes is a platform for building platforms.
Unfortunately, we've gotten very caught up with the boring infra parts (the containers and the orchestration of k8s). We too often forget about the other platform we should build that uses these tools.
People don't complain about mass security holes in Heroku. That's long been container based. That's an example of building a platform that enables keeping on top of security issues.
This isn't a problem of the tools we have. It's a problem because of how we use them and what we build with them.
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.
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.
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.
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.
> 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.
> As much as I love Docker for development, going all-in on containers for prod was a huge mistake.
Containers are a great deployment mechanism for production. Unfortunately a lot of people seem to think that they are a substitute for package management. This was obviously (and I do mean very clearly obvious in advance from first principles¹, no hindsight needed) going to become a disaster. Most people just do not care - they are either completely unaware of the problem, or they know that in a few years' time they will either have changed jobs or be promoted (in no small part thanks to their "Docker thought leadership") and it will no longer be their problem (and they would still get to claim "Docker thought leadership" success on their résumés).
¹ Also from experience - VMware came out with "virtual appliances" in the mid-2000s that promised to do a lot of what Docker would later be used for.
I don't interpret "pulling free CentOS images" as being the same thing as "pulling investment in CentOS" in a thread specifically about docker images.
Existing docker images are still there, future images will continue being pushed (but only for CentOS Stream post-2021), and UBI exists for minor releases of RHEL which is supposed to be identical to CentOS anyways.
And considering the fact that Docker containers don't use the kernel provided by the client OS, the difference between CentOS and CentOS Stream is even smaller than it already was. The most significant changes between minor releases of RHEL / CentOS are in the kernel.
It has it's uses though. For example I used to work at a startup where this super finicky NodeJS script was written by a junior dev that ended up being the main deployment script for client build-outs on one of their products. Fast forward a few years, the old CEO contacts me because he still has a few clients using the platform and has no way of running the script. He pays me to try to get it to run on his machine -- I get it working on Ubuntu but will not run on his Mac because the Mac is no longer supported by whatever weird packages the junior dev was using. Long story short, Docker to the rescue -- now he has a baked-in image that will run that script forever.
I only remember too well the pain of having to migrate from a legacy VM to a new one, having to figuring out all the software that was installed over the years. Docket is no magical bullet, but much better than managing VM. In our company we regularly force rebuilds of Dockets to ensure we pick up the latest changes
There are indeed other ways to manage the fresh install process. Not sure they result in less critical vulnerabilities overall. It is all too easy to never update ancient versions of installations, especially as server maintenance is often handled by a separate team.
You have all of that inside the container, too: apt-get upgrade doesn’t magically stop working because it’s in a Dockerfile. The difference is that you have a trivial way to confirm deployments and be confident that there isn’t other mutable state preventing an upgrade.
If you base your container on Debian/Ubuntu, that is. And is at odds with the principle of only packing what's actually needed. If you base all your images on Debian/Ubuntu anyway, then what's the point of containers? If there's a vulnerability, you'd have to upgrade all of them anyway and they're living now as binary images on your build host instead of a versioned O/S.
All containers give you a guaranteed build process and proof that mutable state is only stored in well-known locations. That’s a huge advantage over full servers right there as any experienced Unix admin will tell you.
If you’re using a container based on an OS, you are installing far, far less and having only one process running. That again is a huge savings: no time securing postfix and cron, etc.
Another big advantage is that you’re shifting this work from the deployment time to build time. You do it once and can test it as long as you want before deploying it to production - no more failures because Red Hat’s mirror is unavailable or malfunctioning during your prod update window.
A lot of this discussion seems to revolve around running java inside containers without explicitly saying so. Running the JVM brings along a whole host of dependencies which is typically resolved by running a full blown base OS image. It is still desirable by many teams due to past issues with maintaining the JVM on VM or metal hosts.
Exactly, I know a few places that have years old installs of linux that never get updates... same thing.
nothing in docker prevents updates, just people in general are poor about doing maintenance, this is a story that is old as computers, and why MS forced updates on everyone because left to their own most people choose to "postpone" them indefinitely for fear of breaking things
> everyone because left to their own most people choose to "postpone" them indefinitely for fear of breaking things
It sure would be helpful if the updates didn't actually break things. It's usually not the security fixes that do that—stuff rarely breaks on LTSC, or in Debian point releases—it's all the other changes that get rolled in.
There's just too much churn across the industry. Even if the changes are good, too little thought is given to the cost of change itself.
This seems like intentionally misunderstanding a technology in order to make an inflammatory headline. Docker images are versioned, just like any distribution mechanism. Go through indexes for any package mechanism and count how many of the old packages have vulnerabilities. It will be a lot, because old software has vulnerabilities. That's why you update your packages, and why you update your Docker images.
I had the same initial reaction but after digging into their report, they only analyse `latest` tag of all images:
> By default, Prevasio Analyzer first attempts to find the “latest” tag of a container image. If the “latest” tag is missing, it picks up the last tag enlisted in the JSON file
So it's 51% of the "up to date" docker images that have critical vulnerabilities.
`latest` is applied to the most recent image built without an explicit tag (or one explicitly tagged as `latest`); it does not necessarily mean that image is the most "up to date" in any sense. For example, you could have a very old `latest` image, which was built before many explicitly tagged images.
Whoever came up with this heuristic probably did not really understand `latest`. To be fair, though, it is a fairly misleading and confusing "feature".
I've seen headlines like this before, but at the time a lot of the vulnerabilities were in packages that were installed on the image but were not launched, or generally not exposed. I do wish for an easy way to frequently update images though (i.e. rebuilding them from scratch installing the latest packages). It's often hard to determine what you're including in your container.
A container is not a VM and should ONLY contain the exact files needed to run your app to run securely. Any additional packages increase the security footprint.
Every container is one RCE vulnerability away from being compromised and escaped. if your images are distribution based, even slim ones, you’re giving the attacker a broad set of tooling out of the box.
Container runtime defaults in Docker and Kubernetes are insecure and grant attackers a lot of privilege — running as UID 0, no user namespace separation, and potentially dangerous kernel capabilities added to the container’s parent process.
The problem is adding ONLY the exact files needed is currently impossible when building docker containers. If you are building go/rust executables this easy, you will get one executable you'll add. But if you need to pull in some dependency by a package manager you are lost, they will pull in so many dependencies you may not need but are not defined optional by the packages. A small container is really impossible.
There are ways, but they aren't particularly obvious and are more work than they should. With some elbow grease involving multi-step builds, snapshots and diffing the resulting images to copy only the required files into your final image, you can definitely build them, at least.
It isn't made particular easy for you. Honestly it's actually kind of a pain, wherein lies the problem. Doesn't help that some languages' official images are kind of bloated themselves, either.
Is diffing images really necessary? I've done multi step builds in the past for a Java app and I didn't find it especially hard to only include what was required. E.g. the final resultant image would exclude maven, which would be used in the first stage of the build.
If you copy over files directly built by your build steps, sure, you don't really need diffing images, you know where things are. If you're trying to build a minimal image with some specific dependencies copied over that are the result of things you have less control over diffing is pretty much the only way to figure out what you need IME. E.g. you want to copy only the parts of dependencies you actually need.
Multi Step Images will not help if you want to build a python container and the package manager will pull in e.b. Bash for the python runtime snd many more depencies. It only saves you from adding build tools to the image.
Just on a slight tangent, what are the security benefits of having a process run as a non-root user within a Docker container? It's obvious what the benefits are when running outside a container. Inside a container, on the other hand, there should only really be one important process running. That process will need to have access to all the interesting parts of the file system anyway, and being root inside a container doesn't let you do crazy superuser stuff like installing a kernel module.
If you don’t at least drop the sys_module cap, you can install a kernel module [0]. Running as root inside the container increases the risk of a breakout. I’ve seen different approaches at different companies. One bank required a hard-to-get security sign off that included MFA to start (so no automation). A different bank bought expensive monitoring tools and then threw a bunch of money at refining the outputs.
Linux namespaces are quite flexible and aren't used just for docker style containerization. In some use cases having a shared user namespace makes sense.
Docker just doesn't use the provided interface by default.
Which is a shame because a lot of users don't bother or don't know they should bother to configure it.
I think that's kind of a 'we don't care about security' move by docker and given its userbase that's a real problem.
Hmm, i come from a Solaris/BSD background, Jailing (or containerize) a application was all about security, second manageability, and third re-usability. Kind of crazy that Docker ignored the most important thing in the Container-Concept (which can be, run un-trusted code on your trusted platform.)
Docker really is a power tool for developers, especially for freelancers needing to hop customer environments on their own notebook, and excels at that. The problem is the leap of pushing this guerilla tactics into running containers in prod. It's a result of the "move fast and break shit", web-scale, startup, and other agile narrative of the 2010s. And the industry has sure catered for these consumerisation of IT, with outlandish complexity in k8s, depressing oligopolization, and younger developers demanding such technologies to pad their resumes.
Exactly, many of these reports are of the kind "your java Web app container has a priv esc vuln in sudo" which is irrelevant 95% of the time. Need some smart tooling to help comb through all that noise.
I don't second that. If the java web app also has some privilege escalation, this allows somebody to overtake not only the container as root, but, given how Docker works, also to overtake the docker host as root!
Security matters, even if it is apparently about unused parts in a complex system.
Of course "if": That's how security works. The most trivial mistakes are still made in 2020, such as SQL injections. Many people write horribly insecure code, because they were never trained on a security-oriented focus.
Story Time: At a customer I've once seen all (web) applications in their docker containerr running with root permissions. I raised an issue but the devops told me this would be fine. They simply did not care about security.
They run all their containers on two rented VPS. They dockerized everything, also their mail infrastructure, etc.. This means: If anybody found the easiest remote code execution bug in their webpages, they immediately could take over the whole fucking company. Because root in docker = root on the whole machine. Think about that twice.
For that I reason, I typically create my Docker images using Nix. This has been discussed here before a couple of times, for instance at https://news.ycombinator.com/item?id=22295102. :-)
Was looking into this yesterday as I have a bunch of containers running on my media server. Found this tool: https://github.com/aquasecurity/trivy which allows you to easily scan your images for vulns. Anyone have other recs?
Nice. I like the (shortest) output of this one better. And as opposed to trivy, it was able to detect the packages (and 1 vuln) in ghcr.io/linuxserver/swag.
51% feels surprisingly low to me. If I have had to guess before hand, I would have certainly bet on "more than 80%", because of abandoned projects, legacy minor versions, and the fact that even recent images lag behind recent vulnerabilities.
> By default, Prevasio Analyzer first attempts to find the “latest” tag of a container image. If the “latest” tag is missing, it picks up the last tag enlisted in the JSON file
Having an extensive background in *nix and network systems through the 90s and early 2000s, image maintenance is the main reason I have avoided docker until recently (just not having time to investigate). One major reason to pay an OS vendor (e.g. RHEL) is to "outsource" security and systems-integration testing, so that ops people can simply "update" (the entire dep-tree of the distribution). I don't want to bring all that effort in-house, especially if I'm still paying for a vendor service contract. That said, I agree security and deployment can be eased by any form of "container" (in numerous OSes) because ops people can black-box the software while managing resource allocation, etc.
How are people handling container maintenance?
For example, I could imagine modifying SRPM spec files to also build a container (possibly even statically linked binaries inside). Then I can vendor update, and rebuild all the containers I need from SRPM; not much more complicated than `rpmbuild postgressql`, and re-deploy the emitted postgres container.
Almost all my apps get deployed to Heroku, both professionally and side projects and I opt to use the Heroku Stack instead of deploying my own docker image on Heroku. Even though I use docker locally.
One of the main reasons is that Heroku's "Stack" is updated monthly (sometimes more frequently if there are security issues). You don't get this when you deploy docker to Heroku.
The double-edged sword here is that you can get hit by their stack retirement policies. Cedar-14 was killed this year, and Heroku-16 is gone next year.
For better or for worse, Docker images will continue to run.
I deal with this, but they do let you know far ahead of time, and they don't seem to stop existing dynos from running even after a stack is retired. So I now just get a nice, clear message on one long running application I haven't taken the time to update (or more likely, wind down.)
"This app is still using the cedar-14 stack, for which the end-of life window has closed as of November 2nd, 2020. The cedar-14 stack will no longer receive security updates and builds will be disabled for apps running on the cedar-14 stack."
One day they'll have to shutdown old dynos... Either because it's no longer compatible with their systems, or because there is some wormable vulnerability...
I mean, this is true in the same way it's true that some day you'll have to shutdown old images running on docker though. I'm just trying to point out that it's not like they are quick to shut down working processes, and even weell after they EOLed an old bit of tech, and nagged me to update it for over a year, it's not stopped working yet.
The details about the actively malicious ones in there seem a lot more interesting actually. The "X% have some outdated code somewhere, we didn't test if its actually used" reports on the other hand seem to be required yearly publishing for any security company doing anything with containers...
the rest of that 51% had vulnerabilities of some sort.
now, while I understand the value of these analysis tools, I dislike these hyperbole they put around them.
why?
many of those vulnerabilities might be in the base image that is not actually actively used. now, this isn't great, a point of docker is to limit your base environment, but people do take fatter based images in order to make their life easier.
Lets take an example, imagine you have a base image with curl installed. the application actually never uses curl or libcurl itself, but the version of curl installed has a cve against it (perhaps even a critical one). is this a "good" situation. Not really, but the application itself as provided by the docker image isn't really vulnerable in practice as it doesn't use curl.
But, all these vulnerability scanning tools have no way to determine if curl is used or not, so they just scream "security vulnerability". Where a more nuanced take would be, the application probably isn't vulnerable due to curl being installed, but it probably be better to create a leaner image.
I am so glad we don't play around in traffic with containerization bullshit. The opportunity for side channels is profound, the abstraction is leaky, and the amount of engineering effort is non-trivial.
About 5 years ago we decided to take a path less-traveled with regard to applications development and deployment. We decided that our application is humble enough to run entirely on 1 powerful server. Sqlite is more than enough for our persistence needs. We don't need a huge orchestration of machines to get the job done. Instead, we decided to use self-contained deployments of .NET Core applications with all required dependencies embedded. This means we can email a zip file to a customer, they can extract it to any fresh windows/Linux vm, and then our code bootstraps the entire show.
All of our dependencies (the ones we are legally accountable for) are easily tracked in this approach. Introspection of msbuild dependencies is far easier than understanding the full extent of a docker image's vendor scope.
> The opportunity for side channels is profound, the abstraction is leaky, and the amount of engineering effort is non-trivial.
So you instead created, from scratch, a way to run all of your stuff directly on the host with absolutely no isolation? Indeed, you have eliminated side channels - by making them main channels!
> So you instead created, from scratch, a way to run all of your stuff directly on the host with absolutely no isolation?
I like how we are able to frame basic application development like its somehow insecure by default and only with the blessing of containerization technology can it be made secure.
If your application has serious side channel considerations, you should be running it on a dedicated host (with or without hypervisor/containers/et. al.). This is precisely what all of our clients do when hosting our application in their environments.
Docker does not magically protect your application from others running on the same physical machine. The marketing materials may present it in this light, but there are foundational security considerations with running 2+ applications on the same physical CPU that go way deeper than OS-level containerization primitives.
This is why I wish docker had a way to be more self-contained.
Like a first class way to start with
FROM scratch
and a way to configure it to pull only from a local, private registry.
It seems docker (the company) has actively worked against this. The redhat versions allow configuring a private registry, but they don't worry about pissing off docker.
What's wrong with "FROM scratch"? As in, if you do not want the dependency resolution, file system layout and backported fixes a distribution gives you - what do you want "FROM scratch" to do? Docker already provides an init - is there something else missing? Libc perhaps?
I'm saying docker hub is hardcoded. Sort of like google devices hardcode 8.8.8.8.
I think they should allow people to configure docker to be local, and allow some safer or maybe less promiscuous ways to use it (and it also goes around the ubuntu firewall)
It turns out this is actually possible, but not using the genuine Docker CE or EE version.
You can either use Red Hat's fork of docker with the "--add-registry" flag or you can build docker from source yourself with registry/config.go modified to use your own hard-coded default registry namespace
That is about changing the default config, so that if you put a non fully qualified name it might choose a different registry from Docker Hub. You can always pull a fully qualified name on any version of Docker. Red Hat just wanted their install to pull from a different registry if you did "docker run ubuntu" which is kind of confusing for users. You can always just do docker run mydomain.com/ubuntu or whatever on any version.
Perhaps there is space in the market for a product to detect vulnerabilities in Docker images? Pull the image, create container, poll software installed and check for vulnerabilities in installed software.
I'm just a web dev, so it's far beyond my skill set, and it could be out there already.
Bonus if it's pluggable into CI/CD systems, I guess it'd be practically useless if it wasn't.
Are these critical vulnerabilities exploitable? If I run npm audit on some of my projects I get critical vulnerabilities on a package that Webpack is using during the build phase.
Another interesting section is the paragraph about dynamic payloads, I can see Go Lang or Deno builds requesting modules from arbitrary urls being a security issue.
My imagination tells me to be with tool which are inside of Linux already ... or some very well tested tool like Nginx and limit CI/CD with Github as they seems will stay in business till the end of my life ...
I dont want to be the part of someone else ecosystem. I just want to self-sufficient, self-hosted and secure. Is it too much to wish?
There are vendors in this space already like Black Duck who already have significant traction, Docker would have its work cut out especially considering its reputation for security already.
Static linking is static linking. Whether it's C, Go, or Docker, in the end, the problem is the same: once vulnerable, that very binary/image is always vulnerable-
Immutability of the deployed container, yes. But the base images still need to be updated as needed (and then used to replace the currently running versions).
That doesn't mean anything. If base images still need to be updated it's no different to traditional app deployment. If you deploy without containers, the program you've deployed is "immutable" in the sense that running apt-get upgrade won't change it (assuming no new version of the app itself of course). Only the dependencies will change.
Does this help? My understanding is that would give you a reproducible way to get the same vulnerable versions, rather than an artifact with the vulnerable versions
Shocker.. A lot of people I know who are using docker images, just follow old tutorials and are not sure what they are doing, nor know what docker itself is. This is the old trope of copy pasta.
Who cares? Most of these images are going to be used once, or never, or they're going to launch, run some CI tests and then be immediately thrown away.
That is not a wise attitude towards information security and vulnerabilities, and in many ways unacceptable. No security is stronger than it's weakest link...
Those who are concerned with their application code are often not all that concerned with the platform it's running in. They just want to run their code.
Containers mixes the concerns. We now ask those concerned with application code to be concerned with the platform they're running in. To do this takes away time and energy invested in their application.
So, it's no surprise they don't put much time in to it.
The days of letting people who are concerned with the platform be concerned with this are gone in this season. We now overload the app dev with more stuff to be concerned with.
I disagree, somewhat. Even at the highest application level developers should be concerned about their runtime dependencies. The bigger issues, imho, is that (docker at least) doesn’t make it easy to separate build vs runtime dependencies in any systematic way, and makes it very difficult to build minimal runtime images while providing access to developer tools during development. Bazel and Spring both have ways to address this, but they require knowledge of + _n_ tools on top of the native build too chain.
If I hear what you're saying right... you're saying that someone working in node.js should be concerned with the vulnerabilities in system libraries of the OS that node.js runs in.
Bringing up Bazel to deal with system dependencies is going down the road of DevOps rather than Dev. Docker is pitched as Dev. A lot of them don't care about the lower level ops.
There is something to be said for separation of concerns and targeting each concern well. Our current problems are because we're doing a poor job mixing concerns or even understanding the separation.
No, I’m saying for a node.js developer all of their dependencies affect how their applications work. If they can get away with a statically linked node binary and no other libraries, great!
In the past you had developers who worked on their app code and ops people who are concerned with where it runs.
Now, we're moving a bunch of that ops work over to be work of the app dev. That means more context switching and knowledge outside the area of most concern. All while companies what increased velocity.
Why should developers always be concerned with the platform details?
If the developers should be concerned with the platform should ops also now need to be intimately concerned with the details of the apps? How much less time could they do on ops if they have to know all about the apps?
The timeframe in which there was such a thing as an "Ops engineer" is so brief it could be considered a fad, owing to the complexity of the solutions to deploy software that arose then.
> Why should developers always be concerned with the platform details?
Every platform has constraints. Do you have effectively unlimited memory, unlimited storage, unlimited bandwidth, zero latency and infinitely scalable CPU available for the process(es) you are responsible for? Can you be sure that given system call is available and behaves exactly the same everywhere?
Of course not. If you were to act as if these things were true at all times, you would create something with sub-par performance and reliability, eventually driving up the cost of deployments to impossible levels.
> The timeframe in which there was such a thing as an "Ops engineer" is so brief it could be considered a fad
I've been working in software since I was a kid. I remember working for an ISP in the dialup days. I saw the separation of roles between those concerned with the platform and those concerned with the running applications even back then.
To call it a brief fad, I think, misses a lot of what's happened in the market and the different roles with their different concerns.
> Every platform has constraints.
We live in a world where you have a platform built on a platform. To a node.js or PHP developer you'll have people thinking of those as the platforms. They aren't thinking about Ubuntu, CentOS, Windows, or the other lower level systems.
This is why a JS dev will code something up on a Mac and then run it on Linux in production. node.js is the platform for them.
But, with containers we're also asking them to make the Linux distro with all the things related to that as part of their platform. Not to just make it work but keep up on security. This is the wrong level in the stack for them. If they put a bunch of time into being concerned with that it will slow their velocity on the node.js work and be a big context switch (along with different knowledge in this context).
It looks like I see a bunch of Ops/DevOps people saying that app devs should be concerned with their stuff in addition or in displacement to their own. That's not happening well for a reason.
The vast majority of those 4M docker images are stale and probably never pulled anymore.
For example I probably have a good 100-200 public docker images on my account, virtually all of them will have critical vulnerabilities as I don't maintain them. Those are images I used for past personal projects, or testing something quickly, demo projects, iterating quickly on something etc. As soon as I am done with them, I forget about them and will never invest the time to maintain them, probably no one will ever pull them either (why would you pull an undocumented `randomuser/test-ml-my-shitty-project:latest` image?) I suspect a huge share of the 4M docker images analysed fall in that category.