<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">Le 24/06/2015 19:56, Joe Gordon a
écrit :<br>
</div>
<blockquote
cite="mid:CAHXdxOedgyWi_uAtrPhzTo59XSKshbQ1ExK473qVpdPeR32XPw@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Jun 23, 2015 at 3:41 AM,
Sylvain Bauza <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:sbauza@redhat.com" target="_blank">sbauza@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi team,<br>
<br>
Some discussion occurred over IRC about a bug which was
publicly open related to TrustedFilter [1]<br>
I want to take the opportunity for raising my concerns
about that specific filter, why I dislike it and how I
think we could improve the situation - and clarify
everyone's thoughts)<br>
<br>
The current situation is that way : Nova only checks if
one host is compromised only when the scheduler is called,
ie. only when booting/migrating/evacuating/unshelving an
instance (well, not exactly all the evacuate/live-migrate
cases, but let's not discuss about that now). When the
request goes in the scheduler, all the hosts are checked
against all the enabled filters and the TrustedFilter is
making an external HTTP(S) call to the Attestation API
service (not handled by Nova) for *each host* to see if
the host is valid (not compromised) or not.<br>
<br>
To be clear, that's the only in-tree scheduler filter
which explicitly does an external call to a separate
service that Nova is not managing. I can see at least 3
reasons for thinking about why it's bad :<br>
<br>
#1 : that's a terrible bottleneck for performance, because
we're IO-blocking N times given N hosts (we're even not
multiplexing the HTTP requests)<br>
#2 : all the filters are checking an internal Nova state
for the host (called HostState) but that the
TrustedFilter, which means that conceptually we defer the
decision to a 3rd-party engine<br>
#3 : that Attestation API services becomes a de facto
dependency for Nova (since it's an in-tree filter) while
it's not listed as a dependency and thus not gated.<br>
<br>
<br>
All of these reasons could be acceptable if that would
cover the exposed usecase given in [1] (ie. I want to make
sure that if my host gets compromised, my instances will
not be running on that host) but that just doesn't work,
due to the situation I mentioned above.<br>
<br>
So, given that, here are my thoughts :<br>
a/ if a host gets compromised, we can just disable its
service to prevent its election as a valid destination
host. There is no need for a specialised filter.<br>
b/ if a host is compromised, we can assume that the
instances have to resurrect elsewhere, ie. we can call a
nova evacuate<br>
c/ checking if an host is compromised or not is not a Nova
responsibility since it's already perfectly done by [2]<br>
<br>
In other words, I'm considering that "security" usecase as
something analog as the HA usecase [3] where we need a
3rd-party tool responsible for periodically checking the
state of the hosts, and if compromised then call the Nova
API for fencing the host and evacuating the compromised
instances.<br>
<br>
Given that, I'm proposing to deprecate TrustedFilter and
explictly mention to drop it from in-tree in a later cycle
<a moz-do-not-send="true"
href="https://review.openstack.org/194592"
rel="noreferrer" target="_blank">https://review.openstack.org/194592</a></blockquote>
<div><br>
</div>
<div>Given people are using this, it is a negligible
maintenance burden. I think deprecating with the
intention of removing is not worth it.</div>
<div><br>
</div>
<div>Although it would be very useful to further document
the risks with this filter (live migration, possible
performance issues etc.)</div>
<div> </div>
</div>
</div>
</div>
</blockquote>
<br>
Well, I can understand that customers could not be agreeing to
remove the filter because there is no clear alternative for them.
That said, I think saying that the filter is deprecated without
saying when it would be removed would help some contributors
thinking about that and working on a better solution, exactly like
we did for EC2 API.<br>
<br>
To be clear, I want to freeze the filter by deprecating it and
explaining why it's wrong (by amending the devref section and giving
a LOG warning saying it's deprecated) and then leave the filter
within in-tree unless we are sure that there is a good solution out
of Nova.<br>
<br>
-Sylvain<br>
<br>
<br>
<blockquote
cite="mid:CAHXdxOedgyWi_uAtrPhzTo59XSKshbQ1ExK473qVpdPeR32XPw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Thoughts ?<br>
-Sylvain<br>
<br>
<br>
<br>
[1] <a moz-do-not-send="true"
href="https://bugs.launchpad.net/nova/+bug/1456228"
rel="noreferrer" target="_blank">https://bugs.launchpad.net/nova/+bug/1456228</a><br>
[2] <a moz-do-not-send="true"
href="https://github.com/OpenAttestation/OpenAttestation"
rel="noreferrer" target="_blank">https://github.com/OpenAttestation/OpenAttestation</a><br>
[3] <a moz-do-not-send="true"
href="http://blog.russellbryant.net/2014/10/15/openstack-instance-ha-proposal/"
rel="noreferrer" target="_blank">http://blog.russellbryant.net/2014/10/15/openstack-instance-ha-proposal/</a><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage
questions)<br>
Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>