[nova-volume][tgtd] Implement authentication to targets

[David Naori]

[nova-volumes][tgtd]

Currently anyone who is not blocked by iptables (and nova does not implement any related rules by default) can login to targets and get full access to the nova-volumes.

CHAP authentication can be used to prevent this.

[Russell Bryant (russellb)]

After looking at this and talking to David Naori, I don't think we need to treat this as a security vulnerability. I think the problem would be a deployment vulnerability as opposed to a code vulnerability. CHAP support would be a very good security hardening enhancement to make, though. There is a blueprint for it, so it's at least on the radar:

https://blueprints.launchpad.net/cinder/+spec/iscsi-chap

There may be some things we can do in documentation to make sure people know that they should make sure that VM guests are not able to directly access volume nodes.

[Thierry Carrez (ttx)]

I'd agree it's probably not a Nova issue, and more a deployment/packaging issue. By default, Nova needs to be deployed in a way that prevents random VMs from accessing volumes. And a welcome strengthening would be that even in case of internal network compromise, the VMs can't access it either (for example, require CHAP auth).

@Vishy: how could we fix this ?

[Mark McLoughlin (markmc)]

My quick take on irc was that I'm pretty sure tgtd would not be accessible to VMs from their private network. If a cloud operator makes their management network publicly accessible, then this is an issue ... but clearly that's not a sane deployment choice.

However, I had assumed we had at least host/initiator based access control here - the initialize_connection() method supplies the initiator details and we could configure access control from there. That would be a new feature, though, not suitable for backporting because of the regression risk.

[Vish Ishaya (vishvananda)]

targets are not available to vms unless the deployer puts the volume service on a vm routable network. While, chap should be supported by default, I agree with mark that this is a new feature and doesn't warrant a backport.

[Thierry Carrez (ttx)]

OK, then I propose we open up this bug to the public, rename it "Support CHAP auth for volume targets", and consider it a "welcome security strengthening feature" rather than an "exploitable vulnerability". Let me know if you see any problem with that.

[Kurt Seifried (kseifried)]

Is the need for such IPTables/firewalling documented in the install/setup documentation? Can someone point me to it? This issue may need a CVE depending on various factors. Thanks.

[Russell Bryant (russellb)]

This code is no longer in nova. It has moved to Cinder. CHAP support was added in Cinder, so we can consider this done now.