Remove APT cache (for Dockerfile)

remove_apt_cache

apt-get clean autoclean
apt-get autoremove --yes
rm -rf /var/lib/{apt,dpkg,cache,log}/

Permanently making apt non-functional is actually a very desirable goal, CIS 4.x guidelines would dictate this for security reasons. In a proper container deployment environment you would never need to run apt again after the Docker image was built, you would redo the docker image and repush that image itself.

In fact, it is often needed to be able to install new binaries on an instance when something is going wrong and you need to debug things.

it is insecure
ideally you wouldn't have root on your container anyways, so you won't be able to do apt thingies anyways

@redthor, I think @JimmyChatz point still stands for docker though; if you rm -rf /var/lib/{apt,dpkg,cache,log}/ and make it impossible to use apt after that point, you are preventing anyone from using your image as a base image and making modifications with apt.

If you making a conscious decision to do that in exchange for 200 bytes and provide documentation warning people about this, it's probably fine. I, however, think that 200 bytes vs ruining the image's ability to be a base image is a bad tradeoff.

Also, apt-get clean is the superset of apt-get autoclean, so you only need to run clean. As per the docs (emphasis mine): https://linux.die.net/man/8/apt-get

clean
Clears out the local repository of retrieved package files. It removes everything but the lock file from /var/cache/apt/archives/ and /var/cache/apt/archives/partial/.
autoclean
Like clean, autoclean clears out the local repository of retrieved package files. The difference is that it only removes package files that can no longer be downloaded, and are largely useless. This allows a cache to be maintained over a long period of time without it growing out of control. The configuration option APT::Clean-Installed will prevent installed packages from being erased if it is set to off.

making apt unusable is for security reasons. If someone were to ssh into the pod they wouldnt be able to install malicious packages or even install ftp, sftp or scp and transfer secrets, certs or files from the code inside the docker to their remote server.

If someone were to ssh into the pod they wouldnt be able to install malicious packages

Uh?

1. If you have an SSH server on your container, remove your SSH server ASAP. It is not needed to enter inside. That is a FAQ.

2. If an un-trusted user is able to enter in your container as root, your container is TOTALLY COMPROMISED. NUKE IT ASAP.

3. Destabilizing APT to make an "un-trusted root user" more hampered, so that they cannot use "APT", is really a nonsense, since I do not know even one root kracker that uses "APT" to download "malicious software". A malicious root software is directly executed in other low-level ways, like opening a TCP tunnel to a resource, and piping the response to a shell. Trust me, a root cracker will not run "apt install supertuxkart-yeah-malicious" or similar since it leaves too many traces.

If you remove the apt lists and make apt unusable, you might as well remove apt entirely RUN apt remove apt --autoremove -y --allow-remove-essential to save 10Mb

Hi guys, simple question: what's the meaning of && rm -rf /var/lib/apt/lists/* given by the docker doc, and should I do it in my Dockerfile?

Anyone who is coming to this gist to remove apt-cache in their docker images; I recommend you to install dive tool and check which directories consume more space in your image. For me; /var/lib folder itself was 53MB, where I could have saved a bunch of MBs on other directories.

A tool for exploring each layer in a docker image
https://github.com/wagoodman/dive

A tool for exploring each layer in a docker image https://github.com/wagoodman/dive

@leiless Thanks for introducing that. really nice.

Hi guys, simple question: what's the meaning of && rm -rf /var/lib/apt/lists/* given by the docker doc, and should I do it in my Dockerfile?

@ZYinMD ubuntu:22.04 image had it empty and it increased even if I did apt-get clean. removing it would not harm anything.

@valerio-bozzolan

1. If you have an SSH server on your container, remove your SSH server ASAP. It is not needed to enter inside. That is a FAQ.

There are a number of containers that require allow ssh ingress to the container for legitimate reasons - gitea, gitlab, ssh tunnel deployments, etc

I think the better way to word what you're trying to say is:

If you need to access the shell within the container or execute arbitrary commands inside the container and can remote in to the host, it is advised that you run docker exec -it <container-name> <shell command> (example: docker exec -it traefik sh) from the host rather than install an SSH server in the container.