Nick Janetakis shares a few patterns he’s picked up based on using Docker since 2014 for many freelance projects. He also posted a timestamped video version on YouTube if you’d prefer to watch over reading.
Docker images can leak runtime secrets, build secrets, and even just some secret files you have lying around. Learn how to leak them, and (probably more usefully) how to avoid leaks.
WireGuard Easy uses Docker to set up WireGuard VPN along with a web UI for easy management. While this may be the easiest way to get up and running, I’d still advise checking out Algo VPN as well since it’s also pretty easy and has been designed/configured with maximum security in mind. Still, this looks cool and the web admin UI makes it quite approachable as well.
Thomas Ptacek writing on Fly’s blog:
Even though most of our users deliver software to us as Docker containers, we don’t use Docker to run them. Docker is great, but we’re high-density multitenant, and despite strides, Docker’s isolation isn’t strong enough for that. So, instead, we transmogrify container images into Firecracker micro-VMs.
This is a fun, technical read about how they’re converting Docker’s OCI images (turns out they’re just a stack of tarballs) into Firecracker VMs. It’s much simpler to accomplish than I would’ve thought! Money quote:
You’re likely of one of two mindsets about this: (1) that it’s extremely Unixy and thus excellent, or (2) that it’s extremely Unixy and thus horrifying.
Local network monitoring stack (forked from this project) that’s tailored to run on your Raspberry Pi.
Samanta de Barros:
If, like me, configuring GitHub Actions is not your thing and you find yourself wanting to try something before actually pushing it to GitHub (and having to see the effects on real-life), follow this step by step of how to run your GitHub Actions on your own computer.
Working with Docker CLI is very straightforward - you just
push containers and images, but have you ever wondered how do the internals behind this Docker interface actually work?
Behind this simple interface hides a lot of cool technologies and in this article you can learn about one of them - the union filesystem - the underlying filesystem behind all the container and image layers.
In other jobs, we’ve used docker and it’s worked out just fine (for the most part… there was that time the RedHat filesystem on our prod server got mysteriously hosed – maybe it wasn’t docker’s fault.) But no, the reason we don’t use docker is because we don’t need it. Literally. Writing golang web services and static html embedded with with golang 1.16’s new //embed directive, we end up with a single deployable binary.
As a self-sustaining startup, we have limited resources to devote to tasks. We chose golang exactly for this reason. It sure would be nice if we could spend a couple weeks building the perfect CI/CD pipeline, an elegant deployment process, along with pretty dashboards. But we have software we need to ship in order to get users in order to drive subscriptions. Anything that doesn’t directly serve that goal is a complication. So at best, docker is a complication. A 9 million LoC complication that brings its own bugs and its own idiosyncrasies.
I’m not here to tell you whether or not you should use Docker. I don’t know what you should do. What I do know, is that you (all) need to make your own decisions based on your needs.
That’s why I like this piece by the team behind MeeZee Workouts. They share their decision and why they made it. Add this to your knowledge base for your next big decision.
If you’ve ever been alarmed by how many security vulnerabilities your Docker image has, even after you’ve installed security updates, here’s what’s going on—your image may actually be fine!
BuildKit CLI is a plugin for kubectl (the Kubernetes command-line tool). The plugin extends the functionality of kubectl, allowing to build container images without a local Docker installation.
This article tells you how to use BuildKit CLI and how it will improve your inner-loop productivity flow.
At this point probably everybody has heard about Docker and most developers are familiar with it, use it, and therefore know the basics such as how to build a Docker image. It is as easy as running
docker built -t name:tag ., yet there is much more to it, especially when it comes to optimizing both the build process and the final image that is created.
The article goes on to cover caching, slimming, and securing your images so they’ll run faster and be less prone to abuse.
Container security is often overlooked topic, as people assume that containers are secure by default - which is not true. One of the ways to secure container workloads in Docker and Kubernetes is to leverage
seccomp profiles and this advanced feature of container runtimes is explained and shown in this article.
I only installed Git, Docker, and Dip on my new computer to see how productive I can be with a barebones system setup.
I hadn’t heard of Dip prior to reading this. It definitely looks like it’ll clean up your setup. 👌
This post by a community member from India shows how to use GitHub actions to build, push and deploy to OpenFaaS anywhere - whether in the cloud or on an RPi at home. The best part is that this is a fully multi-arch setup, and uses the new Docker buildx with GitHub Actions.
Avoid the hassle of following security best practices each time you need a web server or reverse proxy. Bunkerized-nginx provides generic security configs, settings and tools so you don’t need to do it yourself.
What’s not to love?
8 common security issues when using Docker and how to avoid them. Here’s a sampler:
Avoid curl bashing
Pulling stuff from internet and piping it into a shell is as bad as it could be. Unfortunately it’s a widespread solution to streamline installations of software.
The risk is the same framed for supply chain attacks and it boils down to trust. If you really have to curl bash, do it right…
The incomparable Jessica Kerr drops by with a grab-bag of amazing topics. Understanding software systems, transferring knowledge between devs, building relationships, using VS Code & Docker to code together, observability as a logical extension of TDD, and a whole lot more.
Build your own using these as a reference or simply pull them as-is from Docker Hub and
If you’re using Docker, the next natural step seems to be Kubernetes, aka K8s. Or is it? If you’re part of a small team, Kubernetes probably isn’t for you: it’s a lot of pain with very little benefits.
If you’ve been following along in the open source news cycle lately, you’ve probably heard that Red Hat has dropped the docker container runtime engine from both its Red Hat Enterprise Linux (RHEL) and CentOS Linux distributions.
I must not be following along, because that’s news to me.
That being the case, what do you do when you need to deploy containers? Fortunately, they’ve created a near drop-in replacement for docker, called Podman.
Podman is a rename from kpod, sorta. The new thing is actually called libpod, and Podman exists as the CLI for that library. It’s all a bit confusing, but what’s cool is none of this requires a daemon like the Docker Engine.
If you’d like to give it a go, this walk-through by The New Stack will get you started.
Gives you access to a virtualised ARM based Raspberry Pi machine running the Raspian operating system. This is not just a Raspian Docker image, it’s a full ARM based Raspberry Pi virtual machine environment.
How it does its thing:
A full ARM environment is created by using Docker to bootstrap a QEMU virtual machine. The Docker QEMU process virtualises a machine with a single core ARM11 CPU and 256MB RAM, just like the Raspberry Pi. The official Raspbian image is mounted and booted along with a modified QEMU compatible kernel.
DockerSlim promises a lot:
docker-slimwill optimize and secure your containers by understanding your application and what it needs using various analysis techniques. It will throw away what you don’t need reducing the attack surface for your container. What if you need some of those extra things to debug your container? You can use dedicated debugging side-car containers for that.
Their minification examples are impressive…
A new cryptojacking worm, named Graboid, has been spread into more than 2,000 Docker hosts, according to the Unit 42 researchers from Palo Alto Networks. This is the first time such a piece of malware has spread via containers within the Docker Engine (specifically docker-ce).
Scary stuff, and (at the moment) difficult to detect & prevent:
We’ve reached a point with containers where security must be constantly on the front burner. Antivirus and anti-malware applications currently have no means of analyzing and cleaning containers and container images. That’s the heart of the issue.
Graboid may be the first malware to target containers, but it certainly won’t be the last.