Jump to: navigation, search

Difference between revisions of "IscsiChapSupport"

Line 7: Line 7:
 
A server
 
A server
  
−
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.  
+
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.
−
At the beginning of this blueprint, one-way CHAP authentication, via which the target authenticates the initiators, will be implemented first.
 
  
 
== Release Note ==
 
== Release Note ==
Line 19: Line 18:
 
Example of a target description to be saved:
 
Example of a target description to be saved:
  
−
* --volume_manager=nova.volume.manager.[[VolumeManager]] --volume_driver=nova.volume.san.SolidFireSanISCSIDriver --iscsi_ip_prefix=192.168.69.211 --san_ip=192.168.69.210 --san_login=cluster_login --san_password=password --poolname=nova
 
  
−
So far there are three use cases, which are taken into account for this one-way authentication. It could be more to be implemented.
+
<pre><nowiki>
 +
<VirtualHost {{IP_ADDRESS}}:*>
 +
  DocumentRoot "{{HTML_ROOT}}";
 +
</VirtualHost>
 +
</nowiki></pre>
 +
 
 +
 
 +
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:
 
volume-create-with-authentication:
Line 27: Line 32:
 
* 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.
 
* 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.
  
−
volume-attach:
+
attach-volume-with-authentication-to-VM:
  
−
* Volume is attached using the current iSCSI/nova api methods. Model updates are done during creation as well as export to avoid re-scans.
+
* 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.
  
−
volume-delete:
+
enable-volume-authentication/volume-bind-username-password:
  
−
* The [[SolidFire]] driver verifies the volume_name from the database as well as the account and issues the [[SolidFire]] API call to delete the volume.
+
* 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.
  
−
On volume_create()
+
disable-volume-authentication/volume-unbind-username-password:
  
−
* A user account name is built based on a concatenation of the compute nodes hostname and the project-id ie on compute node with hostname 'myhost' and a project_if of '1' the result would be:
+
* 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.
−
** 'myhost-1'
 
−
 
 
−
This has been tested with the current Diablo release using the nova api, as well as with the current Trunk release of Essex (devstack install
 
  
 
== Assumptions ==
 
== Assumptions ==
 
== Design ==
 
== Design ==
 
== Implementation ==
 
== 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.
 +
 
== Test/Demo Plan ==
 
== Test/Demo Plan ==
 
== Unresolved issues ==
 
== Unresolved issues ==

Revision as of 13:06, 14 August 2012

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

Summary

A server

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.

Rationale

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.

Assumptions

Design

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.

Test/Demo Plan

Unresolved issues

BoF agenda and discussion

Retrieved from "https://wiki.openstack.org/w/index.php?title=IscsiChapSupport&oldid=993"