There is a common security vulnerability I’ve noticed on production Docker containers, to do with the way private Github repos are handled. An environment variable called something like $GITHUB_TOKEN is injected into the container by a build server. Though the env var is only needed briefly – for a package manager to download private Github repos of library code – the env var is often left in place. The container then sits on production infrastructure, with this secret in its environment variables.
In the above diagram, a build server builds a container. The Composer PHP package manager is run, to download open source frameworks, and private Github repos containing library code. Though the $GITHUB_TOKEN environment variable is now no longer needed, it is not deleted. The container ships to production infrastructure, with a secret on it that doesn’t need to be there.
In examining the possible impact of this vulnerability, we note that the container might not be ‘important’. It could handle non-critical functionality, and the database it has access to may not contain anything sensitive (personally identifying information, etc.). However, an attacker compromising the container will gain the version control access token. They only need to be the user mentioned in the Dockerfile to do this, and may not need to have root on the production container. The attacker is now able to clone everything the token allows access to. In the real world, this is often every private Github repository belonging to an organisation, and may facilitate further exploits.