From 36f512a3d31a51c4d14e07d41561ef4751f14307 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Petazzoni?= Date: Fri, 29 Sep 2017 23:35:52 +0200 Subject: [PATCH] Backport content from DOD MSP --- docs/index.html | 198 ++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 184 insertions(+), 14 deletions(-) diff --git a/docs/index.html b/docs/index.html index c1498aea..580b7008 100644 --- a/docs/index.html +++ b/docs/index.html @@ -778,6 +778,10 @@ class: extra-details (instead of e.g. IP address or FQDN) +- Network aliases are automatically namespaced + + (i.e. you can have multiple apps declaring and using a service named `database`) + --- ## Example in `worker/worker.py` @@ -1207,18 +1211,6 @@ Scaling out - It is a plumbing part of the Docker ecosystem - - -- SwarmKit/swarmd/swarmctl → libcontainer/containerd/container-ctr - --- ## SwarmKit features @@ -1841,6 +1833,8 @@ class: docker-machine --- +class: under-the-hood + ## Under the hood: docker swarm init When we do `docker swarm init`: @@ -1855,6 +1849,8 @@ When we do `docker swarm init`: --- +class: under-the-hood + ## Under the hood: join tokens There is one token to *join as a worker*, and another to *join as a manager*. @@ -1872,6 +1868,8 @@ docker swarm join-token --rotate --- +class: under-the-hood + ## Under the hood: docker swarm join When a node joins the Swarm: @@ -1890,6 +1888,8 @@ When a node joins the Swarm: --- +class: under-the-hood + ## Under the hood: cluster communication - The *control plane* is encrypted with AES-GCM; keys are rotated every 12 hours @@ -1905,6 +1905,8 @@ When a node joins the Swarm: --- +class: under-the-hood + ## Under the hood: I want to know more! Revisit SwarmKit concepts: @@ -2162,6 +2164,24 @@ class: self-paced --- +## Real-life deployment methods + +-- Running commands manually over SSH + +-- + + (lol jk) + +-- + +- Using your favorite configuration management tool + +- [Docker for AWS](https://docs.docker.com/docker-for-aws/#quickstart) + +- [Docker for Azure](https://docs.docker.com/docker-for-azure/) + +--- + # Running our first Swarm service - How do we run services? Simplified version: @@ -2222,6 +2242,8 @@ Note: by default, when a container is destroyed (e.g. when scaling down), its lo --- +class: extra-details + ## Before Docker Engine 17.05 - Docker 1.13/17.03/17.04 have `docker service logs` as an experimental feature @@ -2470,6 +2492,8 @@ There are many ways to deal with inbound traffic on a Swarm cluster. --- +class: btw-labels + ## Managing HTTP traffic - The TCP routing mesh doesn't parse HTTP headers @@ -2487,6 +2511,8 @@ There are many ways to deal with inbound traffic on a Swarm cluster. --- +class: btw-labels + ## You should use labels - Labels are a great way to attach arbitrary information to services @@ -2751,6 +2777,8 @@ class: extra-details --- +class: manual-btp + # Deploying a local registry - We will create a single-instance service, publishing its port @@ -2774,6 +2802,8 @@ class: extra-details --- +class: manual-btp + ## Testing our local registry - We can retag a small image, and push it to the registry @@ -2795,6 +2825,8 @@ class: extra-details --- +class: manual-btp + ## Checking what's on our local registry - The registry API has endpoints to query what's there @@ -3028,6 +3060,8 @@ It has been replaced by the new version, with port 80 accessible from outside. --- +class: manual-btp + ## Connect to the web UI - The web UI is now available on port 8000, *on all the nodes of the cluster* @@ -3063,6 +3097,8 @@ You should see the performance peaking at 10 hashes/s (like before). --- +class: manual-btp + # Global scheduling - We want to utilize as best as we can the entropy generators @@ -3078,6 +3114,8 @@ You should see the performance peaking at 10 hashes/s (like before). --- +class: manual-btp + ## Scaling the `rng` service .exercise[ @@ -3099,7 +3137,7 @@ You should see the performance peaking at 10 hashes/s (like before). --- -class: extra-details +class: extra-details, manual-btp ## Why do we have to re-create the service to enable global scheduling? @@ -3117,6 +3155,8 @@ class: extra-details --- +class: swarm-ready + ## How did we make our app "Swarm-ready"? This app was written in June 2015. (One year before Swarm mode was released.) @@ -3141,6 +3181,8 @@ What did we change to make it compatible with Swarm mode? --- +class: swarm-ready + ## What did we change in our app since its inception? - Compose files @@ -3153,10 +3195,14 @@ What did we change to make it compatible with Swarm mode? -- +class: swarm-ready + *We didn't change a single line of code in this app since it was written.* -- +class: swarm-ready + *The images that were [built in June 2015]( https://hub.docker.com/r/jpetazzo/dockercoins_worker/tags/) (when the app was written) can still run today ... @@ -3165,6 +3211,8 @@ https://hub.docker.com/r/jpetazzo/dockercoins_worker/tags/) --- +class: swarm-ready + ## How did we design our app in the first place? - [Twelve-Factor App](https://12factor.net/) principles @@ -3181,6 +3229,8 @@ https://hub.docker.com/r/jpetazzo/dockercoins_worker/tags/) --- +class: manual-btp + # Integration with Compose - The previous section showed us how to streamline image build and push @@ -3211,6 +3261,8 @@ https://hub.docker.com/r/jpetazzo/dockercoins_worker/tags/) --- +class: manual-btp + ## Removing everything - Before deploying using "stacks," let's get a clean slate @@ -3230,7 +3282,7 @@ https://hub.docker.com/r/jpetazzo/dockercoins_worker/tags/) We need a registry to move images around. -Before, we deployed it with the following command: +Without a stack file, it would be deployed with the following command: ```bash docker service create --publish 5000:5000 registry:2 @@ -3311,6 +3363,8 @@ services: --- +class: manual-btp + ## Specifics of stack deployment Our registry is not *exactly* identical to the one deployed with `docker service create`! @@ -3329,6 +3383,72 @@ Our registry is not *exactly* identical to the one deployed with `docker service --- +## Testing our local registry + +- Connecting to port 5000 *on any node of the cluster* routes us to the registry + +- Therefore, we can use `localhost:5000` or `127.0.0.1:5000` as our registry + +.exercise[ + +- Issue the following API request to the registry: + ```bash + curl 127.0.0.1:5000/v2/_catalog + ``` + +] + +It should return: + +```json +{"repositories":[]} +``` + +If that doesn't work, retry a few times; perhaps the container is still starting. + +--- + +## Pushing an image to our local registry + +- We can retag a small image, and push it to the registry + +.exercise[ + +- Make sure we have the busybox image, and retag it: + ```bash + docker pull busybox + docker tag busybox 127.0.0.1:5000/busybox + ``` + +- Push it: + ```bash + docker push 127.0.0.1:5000/busybox + ``` + +] + +--- + +## Checking what's on our local registry + +- The registry API has endpoints to query what's there + +.exercise[ + +- Ensure that our busybox image is now in the local registry: + ```bash + curl http://127.0.0.1:5000/v2/_catalog + ``` + +] + +The curl command should now output: +```json +"repositories":["busybox"]} +``` + +--- + ## Building and pushing stack services - When using Compose file version 2 and above, you can specify *both* `build` and `image` @@ -5093,6 +5213,56 @@ class: secrets --- +# Least privilege model + +- All the important data is stored in the "Raft log" + +- Managers nodes have read/write access to this data + +- Workers nodes have no access to this data + +- Workers only receive the minimum amount of data that they need: + + - which services to run + - network configuration information for these services + - credentials for these services + +- Compromising a worker node does not give access to the full cluster + +--- + +## What can I do if I compromise a worker node? + +- I can enter the containers running on that node + +- I can access the configuration and credentials used by these containers + +- I can inspect the network traffic of these containers + +- I cannot inspect or disrupt the network traffic of other containers + + (network information is provided by manager nodes; ARP spoofing is not possible) + +- I cannot infer the topology of the cluster and its number of nodes + +- I can only learn the IP addresses of the manager nodes + +--- + +## Guidelines for workload isolation leveraging least privilege model + +- Define security levels + +- Define security zones + +- Put managers in the highest security zone + +- Enforce workloads of a given security level to run in a given zone + +- Enforcement can be done with [Authorization Plugins](https://docs.docker.com/engine/extend/plugins_authorization/) + +--- + class: namespaces name: namespaces