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
Rewrite Distrobox in go (POC) by fabriziosestito
Description
Rewriting Distrobox in Go.
Main benefits:
- Easier to maintain and to test
- Adapter pattern for different container backends (LXC, systemd-nspawn, etc.)
Goals
- Build a minimal starting point with core commands
- Keep the CLI interface compatible: existing users shouldn't notice any difference
- Use a clean Go architecture with adapters for different container backends
- Keep dependencies minimal and binary size small
- Benchmark against the original shell script
Resources
- Upstream project: https://github.com/89luca89/distrobox/
- Distrobox site: https://distrobox.it/
- ArchWiki: https://wiki.archlinux.org/title/Distrobox
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.
- Investigate performance bottlenecks for Blame and Status.
Resources
- https://github.com/go-git/go-git/
- https://go-git.github.io/docs/
Contribute to terraform-provider-libvirt by pinvernizzi
Description
The SUSE Manager (SUMA) teams' main tool for infrastructure automation, Sumaform, largely relies on terraform-provider-libvirt. That provider is also widely used by other teams, both inside and outside SUSE.
It would be good to help the maintainers of this project and give back to the community around it, after all the amazing work that has been already done.
If you're interested in any of infrastructure automation, Terraform, virtualization, tooling development, Go (...) it is also a good chance to learn a bit about them all by putting your hands on an interesting, real-use-case and complex project.
Goals
- Get more familiar with Terraform provider development and libvirt bindings in Go
- Solve some issues and/or implement some features
- Get in touch with the community around the project
Resources
- CONTRIBUTING readme
- Go libvirt library in use by the project
- Terraform plugin development
- "Good first issue" list
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)
Updatecli Autodiscovery supporting WASM plugins by olblak
Description
Updatecli is a Golang Update policy engine that allow to write Update policies in YAML manifest. Updatecli already has a plugin ecosystem for common update strategies such as automating Dockerfile or Kubernetes manifest from Git repositories.
This is what we call autodiscovery where Updatecli generate manifest and apply them dynamically based on some context.
Obviously, the Updatecli project doesn't accept plugins specific to an organization.
I saw project using different languages such as python, C#, or JS to generate those manifest.
It would be great to be able to share and reuse those specific plugins
During the HackWeek, I'll hang on the Updatecli matrix channel
https://matrix.to/#/#Updatecli_community:gitter.im
Goals
Implement autodiscovery plugins using WASM. I am planning to experiment with https://github.com/extism/extism
To build a simple WASM autodiscovery plugin and run it from Updatecli
Resources
- https://github.com/extism/extism
- https://github.com/updatecli/updatecli
- https://www.updatecli.io/docs/core/autodiscovery/
- https://matrix.to/#/#Updatecli_community:gitter.im