[openstack-dev] [nova] How to properly detect and fence a compromised host (and why I dislike TrustedFilter)
Dulko, Michal
michal.dulko at intel.com
Thu Jun 25 13:09:04 UTC 2015
> -----Original Message-----
> From: John Garbutt [mailto:john at johngarbutt.com]
> Sent: Thursday, June 25, 2015 2:22 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [nova] How to properly detect and fence a
> compromised host (and why I dislike TrustedFilter)
>
> On 24 June 2015 at 09:35, Dulko, Michal <michal.dulko at intel.com> wrote:
> >> -----Original Message-----
> >> From: Sylvain Bauza [mailto:sbauza at redhat.com]
> >> Sent: Wednesday, June 24, 2015 9:39 AM
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> Subject: Re: [openstack-dev] [nova] How to properly detect and fence
> >> a compromised host (and why I dislike TrustedFilter)
(snip)
> >> > So I would suggest using the 3rd-party tools as enhancing way to
> >> supplement our TCP/trustedfilter feature. And the 3rd party tools can
> >> also call attestation API for host attestation.
> >>
> >> I don't see much benefits of keeping such filter for the reasons I
> >> mentioned below. Again, if you want to fence one host, you can just
> >> disable its service, that's enough.
> >
> > This won't address the case in which you have heterogenic environment
> and you want only some important VMs to run on trusted hosts (and for the
> rest of the VMs you don't care).
>
> This is an interesting one to dig into.
>
> I had assumed in this case you put all the VMs that want the attestation
> check in a subset of nodes that are setup to use that set.
> You can do that using host aggregates and our existing filters.
>
> An external system could then just disable hosts within that subset of hosts
> that have the attestation check working.
>
> Does that work for your use case?
It should be fine for this case. But then - why not go further and remove SG API? Let's leave monitoring of services to Pacemaker and NagiOS and they disable them if they consider that service is down.
My point is that following this logic we may use external services to replace any filter that has such simple logic. Is this the right direction?
More information about the OpenStack-dev
mailing list