容器正在改变我们对应用程序和基础设施的看法。无论容器内的代码量是大还是小，容器架构都会引起代码如何与硬件相互作用方式的改变 —— 它从根本上将其从基础设施中抽象出来。对于容器安全来说，在 Docker 中，容器的安全性有三个关键组成部分，它们相互作用构成本质上更安全的应用程序。
构建更安全的应用程序的一个关键因素是与系统和其他应用程序进行安全通信，这通常需要证书、令牌、密码和其他类型的验证信息凭证 —— 通常称为应用程序涉密信息secrets。我们很高兴可以推出 Docker Secrets，这是一个容器原生的解决方案，它是加强容器安全的可信赖交付Trusted Delivery组件，用户可以在容器平台上直接集成涉密信息分发功能。
有了容器，现在应用程序是动态的，可以跨越多种环境移植。这使得现存的涉密信息分发的解决方案略显不足，因为它们都是针对静态环境。不幸的是，这导致了应用程序涉密信息管理不善的增加，在不安全的、土造的方案中（如将涉密信息嵌入到 GitHub 这样的版本控制系统或者同样糟糕的其它方案），这种情况十分常见。
Docker 涉密信息管理介绍根本上我们认为，如果有一个标准的接口来访问涉密信息，应用程序就更安全了。任何好的解决方案也必须遵循安全性实践，例如在传输的过程中，对涉密信息进行加密；在不用的时候也对涉密数据进行加密；防止涉密信息在应用最终使用时被无意泄露；并严格遵守最低权限原则，即应用程序只能访问所需的涉密信息，不能多也不能不少。
通过将涉密信息整合到 Docker 编排，我们能够在遵循这些确切的原则下为涉密信息的管理问题提供一种解决方案。
下图提供了一个高层次视图，并展示了 Docker swarm 模式体系架构是如何将一种新类型的对象 —— 一个涉密信息对象，安全地传递给我们的容器。
Docker Secrets Management
在 Docker 中，涉密信息是任意的数据块，比如密码、SSH 密钥、TLS 凭证，或者任何其他本质上敏感的数据。当你将一个涉密信息加入 swarm 集群（通过执行 docker secret create ）时，利用在引导新集群时自动创建的内置证书颁发机构，Docker 通过相互认证的 TLS 连接将密钥发送给 swarm 集群管理器。
$ echo"This is a secret"| docker secret create my_secret_data -
一旦，涉密信息到达某个管理节点，它将被保存到内部的 Raft 存储区中。该存储区使用 NACL 开源加密库中的 Salsa20、Poly1305 加密算法生成的 256 位密钥进行加密，以确保从来不会把任何涉密信息数据写入未加密的磁盘。将涉密信息写入到内部存储，赋予了涉密信息跟其它 swarm 集群数据一样的高可用性。
当 swarm 集群管理器启动时，包含涉密信息的加密 Raft 日志通过每一个节点独有的数据密钥进行解密。此密钥以及用于与集群其余部分通信的节点 TLS 证书可以使用一个集群级的加密密钥进行加密。该密钥称为“解锁密钥”，也使用 Raft 进行传递，将且会在管理器启动的时候使用。
当授予新创建或运行的服务权限访问某个涉密信息权限时，其中一个管理器节点（只有管理器可以访问被存储的所有涉密信息）会通过已经建立的 TLS 连接将其分发给正在运行特定服务的节点。这意味着节点自己不能请求涉密信息，并且只有在管理器提供给他们的时候才能访问这些涉密信息 —— 严格地控制请求涉密信息的服务。
$ docker service create --name="redis"--secret="my_secret_data" redis:alpine
未加密的涉密信息被挂载到一个容器，该容器位于 /run/secrets/<secret_name> 的内存文件系统中。
$ docker exec $(docker ps--filter name=redis -q)ls-l /run/secrets
total 4
-r--r--r-- 1 root root 17Dec1322:48 my_secret_data