Meeting 28/06/23

[THS-on]

Attendees

• @ansasaki
• @aplanas
• @edwards-n
• @galmasi
• @kkaarreell
• @lkatalin
• @lukehinds
• @maugustosilva
• @mdrocco
• @mbestavros
• @mheese
• @mpeters
• @osresearch
• @ruocco
• @stringlytyped
• @stefanberger
• @THS-on
• @tpletcher-hpe
• @ueno
• Isaac
• Supreshna

Time: 27/06/23 15:30 BST (https://www.timeanddate.com/worldclock/fixedtime.html?msg=Keylime+Meeting&iso=20230627T1530&p1=136&ah=1)
Link: https://ibm.webex.com/ibm/j.php?MTID=m75a71317639649f0b924f04d69027b56

Topics

• Architecture
  * Ongoing effort to make Measured Boot Attestation (MBA) more flexible with support for plugins (mba: making MBA policy parser and checker pluggable keylime#1410)
• Technical debt
  * Fixes for keylime_tenant (tenant: log cleanup and output improvements keylime#1409)
• Kubernetization
  * Initial version of a (non-scale out) helm chart available at https://github.com/keylime/attestation-operator.git
  * A somewhat functional, end-to-end "scale out" deployment in available under the "hack" directory
• Proposal
  * Client-side (i.e., keylime_tenant) "sharding": the code, as it is written currently, requires that "add", "delete", "update" and "reactivate" operations over an agent to be directed to a specific verifier. While it would be possible to have a less than conventional load balancer algorithm to to ensure this behavior (e.g., consistent hashing using the keylime_tenant requests URI, which contains the agent UUID) I would like to at least explore the possibility to have client-side consistent hashing (using the --uuid/-u as the key)

Actions

• New release this week (28/06/2023): 7.3

Meeting notes

[galmasi]

Adding discussion items to the "architecture" part for upcoming changes:

• mba: alternative policy agent based on OPA; potentially seedwing later.
• mba: alternative pure-python event log parser. Potential unresolved question with whether to merge the code or keep separate. We all guess this depends on community acceptance.
• registration: adding a policy engine as an alternative to running an "accept/reject" bash script. This would require some tenant changes, to allow per-agent registration policy. It would also accommodate confidential computing requirements (e.g. acceptance policy for a boot measurement).

[mheese]

adding items to the Kubernetization part:

• agent Dockerfiles need review, and decision on how to proceed
• there is a questionable PR for the keylime_tenant docker image from me here, I'd like to discuss what the best strategy is to proceed
• I hopefully have a POC for Kubernetes CRDs by tomorrow to demo, can't promise though that it's ready (today is quite busy for me)

on the client-side sharding proposal:

• there are currently a few things which work against our Kubernetization effort, namely:
  • agents bind to instances of verifiers
  • that makes every instance of a verifier essential, and breaks high availability (no other verifier can take over until the old one is "repaired")
  • agents do not recover on restart, which breaks a core Kubernetes tennet: all components must be self-healing
• moving towards a push model might remove this requirement?
• a job based system that distributes and load-balances verifier "jobs" amongst all verifiers would also eliminate the need for binding an agent to a verifier, eliminate HA concerns, and make the solution more scalable altogether (it would also eliminate potential vertical-scale issues)

[maugustosilva]

@mheese Let's discuss tomorrow: the fact of the matter is that Keylime is packaged by several maintainers (Red Hat, SuSe, Debian), and any radical architectural change will take months, if not years, to supersede what is currently in place (i.e., we would have to support both modes of operation for quite a while).