mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-25 23:11:02 +08:00
Translated by qhwdw
This commit is contained in:
qhwdw
parent
e022c33b77
commit
36de244d48
@ -1,177 +0,0 @@
|
||||
Translating by qhwdw
|
||||
# LEAST PRIVILEGE CONTAINER ORCHESTRATION
|
||||
|
||||
|
||||
The Docker platform and the container has become the standard for packaging, deploying, and managing applications. In order to coordinate running containers across multiple nodes in a cluster, a key capability is required: a container orchestrator.
|
||||
|
||||
|
||||
|
||||
Orchestrators are responsible for critical clustering and scheduling tasks, such as:
|
||||
|
||||
* Managing container scheduling and resource allocation.
|
||||
|
||||
* Support service discovery and hitless application deploys.
|
||||
|
||||
* Distribute the necessary resources that applications need to run.
|
||||
|
||||
Unfortunately, the distributed nature of orchestrators and the ephemeral nature of resources in this environment makes securing orchestrators a challenging task. In this post, we will describe in detail the less-considered—yet vital—aspect of the security model of container orchestrators, and how Docker Enterprise Edition with its built-in orchestration capability, Swarm mode, overcomes these difficulties.
|
||||
|
||||
Motivation and threat model
|
||||
============================================================
|
||||
|
||||
One of the primary objectives of Docker EE with swarm mode is to provide an orchestrator with security built-in. To achieve this goal, we developed the first container orchestrator designed with the principle of least privilege in mind.
|
||||
|
||||
In computer science,the principle of least privilege in a distributed system requires that each participant of the system must only have access to the information and resources that are necessary for its legitimate purpose. No more, no less.
|
||||
|
||||
> #### ”A process must be able to access only the information and resources that are necessary for its legitimate purpose.”
|
||||
|
||||
#### Principle of Least Privilege
|
||||
|
||||
Each node in a Docker EE swarm is assigned role: either manager or worker. These roles define a coarsegrained level of privilege to the nodes: administration and task execution, respectively. However, regardless of its role, a node has access only to the information and resources it needs to perform the necessary tasks, with cryptographically enforced guarantees. As a result, it becomes easier to secure clusters against even the most sophisticated attacker models: attackers that control the underlying communication networks or even compromised cluster nodes.
|
||||
|
||||
# Secure-by-default core
|
||||
|
||||
There is an old security maxim that states: if it doesn’t come by default, no one will use it. Docker Swarm mode takes this notion to heart, and ships with secure-by-default mechanisms to solve three of the hardest and most important aspects of the orchestration lifecycle:
|
||||
|
||||
1. Trust bootstrap and node introduction.
|
||||
|
||||
2. Node identity issuance and management.
|
||||
|
||||
3. Authenticated, Authorized, Encrypted information storage and dissemination.
|
||||
|
||||
Let’s look at each of these aspects individually
|
||||
|
||||
### Trust Bootstrap and Node Introduction
|
||||
|
||||
The first step to a secure cluster is tight control over membership and identity. Without it, administrators cannot rely on the identities of their nodes and enforce strict workload separation between nodes. This means that unauthorized nodes can’t be allowed to join the cluster, and nodes that are already part of the cluster aren’t able to change identities, suddenly pretending to be another node.
|
||||
|
||||
To address this need, nodes managed by Docker EE’s Swarm mode maintain strong, immutable identities. The desired properties are cryptographically guaranteed by using two key building-blocks:
|
||||
|
||||
1. Secure join tokens for cluster membership.
|
||||
|
||||
2. Unique identities embedded in certificates issued from a central certificate authority.
|
||||
|
||||
### Joining the Swarm
|
||||
|
||||
To join the swarm, a node needs a copy of a secure join token. The token is unique to each operational role within the cluster—there are currently two types of nodes: workers and managers. Due to this separation, a node with a copy of a worker token will not be allowed to join the cluster as a manager. The only way to get this special token is for a cluster administrator to interactively request it from the cluster’s manager through the swarm administration API.
|
||||
|
||||
The token is securely and randomly generated, but it also has a special syntax that makes leaks of this token easier to detect: a special prefix that you can easily monitor for in your logs and repositories. Fortunately, even if a leak does occur, tokens are easy to rotate, and we recommend that you rotate them often—particularly in the case where your cluster will not be scaling up for a while.
|
||||
|
||||
|
||||
|
||||
### Bootstrapping trust
|
||||
|
||||
As part of establishing its identity, a new node will ask for a new identity to be issued by any of the network managers. However, under our threat model, all communications can be intercepted by a third-party. This begs the question: how does a node know that it is talking to a legitimate manager?
|
||||
|
||||
|
||||
|
||||
Fortunately, Docker has a built-in mechanism for preventing this from happening. The join token, which the host uses to join the swarm, includes a hash of the root CA’s certificate. The host can therefore use one-way TLS and use the hash to verify that it’s joining the right swarm: if the manager presents a certificate not signed by a CA that matches the hash, the node knows not to trust it.
|
||||
|
||||
### Node identity issuance and management
|
||||
|
||||
Identities in a swarm are embedded in x509 certificates held by each individual node. In a manifestation of the least privilege principle, the certificates’ private keys are restricted strictly to the hosts where they originate. In particular, managers do not have access to private keys of any certificate but their own.
|
||||
|
||||
### Identity Issuance
|
||||
|
||||
To receive their certificates without sharing their private keys, new hosts begin by issuing a certificate signing request (CSR), which the managers then convert into a certificate. This certificate now becomes the new host’s identity, making the node a full-fledged member of the swarm!
|
||||
|
||||
####
|
||||
|
||||
|
||||
When used alongside with the secure bootstrapping mechanism, this mechanism for issuing identities to joining nodes is secure by default: all communicating parties are authenticated, authorized and no sensitive information is ever exchanged in clear-text.
|
||||
|
||||
### Identity Renewal
|
||||
|
||||
However, securely joining nodes to a swarm is only part of the story. To minimize the impact of leaked or stolen certificates and to remove the complexity of managing CRL lists, Swarm mode uses short-lived certificates for the identities. These certificates have a default expiration of three months, but can be configured to expire every hour!
|
||||
|
||||
|
||||
|
||||
This short certificate expiration time means that certificate rotation can’t be a manual process, as it usually is for most PKI systems. With swarm, all certificates are rotated automatically and in a hitless fashion. The process is simple: using a mutually authenticated TLS connection to prove ownership over a particular identity, a Swarm node generates regularly a new public/private key pair and sends the corresponding CSR to be signed, creating a completely new certificate, but maintaining the same identity.
|
||||
|
||||
### Authenticated, Authorized, Encrypted information storage and dissemination.
|
||||
|
||||
During the normal operation of a swarm, information about the tasks has to be sent to the worker nodes for execution. This includes not only information on which containers are to be executed by a node;but also, it includes all the resources that are necessary for the successful execution of that container, including sensitive secrets such as private keys, passwords, and API tokens.
|
||||
|
||||
### Transport Security
|
||||
|
||||
The fact that every node participating in a swarm is in possession of a unique identity in the form of a X509 certificate, communicating securely between nodes is trivial: nodes can use their respective certificates to establish mutually authenticated connections between one another, inheriting the confidentiality, authenticity and integrity properties of TLS.
|
||||
|
||||
|
||||
|
||||
One interesting detail about Swarm mode is the fact that it uses a push model: only managers are allowed to send information to workers—significantly reducing the surface of attack manager nodes expose to the less privileged worker nodes.
|
||||
|
||||
### Strict Workload Separation Into Security Zones
|
||||
|
||||
One of the responsibilities of manager nodes is deciding which tasks to send to each of the workers. Managers make this determination using a variety of strategies; scheduling the workloads across the swarm depending on both the unique properties of each node and each workload.
|
||||
|
||||
In Docker EE with Swarm mode, administrators have the ability of influencing these scheduling decisions by using labels that are securely attached to the individual node identities. These labels allow administrators to group nodes together into different security zones limiting the exposure of particularly sensitive workloads and any secrets related to them.
|
||||
|
||||
|
||||
|
||||
### Secure Secret Distribution
|
||||
|
||||
In addition to facilitating the identity issuance process, manager nodes have the important task of storing and distributing any resources needed by a worker. Secrets are treated like any other type of resource, and are pushed down from the manager to the worker over the secure mTLS connection.
|
||||
|
||||
|
||||
|
||||
On the hosts, Docker EE ensures that secrets are provided only to the containers they are destined for. Other containers on the same host will not have access to them. Docker exposes secrets to a container as a temporary file system, ensuring that secrets are always stored in memory and never written to disk. This method is more secure than competing alternatives, such as [storing them in environment variables][12]. Once a task completes the secret is gone forever.
|
||||
|
||||
### Storing secrets
|
||||
|
||||
On manager hosts secrets are always encrypted at rest. By default, the key that encrypts these secrets (known as the Data Encryption Key, DEK) is also stored in plaintext on disk. This makes it easy for those with minimal security requirements to start using Docker Swarm mode.
|
||||
|
||||
However, once you are running a production cluster, we recommend you enable auto-lock mode. When auto-lock mode is enabled, a newly rotated DEK is encrypted with a separate Key Encryption Key (KEK). This key is never stored on the cluster; the administrator is responsible for storing it securely and providing it when the cluster starts up. This is known as unlocking the swarm.
|
||||
|
||||
Swarm mode supports multiple managers, relying on the Raft Consensus Algorithm for fault tolerance. Secure secret storage scales seamlessly in this scenario. Each manager host has a unique disk encryption key, in addition to the shared key. Furthermore, Raft logs are encrypted on disk and are similarly unavailable without the KEK when in autolock mode.
|
||||
|
||||
### What happens when a node is compromised?
|
||||
|
||||
|
||||
|
||||
In traditional orchestrators, recovering from a compromised host is a slow and complicated process. With Swarm mode, recovery is as easy as running the docker node rm command. This removes the affected node from the cluster, and Docker will take care of the rest, namely re-balancing services and making sure other hosts know not to talk to the affected node.
|
||||
|
||||
As we have seen, thanks to least privilege orchestration, even if the attacker were still active on the host, they would be cut off from the rest of the network. The host’s certificate — its identity — is blacklisted, so the managers will not accept it as valid.
|
||||
|
||||
# Conclusion
|
||||
|
||||
Docker EE with Swarm mode ensures security by default in all key areas of orchestration:
|
||||
|
||||
* Joining the cluster. Prevents malicious nodes from joining the cluster.
|
||||
|
||||
* Organizing hosts into security zones. Prevents lateral movement by attackers.
|
||||
|
||||
* Scheduling tasks. Tasks will be issued only to designated and allowed nodes.
|
||||
|
||||
* Allocating resources. A malicious node cannot “steal” another’s workload or resources.
|
||||
|
||||
* Storing secrets. Never stored in plaintext and never written to disk on worker nodes.
|
||||
|
||||
* Communicating with the workers. Encrypted using mutually authenticated TLS.
|
||||
|
||||
As Swarm mode continues to improve, the Docker team is working to take the principle of least privilege orchestration even further. The task we are tackling is: how can systems remain secure if a manager is compromised? The roadmap is in place, with some of the features already available such as the ability of whitelisting only specific Docker images, preventing managers from executing arbitrary workloads. This is achieved quite naturally using Docker Content Trust.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://blog.docker.com/2017/10/least-privilege-container-orchestration/
|
||||
|
||||
作者：[Diogo Mónica ][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://blog.docker.com/author/diogo/
|
||||
[1]:http://www.linkedin.com/shareArticle?mini=true&url=http://dockr.ly/2yZoNdy&title=Least%20Privilege%20Container%20Orchestration&summary=The%20Docker%20platform%20and%20the%20container%20has%20become%20the%20standard%20for%20packaging,%20deploying,%20and%20managing%20applications.%20In%20order%20to%20coordinate%20running%20containers%20across%20multiple%20nodes%20in%20a%20cluster,%20a%20key%20capability%20is%20required:%20a%20container%20orchestrator.Orchestrators%20are%20responsible%20for%20critical%20clustering%20and%20scheduling%20tasks,%20such%20as:%20%20%20%20Managing%20...
|
||||
[2]:http://www.reddit.com/submit?url=http://dockr.ly/2yZoNdy&title=Least%20Privilege%20Container%20Orchestration
|
||||
[3]:https://plus.google.com/share?url=http://dockr.ly/2yZoNdy
|
||||
[4]:http://news.ycombinator.com/submitlink?u=http://dockr.ly/2yZoNdy&t=Least%20Privilege%20Container%20Orchestration
|
||||
[5]:https://blog.docker.com/author/diogo/
|
||||
[6]:https://blog.docker.com/tag/docker-orchestration/
|
||||
[7]:https://blog.docker.com/tag/docker-secrets/
|
||||
[8]:https://blog.docker.com/tag/docker-security/
|
||||
[9]:https://blog.docker.com/tag/docker-swarm/
|
||||
[10]:https://blog.docker.com/tag/least-privilege-orchestrator/
|
||||
[11]:https://blog.docker.com/tag/tls/
|
||||
[12]:https://diogomonica.com/2017/03/27/why-you-shouldnt-use-env-variables-for-secret-data/
|
||||
|
||||
|
||||
@ -0,0 +1,176 @@
|
||||
# 最小权限的容器协调器
|
||||
|
||||
|
||||
Docker 平台和容器已经成为打包、部署、和管理应用程序的标准。为了在一个集群内协调跨节点的容器，必须有一个关键的能力：一个容器协调器。
|
||||
|
||||
|
||||
|
||||
对于关键的集群化以及计划的任务，协调器是起重大作用的，比如：
|
||||
|
||||
* 管理容器计划和资源分配。
|
||||
|
||||
* 支持服务发现和无缝（hitless）应用程序部署。
|
||||
|
||||
* 分配应用程序运行必需的资源。
|
||||
|
||||
不幸的是，在这种环境下，协调器的分布式特性和资源的短暂性使得确保协调器的安全是一个极具挑战性的任务。在这篇文章中，我们将讨论容器协调器安全模型中没有考虑到的、但是很重要的方面的详细情况，以及 Docker 企业版中如何使用内置的编排性能、Swarm 模式，去克服这些问题。
|
||||
|
||||
诱因和威胁模型
|
||||
============================================================
|
||||
|
||||
使用 swarm 模式的 Docker 企业版的其中一个主要目标是提供一个内置安全特性的协调器。为达到这个目标，我们部署了第一个在我们心目中认为的最小权限原则设计的容器协调器。
|
||||
|
||||
在计算机科学中，一个分布式系统所要求的最小权限原则是，系统中的每个参与着仅仅能访问它正当目的所需要的信息和资源。不是更多，也不是更少。
|
||||
|
||||
> #### “一个进程必须仅仅能去访问它的正当目的所需要的信息和资源”
|
||||
|
||||
#### 最小权限原则
|
||||
|
||||
在一个 Docker 企业版集群中的每个节点分配的角色：既不是管理者（manager），也不是工人（worker）。这些角色为节点定义了一个很粗粒度的权限级别：管理和运行各自的任务。尽管如此，不用理会它的内置的角色，通过使用加密的方式，来保证一个节点仅仅有执行它的任务所需要的信息和资源。结果是，防止大多数的复杂的攻击者模式：攻击者控制底层通讯网络，或者甚至是攻陷的集群节点，确保集群安全变得更容易了。
|
||||
|
||||
# 内核缺省安全
|
||||
|
||||
这是一个很老的安全最大化状态：如果它不是缺省的，没有一个使用它。Docker Swarm 模式将内核缺省安全这一概念融入了内核，并且使用这一机制去解决协调器生命周期中三个很难的并且很重要的部分：
|
||||
|
||||
1. 可信引导和节点引入。
|
||||
|
||||
2. 节点身份发布和管理。
|
||||
|
||||
3. 经过认证、授权、和加密的信息存储和传播。
|
||||
|
||||
我们来分别看一下这三个部分
|
||||
|
||||
### 可信引导和节点引入
|
||||
|
||||
确保集群安全的第一步，没有别的，就是严格控制成员和身份。管理员不能依赖它们节点的身份，并且在节点之间强制实行绝对的负载隔离。这意味着，未授权的节点不能允许加入到集群中，并且，已经是集群一部分的节点不能改变身份，突然去伪装成另一个节点。
|
||||
|
||||
为解决这种情况，通过 Docker 企业版 Swarm 模式管理的节点，维护了健壮的、不可改变的身份。期望的特性是，通过使用两种关键的构建块去保证加密：
|
||||
|
||||
1. 为集群成员使用安全加入令牌。
|
||||
|
||||
2. 从一个集中化的认证机构发行的内嵌唯一身份的证书。
|
||||
|
||||
### 加入 Swarm
|
||||
|
||||
去安全加入 Swarm，需要这个节点的令牌拷贝。在集群内的每个操作角色中，令牌是独一无二的 — 那里现在有两种类型的节点：工人（workers）和管理者（managers）。由于这种分隔，拥有一个工人令牌的节点将不允许以管理者角色加入到集群。唯一的方式是通过 swarm 的管理 API，去向集群管理者请求一个特殊的令牌。
|
||||
|
||||
令牌是安全的并且是随机生成的，它也有一个使得令牌漏洞更容易去检测的特殊语法：一个可以在你的日志和仓库中很容易监视的特殊前缀。幸运的是，即便发现一个漏洞，令牌也可以很容易去更新，并且，推荐你经常去更新它们 — 特别是，在一段时间中你的集群不进行扩大的情况下。
|
||||
|
||||
|
||||
|
||||
### 引导信任
|
||||
|
||||
作为它的身份标识创建的一部分，一个新的节点将向任意一个网络管理者请求发布一个新的身份。但是，在我们下面的威胁模型中，所有的通讯可以被一个第三方拦截。这种请求存在的问题是：一个节点怎么知道与它进行对话的对方是合法的管理者？
|
||||
|
||||
|
||||
|
||||
幸运的是，Docker 有一个内置机制可以避免这种情况。加入令牌，它被主机用于加入 Swarm，包含一个根 CA 证书的哈希串。所以，主机可以使用单向 TLS，并且使用这个哈希串去验证它加入的 Swarm 是否正确：如果管理者持有的证书没有被正确的 CA 哈希串签名，节点就知道它不可信任。
|
||||
|
||||
### 节点身份发布和管理
|
||||
|
||||
在一个 Swarm 中，身份标识是内嵌在每个节点都单独持有的一个 x509 证书中。在一个最小权限原则的表现中，证书的私钥被绝对限制到主机的原始位置。尤其是，管理者不能访问除了它自己的私钥以外的任何一个私钥。
|
||||
|
||||
### 身份发布
|
||||
|
||||
去接收它们的证书而无需共享它们的私钥，新的主机通过发布一个证书签名请求（CSR）来开始，管理者收到证书签名请求之后，转换成一个证书。这个证书成为这个新的主机的身份标识，使这个节点成为 Swarm 的一个完全合格成员！
|
||||
|
||||
####
|
||||
|
||||
|
||||
当和安全引导机制一起使用时，发行身份标识的这个机制去加入节点是缺省安全的：所有的通讯部分都是经过认证的、授权的，并且非敏感信息从来都不会以明文方式进行交换。
|
||||
|
||||
### 身份标识延期
|
||||
|
||||
尽管如此，给一个 Swarm 中安全地加入节点，仅仅是 “故事” 的一部分。为降低证书的漏洞或者失窃造成的影响，并且移除管理 CRL 列表的复杂性，Swarm 模式为身份标识使用了较短存活周期的证书。这些证书缺省情况下三个月后将过期，但是，也可以配置为一个小时后即刻过期！
|
||||
|
||||
|
||||
|
||||
这个较短的证书过期时间，意味着不能手动去处理证书更新，所以，通常会使用一个 PKI 系统。对于 Swarm，所有的证书是以一种不中断的方式进行自动更新的。这个过程很简单：使用一个相互认证的 TLS 连接去证明一个特定身份标识的所有者，一个 Swarm 节点定期生成一个新的公钥/私钥密钥对并且用相关的 CSR 去签名发送，创建一个维持相同身份标识的完整的新证书。
|
||||
|
||||
### 经过认证、授权、和加密的信息存储和传播。
|
||||
|
||||
在一个正常的 Swarm 的操作中，发送到工人（worker）节点去运行的关于任务的信息。这里不仅仅包含将被一个节点运行的容器的信息；也包含那个容器运行所必需的资源的所有的信息，包括敏感的秘密，比如，私钥、密码、和 API 令牌。
|
||||
|
||||
### 传输安全
|
||||
|
||||
事实上，参与 Swarm 的每个节点都拥有一个独一无二的 X509 格式的证书，因此，节点之间的通讯安全是没有问题的：节点使用它们各自的证书，与另一个连接方进行相互认证、继承机密、真实性、和 TLS 的完整性。
|
||||
|
||||
|
||||
|
||||
关于 Swarm 模式的一个有趣的细节是，本质上它是使用了一个推送模式：仅管理者被允许去发送信息到工人们（workers）— 显著降低了暴露在低权限工人节点面前的管理者节点的攻击面。
|
||||
|
||||
### 将负载严格隔离进安全区域
|
||||
|
||||
管理者节点的其中一个责任是，去决定发送到每个工人（worker）节点的任务是什么。管理者节点使用多种策略去做这个决定；根据每个节点和每个负载的特性，去跨 Swarm 去安排负载。
|
||||
|
||||
在使用 Swarm 模式的 Docker 企业版中，管理者通过使用附加到每个单个节点标识上的安全标签，去影响这些安排决定。这些标签允许管理者将节点组与不同的安全区域连接到一起，以限制敏感负载暴露，以及使相关秘密信息更安全。
|
||||
|
||||
|
||||
|
||||
### 安全分发秘密
|
||||
|
||||
除了加快身份标识发布过程之外，管理者节点还有存储和分发工人节点所需要的任何资源的任务。像任何其它类型的资源一样处理秘密，并且基于安全的 mTLS 连接，从管理者推送到工人节点。
|
||||
|
||||
|
||||
|
||||
在主机上，Docker 企业版能确保秘密仅提供给它们指定的容器。在同一个主机上的其它容器并不能访问它们。Docker 以一个临时文件系统的方式显露秘密给一个容器，确保秘密总是保存在内存中，并且从不写入到磁盘。这种方式比其它竞争的替代者更加安全，比如，[在环境变量中存储它们][12]。一旦这个任务完成，这个秘密将永远消失。
|
||||
|
||||
### 存储秘密
|
||||
|
||||
在管理者主机上的秘密总是加密静止的。缺省情况下，加密这些秘密的密钥（被称为数据加密密钥，DEK）是以明文的方式存储在硬盘上的。这使得那些对安全性要求较低的人可以轻松地去使用 Docker Swarm 模式。
|
||||
|
||||
但是，如果你运行一个生产集群，我们推荐你启用自动锁定模式。当自动锁定模式启用后，一个重新更新过的 DEK 被一个独立的加密密钥加密（KEK）。这个密钥从不被存储在集群中；管理者有责任将它存储在一个安全可靠的地方，并且当集群启动的时候可以提供它。这就是所谓的 “解锁” Swarm。
|
||||
|
||||
根据 Raft 故障容错一致性算法，Swarm 模式支持多个管理者。在这个场景中，无缝扩展了秘密存储的安全性。每个管理者主机除了共享密钥之外 ，还有一个唯一的磁盘加密密钥。幸运的是，Raft 日志在磁盘上也是加密的，并且，在自动锁定模式下，没有 KEK 同样是不可访问的。
|
||||
|
||||
### 当一个节点被攻陷后发生了什么？
|
||||
|
||||
|
||||
|
||||
在传统的协调器中，挽回一台被攻陷的主机是一个缓慢而复杂的过程。使用 Swarm 模式，恢复它就像运行一个 Docker 节点的 rm 命令一样容易。这是从集群中删除一个受影响的节点，而 Docker 将去处理剩下的事情，即，重新均衡负载，并且确保其它的主机已经知道，而不会去与受影响的节点通讯。
|
||||
|
||||
正如我们看到的那样，感谢最小权限协调器，甚至是，如果攻击者在主机上持续活动，它们将被从剩余的网络上切断。主机的证书 — 它的身份标识 — 被列入黑名单，因此，管理者也不能有效访问它。
|
||||
|
||||
# 结论
|
||||
|
||||
使用 Swarm 模式的 Docker 企业版，在缺省情况下确保了协调器的所有关键区域的安全：
|
||||
|
||||
* 加入集群。阻止恶意节点加入到集群。
|
||||
|
||||
* 安排主机进入安全区域。阻止攻击者的横向移动。
|
||||
|
||||
* 安排任务。任务将仅被委派到允许的节点。
|
||||
|
||||
* 分配资源。恶意节点不能 “盗取” 其它的负载或者资源。
|
||||
|
||||
* 存储秘密。从不明文保存并且从不写入到工人节点的磁盘上。
|
||||
|
||||
* 与工人节点的通讯。使用相互认证的 TLS 加密。
|
||||
|
||||
因为 Swarm 模式持续提升，Docker 团队正在努力将最小权限原则进一步推进。我们正在处理的一个任务是：如果一个管理者被攻陷了，怎么去保证剩下的节点的安全？路线图已经有了，其中一些功能已经可以使用，比如，白名单功能，仅允许特定的 Docker 镜像，阻止管理者随意运行负载。这是通过 Docker 可信内容来实现的。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://blog.docker.com/2017/10/least-privilege-container-orchestration/
|
||||
|
||||
作者：[Diogo Mónica][a]
|
||||
译者：[qhwdw](https://github.com/qhwdw)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://blog.docker.com/author/diogo/
|
||||
[1]:http://www.linkedin.com/shareArticle?mini=true&url=http://dockr.ly/2yZoNdy&title=Least%20Privilege%20Container%20Orchestration&summary=The%20Docker%20platform%20and%20the%20container%20has%20become%20the%20standard%20for%20packaging,%20deploying,%20and%20managing%20applications.%20In%20order%20to%20coordinate%20running%20containers%20across%20multiple%20nodes%20in%20a%20cluster,%20a%20key%20capability%20is%20required:%20a%20container%20orchestrator.Orchestrators%20are%20responsible%20for%20critical%20clustering%20and%20scheduling%20tasks,%20such%20as:%20%20%20%20Managing%20...
|
||||
[2]:http://www.reddit.com/submit?url=http://dockr.ly/2yZoNdy&title=Least%20Privilege%20Container%20Orchestration
|
||||
[3]:https://plus.google.com/share?url=http://dockr.ly/2yZoNdy
|
||||
[4]:http://news.ycombinator.com/submitlink?u=http://dockr.ly/2yZoNdy&t=Least%20Privilege%20Container%20Orchestration
|
||||
[5]:https://blog.docker.com/author/diogo/
|
||||
[6]:https://blog.docker.com/tag/docker-orchestration/
|
||||
[7]:https://blog.docker.com/tag/docker-secrets/
|
||||
[8]:https://blog.docker.com/tag/docker-security/
|
||||
[9]:https://blog.docker.com/tag/docker-swarm/
|
||||
[10]:https://blog.docker.com/tag/least-privilege-orchestrator/
|
||||
[11]:https://blog.docker.com/tag/tls/
|
||||
[12]:https://diogomonica.com/2017/03/27/why-you-shouldnt-use-env-variables-for-secret-data/
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user