[Openstack-sigs] [security] A Security Project Proposal

Luke Hinds lhinds at redhat.com
Wed Oct 17 15:24:39 UTC 2018


Hi Ting,

Here's my thoughts on the topic / proposal.

To jump straight to my main concern, I am sceptical of storing a 'trust
state' in yet another API, especially for trusted compute, as we then need
to trust an API and it's less secure (than a TPM) components (database,
memory, disc etc).

Up to present the trusted compute approach in OpenStack has been always
been some type of API query to establish if a node can be 'trusted' and
hooking that into nova's scheduler. One current approach being the traits
API.

The problem with this is that the stored state of 'trusted' is then on disc
or volatile memory , typically a row in a mariaDB table somewhere on the
controller - this then means we immediately lose all of the true
attractiveness of a TPM, that being a tamper proof hardware route of trust
,  unlike an API which sets the 'trust state' in a datastore on disc or
memory (which can be hacked to spoof trust).

So I can't really comment on the current proposal or really get behind it,
as its to vague at present in why it should provide unified trust and how
we would trust it. On the face of it, this proposal appears to be another
actor susceptible to the flaws outlined above. I would need to know how the
above concern would be resolved, so that there is implicit hardware routed
trust presented to the workload wanting a trusted node to schedule upon,
without a go between actor hosting the trust state of compute nodes.

Perhaps you have already solved this, if so I would recommend you outline
it in your proposal.

Best Regards,

Luke

On Wed, Oct 17, 2018 at 3:48 PM TING PANG <chengfeiyoiua at gmail.com> wrote:

> Dear all,
>
> As we all known, security has always been a hot topic among people. In
> OpenStack, if an attacker make a system un-trustworthy, it will make a
> risk for entire infrastructure and affect customers confidence.
> Fortunately, more and more vendors start providing security solutions with
> the trusted computing. It is a security technology based on a hardware
> trust format to improve system integrity and trustworthy. The risks and
> threats on cloud can be mitigated and managed with trusted computing
> technology, which can make a customer more confident when utilizing
> OpenStack.
>
> However, there are some mainstream trusted formats (e.g. TPM, TCM) and
> some special trusted formats provided by vendors (e.g. Google, Microsoft )
> in the world, which cause huge development costs and interoperability
> issues for vendors to support various trusted formats.
>
> To resolve problems above, we want to create a new security project named
> "Hawthorn" that provides a general unified trust management framework to be
> compatible with different trust formats in OpenStack.
>
> More general information can be found here:  *https://wiki.openstack.org/wiki/Hawthorn
> <https://wiki.openstack.org/wiki/Hawthorn>*
>
> Please feel free to contact me if you are interested in this proposal or
> have questions and suggestion.
>
> Best regards,
>
> Ting
>
> _______________________________________________
> openstack-sigs mailing list
> openstack-sigs at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>


-- 
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://lists.openstack.org/pipermail/openstack-sigs/attachments/20181017/db65264c/attachment.html>


More information about the openstack-sigs mailing list