{"id":3179,"date":"2019-01-04T07:00:06","date_gmt":"2019-01-04T01:30:06","guid":{"rendered":"http:\/\/www.upnxtblog.com\/?p=3179"},"modified":"2020-04-23T12:21:05","modified_gmt":"2020-04-23T06:51:05","slug":"implementing-secure-containers-using-gvisordocker-tutorial","status":"publish","type":"post","link":"https:\/\/www.upnxtblog.com\/index.php\/2019\/01\/04\/implementing-secure-containers-using-gvisordocker-tutorial\/","title":{"rendered":"Implementing secure containers using gVisor+Docker tutorial"},"content":{"rendered":"
<\/div>

Linux containers<\/a> have been around since the early 2000s and architected into Linux in 2007. Due to the small footprint and portability of containers, the same hardware can support an exponentially larger number of containers than VMs, dramatically reducing infrastructure costs and enabling more apps to deploy faster. But due to usability issues, it didn\u2019t kick-off enough interest until Docker (2013) came into the picture.<\/p>\n

Unlike hypervisor (ex. Xen,hyper-v) virtualization, where virtual machines run on physical hardware via an intermediation layer (hypervisor), containers instead run userspace on top of an operating system\u2019s kernel. That makes them very lightweight and fast. <\/em><\/p>\n

Containers have also sparked an interest in\u00a0microservice architecture<\/em><\/a>, a design pattern<\/a> for developing applications in which complex applications are broken down into smaller, composable services that work together.<\/p>\n

Now with the increasing adoption<\/a> of containers and microservices in the enterprises, there are also risks that come along with containers. For example, If any one of the containers breaks out, it can allow unauthorized access across containers, hosts or data centers, etc., thus affecting all the containers hosted on the Host OS.<\/p>\n

To mitigate these risks, we are going to take look at various approaches and specifically Google’s gVisor<\/a> approach, which is a kind of sandbox that helps provide secure isolation for containers. It also integrates with Docker and Kubernetes container platforms thus making it simple and easy to run sandboxed containers in production environments.<\/p>\n

With this context, now let’s check out how to implement sandboxed containers.<\/p>\n

Cross-posted from: New Stack<\/a><\/span><\/em><\/p>\n\n

Roundup of Container isolation mechanisms<\/h2>\n

#1.Machine-level virtualization\u00a0<\/strong>exposes virtualized hardware to a guest kernel via a Virtual Machine Monitor (VMM). Running containers in distinct virtual machines can provide great isolation, compatibility, and performance but it often requires additional proxies and agents and may require a larger resource footprint and slower start-up times.<\/p>\n

\"\"
Image – Machine Level Virtualization<\/figcaption><\/figure>\n

\"ComparisonImage – Comparison between Conventional Platform vs Machine Level Virtualization Enabled Platform<\/span><\/p>\n

KVM <\/a>is one of the best examples of machine-level virtualization. Recently Amazon has also launched Firecracker<\/span><\/a>, a new virtualization technology that makes use of a modified version of KVM<\/a>.AWS Lambda\/Fargate extensively uses Firecracker for provisioning and running secure sandboxes to execute customer functions.<\/p>\n

\"KVM
Image – KVM Virtualization infrastructure<\/figcaption><\/figure>\n

Another notable project based on KVM is Kata containers<\/a>\u00a0leverages lightweight virtual machine\u00a0that seamlessly integrates within the container ecosystem like Docker <\/a>or Kubernetes<\/a>.<\/p>\n

#2.Rule-based execution, <\/strong>for example,\u00a0seccomp<\/a> filters, allows the specification of a fine-grained security policy for an application or container. However, in practice it can be extremely difficult to reliably define a policy for applications, making this approach challenging to apply for all scenarios.<\/p>\n

\"\"
Image – Rule-Based Execution<\/figcaption><\/figure>\n

To configure the same in Docker,Docker needs to be built with\u00a0seccomp<\/code>\u00a0and the kernel is configured with\u00a0CONFIG_SECCOMP<\/code>\u00a0enabled. To check if your kernel supports\u00a0seccomp<\/code>and configured.<\/p>\n

grep <\/span>CONFIG_SECCOMP<\/span>=<\/span> \/boot\/config-$(<\/span>uname -r<\/span>)\r\n<\/span><\/code><\/pre>\n
\"Check
Image – Check if seccomp is enabled<\/figcaption><\/figure>\n
Docker by default runs on default seccomp profile,to\u00a0override use\u00a0--security-opt<\/code>option during Docker run<\/code> command. For example, the following explicitly specifies a policy:<\/p>\n
$ <\/span>docker run --rm<\/span> \\<\/span>\r\n             -it<\/span> \\<\/span>\r\n             --security-opt<\/span> seccomp<\/span>=<\/span>\/usr\/local\/profile.json \\<\/span>\r\n             hello-world<\/code><\/pre>\n
profile.json<\/code> whitelists specific system calls\u00a0and denies access to other system calls.<\/p>\n
In the next section,we will look at gVisor (Google’s) approach to container isolation mechanisms.<\/p>\n
Introducing gVisor<\/h2>\n
gVisor is a lightweight user-space kernel<\/strong>, written in Go, that implements a substantial portion of the Linux system surface. By implementing Linux system surface,it provides isolation between host and application. Also, it includes an Open Container Initiative (OCI)<\/a>\u00a0runtime called\u00a0runsc<\/code> so that the isolation boundary between the application and the host kernel is maintained.<\/p>\n
It intercepts all application system calls and acts as the guest kernel, without the need for translation through virtualized hardware. Also, gVisor does not simply redirect the application system calls through to the host kernel. Instead, gVisor implements most kernel primitives<\/strong> (like signals, file systems, futexes, pipes, mm, etc.<\/em>) and has complete system call handlers built on top of these primitives.<\/p>\n
\"\"
Image – gVisor Kernel<\/figcaption><\/figure>\n
Unlike the above mechanisms, gVisor provides a strong isolation boundary by intercepting application system calls and acting as the guest kernel, all while running in user-space. Unlike a VM which requires a fixed set of resources on creation, gVisor can accommodate changing resources over time like normal Linux processes do.<\/p>\n
Although gVisor implements a large portion of the Linux surface and its broadly compatible, there are unimplemented features and bugs. Please file a bug here<\/a>, if you run into issues.<\/p>\n
How to implement Sandboxed containers (for Docker application)<\/h2>\n
First step is to download\u00a0\u00a0runsc<\/code>\u00a0 container runtime from the\u00a0latest nightly build<\/a>. Post downloading the binary, check it against the SHA512 checksum file<\/a>.<\/p>\n
wget https:\/\/storage.googleapis.com\/gvisor\/releases\/nightly\/latest\/runsc\r\nwget https:\/\/storage.googleapis.com\/gvisor\/releases\/nightly\/latest\/runsc.sha512\r\nsha512sum -c runsc.sha512\r\nchmod a+x runsc\r\nsudo mv runsc \/usr\/local\/bin\r\n<\/code><\/pre>\n
\"runsc
Image – runsc gVisor Docker runtime<\/figcaption><\/figure>\n
Next step is to configure Docker to use\u00a0runsc<\/code>\u00a0by adding a runtime entry to Docker configuration (\/etc\/docker\/daemon.json<\/code>)<\/p>\n
\"Docker
Image – Docker configuration for runsc<\/figcaption><\/figure>\n
Restart the Docker daemon post making changes.<\/p>\n
Now the gVisor configuration is complete, we can now test it by running hello-world container<\/em> using command\u00a0docker run --runtime=runsc hello-world<\/code><\/p>\n
\"Run
Image – Run hello world container using runsc (gVisor)<\/figcaption><\/figure>\n
Let us try to run httpd<\/code> server on gVisor,here test-apache-app<\/code> would use httpd<\/code> image with gVisor runtime.<\/p>\n
\"Run
Image – Run httpd server on gVisor<\/figcaption><\/figure>\n
The\u00a0runsc<\/code>\u00a0runtime can also run sandboxed pods in a Kubernetes cluster through the use of either the\u00a0cri-o<\/a>\u00a0or\u00a0cri-containerd<\/a>\u00a0projects, which convert messages from the\u00a0Kubelet\u00a0into OCI runtime commands.<\/p>\n
Congrats! we have learned how to implement Sandboxed containers using gVisor.<\/em><\/p>\n
Like this post? Don\u2019t forget to share it!<\/strong><\/em><\/p>\n
Additional Resources :<\/h2>\n
The default\u00a0seccomp<\/code>\u00a0profile provides running containers with seccomp and disables around 44 system calls out of 300+. It is moderately protective while providing wide application compatibility.The default Docker profile can be found\u00a0here<\/a>.<\/p>\n