IscsiChapSupport

• Launchpad Entry: CinderSpec:iscsi-chap
• Created: 13 Aug 2012
• Contributors: Vincent Hou

Summary

CHAP(Challenge-Handshake Authentication Protocol) is an authentication scheme used by Point to Point Protocol (PPP) servers to validate the identity of remote clients. It can applied in iSCSI to authenticate the initiators or the targets. There are several types of CHAP, including one-way authentication, two-way authentication and reverse authentication. At the beginning of this blueprint, one-way CHAP authentication, via which the target authenticates the initiators, will be implemented first.

Release Note

This feature plans to be finished in G version.

User stories

For one-way CHAP authentication, the user can create a volume with a username and a password, enable the authentication of a volume by binding to a username and a password and disbale the authentication of a volume by unbinding the username and the password.

Example of a target description to be saved:

<VirtualHost {{IP_ADDRESS}}:*>
  DocumentRoot "{{HTML_ROOT}}";
</VirtualHost>

As the first stepstone, there are four use cases, which are taken into account for this one-way authentication. It could be more to be implemented.

volume-create-with-authentication:

• When creating a volume, the user can specify three additional parameters, CHAP username, CAHP password and CHAP type to create the credentials for the volume. For the iSCSI target, there are two types of authentication. For one-way authetication, the CHAP type is 'incoming'(The other is 'outgoing'.). The default value can be 'incoming'. In order to make the username and the password consistent with the target, they are saved in the target. The API for creating a volume should be extended with three of these parameters, and so should be the shell command.

attach-volume-with-authentication-to-VM:

• Attach a volume with CHAP authentication to a VM. Two parameters, the username and the password, need to be added to the initiator for the authentication. If the authentication succeeds, it will be attached. Otherwise, the voluem will not be attached.

enable-volume-authentication/volume-bind-username-password:

• An existing volume without authentication can be enabled with the authentication by binding to a username and a password. This can be done when the volume is in the available state without attaching to any instances. Otherwise, exceptions will be raised.

disable-volume-authentication/volume-unbind-username-password:

• The authentication of an existing volume can be disabled by unbinding the username and the password. This can be done when the volume is in the available state. Otherwise, exceptions will be raised. This can be done when the volume is in the available state without attaching to any instances. Otherwise, exceptions will be raised.

Implementation

The username and the password can be implemented with a model called account with a few attributes. There can be one-to-many relationship between the account and the volume. Another way of the implementation can be there is no account model. Username and password only exist when they are bond to a volume(iSCSI target). A username and a password can be bond to a volume and saved in the target or in other secure place. If they are unbond from the volume, they disappeared. At the beginning, the second way will be chosen. The first way can be left for further implementation if necessary.

• Three parameters(username, password and CHAP type) will be added to the volume-create method, including the API, iscsi driver, etc.
• Two parameters(username, and password) will be added to the volume-attach method, including the API, iscsi driver, etc.
• Add one method to enable the authentication for a volume.
• Add one method to disable the authentication for a volume.
• Test cases for the above four use cases.

---