最近,我们遇到了一个Docker私有镜像拉取的错误,花费了数小时研究Docker私有仓库(Registry)凭证存储的细节才能弄清楚。尽管最终修复起来很容易,但是我们在凭据存储设计的过程中了解了一两件事,以及如何对Docker私有仓库(Registry)凭证进行安全配置。
Docker私有镜像拉取失败的情况如下:
Blimp有时需要从Docker私有仓库(Registry)中拉取私有镜像。这通常可以正常工作,但是不幸的是,有时拉取私有镜像时,会收到以下错误消息:
Get https://1234.dkr.ecr.us-east-1.amazonaws.com/v2/blimp/blimp/manifests/v0.1: no basic auth credentials
要了解我们是如何解决的,首先你需要了解Docker凭证。
Docker的外部证书存储
一般建议,存储Docker凭证要放在外部凭证存储中。通常位于~/.docker/config.json的Docker配置文件中。
企业中使用私有镜像仓库,通常都需要开启认证,认证凭据可能是用户在企业中通用的账户。但docker login以后,会在~/.docker/config.json中保存base64以后的用户名、密码,这样,在一些多人使用的服务器上,就会出现账号泄露的问题。
有没有解决方法呢?
docker提供credentials store,也就是讲密码存储到外置的credentials store中。
目前支持如下几种:
- D-Bus Secret Service: https://github.com/docker/docker-credential-helpers/releases
- Apple macOS keychain: https://github.com/docker/docker-credential-helpers/releases
- Microsoft Windows Credential Manager: https://github.com/docker/docker-credential-helpers/releases
- pass: https://github.com/docker/docker-credential-helpers/releases
对于linux服务器来说,只能选择pass,因为D-Bus需要X11支持,而Apple和Microsoft看上去就不像是给Linux准备的。
因此,为了提高Docker凭据的安全性,你可以在Docker配置文件中使用两个字段来配置Docker获取凭据和存储凭据的方式:credsStore和credHelpers。
credsStore告诉Docker使用哪个帮助程序与凭证存储(credentials store)进行交互。所有帮助程序的名称都以docker-credential-开头,credsStore的值为帮助程序名称的后缀。
如果你使用Mac笔记本电脑,则可能会使用Mac OS钥匙串。使用Mac OS钥匙串后的帮助程序的名称是docker-credential-osxkeychain。因此,你Docker配置文件config.json将包括以下内容:
{ "credsStore": "osxkeychain" }
如果要查看Docker当前为你提供的凭据是什么,可以使用list命令。例如:
docker-credential-osxkeychain list
输出信息是一对服务器和用户名列表。例如:
{ "http://quay.io":"kklin", "https://index.docker.io":"kevinklin" }
credHelpers是帮助程序( helpers ),用于生成短暂的凭据。例如,如果你使用gcr,gcloud会安装一个credHelper来使用你的Google登录名获取令牌的。采用这种方式后,Docker永远不会直接拥有你的Google凭据, docker-credential-gcloud充当Docker和Google凭据之间的中间人。
但即使我们对Docker login密码加密保存,仍然得到如下的错误消息:
Get https://1234.dkr.ecr.us-east-1.amazonaws.com/v2/blimp/blimp/manifests/v0.1: no basic auth credentials
通过上文,我们知道可以通过运行docker-credential-osxkeychain list和get命令来查看1234.dkr.ecr.us-east-1.amazonaws.com的凭据,分析判断那么为什么会收到一个错误消息-没有任何凭据(no basic auth credentials)?
Docker1.11版本前:私有仓库密码存储在配置文件中
Docker1.11版本前,Docker配置文件config.json通过auths字段来存储凭据,直到2016年1.11版本才能够使用外部凭据存储。
每当你登录私有仓库时,Docker都会将auths的值设置为你的密码。你的配置文件可能包含以下内容:
{ "auths": { "https://index.docker.io/v1/": { "auth": "YW11cmRhY2E6c3VwZXJzZWNyZXRwYXNzd29yZA==" }, "localhost:5001": { "auth": "aGVzdHVzZXI6dGVzdHBhc3N3b3Jk" } } }
因此在采用credsStore后,当你使用docker login进行登录时,你的凭据还会被存储,但其中的字段auths不包含用户名或密码。结果看起来像这样:
{ "auths": { "https://index.docker.io/v1/": {} }
但Docker拉取镜像时从auths 和 credsStore两者同时获取凭据。因此,Docker拉取镜像时会有两份凭据,一份具有正确的用户名和密码,而一份则完全没有密码。
不幸的是,Docker偏爱使用auths中的https://的凭证,并尝试使用空凭证拉取镜像。因此,会有no basic auth credentials错误。
通过上文,我们确定了问题是一个空凭证被添加到 Docker配置文件config.json 中,我们就很容易解决该问题。我们需要做的就是添加一条if语句以跳过空凭据:
具体参考: https://github.com/kelda/blimp/blob/master/cli/up/up.go
addCredentials := func(authConfigs map[string]clitypes.AuthConfig) { for host, cred := range authConfigs { // Don't add empty config sections. if cred.Username != "" || cred.Password != "" || cred.Auth != "" || cred.Email != "" || cred.IdentityToken != "" || cred.RegistryToken != "" { creds[host] = types.AuthConfig{ Username: cred.Username, Password: cred.Password, Auth: cred.Auth, Email: cred.Email, ServerAddress: cred.ServerAddress, IdentityToken: cred.IdentityToken, RegistryToken: cred.RegistryToken, } } } }
Docker凭证安全风险
很多使用Docker的组织,可能仍在使用传统的auths方法。如果是这样,你的~/.docker/config.json可能看起来像这样:
{ "auths": { "https://index.docker.io/v1/": { "auth": "YW11cmRhY2E6c3VwZXJzZWNyZXRwYXNzd29yZA==" }, "localhost:5001": { "auth": "aGVzdHVzZXI6dGVzdHBhc3N3b3Jk" } } }
这看起来很安全,密码似乎是一堆乱码。你们会想,这些密码肯定是加密的吧?
其实,Docker所做的只是使用base64对密码进行编码。正如David Rieger在Hacker Noon上指出的那样,
Base64乍一看可能看起来像加密,但事实并非如此。Base64是一种编码方案,不是加密方案。你只需复制Base64字符串,然后在几秒钟内将其转换为ASCII。
那个看似安全的密码aGVzdHVzZXI6dGVzdHBhc3N3b3Jk,读取密码所需要做的只是对base64进行解码:
$ echo aGVzdHVzZXI6dGVzdHBhc3N3b3Jk| base64 -D hestuser:testpassword
因此,如果未对Docker配置文件中的密码加密,则Docker将以纯文本格式存储你的密码。纯文本格式的好消息是,解决问题很容易,但是也容易被泄露和攻击。
为此,Docker提供了credentials store,也就是把密码存储到外置的credentials store中。
译文链接: https://dzone.com/articles/what-a-mysterious-bug-taught-us-about-how-docker-s
登录后评论
立即登录 注册