openstack team mailing list archive

[Shawn Starr <shawn.starr@xxxxxxxxxx>]

On Monday, February 25, 2013 10:34:11 PM Jeremy Stanley wrote:
> On 2013-02-25 06:20 -0500 (-0500), Shawn Starr wrote:
> [...]
> 
> > I see no options on how to control what nova-compute nodes can be
> > 'provisioned' into an OpenStack cloud, I'd consider that a
> > security risk (potentially) if any computer could just register to
> > become a nova-compute?
> 
> [...]
> 
> On 2013-02-25 11:42:47 -0500 (-0500), Shawn Starr wrote:
> > I was hoping in future we could have a mechanism via mac address
> > to restrict which hypervisor/nova-computes are able to join the
> > cluster.
> 
> [...]
> 
> It bears mention that restricting by MAC is fairly pointless as
> security protections go. There are a number of tricks an adversary
> can play to rewrite the system's MAC address or otherwise
> impersonate other systems at layer 2. Even filtering by IP address
> doesn't provide you much protection if there are malicious actors
> within your local broadcast domain, but at least there disabling
> learning on switches or implementing 802.1x can buy some relief.
> 
> Extending the use of MAC address references from the local broadcast
> domain where they're intended to be relevant up into the application
> layer (possibly across multiple routed hops well away from their
> original domain of control) makes them even less effective of a
> system identifier from a security perspective.

Hi Jeremy,

Of course, one can modify/spoof the MAC address and or assign themselves an 
IP. It is more so that new machines aren't immediately added to the cluster 
and start launching VM instances without explicitly being enabled to do so. In 
this case, I am not concerned about impersonators on the network trying to 
join the cluster.

Thanks,
Shawn