最近，我们遇到了一个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
