Virtualized containers
•Download as PPSX, PDF•
1 like•182 views
Introduction to virtualized containers - presented in conatiner conference 2018, Bangalore
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Virtualized containers
Similar to Virtualized containers (20)
Recently uploaded
Recently uploaded (20)
Virtualized containers
- 1. VIRTUALIZED CONTAINERS Ananth, Himanshu, Rajaram, Sandeep, Siva, Sanjay
- 2. AGENDA • VMs vs containers • Virtualized containers • Kata containers • Container security • Kata containers & Docker • Kata containers & K8s • Summary
- 3. VM VS CONTAINERS Ref: https://katacontainers.io
- 4. VM VS CONTAINERS • VMs are abstraction of the hardware, allowing multiple servers to run on the same hardware • Containers are abstraction at the application layer, that packages app code and dependencies together • Each VM has its own operating system, all necessary binaries and libraries, making it heavy • Containers share the host OS kernel and has only those packages necessary to run the application, therefore very light • VMs take time to boot-up and the images are large in size • The USP for containers is speed and portability
- 5. VIRTUALIZED CONTAINERS • Speed of containers • Security of VMs • Otherwise called hypervisor based containers Image Ref Image Ref Image refImage Ref
- 6. VIRTUALIZED CONTAINERS CONTD… Traditional containers such as Docker Virtualized containers Ref: http://katacontainers.io Shared kernel Dedicated kernel
- 7. VIRTUALIZED CONTAINERS CONTD… • Traditional containers share the underlying OS kernel. • We run a lot of unknown un-trusted applications on containers in our datacenter. • If a malicious user gains access to the host OS kernel, rest of the containers and the entire system can be compromised. • Kata-runtime boots each containers as a light weight VM, using hardware virtualization. • Provides double isolation without compromising on performance • Reduces the attacking surface, thereby improving security
- 8. CONTAINER SECURITY • Docker itself is built with security and isolation in mind. It provides lot of inherent features and hooks to make your system more secure. • However, it does not prevent you from “Running random code downloaded from the Internet and running it as root” • We need not worry if proper security measures are taken and best practices are adhered to
- 9. CONTAINER SECURITY CONTD… • Host and kernel security • Denial-of-service attacks • Container breakout • Credentials and secrets • Authenticity of images • Static image vulnerabilities • Runtime security
- 11. KATA CONTAINERS WITH DOCKER Ref: http://katacontainers.io
- 12. CONFIGURATION STEPS • Enable virtualization (Intel VT / AMD-V) on the docker host • Create a config file inside docker.service.d • Restart docker • Spin up kata containers using docker run command and docker images [root@tt2aio docker-host]# cd /etc/systemd/system/docker.service.d [root@tt2aio docker-host]# cat <<EOF | sudo tee kata-containers.conf [Service] ExecStart= ExecStart=/usr/bin/dockerd -D --add-runtime kata- runtime=/usr/bin/kata-runtime --default-runtime=kata-runtime EOF [root@tt2aio docker-host]# systemctl daemon-reload [root@tt2aio docker-host]# systemctl restart docker
- 13. K8S – CRI - OCI Ref: https://katacontainers.io/posts/why-kata-containers-doesnt-replace- kubernetes
- 14. KATA CONTAINERS AND KUBERNETES Kubelet cri- containerd Kata Runtime CRI OCI cri-o VM Pod Contain er
- 15. SUMMARY • Kata-containers are new, exciting, evolving • More secure by design without much impact on performance • Has limited support for various hypervisors to begin with • Does not replace Docker and Kubernetes, rather complements them.
- 16. WHAT’S IN STORE • Support hypervisor based runtime called fracti. • Fracti can schedule pods and containers directly inside a hypervisor via runV. • Enable runV to kata-runtime migrations • Provide “official” support for Kubernetes Contribute to https://github.com/kata- containers
- 17. REFERENCES • https://docs.docker.com/ • https://katacontainers.io/ • Docker runtime execution options • Why Kata containers cannot replaces K8S • Container security vulnerabilities and threats • Securing containers • Running kata with Docker • Running kata with K8s
Editor's Notes
- Host and kernel security Encrypted and authenticated access Keep base system reasonably updated with latest patches Reduce attack surface by using minimal container centric host systems like CoreOS, Red Hat Atomic, RancherOS Enforce mandatory access control both on host and containers using Seccomp, AppArmor, SELinux etc., Restrict the system calls a container a make and drop unnecessary kernel capabilities from the container Default seccomp policy for Docker disables 44 system calls out of 300+ system calls DoS attacks Since containers share kernel resources, it can starve other containers by monopolizing access to certain resources, leading to denial of service. Limit the resources allocated to containers using cgroups Container breakout Unlikely, but possible! When a container bypasses the isolation checks and gains access to sensitive information on the host or can execute privileged instructions Reduce the default container privilege. Create a user to run Docker daemon rather than root. A root user escaping out of container gains root privilege on the host! Map the container to a non privileged user on the host. “–userns-remap” https://blog.docker.com/2014/06/docker-container-breakout-proof-of-concept-exploit/ Credentials and secrets Database access keys, certificates, passwords etc., can be leaked if not protected. Thereby exposing the other services that are used by the containers. Do not embed these credentials in the image or pass them as environment variables. Deploy a credentials manager such as HashiCorp Vault. Authenticity of images Difficult to know if the images downloaded from the internet are trustworthy and not been tampered with Difficult to know the vulnerabilities of the applications running inside the images Prefer to host images in a private registry. If publishing to docker hub, ensure content trust is enabled Static image vulnerabilities Update and patch container images regularly – rebuild image with updates Try to split containers if they are too complex – remember less software, less attacking surface Use vulnerability scanners such as sysdig, Aqua, Clair etc. Runtime security Security is only a journey, not a destination. Continously monitor the runtime security of the system using tools such as sysdig Falco, Clair. Security is a journey and not a destination! An attacker only needs to worry about finding at lease one loop hole. The security guy has to worry about blocking every possible loop hole!
- The word Kata comes from the Greek word, Καταπίστευμα (“ka-ta-PI-stev-ma”), which means “trust something to someone.” Kata Containers uses QEMU/KVM to create virtual machines (mini-OS) systemd, running inside the mini-OS context, will launch the kata-agent in the same context. The agent will create a new confined context to run the specified container kata-agent is a process running in the guest as a supervisor for managing containers and processes running within those containers. kata-proxy is a process offering access to the VM kata-agent to multiple kata-shim and kata-runtime clients associated with the VM. kata-shim needs to handle all container I/O streams (stdout, stdin and stderr)
- Containerd – Default runtime for docker and kubernetes. high level container runtime. Uses ‘runc’ as low level runtime Kata runtime – OCI compatible, works with docker and K8s Creates a QEMU/KVM VM for each container or pod Kata agent – runs inside the VM created by kata runtime. managing containers and processes running within those containers. Kata runtime communicates with kata agent using gRPC protocol Kata-proxy Hypervisor – currently supports QEMU/KVM. hypervisor launches a virtual machine which includes a minimal guest kernel and a guest image.
- CRI-O and CRI-Containerd are the implementation of kubernetes CRI to enable OCI compatible runtimes.