summaryrefslogtreecommitdiffhomepage
path: root/README.md
diff options
context:
space:
mode:
authorFabricio Voznika <fvoznika@google.com>2018-04-28 11:12:01 -0700
committerShentubot <shentubot@google.com>2018-04-28 11:12:54 -0700
commit54a20025b15795bf3d6bd2435b8e83dbbca55a64 (patch)
tree5c00e4d8ed493a776e7f63d47e43436f85c7218e /README.md
parent300a7b60e124f6632f23bdafd499d153a0fe361c (diff)
Fix center alignment
github markdown doesn't like {style} tags. Also moved the image after their respective section. PiperOrigin-RevId: 194663070 Change-Id: I7a7b97c1bc6f2b368837a3aa936f8bd3c00469fd
Diffstat (limited to 'README.md')
-rw-r--r--README.md13
1 files changed, 6 insertions, 7 deletions
diff --git a/README.md b/README.md
index 3b8ad1857..e5fc31ac8 100644
--- a/README.md
+++ b/README.md
@@ -35,9 +35,6 @@ made available to a container.
Two other approaches are commonly taken to provide stronger isolation than
native containers.
-![Machine-level virtualization](g3doc/Machine-Virtualization.png "Machine-level
-virtualization"){style="display:block;margin:auto"}
-
**Machine-level virtualization**, such as [KVM][kvm] and [Xen][xen], exposes
virtualized hardware to a guest kernel via a Virtual Machine Monitor (VMM). This
virtualized hardware is generally enlightened (paravirtualized) and additional
@@ -48,7 +45,7 @@ performance (though nested virtualization may bring challenges in this area),
but for containers it often requires additional proxies and agents, and may
require a larger resource footprint and slower start-up times.
-![Rule-based execution](g3doc/Rule-Based-Execution.png "Rule-based execution"){style="display:block;margin:auto"}
+<p align="center"><img src="g3doc/Machine-Virtualization.png"></p>
**Rule-based execution**, such as [seccomp][seccomp], [SELinux][selinux] and
[AppArmor][apparmor], allows the specification of a fine-grained security policy
@@ -63,7 +60,7 @@ making this approach challenging to apply universally.
Rule-based execution is often combined with additional layers for
defense-in-depth.
-![gVisor](g3doc/Layers.png "gVisor"){style="display:block;margin:auto"}
+<p align="center"><img src="g3doc/Rule-Based-Execution.png"></p>
**gVisor** provides a third isolation mechanism, distinct from those mentioned
above.
@@ -79,6 +76,8 @@ reduced application compatibility and higher per-system call overhead.
On top of this, gVisor employs rule-based execution to provide defense-in-depth
(details below).
+<p align="center"><img src="g3doc/Layers.png"></p>
+
gVisor's approach is similar to [User Mode Linux (UML)][uml], although UML
virtualizes hardware internally and thus provides a fixed resource footprint.
@@ -107,8 +106,6 @@ application to directly control the system calls it makes.
### File System Access
-![Sentry](g3doc/Sentry-Gofer.png){style="display:block;margin:auto"}
-
In order to provide defense-in-depth and limit the host system surface, the
gVisor container runtime is normally split into two separate processes. First,
the *Sentry* process includes the kernel and is responsible for executing user
@@ -122,6 +119,8 @@ access itself. Furthermore, the Sentry runs in an empty user namespace, and the
system calls made by gVisor to the host are restricted using seccomp filters in
order to provide defense-in-depth.
+<p align="center"><img src="g3doc/Sentry-Gofer.png"></p>
+
### Network Access
The Sentry implements its own network stack (also written in Go) called