Note:

The Funtoo Linux project has transitioned to "Hobby Mode" and this wiki is now read-only.

Difference between revisions of "LXD/Features and Concepts"

From Funtoo
< LXD
Jump to navigation Jump to search
(Created page with "== Features == <!--T:108--> <!--T:109--> Some of the biggest features of LXD are: <!--T:110--> * Secure by design (unprivileged containers, resource restrictions, AppArmor s...")
 
Line 1: Line 1:
== Features == <!--T:108-->
=== Features === <!--T:108-->


<!--T:109-->
<!--T:109-->
Line 11: Line 11:
* Live migration -- migrating of containers with no apparent downtime.
* Live migration -- migrating of containers with no apparent downtime.


==== Unprivileged Containers ==== <!--T:111-->
=== Unprivileged Containers === <!--T:111-->


<!--T:112-->
<!--T:112-->

Revision as of 21:41, October 21, 2019

Features

Some of the biggest features of LXD are:

  • Secure by design (unprivileged containers, resource restrictions, AppArmor support)
  • Scalable (from containers on your laptop to thousand of compute nodes)
  • Intuitive (simple, clear API and crisp command line experience)
  • Image based (no more distribution templates, only good, trusted images)
  • Live migration -- migrating of containers with no apparent downtime.

Unprivileged Containers

LXD uses unprivileged containers by default. The difference between an unprivileged container and a privileged one is whether the root user in the container is the “real” root user (uid 0 at the kernel level).

The way unprivileged containers are created is by taking a set of normal UIDs and GIDs from the host, usually at least 65536 of each (to be POSIX compliant) and mapping those into the container.

The most common example and what most LXD users will end up with by default is a map of 65536 UIDs and GIDs, with a host base id of 100000. This means that root in the container (uid 0) will be mapped to the host uid 100000 and uid 65535 in the container will be mapped to uid 165535 on the host. UID/GID 65536 and higher in the container aren’t mapped and will return an error if you attempt to use them.

From a security point of view, that means that anything which is not owned by the users and groups mapped into the container will be inaccessible. Any such resource will show up as being owned by uid/gid “-1” (rendered as 65534 or nobody/nogroup in userspace). It also means that should there be a way to escape the container, even root in the container would find itself with just as much privileges on the host as a nobody user.

LXD does offer a number of options related to unprivileged configuration:

  • Increasing the size of the default uid/gid map
  • Setting up per-container maps
  • Punching holes into the map to expose host users and groups

Relationship with LXC

LXD isn't a rewrite of LXC, in fact it's building on top of LXC to provide a new, better user experience. Under the hood, LXD uses LXC through liblxc and its Go binding to create and manage the containers.

It's basically an alternative to LXC's tools and distribution template system with the added features that come from being controllable over the network.