Meeting 22/02/23

[THS-on]

Project Board

https://github.com/orgs/keylime/projects/1

Attendees

Attendees

• [x] @ansasaki
• [ ] @aplanas
• [ ] @edwards-n
• [x] @galmasi
• [ ] @gustavobbrand
• [x] @kkaarreell
• [x] @lkatalin
• [ ] @iolivergithub
• [ ] @lukehinds
• [x] @maugustosilva
• [ ] @mdrocco
• [x] @mbestavros
• [x] @mheese
• [ ] @mpeters
• [ ] @osresearch
• [ ] @ruocco
• [x] @stringlytyped
• [x] @stefanberger
• [x] @THS-on
• [x] @tpletcher-hpe
• [ ] @ueno

Time: Time: 22/02/23 15:30 GMT, 16:30 CET (https://www.timeanddate.com/worldclock/fixedtime.html?msg=Keylime+Meeting&iso=20230222T1530&p1=769&ah=1) Link: https://uni-kiel.zoom.us/j/63493301176?pwd=RDlraWpMRUtya0JHNlhsaGtUaU9pQT09

Topics

• Release schedule for rust agent
• Document release cycle more clearly
• Separate repo for guidelines, CoC etc.
• zeroMQ and agent rovocations
• potential policy engine for Keylime
• Removal of dependency on tpm2-tools on the verifier
• Removal of keylime.conf - https://github.com/keylime/keylime/pull/1133
• Removal of the python agent - https://github.com/keylime/keylime/pull/1289
• State of ./run_local.sh
• Kubernetes integration
• End of term for @mpeters + propose @maugustosilva - https://github.com/keylime/keylime/pull/1320

Actions

• Fedora e2e test cover most of the test suite reduce ./run_local.sh script to only run unit tests.
• @THS-on will work on the Python agent removal next week
• @maugustosilva will write a proposal for the removal of the agent revocation
• @maugustosilva will provide a document on how to scale Keylime

Meeting notes

Release schedules

• The Python side moves to a monthly schedule with a release in the first week of the month
• Rust agent will also follow this model starting in April or when the publishing of the creates is implemented
• Release schedule gets documented in the docs page
• Minor releases can be made also during the month

Open PRs

• Removal of the python agent - WIP: remove Python agent keylime#1289
  • @THS-on will work on that
• Removal of keylime.conf - Draft: Remove keylime.conf keylime#1133
  • Nothing relies on the keylime.conf anymore
  • Should be done before 7.0.0

Agent revocations

• remove support for zeroMQ in the next bigger release (already disabled in the rust agent by default)
• remove the feature entirely in a couple of releases, because it has some flaws when used at scale and does not guarantee that the agent receives and processes the message.

DSSE

See https://github.com/keylime/keylime/pull/1320

Separate repo for guidelines CoC etc.

• Keep the information in the main repo for now
• Add entry to docs for better visibility

End of term for @mpeters + propose @maugustosilva - End of term for @mpeters + propose @maugustosilva keylime#1320

• If you are a maintainer please vote on that change!
• After the change we update the current maintainer list: (ask current rust maintainers and ask current maintainers on their status)

Kubernetes integration

• @maugustosilva will provide a document on how to scale Keylime
• HELM chart to deploy the control plane (verifier, registrar) is a good idea
• We should discuss stable server side APIs, after cleaning them up

Removal of dependency on tpm2-tools on the verifier

• Keylime currently uses: tpm2_print, tpm2_checkqoute, tpm2_makecredential and tpm2_eventlog
• Potential library to replace tpm2_eventlog from @galmasi: https://github.com/galmasi/python3-uefi-eventlog

HPE Aurora and Keylime

More next month from @tpletcher-hpe

potential policy engine for Keylime

• Potential canidates are OPA with Regor or Seedwing (https://github.com/seedwing-io/seedwing-policy)
• Some experiments are done with Measured Boot and IMA, more results in the next couple of months

[lkatalin]

Could we add a topic, "potential policy engine for Keylime"?

[THS-on]

@lkatalin added :+1:

[mheese]

@THS-on I would like to talk about a potential Kubernetes integration topic.

This is essentially what we are going to develop at Hedgehog (think of it as a "tenant controller"), and if there is broader interest we would of course like to make this an open source contribution (which means I would take that into account while planning/preparing the design).

[THS-on]

@mheese added. Sounds definitely interesting and is probably a good reason to think about adding stable support for server side APIs.

If you want to see another tenant implementation you can look at the middleware between Keylime and our exam system that I work on: https://github.com/Lernstick/Lernstick-Bridge

[mpeters]

I unfortunately won't be able to attend as I'll be travelling, but wanted to add topic for discussion - "End of term for @mpeters + propose @maugustosilva"