ストレージバックエンドの暗号化の設定
Astra Control Provisionerを使用すると、管理対象クラスタとストレージバックエンドの間のトラフィックの暗号化を有効にすることで、データアクセスセキュリティを強化できます。
Astra Control Provisionerは、次の2種類のストレージバックエンドでKerberos暗号化をサポートします。
-
*オンプレミスのONTAP *- Astra Control Provisionerは、Red Hat OpenShiftおよびアップストリームのKubernetesクラスタからオンプレミスのONTAPボリュームへのNFSv3およびNFSv4接続でKerberos暗号化をサポートします。
-
* Azure NetApp Files *- Astra Control Provisionerは、アップストリームのKubernetesクラスタからAzure NetApp FilesボリュームへのNFSv4.1接続でKerberos暗号化をサポートします。
作成、削除、サイズ変更、スナップショット、クローン、 読み取り専用のクローンを作成し、NFS暗号化を使用するボリュームをインポートします。
オンプレミスのONTAPボリュームでの転送中Kerberos暗号化の設定
管理対象クラスタとオンプレミスのONTAPストレージバックエンドの間のストレージトラフィックに対してKerberos暗号化を有効にすることができます。
オンプレミスのONTAPストレージバックエンドを使用するNFSトラフィックに対するKerberos暗号化は、 ontap-nas ストレージドライバ。
|
-
管理対象クラスタでAstra Control Provisionerが有効になっていることを確認します。を参照してください "Astra Control Provisionerを有効にする" 手順については、を参照し
-
にアクセスできることを確認します。
tridentctl
ユーティリティ。 -
ONTAPストレージバックエンドへの管理者アクセス権があることを確認します。
-
ONTAPストレージバックエンドから共有するボリュームの名前を確認しておきます。
-
NFSボリュームのKerberos暗号化をサポートするようにONTAP Storage VMを準備しておく必要があります。を参照してください "データ LIF で Kerberos を有効にします" 手順については、を参照し
-
Kerberos暗号化で使用するNFSv4ボリュームが正しく設定されていることを確認します。『NetApp NFSv4ドメイン設定』のセクション(13ページ)を参照してください。 "『NetApp NFSv4 Enhancements and Best Practices Guide』"。
ONTAPエクスポートポリシーを追加または変更する
既存のONTAPエクスポートポリシーにルールを追加するか、ONTAP Storage VMのルートボリュームおよびアップストリームのKubernetesクラスタと共有するONTAPボリュームに対してKerberos暗号化をサポートする新しいエクスポートポリシーを作成する必要があります。追加するエクスポートポリシールールまたは新規に作成するエクスポートポリシーでは、次のアクセスプロトコルとアクセス権限がサポートされている必要があります。
NFS、NFSv3、およびNFSv4の各アクセスプロトコルを使用してエクスポートポリシーを設定します。
ボリュームのニーズに応じて、次の3つのバージョンのいずれかを設定できます。
-
* Kerberos 5 *-(認証と暗号化)
-
* Kerberos 5i *-(ID保護による認証と暗号化)
-
* Kerberos 5p *-(IDおよびプライバシー保護による認証および暗号化)
適切なアクセス権限を指定してONTAPエクスポートポリシールールを設定します。たとえば、Kerberos 5i暗号化とKerberos 5p暗号化が混在しているNFSボリュームをクラスタにマウントする場合は、次のアクセス設定を使用します。
を入力します | 読み取り専用アクセス | 読み取り/書き込みアクセス | スーパーユーザアクセス |
---|---|---|---|
「 UNIX 」 |
有効 |
有効 |
有効 |
Kerberos 5i |
有効 |
有効 |
有効 |
Kerberos 5p |
有効 |
有効 |
有効 |
ONTAPエクスポートポリシーおよびエクスポートポリシールールの作成方法については、次のドキュメントを参照してください。
ストレージバックエンドの作成
Kerberos暗号化機能を含むAstra Control Provisionerストレージバックエンド構成を作成できます。
Kerberos暗号化を設定するストレージバックエンド構成ファイルを作成するときに、 spec.nfsMountOptions
パラメータ:
-
spec.nfsMountOptions: sec=krb5
(認証と暗号化) -
spec.nfsMountOptions: sec=krb5i
(ID保護による認証と暗号化) -
spec.nfsMountOptions: sec=krb5p
(IDおよびプライバシー保護による認証および暗号化)
Kerberosレベルを1つだけ指定してください。パラメータリストで複数のKerberos暗号化レベルを指定した場合は、最初のオプションのみが使用されます。
-
管理対象クラスタで、次の例を使用してストレージバックエンド構成ファイルを作成します。括弧<>の値は、環境の情報で置き換えます。
apiVersion: v1 kind: Secret metadata: name: backend-ontap-nas-secret type: Opaque stringData: clientID: <CLIENT_ID> clientSecret: <CLIENT_SECRET> --- apiVersion: trident.netapp.io/v1 kind: TridentBackendConfig metadata: name: backend-ontap-nas spec: version: 1 storageDriverName: "ontap-nas" managementLIF: <STORAGE_VM_MGMT_LIF_IP_ADDRESS> dataLIF: <PROTOCOL_LIF_FQDN_OR_IP_ADDRESS> svm: <STORAGE_VM_NAME> username: <STORAGE_VM_USERNAME_CREDENTIAL> password: <STORAGE_VM_PASSWORD_CREDENTIAL> nasType: nfs nfsMountOptions: ["sec=krb5i"] #can be krb5, krb5i, or krb5p qtreesPerFlexvol: credentials: name: backend-ontap-nas-secret
-
前の手順で作成した構成ファイルを使用して、バックエンドを作成します。
tridentctl create backend -f <backend-configuration-file>
バックエンドの作成に失敗した場合は、バックエンドの設定に何か問題があります。次のコマンドを実行すると、ログを表示して原因を特定できます。
tridentctl logs
構成ファイルで問題を特定して修正したら、 create コマンドを再度実行できます。
ストレージクラスを作成する。
ストレージクラスを作成して、Kerberos暗号化を使用してボリュームをプロビジョニングできます。
ストレージクラスオブジェクトを作成するときに、を使用して3つの異なるバージョンのKerberos暗号化のいずれかを指定できます。 mountOptions
パラメータ:
-
mountOptions: sec=krb5
(認証と暗号化) -
mountOptions: sec=krb5i
(ID保護による認証と暗号化) -
mountOptions: sec=krb5p
(IDおよびプライバシー保護による認証および暗号化)
Kerberosレベルを1つだけ指定してください。パラメータリストで複数のKerberos暗号化レベルを指定した場合は、最初のオプションのみが使用されます。ストレージバックエンド構成で指定した暗号化レベルがストレージクラスオブジェクトで指定したレベルと異なる場合は、ストレージクラスオブジェクトが優先されます。
-
次の例を使用して、StorageClass Kubernetesオブジェクトを作成します。
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: ontap-nas-sc provisioner: csi.trident.netapp.io mountOptions: ["sec=krb5i"] #can be krb5, krb5i, or krb5p parameters: backendType: "ontap-nas" storagePools: "ontapnas_pool" trident.netapp.io/nasType: "nfs" allowVolumeExpansion: True
-
ストレージクラスを作成します。
kubectl create -f sample-input/storage-class-ontap-nas-sc.yaml
-
ストレージクラスが作成されていることを確認します。
kubectl get sc ontap-nas-sc
次のような出力が表示されます。
NAME PROVISIONER AGE ontap-nas-sc csi.trident.netapp.io 15h
ボリュームのプロビジョニング
ストレージバックエンドとストレージクラスを作成したら、ボリュームをプロビジョニングできるようになりました。手順については、を参照してください "ボリュームをプロビジョニングする"。
Azure NetApp Filesボリュームでの転送中Kerberos暗号化の設定
管理対象クラスタと単一のAzure NetApp FilesストレージバックエンドまたはAzure NetApp Filesストレージバックエンドの仮想プールの間のストレージトラフィックに対してKerberos暗号化を有効にすることができます。
-
管理対象のRed Hat OpenShiftクラスタでAstra Control Provisionerが有効になっていることを確認します。を参照してください "Astra Control Provisionerを有効にする" 手順については、を参照し
-
にアクセスできることを確認します。
tridentctl
ユーティリティ。 -
要件を確認し、次の手順に従って、Kerberos暗号化用のAzure NetApp Filesストレージバックエンドの準備が完了していることを確認します。 "Azure NetApp Files のドキュメント"。
-
Kerberos暗号化で使用するNFSv4ボリュームが正しく設定されていることを確認します。『NetApp NFSv4ドメイン設定』のセクション(13ページ)を参照してください。 "『NetApp NFSv4 Enhancements and Best Practices Guide』"。
ストレージバックエンドの作成
Kerberos暗号化機能を含むAzure NetApp Filesストレージバックエンド構成を作成できます。
Kerberos暗号化を設定するストレージバックエンド構成ファイルを作成する場合は、次の2つのレベルのいずれかで適用するように定義できます。
-
ストレージバックエンドレベル*を使用して
spec.kerberos
フィールド -
仮想プールレベル*を使用して
spec.storage.kerberos
フィールド
仮想プールレベルで構成を定義する場合、ストレージクラスのラベルを使用してプールが選択されます。
どちらのレベルでも、次の3つのバージョンのKerberos暗号化のいずれかを指定できます。
-
kerberos: sec=krb5
(認証と暗号化) -
kerberos: sec=krb5i
(ID保護による認証と暗号化) -
kerberos: sec=krb5p
(IDおよびプライバシー保護による認証および暗号化)
-
管理対象クラスタで、ストレージバックエンドを定義する必要がある場所(ストレージバックエンドレベルまたは仮想プールレベル)に応じて、次のいずれかの例を使用してストレージバックエンド構成ファイルを作成します。括弧<>の値は、環境の情報で置き換えます。
ストレージバックエンドレベルの例apiVersion: v1 kind: Secret metadata: name: backend-tbc-anf-secret type: Opaque stringData: clientID: <CLIENT_ID> clientSecret: <CLIENT_SECRET> --- apiVersion: trident.netapp.io/v1 kind: TridentBackendConfig metadata: name: backend-tbc-anf spec: version: 1 storageDriverName: azure-netapp-files subscriptionID: <SUBSCRIPTION_ID> tenantID: <TENANT_ID> location: <AZURE_REGION_LOCATION> serviceLevel: Standard networkFeatures: Standard capacityPools: <CAPACITY_POOL> resourceGroups: <RESOURCE_GROUP> netappAccounts: <NETAPP_ACCOUNT> virtualNetwork: <VIRTUAL_NETWORK> subnet: <SUBNET> nasType: nfs kerberos: sec=krb5i #can be krb5, krb5i, or krb5p credentials: name: backend-tbc-anf-secret
仮想プールレベルの例apiVersion: v1 kind: Secret metadata: name: backend-tbc-anf-secret type: Opaque stringData: clientID: <CLIENT_ID> clientSecret: <CLIENT_SECRET> --- apiVersion: trident.netapp.io/v1 kind: TridentBackendConfig metadata: name: backend-tbc-anf spec: version: 1 storageDriverName: azure-netapp-files subscriptionID: <SUBSCRIPTION_ID> tenantID: <TENANT_ID> location: <AZURE_REGION_LOCATION> serviceLevel: Standard networkFeatures: Standard capacityPools: <CAPACITY_POOL> resourceGroups: <RESOURCE_GROUP> netappAccounts: <NETAPP_ACCOUNT> virtualNetwork: <VIRTUAL_NETWORK> subnet: <SUBNET> nasType: nfs storage: - labels: type: encryption kerberos: sec=krb5i #can be krb5, krb5i, or krb5p credentials: name: backend-tbc-anf-secret
-
前の手順で作成した構成ファイルを使用して、バックエンドを作成します。
tridentctl create backend -f <backend-configuration-file>
バックエンドの作成に失敗した場合は、バックエンドの設定に何か問題があります。次のコマンドを実行すると、ログを表示して原因を特定できます。
tridentctl logs
構成ファイルで問題を特定して修正したら、 create コマンドを再度実行できます。
ストレージクラスを作成する。
ストレージクラスを作成して、Kerberos暗号化を使用してボリュームをプロビジョニングできます。
-
次の例を使用して、StorageClass Kubernetesオブジェクトを作成します。
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: anf-sc-nfs provisioner: csi.trident.netapp.io parameters: backendType: "azure-netapp-files" trident.netapp.io/nasType: "nfs" selector: "type=encryption"
-
ストレージクラスを作成します。
kubectl create -f sample-input/storage-class-anf-sc-nfs.yaml
-
ストレージクラスが作成されていることを確認します。
kubectl get sc anf-sc-nfs
次のような出力が表示されます。
NAME PROVISIONER AGE anf-sc-nfs csi.trident.netapp.io 15h
ボリュームのプロビジョニング
ストレージバックエンドとストレージクラスを作成したら、ボリュームをプロビジョニングできるようになりました。手順については、を参照してください "ボリュームをプロビジョニングする"。