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
-
almost 3 years 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 hyphens - for unordereed - lists This is an [link to example.com](http://example.com/) This is an image  This is a user link @hans This is a project link hw#some-cool-title
Similar Projects
go-git: unlocking SHA256-based repository cloning ahead of git v3 by pgomes
Description
The go-git library implements the git internals in pure Go, so that any Go application can handle not only Git repositories, but also lower-level primitives (e.g. packfiles, idxfiles, etc) without needing to shell out to the git binary.
The focus for this Hackweek is to fast track key improvements for the project ahead of the upstream release of Git V3, which may take place at some point next year.
Goals
- Add support for cloning SHA256 repositories.
- Decrease memory churn for very large repositories (e.g. Linux Kernel repository).
- Cut the first alpha version for
go-git/v6.
Stretch goals
- Review and update the official documentation.
- Optimise use of go-git in Fleet.
- Create RFC/example for go-git plugins to improve extensibility.
Resources
- https://github.com/go-git/go-git/
- https://go-git.github.io/docs/
SUSE Health Check Tools by roseswe
SUSE HC Tools Overview
A collection of tools written in Bash or Go 1.24++ to make life easier with handling of a bunch of tar.xz balls created by supportconfig.
Background: For SUSE HC we receive a bunch of supportconfig tar balls to check them for misconfiguration, areas for improvement or future changes.
Main focus on these HC are High Availability (pacemaker), SLES itself and SAP workloads, esp. around the SUSE best practices.
Goals
- Overall improvement of the tools
- Adding new collectors
- Add support for SLES16
Resources
csv2xls* example.sh go.mod listprodids.txt sumtext* trails.go README.md csv2xls.go exceltest.go go.sum m.sh* sumtext.go vercheck.py* config.ini csvfiles/ getrpm* listprodids* rpmdate.sh* sumxls* verdriver* credtest.go example.py getrpm.go listprodids.go sccfixer.sh* sumxls.go verdriver.go
docollall.sh* extracthtml.go gethostnamectl* go.sum numastat.go cpuvul* extractcluster.go firmwarebug* gethostnamectl.go m.sh* numastattest.go cpuvul.go extracthtml* firmwarebug.go go.mod numastat* xtr_cib.sh*
$ getrpm -r pacemaker
>> Product ID: 2795 (SUSE Linux Enterprise Server for SAP Applications 15 SP7 x86_64), RPM Name:
+--------------+----------------------------+--------+--------------+--------------------+
| Package Name | Version | Arch | Release | Repository |
+--------------+----------------------------+--------+--------------+--------------------+
| pacemaker | 2.1.10+20250718.fdf796ebc8 | x86_64 | 150700.3.3.1 | sle-ha/15.7/x86_64 |
| pacemaker | 2.1.9+20250410.471584e6a2 | x86_64 | 150700.1.9 | sle-ha/15.7/x86_64 |
+--------------+----------------------------+--------+--------------+--------------------+
Total packages found: 2
Mammuthus - The NFS-Ganesha inside Kubernetes controller by vcheng
Description
As the user-space NFS provider, the NFS-Ganesha is wieldy use with serval projects. e.g. Longhorn/Rook. We want to create the Kubernetes Controller to make configuring NFS-Ganesha easy. This controller will let users configure NFS-Ganesha through different backends like VFS/CephFS.
Goals
- Create NFS-Ganesha Package on OBS: nfs-ganesha5, nfs-ganesha6
- Create NFS-Ganesha Container Image on OBS: Image
- Create a Kubernetes controller for NFS-Ganesha and support the VFS configuration on demand. Mammuthus
Resources
A CLI for Harvester by mohamed.belgaied
Harvester does not officially come with a CLI tool, the user is supposed to interact with Harvester mostly through the UI. Though it is theoretically possible to use kubectl to interact with Harvester, the manipulation of Kubevirt YAML objects is absolutely not user friendly. Inspired by tools like multipass from Canonical to easily and rapidly create one of multiple VMs, I began the development of Harvester CLI. Currently, it works but Harvester CLI needs some love to be up-to-date with Harvester v1.0.2 and needs some bug fixes and improvements as well.
Project Description
Harvester CLI is a command line interface tool written in Go, designed to simplify interfacing with a Harvester cluster as a user. It is especially useful for testing purposes as you can easily and rapidly create VMs in Harvester by providing a simple command such as:
harvester vm create my-vm --count 5
to create 5 VMs named my-vm-01 to my-vm-05.
Harvester CLI is functional but needs a number of improvements: up-to-date functionality with Harvester v1.0.2 (some minor issues right now), modifying the default behaviour to create an opensuse VM instead of an ubuntu VM, solve some bugs, etc.
Github Repo for Harvester CLI: https://github.com/belgaied2/harvester-cli
Done in previous Hackweeks
- Create a Github actions pipeline to automatically integrate Harvester CLI to Homebrew repositories: DONE
- Automatically package Harvester CLI for OpenSUSE / Redhat RPMs or DEBs: DONE
Goal for this Hackweek
The goal for this Hackweek is to bring Harvester CLI up-to-speed with latest Harvester versions (v1.3.X and v1.4.X), and improve the code quality as well as implement some simple features and bug fixes.
Some nice additions might be: * Improve handling of namespaced objects * Add features, such as network management or Load Balancer creation ? * Add more unit tests and, why not, e2e tests * Improve CI * Improve the overall code quality * Test the program and create issues for it
Issue list is here: https://github.com/belgaied2/harvester-cli/issues
Resources
The project is written in Go, and using client-go the Kubernetes Go Client libraries to communicate with the Harvester API (which is Kubernetes in fact).
Welcome contributions are:
- Testing it and creating issues
- Documentation
- Go code improvement
What you might learn
Harvester CLI might be interesting to you if you want to learn more about:
- GitHub Actions
- Harvester as a SUSE Product
- Go programming language
- Kubernetes API
- Kubevirt API objects (Manipulating VMs and VM Configuration in Kubernetes using Kubevirt)
Q2Boot - A handy QEMU VM launcher by amanzini
Description
Q2Boot (Qemu Quick Boot) is a command-line tool that wraps QEMU to provide a streamlined experience for launching virtual machines. It automatically configures common settings like KVM acceleration, virtio drivers, and networking while allowing customization through both configuration files and command-line options.
The project originally was a personal utility in D, now recently rewritten in idiomatic Go. It lives at repository https://github.com/ilmanzo/q2boot
Goals
Improve the project, testing with different scenarios , address issues and propose new features. It will benefit of some basic integration testing by providing small sample disk images.
Resources