complete translation and make it standard format

This commit is contained in:
魑魅魍魉 2017-12-17 22:13:19 +08:00 committed by GitHub
parent 3932b5e0bc
commit e59f4a2664
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -1,4 +1,4 @@
Dockers Secrets 管理介绍
=========================
@ -6,9 +6,9 @@ Dockers Secrets 管理介绍
![Docker Security](https://i2.wp.com/blog.docker.com/wp-content/uploads/e12387a1-ab21-4942-8760-5b1677bc656d-1.jpg?w=1140&ssl=1)
构建更安全的应用程序的一个关键因素是与其他应用程序和系统进行安全通信这通常需要证书、tokens、密码和其他类型的验证信息凭证 —— 通常称为应用程序 涉密数据。我们很高兴可以推出Docker 涉密数据一个容器的原生解决方案它是加强容器安全的可信赖交付组件用户可以在容器平台上直接集成涉密数据secret 分发功能。
构建更安全的应用程序的一个关键因素是与其他应用程序和系统进行安全通信这通常需要证书、tokens、密码和其他类型的验证信息凭证 —— 通常称为应用程序 涉密数据。我们很高兴可以推出 Docker 涉密数据一个容器的原生解决方案它是加强容器安全的可信赖交付组件用户可以在容器平台上直接集成涉密数据secret 分发功能。
有了容器现在应用程序在多环境下是动态的、可移植的。这使得现存的涉密数据secret 分发的解决方案略显不足因为它们都是针对静态环境。不幸的是这导致了应用程序涉密数据secrets应用不善管理的增加使得不安全的本地解决方案变得十分普遍比如像GitHub嵌入涉密数据secrets到版本控制系统或者在这之后考虑了其他同样不好的解决方案。
有了容器现在应用程序在多环境下是动态的、可移植的。这使得现存的涉密数据secret 分发的解决方案略显不足因为它们都是针对静态环境。不幸的是这导致了应用程序涉密数据secrets应用不善管理的增加使得不安全的本地解决方案变得十分普遍比如像 GitHub 嵌入涉密数据secrets到版本控制系统或者在这之后考虑了其他同样不好的解决方案。
### Docker 涉密数据Secrets 管理介绍
@ -26,17 +26,17 @@ Dockers Secrets 管理介绍
$ echo "This is a secret" | docker secret create my_secret_data -
```
一旦,涉密数据到达一个管理节点,它将被保存到内部的 Raft 存储区中该存储区使用NACL 开源加密库中的Salsa20Poly1305加密算生成的256 位密钥加密。以确保没有任何数据被永久写入未加密的磁盘。向内部存储写入涉密数据,给予了涉密数据跟其他集群数据一样的高可用性。
一旦,涉密数据到达一个管理节点,它将被保存到内部的 Raft 存储区中,该存储区使用 NACL 开源加密库中的Salsa20Poly1305加密算生成的256位密钥加密。以确保没有任何数据被永久写入未加密的磁盘。向内部存储写入涉密数据给予了涉密数据跟其他集群数据一样的高可用性。
当集群管理器启动的时,包含 涉密数据 的被加密过的 Raft 日志通过每一个节点唯一的数据密钥进行解密。此密钥以及用于与集群其余部分通信的节点的 TLS 证书可以使用一个集群范围的加密密钥进行加密。该密钥称为“解锁密钥”也使用Raft进行传播将且会在管理器启动的时候被使用。
当集群管理器启动的时,包含 涉密数据 的被加密过的 Raft 日志通过每一个节点唯一的数据密钥进行解密。此密钥以及用于与集群其余部分通信的节点的 TLS 证书可以使用一个集群范围的加密密钥进行加密。该密钥称为“解锁密钥”,也使用 Raft 进行传播,将且会在管理器启动的时候被使用。
当授予新创建或运行的服务权限访问某个涉密数据时其中一个管理器节点只有管理人员可以访问被存储的所有涉密数据将已建立的TLS连接分发给正在运行特定服务的节点。这意味着节点自己不能请求涉密数据并且只有在管理员提供给他们的时候才能访问这些涉密数据 —— 严格地控制请求 涉密数据 的服务。
当授予新创建或运行的服务权限访问某个涉密数据时,其中一个管理器节点(只有管理人员可以访问被存储的所有涉密数据),将已建立的 TLS 连接分发给正在运行特定服务的节点。这意味着节点自己不能请求涉密数据,并且只有在管理员提供给他们的时候才能访问这些涉密数据 —— 严格地控制请求涉密数据的服务。
```
$ docker service  create --name="redis" --secret="my_secret_data" redis:alpine
```
未加密的涉密数据被挂载到一个容器,该容器位于 /run/secrets/<secret_name> 的内存文件系统中。
未加密的涉密数据被挂载到一个容器,该容器位于 `/run/secrets/<secret_name>` 的内存文件系统中。
```
$ docker exec $(docker ps --filter name=redis -q) ls -l /run/secrets
@ -54,7 +54,7 @@ $ docker exec -it $(docker ps --filter name=redis -q) cat /run/secrets/my_secret
cat: can't open '/run/secrets/my_secret_data': No such file or directory
```
查看Docker sercet文档以获取更多信息和示例了解如何创建和管理您的涉密数据。同时特别推荐Docker 安全合作团 Laurens Van Houtven (https://www.lvh.io/) 和使这一特性成为现实的团队。
查看 Docker secret 文档以获取更多信息和示例,了解如何创建和管理您的涉密数据。同时,特别推荐 Docker 安全合作团 Laurens Van Houtven (https://www.lvh.io/) 和使这一特性成为现实的团队。
[Get safer apps for dev and ops w/ new #Docker secrets management][5]
@ -65,7 +65,7 @@ cat: can't open '/run/secrets/my_secret_data': No such file or directory
### 通过 Docker 更安全地使用应用程序
Docker 涉密数据旨在让开发人员和IT运营团队轻松使用以用于构建和运行更安全的应用程序。它是是首个被设计为既能保持涉密数据安全又能仅在当被需要涉密数据操作的确切容器需要的使用的容器结构。从使用Docker Compose定义应用程序和涉密数据到 IT 管理人员直接在Docker Datacenter中部署Compose文件、涉密数据涉密数据networks 和卷 volumes 都将加密、安全地跟应用程序一起传输。
Docker 涉密数据旨在让开发人员和IT运营团队可以轻松使用以用于构建和运行更安全的应用程序。它是是首个被设计为既能保持涉密数据安全又能仅在当被需要涉密数据操作的确切容器需要的使用的容器结构。从使用Docker Compose定义应用程序和涉密数据到 IT 管理人员直接在 Docker Datacenter 中部署 Compose 文件、涉密数据涉密数据networks 和卷 volumes 都将加密、安全地跟应用程序一起传输。
更多相关学习资源: