airship
/
maas
Code Issues Proposed changes
Kubernetes deployment artifacts for Canonical's MaaS.
94 Commits 1 Branch 0 Tags 3.4 MiB
Smarty 54.3%
Dockerfile 28.9%
Makefile 5.7%
Shell 5.6%
Python 5.5%
Go to file
Rick Bartra 7857fdf2cf Run maas-rack and maas-region containers as non-privileged 
The maas-rack and maas-region containers can successfully run and function
as non-privileged if given the appropriate Linux capabilities. This change
is a security enhancement as the maas-rack and maas-region containers now only
have access to the capabiities it needs to do its job - instead of having full
root access.

The capabilities listed in the `statefulset-rack` and `statefulset-region`
charts function as a whitelist in that the maas-rack and maas-region containers
only have access to the Linux capabilities listed in their SecurityContext
along with the default capabilties that Docker gives to unprivileged containers.
The default list of capabilties include the following:
  - SETPCAP
  - MKNOD
  - AUDIT_WRITE
  - CHOWN
  - NET_RAW
  - DAC_OVERRIDE
  - FOWNER
  - FSETID
  - KILL
  - SETGID
  - SETUID
  - NET_BIND_SERVICE
  - SYS_CHROOT
  - SETFCAP

The bcc-capable tool [0] was used to discover which Linux capabilities the
maas-rack and maas-region containers invoke. The capabale tool, has the ability
to record the Linux capabiltiies that are invoked by all the processes running
in the container. While still running as privileged, the capable tool was
installed and ran within the container during maas bootstrapping. When
bootstrapping was complete, the list of Linux capabilities were reviewed and
added to the appropriate charts.

[0]https://github.com/iovisor/bcc/blob/master/tools/capable.py

Change-Id: I11cf1da8ea8219320c4d3028502c133391116201
 		2019-03-11 22:21:09 +00:00
charts/maas Run maas-rack and maas-region containers as non-privileged 2019-03-11 22:21:09 +00:00
images (fix) Give systemd service access to env 2019-01-25 11:22:59 -06:00
tools Apparmor profile for MaaS 2018-12-07 16:17:11 -06:00
.gitignore Add .gitignore to repo 2018-08-22 21:24:27 -05:00
.gitreview Update .gitreview for openstack infra 2018-05-17 19:48:42 +01:00
.zuul.yaml (zuul) Add Docker image jobs 2018-06-08 05:38:15 -05:00
LICENSE Initial commit 2017-10-19 11:42:23 -05:00
Makefile Minor: meaningful default label 2018-11-08 19:32:19 +01:00
README.md Add image cache sidecar 2017-12-04 12:50:30 -06:00

README.md

MaaS Helm Artifacts

This repository holds artifacts supporting the deployment of Canonical MaaS in a Kubernetes cluster.

Images

The MaaS install is made up of two required imags and one optional image. The Dockerfiles in this repo can be used to build all three. These images are intended to be deployed via a Kubernetes Helm chart.

MaaS Region Controller

The regiond Dockerfile builds a systemD-based Docker image to run the MaaS Region API server and metadata server.

MaaS Rack Controller

The rackd Dockerfile builds a systemD-based Docker image to run the MaaS Rack controller and dependent services (DHCPd, TFTPd, etc...). This image needs to be run in privileged host networking mode to function.

MaaS Image Cache

The cache image Dockerfile simply provides a point-in-time mirror of the maas.io image repository so that if you are deploying MaaS somewhere without network connectivity, you have a local copy of Ubuntu. Currently this only mirrors Ubuntu 16.04 Xenial and does not update the mirror after image creation.

Charts

Also provided is a Kubernetes Helm chart to deploy the MaaS pieces and integrates them. This chart depends on a previous deployment of Postgres. The recommended avenue for this is the Openstack Helm Postgres chart but any Postgres instance should work.

Overrides

Chart overrides are likely required to deploy MaaS into your environment

  • values.labels.rack.node_selector_key - This is the Kubernetes label key for selecting nodes to deploy the rack controller
  • values.labels.rack.node_selector_value - This is the Kubernetges label value for selecting nodes to deploy the rack controller
  • values.labels.region.node_selector_key - this is the Kubernetes label key for selecting nodes to deploy the region controller
  • values.labels.region.node_selector_value - This is the Kubernetes label value for selecting nodes to deploy the region controller
  • values.conf.cache.enabled - Boolean on whether to use the repo cache image in the deployment
  • values.conf.maas.url.maas_url - The URL rack controllers and nodes should use for accessing the region API (e.g. http://10.10.10.10:8080/MAAS)

Deployment Flow

During deployment, the chart executes the below steps:

  1. Initializes the Postgres DB for MaaS
  2. Starts a Pod with the region controller and optionally the image cache sidecar container
  3. Once the region controller is running, deploy a Pod with the rack controller and join it to the region controller.
  4. Initialize the configuration of MaaS and start the image sync
  5. Export an API key into a Kubernetes secret so other Pods can access the API if needed