2.2. 永続ボリュームの暗号化のためのストレージクラス
永続ボリューム (PV) 暗号化は、テナント (アプリケーション) の分離および機密性を保証します。PV 暗号化を使用する前に、PV 暗号化のストレージクラスを作成する必要があります。永続ボリュームの暗号化は RBD PV の場合にのみ利用できます。
OpenShift Data Foundation は、HashiCorp Vault での暗号化パスフレーズの保存をサポートします。永続的なボリュームの暗号化のために、外部の鍵管理システム (KMS) を使用して、暗号化対応のストレージクラスを作成することができます。ストレージクラスを作成する前に、KMS へのアクセスを設定する必要があります。
PV 暗号化には、有効な Red Hat OpenShift Data Foundation Advanced サブスクリプションが必要です。詳細については、OpenShift Data Foundation サブスクリプションに関するナレッジベースの記事 を参照してください。
2.2.1. Key Management System (KMS) のアクセス設定
ユースケースに基づいて、次のいずれかの方法を使用して KMS へのアクセスを設定する必要があります。
-
vaulttokens
の使用: ユーザーはトークンを使用して認証できるようになります。 -
vaulttenantsa
(テクノロジープレビュー) の使用: ユーザーはserviceaccounts
を使用してVault
で認証できるようになります。
vaulttenantsa
を使用した KMS へのアクセスはテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
2.2.1.1. vaulttokens
を使用した KMS へのアクセス設定
前提条件
-
OpenShift Data Foundation クラスターは
Ready
状態である。 外部の鍵管理システム (KMS) で、以下を実行します。
-
トークンのあるポリシーが存在し、
Vault
のキー値のバックエンドパスが有効化されていることを確認します。 -
vaulttokens
サーバーで署名済みの証明書を使用していることを確認します。
-
トークンのあるポリシーが存在し、
手順
テナントの namespace にシークレットを作成します。
-
OpenShift Container Platform Web コンソールで、Workloads
Secrets に移動します。 -
Create
Key/value secret をクリックします。 -
Secret Name を
ceph-csi-kms-token
として入力します。 -
Key を
token
として入力します。 Value を入力します。
これは Vault のトークンです。Browse をクリックしてトークンが含まれるファイルを選択し、アップロードするか、テキストボックスにトークンを直接入力します。
- Create をクリックします。
トークンは、ceph-csi-kms-token
を使用するすべての暗号化された PVC が削除された後にのみ削除できます。
2.2.1.2. vaulttenantsa
を使用した KMS へのアクセスの設定
前提条件
-
OpenShift Data Foundation クラスターは
Ready
状態である。 外部の鍵管理システム (KMS) で、以下を実行します。
- ポリシーが存在し、Vault のキー値のバックエンドパスが有効になっていることを確認します。
- Vault サーバーで署名済みの証明書を使用していることを確認します。
以下のようにテナント namespace に以下の serviceaccount を作成します。
$ cat <<EOF | oc create -f - apiVersion: v1 kind: ServiceAccount metadata: name: ceph-csi-vault-sa EOF
手順
OpenShift Data Foundation が Vault
で認証して使用を開始する前に、Kubernetes 認証方法を設定する必要があります。以下の手順では、OpenShift Data Foundation が Vault
で認証できるように、serviceAccount
、ClusterRole
、および ClusterRoleBinding
を作成し、設定します。
以下の YAML を Openshift クラスターに適用します。
apiVersion: v1 kind: ServiceAccount metadata: name: rbd-csi-vault-token-review --- kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: rbd-csi-vault-token-review rules: - apiGroups: ["authentication.k8s.io"] resources: ["tokenreviews"] verbs: ["create", "get", "list"] --- kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: rbd-csi-vault-token-review subjects: - kind: ServiceAccount name: rbd-csi-vault-token-review namespace: openshift-storage roleRef: kind: ClusterRole name: rbd-csi-vault-token-review apiGroup: rbac.authorization.k8s.io
serviceaccount トークンおよび CA 証明書のシークレットを作成します。
$ cat <<EOF | oc create -f - apiVersion: v1 kind: Secret metadata: name: rbd-csi-vault-token-review-token namespace: openshift-storage annotations: kubernetes.io/service-account.name: "rbd-csi-vault-token-review" type: kubernetes.io/service-account-token data: {} EOF
シークレットからトークンと CA 証明書を取得します。
$ SA_JWT_TOKEN=$(oc -n openshift-storage get secret rbd-csi-vault-token-review-token -o jsonpath="{.data['token']}" | base64 --decode; echo) $ SA_CA_CRT=$(oc -n openshift-storage get secret rbd-csi-vault-token-review-token -o jsonpath="{.data['ca\.crt']}" | base64 --decode; echo)
OpenShift クラスターエンドポイントを取得します。
$ OCP_HOST=$(oc config view --minify --flatten -o jsonpath="{.clusters[0].cluster.server}")
前の手順で収集した情報を使用して、以下のように Vault で Kubernetes 認証方法を設定します。
$ vault auth enable kubernetes $ vault write auth/kubernetes/config \ token_reviewer_jwt="$SA_JWT_TOKEN" \ kubernetes_host="$OCP_HOST" \ kubernetes_ca_cert="$SA_CA_CRT"
テナント namespace の Vault にロールを作成します。
$ vault write "auth/kubernetes/role/csi-kubernetes" bound_service_account_names="ceph-csi-vault-sa" bound_service_account_namespaces=<tenant_namespace> policies=<policy_name_in_vault>
csi-kubernetes
は、OpenShift Data Foundation が Vault を検索するデフォルトのロール名です。Openshift Data Foundation クラスターのテナント namespace のデフォルトのサービスアカウント名はceph-csi-vault-sa
です。これらのデフォルト値は、テナント namespace に ConfigMap を作成して上書きできます。デフォルト名の上書きに関する詳細は、Overriding Vault connection details using tenant ConfigMap を参照してください。
YAML 例
PV 暗号化の
vaulttenantsa
メソッドを使用する storageclass を作成するには、既存の ConfigMap を編集するか、Vault との接続を確立するために必要なすべての情報を保持するcsi-kms-connection-details
という名前の ConfigMap を作成する必要があります。以下の yaml のサンプルを使用して、
csi-kms-connection-detail
ConfigMap を更新または作成できます。apiVersion: v1 data: vault-tenant-sa: |- { "encryptionKMSType": "vaulttenantsa", "vaultAddress": "<https://hostname_or_ip_of_vault_server:port>", "vaultTLSServerName": "<vault TLS server name>", "vaultAuthPath": "/v1/auth/kubernetes/login", "vaultAuthNamespace": "<vault auth namespace name>" "vaultNamespace": "<vault namespace name>", "vaultBackendPath": "<vault backend path name>", "vaultCAFromSecret": "<secret containing CA cert>", "vaultClientCertFromSecret": "<secret containing client cert>", "vaultClientCertKeyFromSecret": "<secret containing client private key>", "tenantSAName": "<service account name in the tenant namespace>" } metadata: name: csi-kms-connection-details
encryptionKMSType
Vault での認証にサービスアカウントを使用するには、
vaulttenantsa
に設定します。vaultAddress
:ポート番号を持つ vault サーバーのホスト名または IP アドレス。
vaultTLSServerName
:(オプション)vault の TLS サーバー名
vaultAuthPath
(オプション)Vault で kubernetes 認証メソッドが有効なパス。デフォルトのパスは
kubernetes
です。auth メソッドがkubernetes
以外のパスで有効になっている場合は、この変数を"/v1/auth/<path>/login"
として設定する必要があります。vaultAuthNamespace
(オプション)kubernetes 認証メソッドが有効な Vault namespace。
vaultNamespace
(オプション) キーの保存に使用されるバックエンドパスが存在する Vault namespace
vaultBackendPath
暗号化キーが保存される Vault のバックエンドパス
vaultCAFromSecret
:Vault の CA 証明書が含まれる OpenShift Data Foundation クラスターのシークレット
vaultClientCertFromSecret
Vault のクライアント証明書を含む OpenShift Data Foundation クラスターのシークレット
vaultClientCertKeyFromSecret
Vault のクライアントプライベートキーが含まれる OpenShift Data Foundation クラスターのシークレット
tenantSAName
(オプション) テナント namespace のサービスアカウント名。デフォルト値は
ceph-csi-vault-sa
です。別の名前を使用する場合は、この変数を適切に設定する必要があります。
2.2.2. 永続ボリュームの暗号化のためのストレージクラスの作成
前提条件
ユースケースに基づいて、以下のいずれかの KMS へのアクセスを確実に設定する必要があります。
-
vaulttokens
の使用 : Configuring access to KMS usingvaulttokens
の説明に従って、アクセスを確実に設定してください。 -
vaulttenantsa
の使用 (テクノロジープレビュー): Configuring access to KMS usingvaulttenantsa
の説明に従って、アクセスを確実に設定してください。
手順
-
OpenShift Web コンソールで、Storage
Storage Classes に移動します。 - Create Storage Class をクリックします。
- ストレージクラスの Name および Description を入力します。
- Reclaim Policy について Delete または Retain のいずれかを選択します。デフォルトでは、Delete が選択されます。
- Immediate または WaitForFirstConsumer を Volume binding モード として選択します。WaitForConsumer はデフォルトオプションとして設定されます。
-
永続ボリュームをプロビジョニングするために使用されるプラグインである RBD Provisioner
openshift-storage.rbd.csi.ceph.com
を選択します。 - ボリュームデータが保存される Storage Pool をリストから選択するか、新規プールを作成します。
Enable encryption チェックボックスを選択します。KMS 接続の詳細を設定するオプションは 2 つあります。
-
既存の KMS 接続の選択: ドロップダウンリストから既存の KMS 接続を選択します。このリストは、
csi-kms-connection-details
ConfigMap で利用可能な接続の詳細から設定されます。 新しい KMS 接続の作成: これは、
vaulttokens
にのみ適用されます。- Key Management Service Provider はデフォルトで Vault に設定されます。
- Vault サーバーの一意の 接続名、ホスト アドレス、ポート番号および トークン を入力します。
Advanced Settings をデプロイメントして、
Vault
設定に基づいて追加の設定および証明書の詳細を入力します。- OpenShift Data Foundation 専用かつ特有のキーと値のシークレットパスを Backend Path に入力します。
- オプション: TLS Server Name および Vault Enterprise Namespace を入力します。
- PEM でエンコードされた、該当の証明書ファイルをアップロードし、CA 証明書、クライアント証明書、および クライアントの秘密鍵 を指定します。
- Save をクリックします。
- Save をクリックします。
-
既存の KMS 接続の選択: ドロップダウンリストから既存の KMS 接続を選択します。このリストは、
- Create をクリックします。
HashiCorp Vault 設定により、バックエンドパスによって使用されるキー/値 (KV) シークレットエンジン API バージョンの自動検出が許可されない場合は、ConfigMap を編集して
vaultBackend
パラメーターを追加します。注記vaultBackend
は、バックエンドパスに関連付けられた KV シークレットエンジン API のバージョンを指定するために configmap に追加されるオプションのパラメーターです。値がバックエンドパスに設定されている KV シークレットエンジン API バージョンと一致していることを確認します。一致しない場合には、永続ボリューム要求 (PVC) の作成時に失敗する可能性があります。新規に作成されたストレージクラスによって使用されている encryptionKMSID を特定します。
-
OpenShift Web コンソールで、Storage
Storage Classes に移動します。 -
Storage class 名
YAML タブをクリックします。 ストレージクラスによって使用されている encryptionKMSID を取得します。
以下に例を示します。
encryptionKMSID: 1-vault
-
OpenShift Web コンソールで、Storage
-
OpenShift Web コンソールで Workloads
ConfigMaps に移動します。 - KMS 接続の詳細を表示するには、csi-kms-connection-details をクリックします。
ConfigMap を編集します。
-
アクションメニュー (⋮)
Edit ConfigMap をクリックします。 以前に特定した
encryptionKMSID
に設定されるバックエンドに応じて、vaultBackend
パラメーターを追加します。KV シークレットエンジン API バージョン 1 の場合は
kv
を、KV シークレットエンジン API バージョン 2 の場合はkv-v2
を、それぞれ割り当てることができます。以下に例を示します。
kind: ConfigMap apiVersion: v1 metadata: name: csi-kms-connection-details [...] data: 1-vault: |- { "encryptionKMSType": "vaulttokens", "kmsServiceName": "1-vault", [...] "vaultBackend": "kv-v2" } 2-vault: |- { "encryptionKMSType": "vaulttenantsa", [...] "vaultBackend": "kv" }
- 保存をクリックします。
-
アクションメニュー (⋮)
次のステップ
ストレージクラスを使用して、暗号化された永続ボリュームを作成できます。詳細は、managing persistent volume claims を参照してください。
重要Red Hat はテクノロジーパートナーと連携して、本書をお客様へのサービスとして提供します。ただし、Red Hat では、HashiCorp 製品のサポートを提供していません。この製品に関するテクニカルサポートについては、HashiCorp にお問い合わせください。
2.2.2.1. テナント ConfigMap を使用した Vault 接続の詳細の上書き
Vault 接続の詳細は、openshift-storage
namespace の csi-kms-connection-details
ConfigMap で設定された値とは異なる設定オプションを使用して、OpenShift namespace に ConfigMap を作成することにより、テナントごとに再設定できます。ConfigMap はテナント namespace に配置する必要があります。テナント namespace の ConfigMap の値は、その namespace で作成される暗号化された永続ボリュームの csi-kms-connection-details
ConfigMap に設定された値を上書きします。
手順
- テナント namespace にあることを確認します。
-
Workloads
ConfigMaps をクリックします。 - Create ConfigMap をクリックします。
yaml ファイルの例を以下に示します。指定のテナント namespace について過剰に使用される値は、以下に示すように
data
セクションで指定できます。--- apiVersion: v1 kind: ConfigMap metadata: name: ceph-csi-kms-config data: vaultAddress: "<vault_address:port>" vaultBackendPath: "<backend_path>" vaultTLSServerName: "<vault_tls_server_name>" vaultNamespace: "<vault_namespace>"
- yaml を編集したら、Create をクリックします。