Elemental Operator: support hosts without TPM
an invention by fgiudici
Updated almost 3 years ago. 3 hacker ♥️. 1 follower.

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:

  1. 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.
  2. 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.
  3. 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

add-emoji Elemental Operator repo

add-emoji Discussion on TPM alternatives

Looking for hackers with the skills:

golang

This project is part of:

Hack Week 22

Activity

  • almost 3 years ago: flonnegren liked this project.
  • almost 3 years ago: paulgonin liked this project.
  • almost 3 years ago: ademicev0 liked this project.
  • almost 3 years ago: fgiudici removed keyword tpm from this project.
  • almost 3 years ago: fgiudici added keyword "golang" to this project.
  • almost 3 years ago: fgiudici added keyword "tpm" to this project.
  • almost 3 years ago: fgiudici started this project.
  • almost 3 years ago: fgiudici originated this project.


    • Comments

    • fgiudici
      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 add-emoji )

      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

    • zetisno
      about 1 year ago by zetisno | Reply

      thank

    Similar Projects

    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

    1. Create NFS-Ganesha Package on OBS: nfs-ganesha5, nfs-ganesha6
    2. Create NFS-Ganesha Container Image on OBS: Image
    3. Create a Kubernetes controller for NFS-Ganesha and support the VFS configuration on demand. Mammuthus

    Resources

    NFS-Ganesha

    terraform-provider-feilong by e_bischoff

    Project Description

    People need to test operating systems and applications on s390 platform.

    Installation from scratch solutions include:

    • just deploy and provision manually add-emoji (with the help of ftpboot script, if you are at SUSE)
    • use s3270 terminal emulation (used by openQA people?)
    • use LXC from IBM to start CP commands and analyze the results
    • use zPXE to do some PXE-alike booting (used by the orthos team?)
    • use tessia to install from scratch using autoyast
    • use libvirt for s390 to do some nested virtualization on some already deployed z/VM system
    • directly install a Linux kernel on a LPAR and use kvm + libvirt from there

    Deployment from image solutions include:

    • use ICIC web interface (openstack in disguise, contributed by IBM)
    • use ICIC from the openstack terraform provider (used by Rancher QA)
    • use zvm_ansible to control SMAPI
    • connect directly to SMAPI low-level socket interface

    IBM Cloud Infrastructure Center (ICIC) harnesses the Feilong API, but you can use Feilong without installing ICIC, provided you set up a "z/VM cloud connector" into one of your VMs following this schema.

    What about writing a terraform Feilong provider, just like we have the terraform libvirt provider? That would allow to transparently call Feilong from your main.tf files to deploy and destroy resources on your system/z.

    Other Feilong-based solutions include:

    • make libvirt Feilong-aware
    • simply call Feilong from shell scripts with curl
    • use zvmconnector client python library from Feilong
    • use zthin part of Feilong to directly command SMAPI.

    Goal for Hackweek 23

    My final goal is to be able to easily deploy and provision VMs automatically on a z/VM system, in a way that people might enjoy even outside of SUSE.

    My technical preference is to write a terraform provider plugin, as it is the approach that involves the least software components for our deployments, while remaining clean, and compatible with our existing development infrastructure.

    Goals for Hackweek 24

    Feilong provider works and is used internally by SUSE Manager team. Let's push it forward!

    Let's add support for fiberchannel disks and multipath.

    Possible goals for Hackweek 25

    Modernization, maturity, and maintenance.

    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

    Play with the userfaultfd(2) system call and download on demand using HTTP Range Requests with Golang by rbranco

    Description

    The userfaultfd(2) is a cool system call to handle page faults in user-space. This should allow me to list the contents of an ISO or similar archive without downloading the whole thing. The userfaultfd(2) part can also be done in theory with the PROT_NONE mprotect + SIGSEGV trick, for complete Unix portability, though reportedly being slower.

    Goals

    1. Create my own library for userfaultfd(2) in Golang.
    2. Create my own library for HTTP Range Requests.
    3. Complete portability with Unix.
    4. Benchmarks.
    5. Contribute some tests to LTP.

    Resources

    1. https://docs.kernel.org/admin-guide/mm/userfaultfd.html
    2. https://github.com/loopholelabs/userfaultfd-go
    3. https://github.com/DHowett/ranger
    4. https://www.cons.org/cracauer/cracauer-userfaultfd.html