The Academy is free // the war room is optional
DAEMONCORE // ACADEMY
← FIELD NOTES

What a virtual machine gives you that a container does not

2024.01.04//8 MIN READcontainersvirtualizationsecurity-architecturefundamentals

// The Landscape of Virtualization

When considering deployment strategies for applications, the choice between virtual machines (VMs) and containers often arises. VMs provide full system virtualization, while containers offer a lightweight abstraction. But what does a VM actually provide that a container does not? Let's break it down.

// Isolation and Resources

VMs run on hypervisors which allow multiple OS instances on the same hardware. This means each VM has its own kernel, separate from the host OS. Containers, however, share the host's kernel. This fundamental difference influences security and resource allocation.

Resource Isolation

With VMs, resource allocation is strict. The hypervisor manages resources like CPU, memory, and storage, which prevents one VM from affecting another. If one crashes or is compromised, other VMs remain unaffected.

For instance, if you're using KVM (Kernel-based Virtual Machine) on a Linux host, you might see commands like:

# Create a new VM with 2GB of RAM and 2 CPU cores
virt-install \
  --name my-vm \
  --ram 2048 \
  --vcpus 2 \
  --disk path=/var/lib/libvirt/images/my-vm.img,size=20 \
  --os-variant ubuntu20.04 \
  --network bridge=br0 \
  --graphics none \
  --console pty,target_type=serial \
  --location 'http://archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/'

This command creates a VM that is isolated from the host, while containers would share the same kernel.

Security Implications

The isolation in VMs offers a significant security advantage. If a containerized application is compromised, the attacker might gain access to the host OS and any other containers running on it. This risk is mitigated with VMs as they operate in isolation. Consider the following:

  • Containers share the kernel: Vulnerabilities in the kernel can be catastrophic for all containers.
  • VMs have separate kernels: Compromising one VM does not inherently compromise others.

// Networking Differences

Networking for VMs and containers also diverges significantly. VMs have their own virtual network interfaces and can be assigned public IPs directly. Containers typically rely on a shared network namespace and may require additional configuration to expose services.

Exposing Container Services

To expose a service from a container, you might use:

# Run a container and expose port 80 to the host
docker run -d -p 80:80 nginx

This command exposes the Nginx server running in a container, but it does so within the context of the host's network. This can introduce risks if not managed properly.

Defensive Measures

When deploying containers, consider the following defensive measures:

  • Use a dedicated container orchestration tool (like Kubernetes) to help manage networking securely.
  • Regularly patch container images to reduce vulnerabilities.
  • Use tools like Clair or Trivy for image vulnerability scanning.

// Performance Considerations

Containers are generally more lightweight and can start up faster than VMs since they don’t require a full OS boot-up. However, this comes at the cost of isolation. VMs, while heavier, can provide better performance for resource-intensive applications due to dedicated resources.

Performance Example

You can test performance differences between a VM and a container by running a simple load test on both. For instance:

1. On a VM: Run a benchmarking tool like sysbench directly in the VM.

   sysbench --test=cpu --cpu-max-prime=20000 run

2. On a container: Run the same benchmark in a containerized environment.

   docker run --rm -it --name sysbench-container --cpus=2 --memory=2g your-repo/sysbench \
   sysbench --test=cpu --cpu-max-prime=20000 run

You will likely notice different results based on how resources are allocated and managed. This can influence your decision based on application requirements.

// Summary Checklist

When deciding between VMs and containers, consider the following:

  • Isolation: Do you require strong isolation between applications?
  • Networking Needs: Do you need public IPs for each application?
  • Resource Management: How critical are performance and resource allocation?
  • Security Requirements: Can you manage the security implications of shared kernel resources?

// Conclusion

Understanding the differences between VMs and containers is critical for effective infrastructure design. VMs provide superior isolation and resource management, while containers offer speed and efficiency. Both have their place in modern application deployment, and knowing when to use each can be a differentiator in your security architecture.

DaemonCore Academy provides free resources to explore these concepts further. Always practice these techniques in a controlled environment that you own.