The goal of albatross is robust deployment of MirageOS
unikernels using Solo5. Resources managed
by albatross are network interfaces of kind tap, which are connected to
already existing bridges, block devices, memory, and CPU. Each unikernel is
pinned (cpuset / taskset) to a specific core.
Albatross allows remote management. To deploy or destroy a unikernel, no shell access is necessary. The remote channel is a mutually authenticated (with X.509 certificates) TLS connection. Console output of the unikernels is stored in memory in a ring buffer, and accessible remotely. Monitoring data (CPU and memory usage) of the unikernels can be collected as well, and pushed into an Influx time series database.
Albatross consists of multiple processes, each running with the least privileges. Albatross can be run next to other orchestration systems; it does not assume to be the single instance on a dom0 which creates and destroys virtual machines. Resource policies can be dynamically configured for each administrative domain (similar to DNS, a hierarchical naming scheme), and are checked statically (to decrease while going down the tree) and dynamically when a new unikernel is to be deployed.
When a unikernel is deployed, albatross tries its best to keep it running, even when the physical hardware reboots, or albatross is restarted. When the unikernel exits, depending on configuration and its exit code, it is re-started. The current set of running unikernels is persisted on disk, though there is no dependency or order for restarting them.
The scope of albatross is to provide a minimal orchestration system that avoids the need for shell access on the dom0. This leads to mostly immutable - or only mutable via albatross - infrastructure. Further dissemination of albatross into virtual machines, and a communication interface for deploying and destroying unikernels, is being researched on.
Albatross consists of a set of binaries. Several daemons, which communicate in a request-response style over Unix domain sockets, are run in the host system:
albatrossd: privileged to create and destroy unikernelsalbatross-console: reads the console output of unikernelsalbatross-stats: statistics gathering (rusage, ifstat, BHyve debug counters)albatross-tls-endpoint: remote deployment via TLS (and possibly inetd)albatross-influx: statistic reporting fromalbatross-statsto influx
The main daemon is the privileged albatrossd, which supervises unikernels. It opens
a listening Unix domain socket, reads the persisted unikernel configuration,
starts these unikernels, and awaits commands. Access can be regulated by Unix
file permissions -- only those users who can write to that socket can send
commands.
Albatross-console does not keep any persistent state, but a ring buffer of console
output from each unikernel. These messages can be retrieved by a client as a
stream of messages (history, and whenever a new line is output, it is sent to
the interested client). Each unikernel output can only be read by a single
client, to avoid amplification of traffic if lots of clients are connected.
Albatrossd sends a message to albatross-console whenever a new unikernel is started,
upon reception albatross-console opens and reads the fifo which the unikernel will
write their standard output to.
Albatross-stats periodically gathers statistics (memory, CPU, network, hypervisor)
from all running unikernels.
Albatross-tls-endpoint listens on a TCP port, or uses systemd socket activation, or
via inetd (remember to add --syslog when using --inetd to log via syslog),
and proxies requests from remote clients to the respective daemons described
above. It enforces client authentication, and uses the common names of the client
certificate chain as the administrative domain. The policies are embedded in CA
certificates, and the command is embedded in the leaf certificate.
The albatross-client is provided for both local and remote management. It executes the provided command, and can also prepare certificate signing requests (--csr) to send the certificate at a later point.
It also includes functionality for generating an initial CA (and server certificate), and signing certificate signing requests.
Albatross uses PKI to authenticate both client and server. Requests are signed by a certificate authority (CA) that is trusted by the server. CA can delegate resources using policies, which happens by creating an intermediate CA. Revokation is not implemented, as delegation happens without the server knowing about it.
This example shows how one can delegate part of the resources to a user. There are 4 entities:
- server: runs the albatross TLS endpoint
- CA: root certificate authority
- intermediate CA: user certificate authority
- client: requests initiator
Note: there are 4 entities but depending on the security model some can exist
on the same machine. For example, when client and intermediate CA can be
combined, requests are automatically signed using albatross-client --destination (see step 8).
This step-by-step guide shows how files are generated and to which entity they belong. Filename is in bold when it's created by the current step.
- Generate the root CA certificate and server keypair
albatross-client generate ca db
| description | server | CA | intermediate CA | client | |
|---|---|---|---|---|---|
| private key | server.key | ca.key | |||
| public certificate | server.pem | cacert.pem |
- server: start the endpoint using the server keypair and the root CA certificate
albatross-tls-endpoint cacert.pem server.pem server.key
- intermediate CA: we want to delegate part of the resources to a given user. The user generates a signing request to allow a memory of 1024MB to run 16 unikernels on CPU IDs 0 and 1.
albatross-client add-policy user 16 --mem 1024 --cpu 0 --cpu 1 --csr
| description | server | CA | intermediate CA | client | |
|---|---|---|---|---|---|
| private key | server.key | ca.key | user.key | ||
| public certificate | server.pem | cacert.pem | |||
| certificate signing request | user.req |
- CA: CA signs the user's request, which generates an intermediate CA certificate containing the restriction policies (limited memory, cpu), which in turn will be used to sign user requests.
albatross-client sign cacert.pem db ca.key user.req
| description | server | CA | intermediate CA | client | |
|---|---|---|---|---|---|
| private key | server.key | ca.key | user.key | ||
| public certificate | server.pem | cacert.pem | user.pem | ||
| certificate signing request | user.req |
- client: the client wants to create an unikernel, it has to wrap the request in a certificate signing request which will be submitted to the intermediate CA. Note: you can download hello-key.hvt.
albatross-client create hello hello-key.hvt --csr [--arg='--hello=albatross-hi'] [--cpu=1]
| description | server | CA | intermediate CA | client | |
|---|---|---|---|---|---|
| private key | server.key | ca.key | user.key | hello.key | |
| public certificate | server.pem | cacert.pem | user.pem | ||
| certificate signing request | user.req | hello.req |
- intermediate CA: the intermediate CA signs the request
albatross-client sign user.pem db user.key hello.req
| description | server | CA | intermediate CA | client | |
|---|---|---|---|---|---|
| private key | server.key | ca.key | user.key | hello.key | |
| public certificate | server.pem | cacert.pem | user.pem | hello.pem | |
| certificate signing request | user.req | hello.req |
- client: client sends the signed request to the server,
albatross-client signappended the intermediate CA certificate tohello.pemto form the full chain.
albatross-client certificate cacert.pem hello.pem hello.key --destination <REMOTE_IP:PORT>`
- Steps 5, 6, and 7 can be done in a single command - if there's no requirement to retain the signing request and certificate, and the user keys are on the local machine.
albatross-client create hello hello-key.hvt --ca=user.pem --ca-key=user.pem --server-ca=cacert.pem --destination <REMOTE_IP:PORT> [--arg='--hello=albatross-hi'] [--cpu=1]
Binary packages are available for Debian, Ubuntu and FreeBSD. How to install.
For other operating systems / distributions, run opam install albatross.
Also read the blog article for the motivation behind albatross and an overview of its functionality.