[Rh-moc-bare-metal] Further discussion on bare metal provisioning

Fri May 4 09:53:03 UTC 2018

Hi Charlie,

Had some time to read over the slides `docs/llsrc-keylime-acsac-v6.ppt` for
keylime and have a few questions:

vTPM , Keylime sits on Xen hypervisor here, what is the state of play with
KVM/QEMU?

You have the question in slide #3 'Cloud Trust Challenges' -  "After I
provision it, how do I know my cloud machine is still good?", but I could
not spot an answer (might be my own misread).

This was one of the concerns that came up in openstack/nova when TPM was
first positioned. Nodes were designated as 'trusted' based on last boot,
but that boot may have been some time ago and the machine may have been
compromised since then.

Do you have a proposal on how to address this 'rear view mirror' level of
Trust, that degrades after the last known good boot?

My own ideas around this have been that Trust should be a weighted factor
somehow, where attributes such as time since last boot are combined with
perhaps post boot factors such as file integrity hashes, os packages are
updated. Then a OP can weight that level of trust themselves for different
workloads and their required privacy level. This is where I favour an open
API approach, so TPM can be a factor in what is 'trust', more than an
complete arbiter.

Regards,

Luke

On Mon, Apr 23, 2018 at 11:32 PM, Munson, Charles - 0553 - MITLL <
Charles.Munson at ll.mit.edu> wrote:

> Hello,
>
>
>
> We are definitely interested in working towards making Keylime a more
> easily supportable attestation infrastructure.  As per the notes from the
> roundtable discussion we had a few weeks ago, outlined are some goals for
> Keylime and attestation:
>
>
>
> *Keylime and attestation.*
>
> *• We believe Keylime could fill a very useful niche upstream, especially
> in that the only project that rivals it -- Intel's OpenCIT -- appears to be
> open-source in name only and probably not truly open to outside
> contributors. We should therefore as a group devote some effort to
> packaging Keylime, building a CI infrastructure around it, and generally
> making it reasonable to use in a production environment. We should also:*
>
> *o do the work necessary to integrate it with the Fedora early boot
> components;*
>
> *o consider whether it should find a home with an existing upstream
> project like Katello (part of Satellite) or FreeIPA (Red Hat identity
> management project);*
>
> *o Examine -- as a research project? -- how to integrate attestation via
> Keylime with the Ironic state machine*
>
>
>
> We have released a new version of Keylime today (v2.3.3) that includes
> IPsec configuration + documentation, as well as some readme improvements:
> https://github.com/mit-ll/python-keylime.  There is also documentation
> available in the /doc/ directory as we pointed out earlier (including our
> ACSAC paper and presentation), and we would be happy to answer any
> questions you may have.
>
>
>
> We have also opened up an issue related to integrating Keylime with the
> Fedora early boot components for easier collaboration, especially if Ali
> chooses to work on this during the summer: https://github.com/mit-ll/
> python-keylime/issues/6
>
>
>
> Additionally, as we discussed with Peter during the Roundtable, we have
> opened an issue to investigate adding TPM 2.0 support to Keylime (see
> https://github.com/mit-ll/python-keylime/issues/5) instead of relying
> only on the older TPM 1.2.
>
>
>
> We would like to discuss the future steps towards making Keylime more
> production-ready so we can complete the goals outlined above, and we are
> certainly open to supporting this effort from our side as well.  We can
> also set up a telecom if you are interested in discussing this further.
>
>
>
> Best regards,
>
> Charlie
>
>
>
> ----
>
> *Charles Munson, Ph.D.* (*x9331*)
>
> Technical Staff
>
> charles.munson at ll.mit.edu
>
> Secure, Resilient Systems and Technology (5-53)
>
> MIT Lincoln Laboratory
>
>
>
>
>
>
>
> From: <rh-moc-bare-metal-bounces at redhat.com> on behalf of Hugh Brock <
> hbrock at redhat.com>
>
> Date: Monday, April 9, 2018 at 5:19 PM
>
> To: "rh-moc-bare-metal at redhat.com" <rh-moc-bare-metal at redhat.com>
>
> Subject: [Rh-moc-bare-metal] Further discussion on bare metal provisioning
>
>
>
> Folks,
>
>
>
> As you have probably seen, I have added you to a new mailing list for the
> purpose of following up on Friday's bare metal provisioning workshop.
> Please feel free to comment on the summary document Orran and I prepared,
> here:
>
>
>
> https://docs.google.com/document/d/1JNmhqCpoG1irj9mb4o46VpISPvN8E
> 7DAICFiT7BwmVk/edit?usp=sharing
>
>
>
> Thanks for your interest. We'll have further updates forthcoming.
>
>
>
> Take care,
>
> --Hugh
>
> --
>
> Hugh Brock, mailto:hbrock at redhat.com
>
> Director of Engineering, Boston University Research Initiatives
>
> ---
>
> "I know that you believe you understand what you think I said, but I'm not
> sure you realize that what you heard is not what I meant." --Robert
> McCloskey
>
> _______________________________________________
> Rh-moc-bare-metal mailing list
> Rh-moc-bare-metal at redhat.com
> https://www.redhat.com/mailman/listinfo/rh-moc-bare-metal
>
>

-- 
Luke Hinds | NFV Partner Engineering | CTO Office | Red Hat
e: lhinds at redhat.com | irc: lhinds @freenode | t: +44 12 52 36 2483
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/rh-moc-bare-metal/attachments/20180504/e37b0187/attachment.htm>