New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Example about how to securely login through Docker CLI #96
Comments
Azure has published an action that does a secure docker login https://github.com/Azure/k8s-actions/tree/master/docker-login |
@chrispat, thanks for the reference! Unfortunately, the action provided by Azure is at least as bad as using 'docker login' directly, if not worse. The point is that docker login explicitly warns the user about the configuration being stored unencrypted. Azure, however, does not show any warning, despite the underlying storage mechanism being the almost the same. Please, bear with me:
let authenticationToken = new Buffer(`${username}:${password}`).toString('base64');
let config = { "auths": { [loginServer]: { auth: authenticationToken } } };
...
fs.writeFileSync(dockerConfigPath, JSON.stringify(config));
command_1.issueCommand('set-env', { name: 'DOCKER_CONFIG' }, dirPath); Therefore, the only practical difference is that Azure stores the config file in Furthermore, this was brought by @TingluoHuang a week ago (see Azure/container-actions#3). |
Beyond making sure the docker config is cleaned up after the job I am not sure there are any other options that will work in an automated sceanrio. In the end the docker client needs to be able to read the credential in order to pull and push containers. Even if the credential was stored in a credstore that would need to be accessible by the user the docker process is running under so you would have the same potential security issue you have today. I suppose you could have actions that handle pull and push for you that take the crednetial and then use a cred helper that reads from the environment. However, then simple things like docker build or docker run just pulling the image would be more difficult. |
I think that a safer procedure is not to write any sensible unencrypted data to disk, in first place. It is compulsory to clean up after the job is done, of course. But there are four possible contexts with different places to clean up:
Currently, only 1 seems to be possible with GitHub/Azure Actions.
Yes. Precisely, credential stores allow to hold encrypted data in memory and only provide it to the authorized user/service/tool that has the corresponding key. And credential helpers allow the docker client to be able to read from credential stores.
I am not sure I understand this. I'd say the the risk of any unauthorized user to read some raw data that has been written to disk (either while it is being used or after it was expectedly removed from a
or
Ref: https://github.com/docker/docker-credential-helpers/blob/master/ci/before_script_linux.sh |
Ref docker/cli#2089 |
Hey, thanks for your answer @chrispat . I think that @eine raises a valid point though. IMHO this is still an unresolved security issue so if you could please revisit it, it'd be appreciated. Thanks. Your link (https://github.com/Azure/k8s-actions/blob/master/docker-login/src/login.ts) points to an archived repo. Its deprecation notice points to another archived repo (https://github.com/Azure/container-actions), and that repo in turn points to https://github.com/Azure/actions. The last repo seems Azure-specific and cannot readily be used to do a So, something along the lines of the following?
|
Docker has not released their own build and push action would is the "curated" action for this scenario. However, given the Actions VMs only live for the length of the job and then are deleted I am still not following how your suggestions make things more secure. Even using a credstore helper like I think the issue linked above @eine is interesting as it points at the fact that different registries can be configured with different types of authentication. I think the best option would be if we could find a way to get registries to support something like OIDC with a JWT as Vault does https://www.vaultproject.io/docs/auth/jwt. In that case if we had a JWT that said which repo and branch the job was running on the registry could just use that as the auth and you would have no long standing tokens. |
I agree that the official Docker action would be the way to go for now (although it also stores the password unencrypted in /github/home/.docker/config.json by default) and that shorter-lived tokens would be preferable. |
Ref: docker/build-push-action#227 |
This issue has become stale and will be closed automatically within a period of time. Sorry about that. |
Currently, using
echo "$DOCKER_PASS" | docker login -u "$DOCKER_USER" --password-stdin
produces a warning:Please, provide an example workflow, step or action that allows to securely login through Docker CLI.
The text was updated successfully, but these errors were encountered: