ONTAP SANドライバを使用してバックエンドを設定する準備をします
変更を提案
PDF
ONTAP SAN ドライバーを使用した ONTAP バックエンドの設定要件と認証オプションについて理解します。
要件
すべての ONTAP バックエンドで、Trident では少なくとも 1 つのアグリゲートを SVM に割り当てる必要があります。
|
"ASA r2システム"は、ストレージ レイヤの実装において、他のONTAPシステム（ASA、AFF、FAS）とは異なります。ASA r2システムでは、アグリゲートの代わりにストレージの可用性ゾーンが使用されます。ASA r2システムでSVMにアグリゲートを割り当てる方法については、"事項を"ナレッジベースの記事を参照してください。 |
複数のドライバを同時に実行し、それぞれに対応するストレージクラスを作成できることも覚えておいてください。たとえば、 `san-dev`ドライバを使用する `ontap-san`クラスと、 `san-default`ドライバを使用する `ontap-san-economy`クラスを設定することができます。
すべての Kubernetes ワーカー ノードに適切な iSCSI ツールがインストールされている必要があります。詳細については、"ワーカーノードを準備する"を参照してください。
ONTAP バックエンドを認証します
Trident では、 ONTAP バックエンドを認証する 2 つのモードが用意されています。
-
認証情報ベース：必要な権限を持つONTAPユーザーのユーザー名とパスワード。 `admin`または `vsadmin`などの事前定義されたセキュリティログインロールを使用して、ONTAPバージョンとの最大限の互換性を確保することをお勧めします。
-
証明書ベース：Tridentは、バックエンドにインストールされた証明書を使用してONTAPクラスタと通信することもできます。ここで、バックエンド定義には、クライアント証明書、キー、および信頼されたCA証明書（使用する場合）のBase64エンコードされた値が含まれている必要があります（推奨）。
既存のバックエンドを更新して、資格情報ベースの方法と証明書ベースの方法を切り替えることができます。ただし、一度にサポートされる認証方法は 1 つだけです。別の認証方法に切り替えるには、バックエンド構成から既存の方法を削除する必要があります。
|
*資格情報と証明書の両方*を提供しようとすると、構成ファイルに複数の認証方法が提供されているというエラーが発生し、バックエンドの作成が失敗します。 |
クレデンシャルベースの認証を有効にする
Trident が ONTAP バックエンドと通信するには、 SVM スコープ / クラスタスコープの管理者のクレデンシャルが必要です。 `admin`や `vsadmin`などの標準の事前定義されたロールを使用することを推奨します。これにより、将来の ONTAP リリースで公開される可能性のある機能 API を将来の Trident リリースで使用できるように、上位互換性が確保されます。カスタムセキュリティログインロールを作成して Trident で使用することもできますが、推奨されません。
サンプルのバックエンド定義は次のようになります：
---
version: 1
backendName: ExampleBackend
storageDriverName: ontap-san
managementLIF: 10.0.0.1
svm: svm_nfs
username: vsadmin
password: password{
"version": 1,
"backendName": "ExampleBackend",
"storageDriverName": "ontap-san",
"managementLIF": "10.0.0.1",
"svm": "svm_nfs",
"username": "vsadmin",
"password": "password"
}バックエンド定義は、クレデンシャルがプレーンテキストで保存される唯一の場所であることに留意してください。バックエンドが作成されると、ユーザ名/パスワードはBase64でエンコードされ、Kubernetesシークレットとして保存されます。バックエンドの作成または更新は、クレデンシャルに関する知識が必要となる唯一のステップです。したがって、これはKubernetes/ストレージ管理者によって実行される管理者専用の操作です。
証明書ベースの認証の有効化
新規および既存のバックエンドは証明書を使用して ONTAP バックエンドと通信できます。バックエンド定義には 3 つのパラメータが必要です。
-
clientCertificate：クライアント証明書の Base64 エンコードされた値。
-
clientPrivateKey：関連付けられた秘密キーの Base64 エンコードされた値。
-
trustedCACertificate：信頼された CA 証明書の Base64 エンコードされた値。信頼できる CA を使用する場合は、このパラメータを指定する必要があります。信頼できる CA が使用されていない場合は、これを無視できます。
一般的なワークフローには次の手順が含まれます。
-
クライアント証明書とキーを生成します。生成時に、Common Name（CN）を認証する ONTAP ユーザーに設定します。
openssl req -x509 -nodes -days 1095 -newkey rsa:2048 -keyout k8senv.key -out k8senv.pem -subj "/C=US/ST=NC/L=RTP/O=NetApp/CN=admin"
-
信頼できる CA 証明書を ONTAP クラスタに追加します。これはストレージ管理者によってすでに処理されている可能性があります。信頼できる CA が使用されていない場合は無視します。
security certificate install -type server -cert-name <trusted-ca-cert-name> -vserver <vserver-name> ssl modify -vserver <vserver-name> -server-enabled true -client-enabled true -common-name <common-name> -serial <SN-from-trusted-CA-cert> -ca <cert-authority>
-
クライアント証明書とキー（手順1から）をONTAPクラスタにインストールします。
security certificate install -type client-ca -cert-name <certificate-name> -vserver <vserver-name> security ssl modify -vserver <vserver-name> -client-enabled true
このコマンドを実行すると、ONTAPは証明書の入力を求めます。手順1で生成された `k8senv.pem`ファイルの内容を貼り付け、 `END`を入力してインストールを完了します。 -
ONTAP セキュリティログインロールが `cert`認証方法をサポートしていることを確認します。
security login create -user-or-group-name admin -application ontapi -authentication-method cert security login create -user-or-group-name admin -application http -authentication-method cert
-
生成された証明書を使用して認証をテストします。<ONTAP Management LIF>と<vserver name>を管理LIF IPとSVM名に置き換えます。
curl -X POST -Lk https://<ONTAP-Management-LIF>/servlets/netapp.servlets.admin.XMLrequest_filer --key k8senv.key --cert ~/k8senv.pem -d '<?xml version="1.0" encoding="UTF-8"?><netapp xmlns="http://www.netapp.com/filer/admin" version="1.21" vfiler="<vserver-name>"><vserver-get></vserver-get></netapp>'
-
証明書、キー、および信頼された CA 証明書を Base64 でエンコードします。
base64 -w 0 k8senv.pem >> cert_base64 base64 -w 0 k8senv.key >> key_base64 base64 -w 0 trustedca.pem >> trustedca_base64
-
前の手順で取得した値を使用してバックエンドを作成します。
cat cert-backend.json { "version": 1, "storageDriverName": "ontap-san", "backendName": "SanBackend", "managementLIF": "1.2.3.4", "svm": "vserver_test", "clientCertificate": "Faaaakkkkeeee...Vaaalllluuuueeee", "clientPrivateKey": "LS0tFaKE...0VaLuES0tLS0K", "trustedCACertificate": "QNFinfO...SiqOyN", "storagePrefix": "myPrefix_" } tridentctl create backend -f cert-backend.json -n trident +------------+----------------+--------------------------------------+--------+---------+ | NAME | STORAGE DRIVER | UUID | STATE | VOLUMES | +------------+----------------+--------------------------------------+--------+---------+ | SanBackend | ontap-san | 586b1cd5-8cf8-428d-a76c-2872713612c1 | online | 0 | +------------+----------------+--------------------------------------+--------+---------+
認証方法を更新するか、クレデンシャルをローテーションする
既存のバックエンドを更新して、別の認証方法を使用したり、資格情報をローテーションしたりすることができます。これは両方向に機能します。ユーザー名/パスワードを使用するバックエンドは証明書を使用するように更新できます。証明書を使用するバックエンドはユーザー名/パスワード ベースに更新できます。これを行うには、既存の認証方法を削除し、新しい認証方法を追加する必要があります。次に、必要なパラメータを含む更新されたbackend.jsonファイルを使用して `tridentctl backend update`を実行します。
cat cert-backend-updated.json
{
"version": 1,
"storageDriverName": "ontap-san",
"backendName": "SanBackend",
"managementLIF": "1.2.3.4",
"svm": "vserver_test",
"username": "vsadmin",
"password": "password",
"storagePrefix": "myPrefix_"
}
#Update backend with tridentctl
tridentctl update backend SanBackend -f cert-backend-updated.json -n trident
+------------+----------------+--------------------------------------+--------+---------+
| NAME | STORAGE DRIVER | UUID | STATE | VOLUMES |
+------------+----------------+--------------------------------------+--------+---------+
| SanBackend | ontap-san | 586b1cd5-8cf8-428d-a76c-2872713612c1 | online | 9 |
+------------+----------------+--------------------------------------+--------+---------+
|
|
パスワードをローテーションする場合、ストレージ管理者はまず ONTAP でユーザーのパスワードを更新する必要があります。続いてバックエンドの更新が行われます。証明書をローテーションする場合、ユーザーに複数の証明書を追加できます。バックエンドは新しい証明書を使用するように更新され、その後古い証明書は ONTAP クラスタから削除できます。 |
バックエンドを更新しても、すでに作成されているボリュームへのアクセスは中断されず、その後に行われたボリューム接続にも影響はありません。バックエンドのアップデートが成功したということは、TridentがONTAPバックエンドと通信でき、今後のボリューム操作を処理できることを示しています。
Trident 用のカスタム ONTAP ロールを作成します
最小限の権限を持つONTAPクラスタロールを作成することで、Tridentで操作を実行するためにONTAP管理者ロールを使用する必要がなくなります。Tridentバックエンド構成にユーザー名を含めると、Tridentは作成したONTAPクラスタロールを使用して操作を実行します。
Tridentカスタムロールの作成の詳細については、"Tridentカスタムロールジェネレーター"を参照してください。
-
次のコマンドを使用して新しいロールを作成します：
security login role create <role_name\> -cmddirname "command" -access all –vserver <svm_name\> -
Tridentユーザーのユーザー名を作成します：
security login create -username <user_name\> -application ontapi -authmethod <password\> -role <name_of_role_in_step_1\> –vserver <svm_name\> -comment "user_description" -
ロールをユーザーにマップします：
security login modify username <user_name\> –vserver <svm_name\> -role <role_name\> -application ontapi -application console -authmethod <password\>
ONTAP System Managerで次の手順を実行します。
-
カスタムロールを作成する：
-
クラスタレベルでカスタムロールを作成するには、* Cluster > Settings *を選択します。
（または）SVMレベルでカスタムロールを作成するには、*ストレージ > ストレージVM >
required SVM> 設定 > ユーザーとロール*を選択します。 -
ユーザーとロール*の横にある矢印アイコン（→*）を選択します。
-
Roles*の下の+Add*を選択します。
-
ロールのルールを定義し、*保存*をクリックします。
-
-
Tridentユーザーに役割をマッピングする：+*ユーザーとロール*ページで次の手順を実行します：
-
ユーザー*の下にある追加アイコン+*を選択します。
-
必要なユーザー名を選択し、*Role*のドロップダウンメニューで役割を選択します。
-
*保存*をクリックします。
-
詳細については、次のページを参照してください：
双方向CHAPによる接続の認証
Tridentは、 `ontap-san`および `ontap-san-economy`ドライバで双方向CHAPを使用してiSCSIセッションを認証できます。これには、バックエンド定義で `useCHAP`オプションを有効にする必要があります。 `true`に設定すると、TridentはSVMのデフォルトのイニシエータセキュリティを双方向CHAPに設定し、バックエンドファイルからユーザー名とシークレットを設定します。NetAppは、接続の認証に双方向CHAPを使用することを推奨します。次のサンプル構成を参照してください：
---
version: 1
storageDriverName: ontap-san
backendName: ontap_san_chap
managementLIF: 192.168.0.135
svm: ontap_iscsi_svm
useCHAP: true
username: vsadmin
password: password
chapInitiatorSecret: cl9qxIm36DKyawxy
chapTargetInitiatorSecret: rqxigXgkesIpwxyz
chapTargetUsername: iJF4heBRT0TCwxyz
chapUsername: uh2aNCLSd6cNwxyz|
|
`useCHAP`パラメータは、一度だけ設定できるブーリアン パラメータです。デフォルトではfalseに設定されています。trueに設定した後は、falseに設定することはできません。 |
`useCHAP=true`に加えて、 `chapInitiatorSecret`、 `chapTargetInitiatorSecret`、 `chapTargetUsername`、および `chapUsername`フィールドはバックエンド定義に含める必要があります。バックエンドを作成した後、 `tridentctl update`を実行することでシークレットを変更できます。
仕組み
`useCHAP`をtrueに設定すると、ストレージ管理者はTridentにストレージバックエンドでCHAPを設定するように指示します。これには次のものが含まれます：
-
SVM で CHAP を設定する：
-
SVMのデフォルトのイニシエータセキュリティタイプがなし（デフォルトで設定）であり、かつボリューム内に既存のLUNが存在しない場合は、Tridentはデフォルトのセキュリティタイプを `CHAP`に設定し、CHAPイニシエータとターゲットのユーザー名とシークレットの構成に進みます。
-
SVMにLUNが含まれている場合、TridentはSVMでCHAPを有効にしません。これにより、SVM上にすでに存在するLUNへのアクセスが制限されなくなります。
-
-
CHAP イニシエーターとターゲットのユーザー名およびシークレットを構成します。これらのオプションは、バックエンド構成で指定する必要があります（上記を参照）。
バックエンドが作成されると、Tridentは対応する `tridentbackend`CRDを作成し、CHAPシークレットとユーザー名をKubernetesシークレットとして保存します。このバックエンドでTridentによって作成されたすべてのPVは、CHAP経由でマウントおよび接続されます。
資格情報をローテーションしてバックエンドを更新する
`backend.json`ファイルでCHAPパラメータを更新することで、CHAP認証情報を更新できます。これには、CHAPシークレットを更新し、 `tridentctl update`コマンドを使用してこれらの変更を反映する必要があります。
|
|
バックエンドのCHAPシークレットを更新する場合は、 `tridentctl`を使用してバックエンドを更新する必要があります。ONTAP CLIまたはONTAP System Managerを使用してストレージクラスタの資格情報を更新しないでください。Tridentはこれらの変更を反映できません。 |
cat backend-san.json
{
"version": 1,
"storageDriverName": "ontap-san",
"backendName": "ontap_san_chap",
"managementLIF": "192.168.0.135",
"svm": "ontap_iscsi_svm",
"useCHAP": true,
"username": "vsadmin",
"password": "password",
"chapInitiatorSecret": "cl9qxUpDaTeD",
"chapTargetInitiatorSecret": "rqxigXgkeUpDaTeD",
"chapTargetUsername": "iJF4heBRT0TCwxyz",
"chapUsername": "uh2aNCLSd6cNwxyz",
}
./tridentctl update backend ontap_san_chap -f backend-san.json -n trident
+----------------+----------------+--------------------------------------+--------+---------+
| NAME | STORAGE DRIVER | UUID | STATE | VOLUMES |
+----------------+----------------+--------------------------------------+--------+---------+
| ontap_san_chap | ontap-san | aa458f3b-ad2d-4378-8a33-1a472ffbeb5c | online | 7 |
+----------------+----------------+--------------------------------------+--------+---------+
既存の接続は影響を受けません。Trident が SVM で資格情報を更新しても、引き続きアクティブなままになります。新しい接続では更新された資格情報が使用され、既存の接続は引き続きアクティブなままになります。古い PV を切断して再接続すると、更新された資格情報が使用されるようになります。