---
# System prepended metadata

title: MA Stand

---

# MA Stand

## VM Full Disk Encryption (FDE)

![](https://i.imgur.com/fklahwu.png)

## VM Unlock Manual

- Manual Unlock must be possible for **recovery** if automation fails


### Option 1: Store and enter all passwords in plain text

- Minimal SSH server at early boot (dropbear)
- Known procedure, existing packages: cryptsetup-initramfs, dropbear-initramfs

**Cons:**

- Operator must store and manage keys of all nodes locally.
    - Keys should not be in the same keystore used for automatic unlocking
- Rotation must be done manually, too.


![](https://i.imgur.com/t6ip7eX.png)

### Option 2: Use asymmetric key encryption

- Store randomly generated disk password encrypted with public key on node
- Download encrypted disk password and decrypt locally

![](https://i.imgur.com/cSUNn2Q.png)

**Pros:**

- Only one key pair
- Recovery disk password can be rotated automatically
- Private key never exposed

**Cons:**

- Loss of private key would be a big problem
- Rotating key pair also requires manual steps


## VM Provisioning

- **Problem**: The key must not be written in plain text to unencrypted disk, but the node starts in an unencrypted state.

### Option 1: Store key in Vault and give Node access

- The disk key is generated locally and added to the KMS
- The node gets a token to lookup the key once to encrypt the disk
- The token reveals nothing about the key and is useless after it's expired

![](https://i.imgur.com/WLKWAhu.png)

**Pros:**

- Key is secured properly

**Cons:**

- Would not be easy to create nodes automatically
- Transit encryption required because key is transferred

### Option 2: Node generates key and adds it to Vault

- The node gets permission (via token) to:
    - create new KMS credentials and write and read secret in its own namespace using those credentials
- The key is randomly generated on the node and only kept in memory

![](https://i.imgur.com/M0oWKXd.png)

**Pros:**

- The token cannot be used to read any secrets, only to create new "accounts"
- Can be used to automate node creation

**Cons:**

- The token would be hardcoded somewhere
- Transit encryption required because key is transferred

### Option 3: Node generates key and sets up Network Bound Disk Encryption (NBDE)

- Node generates disk password randomly
- Stores it encrypted in a way that it can only be recovered by communicating with the Tang server 

![](https://i.imgur.com/qG7LW30.png)

**Pros:**

- No TLS required
- Automatic node creation possible
- Tang is very lightweight compared to Vault, no (distributed) database
- Packages for unlocking exist

**Cons:**

- The private key on the Tang server must be secured properly
    - It can be used to unlock all nodes


### Option 4: Node generates key and sets up NBDE offline

- The key pair of Tang is generated locally. Only the public key (and a public "advertisement") is needed for provisioning.

![](https://i.imgur.com/7OATexr.png)

**Pros:**

- Creation of Nodes not dependent on creation of Tang: Less dependencies, more parallelism, faster setup


## VM automatic unlocking

- When using KMS, a short-lived token is temporarily generated before reboot that the node can use to retrieve the key
- Works with Kubernetes Reboot Daemon


![](https://i.imgur.com/p2FkwNv.png)


