Docker cli login potential security issue or not? #26826

aleks-ivanov · 2021-09-23T08:29:11Z

aleks-ivanov
Sep 23, 2021

Login to DockerHub in a GiHA pipeline using the Docker CLI:

Run DOCKER_USER=*** DOCKER_USER=*** DOCKER_PASSWORD=***

echo $DOCKER_PASSWORD | docker login --username $DOCKER_USER --password-stdin shell: /usr/bin/bash -e {0} WARNING! Your password will be stored unencrypted in /home/runner/.docker/config.json. Login Succeeded

The *** represent ${{ secrets.DOCKER_USER }} and ${{ secrets.DOCKER_PASSWORD }} respectively.

So, I followed the warning, found the file and printed it in the console:

{
        "auths": {
                "https://index.docker.io/v1/": {
                        "auth": "long-string-of-random-characters"
                }
        }
}

So here I found that the password to my Dhub account was indeed encrypted by GitHub’s Secrets module and appended to this file encrypted, unlike the warning in the log indicated.

Now what I am wondering, if the password is encrypted by the Secrets module is there really a security issue with that value being appended to the config.json file, since the only way someone would have access to that file in that state is to that someone having access to my account in the first place ?

My conclusion is No., but I would like to have a second/third/Nth opinion of someone more experienced than moi.

Answered by airtower-luna

Sep 23, 2021

aleks-ivanov:

So here I found that the password to my Dhub account was indeed encrypted by GitHub’s Secrets module and appended to this file encrypted, unlike the warning in the log indicated.

That conclusion is unfortunately wrong, try base64-decoding that long-string-of-random-characters thing. 😉

If someone could get access to the runner while your credentials are in there they could use them. It’s up to you whether you consider that an unacceptable risk. It is common practice to ensure that the credentials are deleted after use, even though the GitHub-hosted runner VMs are discarded after the job.

View full answer

airtower-luna · 2021-09-23T15:22:08Z

airtower-luna
Sep 23, 2021

aleks-ivanov:

So here I found that the password to my Dhub account was indeed encrypted by GitHub’s Secrets module and appended to this file encrypted, unlike the warning in the log indicated.

That conclusion is unfortunately wrong, try base64-decoding that long-string-of-random-characters thing. 😉

If someone could get access to the runner while your credentials are in there they could use them. It’s up to you whether you consider that an unacceptable risk. It is common practice to ensure that the credentials are deleted after use, even though the GitHub-hosted runner VMs are discarded after the job.

0 replies

aleks-ivanov · 2021-09-24T06:56:18Z

aleks-ivanov
Sep 24, 2021
Author

That’s what I was unsure about, thanks for clarifying.

What are ways that someone could access the runner during execution, other than having access to my GH account ?

0 replies

airtower-luna · 2021-09-24T08:16:28Z

airtower-luna
Sep 24, 2021

If you use GitHub-hosted runners, no-one should be able to access them, assuming that:

GitHub’s security systems work as designed.
You don’t do anything in the workflow to allow outside access or exfiltrate secrets, or that has security issues that allow others to do so.

If you use self-hosted runners, it’s up to you to secure them.

0 replies

jhsu802701 · 2022-11-16T18:30:54Z

jhsu802701
Nov 16, 2022

Is there a more secure solution for allowing GitHub Workflows to push Docker images? This is basically the same solution I'm using now, and it does work. However, I'd like to switch to a better solution, and I cannot replace something with nothing.

5 replies

airtower-luna Nov 16, 2022

It depends on the registry you're pushing to. If it's ghcr.io, you can use the GITHUB_TOKEN. If the registry supports it, you could set up OpenID for authentication. In both cases you'd have short-lived tokens, which would limit damage in case someone manages to steal one.

jhsu802701 Nov 16, 2022

Yes, I'm using ghcr.io. My build.yml file is at https://github.com/rubyonracetracks/docker-debian-bullseye-min-stage1/blob/main/.github/workflows/build.yml . Is there any example of a repository that uses the more secure solution that you've suggested here? My way cuts it for getting the job done but not for doing it in the most secure manner.

airtower-luna Nov 16, 2022

You're already using the short-lived token, so there are mostly minor things you could do better:

Limit workflow permissions to what's actually needed (this is the one major thing).
Set the environment variable with the token only for the login step, not the whole job. That way steps that don't need it won't be able to access it.
Add a logout step with if: always(), to make sure the token is removed from disk before the job ends.

I've linked examples from one of my own repositories. I don't see anything in your workflow that'd need the security-events permission, so you can remove that, too. 😸

As for documentation, Automatic token authentication and Security hardening are probably the most interesting parts for your case.

jhsu802701 Nov 16, 2022

Thanks for the example. I'll make your suggested improvements, but I see from the GitHub actions that you're still getting the following warning message:

WARNING! Your password will be stored unencrypted in /home/runner/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Have you figured how to use the suggested credential helper? I wish I could see a GitHub Workflows example of this in action.

airtower-luna Nov 16, 2022

I have, but it doesn't make sense to do inside the Actions runner in my opinion. The warning is mostly meant for persistent systems, like: "Hey, the credentials will end up on disk in plain text!" On my work laptop I have set up Docker to use pass, which means the credentials get stored with PGP encryption. Technically you could do that in the Actions runner too, but you wouldn't gain anything, because then you'd need to worry about how to protect the key (or its passphrase) instead. 😅

Limiting the credential access to the steps that actually need them should be reasonably safe.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

GitHub Community

Docker cli login potential security issue or not? #26826

{{title}}

Replies: 4 comments 5 replies

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

Docker cli login potential security issue or not? #26826

Replies: 4 comments · 5 replies

aleks-ivanov Sep 24, 2021 Author

Replies: 4 comments 5 replies

aleks-ivanov
Sep 24, 2021
Author