Elemental Operator: support hosts without TPM
Project Description
Currently, the Elemental Operator authenticates the hosts registering for Elemental provisioning via TPM attestation. In particular, the host will perform both Enrollment and Attestation in the same round on the very first registration. Further connections to update the host state will be possible only if the host will be able to proof its identity via TPM (the Enrollment previously done will be used to perform Attestation against the host).
The only available unsupported option to allow nodes without TPM to be provisioned via the Elemental Operator is to use TPM emulation: that would use keys derived by a (random) number to simulate TPM operations and perform attestation (see https://github.com/rancher/elemental-operator/issues/235) .
There are a number of reasons to avoid using random-derived-key TPM emulation in Elemental Operator:
- security is not comparable to the one of a real TPM device: in particular we just allow to derive all TPM keys from one single number, and anyone with the same number will be able to impersonate the host (see https://github.com/rancher-sandbox/go-tpm/issues/6)
- in order to allow the host to update its own data (labels) the random number should be derived by a host unique identifier (UID), in order to let the host re-identify itself, making the whole Attestation useless
Viable alternatives include:
- plain identification (no authentication): just use a host UID for identification, no authentication. This will allow to skip Attestation, providing almost equal security to the one of the current emulated TPM with key derived by a host UID.
- split identification and authentication: identify with some UID from the host and authenticate generating a random key/password, to be stored in the host permanent storage. This could allow a security level between no auth and TPM based Attestation.
- fix random generation of the emulated TPM key (https://github.com/rancher-sandbox/go-tpm/issues/6), generate a new truly random TPM simulator and save its state in the host permanent storage before performing Enrollment and Attestation.
Goal for this Hackweek
The overall goal is to review current authentication methods during registration and explore new ones.
The focus for this Hackweek is to extend the Elemental Operator to allow multiple identification/authentication methods: the target MVP is to allow registration via the alternative 1. (identification and no authentication).
Resources
Looking for hackers with the skills:
This project is part of:
Hack Week 22
Activity
Comments
-
about 1 year ago by fgiudici | Reply
Feb 3, end of the hackweek:
We have a PR introducing a plain identification way to "authenticate" against the elemental-operator, as described at point 1. above.
Instead of a UUID, since we have got report that SMBIOS information can be empty on some hw vendors, we used the MAC address of the "main" network interface as the unique identifier to use during registration (that should really be unique... otherwise, well, you will have bigger issues than registering
)The "main" network interface is actually the first network interface found in the system with a hw address and an IP address assigned there. Good enough for this PoC, since we expect the ifindex net interface to be lower for phisical nics, so they should be checked before any virtual interface.
Some value in the work was to generalize the authentication code, especially on the client side (using Golang interfaces).
Talk is cheap. Show me the code.
here it is: https://github.com/rancher/elemental-operator/pull/345
Reply to fgiudici
Feb 3, end of the hackweek:
We have a PR introducing a plain identification way to "authenticate" against the elemental-operator, as described at point 1. above.
Instead of a UUID, since we have got report that SMBIOS information can be empty on some hw vendors, we used the MAC address of the "main" network interface as the unique identifier to use during registration (that should really be unique... otherwise, well, you will have bigger issues than registering )
The "main" network interface is actually the first network interface found in the system with a hw address and an IP address assigned there. Good enough for this PoC, since we expect the ifindex net interface to be lower for phisical nics, so they should be checked before any virtual interface.
Some value in the work was to generalize the authentication code, especially on the client side (using Golang interfaces).
Talk is cheap. Show me the code.
here it is: https://github.com/rancher/elemental-operator/pull/345
# A First Level Header ## A Second Level Header Use one asterisk to *emphasize* Use two asterisks for **strong emphasis** * Use asterisks * for lists This is an [example link](http://example.com/) This is an  This is a user link @hans This is a project link hw#some-cool-title
Similar Projects
Rancher Upgrader - Upgrades your rancher install via helm, and communicates critical changes from release A to B. by rweir
[comment]: # (Please use the project descriptio...
Go zip updater: Appending new files to zip archive without decompressing the whole file by StarryWang
Project Description
Currently, Golang's `...
A CLI for Harvester by mohamed.belgaied
[comment]: # Harvester does not officially come...
terraform-provider-feilong by e_bischoff
Project Description
People need to test o...
Gameboy emulator written in Go by mikeletux
[comment]: # (Please use the project descriptio...