hack4glarus » hack4glarus-2019-summer

h1. Crowd cloud / Kraut Computing (KC's)

Following is a first sketch of a design document / analysis of the idea.

h2. Use-cases

h3. Create a VM:

1. Pick an image

2. Pick network(s)

3. Pick machine type

[4. Pick machine type parameters]

[X. Add nic to VM / mod VM]

[Y. Upload images to be used for 1]

[Z. Destroy a VM]

Note: this actually includes most of the life-cycle of a VM.

h2. Components

Following components were identified and commented out, sorted out by subjective order of importance.

These components are thought as being some kind of key/value (JSON seems likely, a priori no NOSQL) with possibilities for opaque customer metadata.

* This key/value + metadata information should be usable for filtering / operations.

* It should be versioned.

h3. VM

Defined as an instance of different settings and multiplicities of the other components

h3. Machine types / Templates

General definition with fixed sets of settings and, in a future stage, parametrised options.

Examples of settings:

* CPU/RAM

* HW Type: arm64 / x86

* HW / VM

* ...

h3. Network(s)

Layer2-based, allow common use-cases like: static, dhcp, slaac, dhcpv6, custom gateway.

Outside connections: VXLAN

Note: it is quite important that the gateway can be set to another VM / something customised. That way, we can see firewalls and VPNs as special cases to be considered.

h3. Firewall / routing

Thought as: extra VM, that is potentially "invisible" to customers/users and that can:

* deal with basic sets of rules (e.g. allow TCP 80, 22 from $SUBNET, ...)

* ratelimit

* standard ACLs

* geek_mode: on --> "I know what I'm doing, gimme SSH"

Note: By treating this component as a special case of VMs, we simplify things and keep them simple.

h3. Storage

Thought as being out-of-scope to begin with since it can vary so much. We shouldn't rely on a specific implementation.

h3. Images

Basically a rw repository of prepared images. Uploads can be thought as being "raw" to begin with, and we can later add pre-processors that convert them as needed.

h3. Auth

Thought as "not being our problem".

*BUT*: we should have provisions for checkers as follows:

Use some HTTP Auth Header, which should be treated as opaque.

This value of the header, along with the details of the request, should offload Auth to an implementation.

That implementation should reply with the result of such request.

To facilitate adoption / testing, we should implement a few such Authenticators:

* httpasswd file

* ldap

* god-like tokens

* OTP

* limited-scope tokens

Note: by treating the header as something opaque, it can be e.g. base64(user:name) à la HTTP Basic Auth or a uuid or jwt or ...

h2. Things to consider

* The whole thing should aim to be a set of integrated tools that work well together and build on top of standard technologies as much as possible.

* Language of implementation should be consistent, but is open for discussion

* For the JSON metadata, Azure has some interesting tools / Schemas that are worth taking a look into.

* Take a look at ETCD, consul and the like.