みなさんこんにちは。 Portworxの機能を連載形式でご紹介しております。

-------------------------------------------------------------------------------------------
　入門編　コンテナ環境と「データ」を考える
　第1回　PX-Storeによるボリュームの提供(初級編)
　第2回　PX-Storeによるボリュームの提供(応用編)
　第3回　ボリュームのスナップショット
　第4回　PX-Autopilotによるボリューム・ストレージの自動拡張
　第5回　PX-SecureによるRBACとOwnership
-------------------------------------------------------------------------------------------

連載第1回、第2回でPX-Storeによるボリューム提供方法についてご紹介しました。 ボリュームにデータを配置するにあたり、セキュリティを気にされるお客様もいらっしゃるでしょう。

PX-Secureは認証・認可、RBAC(Role Based Access Control,ロールベースアクセス制御)、Ownership(所有者)、データ暗号化などの機能を提供するものです。 メーカーサイトでは「PX-Security」と表記されている場合もあります。 今回はPX-SecureのRBACやOwnershipに焦点を当て、機能の基礎をご紹介したいと思います。

Portworxにおける認証・認可とRBAC

Portworxはコンテナ環境でデータを扱うための製品ですので、誰でもPortworxの設定やボリュームに変更を加えられてしまうような状態は望ましくありません。 そこで「PX-Secure」を有効化するとPortworxの利用をよりセキュアにすることができます。

Portworxには「ユーザー」の概念があり、PX-Secureではトークンを用いて認証を行います。 トークンが有効であれば、そのユーザーが操作権限を持っているかどうかが判断されます(認可)。

Portworxはクラスター内の操作やボリュームへのアクセス等の権限を管理するために、デフォルトで以下のようなロールを設けています。

・system.admin ... 任意のコマンドを実行可能
・system.view ... 読み取り専用コマンドのみ実行可能
・system.user ... ボリュームライフサイクルコマンド(例: pxctl volume <action>)のみ実行可能
・system.guest ... ユーザーがトークンをPortworxに渡さない場合に利用、Public Volumeに対する操作が可能

Public Volumeについては後述します。 なお、ロールはカスタムで作成することも可能です。詳細についてはメーカーサイトをご参照ください。

　

検証環境

今回は以下のような環境を利用します。

PortworxはOperatorによりインストールされています。(本ブログ記事ではOperatorによりインストールされたPortworxを前提に手順をご紹介いたします。DaemonSetをご利用の場合は操作方法が異なる場合がある点にご留意ください。) Portworxインストール時にPX-CentralでSpecを作成していますが、この際Namespaceとして"portworx"を指定しています。

"pxctl status"コマンドの実行結果は以下の通りです。
　

PX-Secureの有効化

今回使用する環境では前述の通りOperatorによってPortworxをインストールしていますので、メーカーサイト"Secure your storage with the Operator"の記載に従ってPX-Secureを有効化します。 DaemonSetを利用している場合はこちらをご参照ください。

まずは"kubectl get storagecluster"コマンドでCluster IDを確認します。(ここでは"-n"でPortworxをインストールしたNamespaceを指定しています。)"kubectl edit storagecluster"コマンドによりSpecを変更します。Specにsecurity.enabled: trueを追加します。

"kubectl describe storagecluster"コマンドを実行すると、先ほど追加した"security.enabled"以外に新たなパラメータが増えていることが確認できます。
　

Guest Roleによるアクセスの無効化

Public VolumeとGuest Role

ここでPublic Volume(パブリックボリューム)と Guest Role(ゲストロール)という語句について確認しておきたいと思います。

PortworxのボリュームにはOwnership(所有者)を設定することができます。 連載「Portworx基礎」のこれまでのブログ記事では、Ownershipを設定していないボリュームを扱ってきました。Ownership設定のないボリュームはPublic Volumeと呼ばれます。 PX-Secureを有効化する前に作成されたボリュームや、トークンを渡さずに作成したボリュームはPublic Volumeです。さらに、作成したボリュームをPublic Volumeに設定することも可能です。

ボリュームのOwnershipについては"pxctl volume access show"コマンドで確認することができます。 Public Volumeに対して本コマンドを実行すると以下のようにOwnershipが設定されていないことが分かります。

このようなPublic Volumeに対して操作できるのがGuest Roleです。 PX-Secureの認証機能を有効化した後でも、Kubernetesユーザーはトークンを渡さずにGuest RoleによってPublic Volumeの作成や削除が可能です。

ただしPortworxではボリュームをPrivateにすることが推奨されています。 ボリュームに対する操作をOwnershipにより制御できるため、Ownershipが設定されているボリュームの方が安全性が高いと言えます。今回はGuest Roleによるアクセスを無効化し、動作を確認してみたいと思います。

Guest Roleアクセスの無効化と動作確認

Guest Roleによるアクセスはデフォルトで有効になっています。無効化する場合は"kubectl edit storagecluster"コマンドによりSpecを変更します。 具体的にはspec.security.auth.guestAccessに'Disabled'を設定します。

なお、設定を無効化するとトークンなしで作成されたボリュームへのアクセスにはトークンが必要になります。 メーカーサイトも併せてご参照ください。

それではKubernetes側からStorageClassとPVCを利用してボリュームを作成できるか確認してみます。 ここでは以下のStorageClassとPVCを利用し、Namespace "guestrole-test"で動作を確認します。(PortworxはCSIを利用しボリュームを作成することも可能です。ここでは後続のご説明の都合上、こちらの記載に沿ってCSIを利用するStorageClassを作成しています。)

"kubectl apply"コマンドでPVCを作成したのち"kubectl get pvc"コマンドを実行するとPVCのStatusが"Pending"になっていることが確認できます。
"kubectl describe pvc"コマンドを実行すると、認証トークンがなくアクセスが拒否されボリュームのプロビジョンが失敗した旨のイベントを確認できます。
　

PXCLIのコンテキスト設定

PXCLIについては連載第1回でご紹介いたしました。 PX-Secureの有効化以前は、特権ユーザーであればPortworxノード(Kubernetes Workerノード)にログインすることでPXCLI(pxctlコマンド)を実行できていました。

PX-Secureの機能を有効化したことにより、Portworxノード上でPXCLIを実行するとアクセスが拒否されるようになります。赤文字で"couldn't get: /config with error: Access denied token is empty"と表示されています。トークンを渡していないためエラーが発生しているようです。

Portworxの管理者がPXCLIを実行できるようにするために、メーカーサイトに記載の手順に従ってコンテキストを設定します。 今回利用する環境はOperatorによりPortworxをインストールしており、PX-Secureを有効化したことにより以下のSecretが作成されています。

・px-shared-secret ... 共有Secret
・px-admin-token ... 管理者トークン
・px-user-token ... ユーザートークン

今回は"px-admin-token"を利用し、管理者がPXCLIを実行できるようにします。まずは以下のコマンドで管理者トークンを変数ADMIN_TOKENに格納します。("-n"でPortworxがインストールされたNamespaceを指定します)
ADMIN_TOKEN=$(kubectl -n <portworx_namespace> get secret px-admin-token -o json | jq -r '.data."auth-token"' | base64 -d)

以下のコマンドを実行しPortworxが稼働しているPodを確認します。
kubectl -n <portworx_namespace> get pods -l name=portworx -o wide

PXCLIを実行したいノードで稼働しているPodを選び、"pxctl context create"コマンドを実行することでコンテキストを作成します。
kubectl -n <portworx_namespace> exec -ti <portworx_pod> -- /opt/pwx/bin/pxctl context create admin --token=$ADMIN_TOKEN

これにより"kubectl exec"コマンドを実行するとPXCLIを実行できるようになります。以下は"pxctl status"コマンドを実行している例です。
kubectl -n <portworx_namespace> exec -ti <portworx_pod> -- /bin/bash

留意点として、コンテキストの設定は各Portworxノードそれぞれで行う必要があります。 別のPortworxノードに対してPXCLIを実行したい場合には、コンテキストを作成する必要があります。別のPortworxノードにあるPodに以下のコマンドを実行しただけではPXCLIは利用できません。(赤文字で"couldn't get: /config with error: Access denied token is empty"と表示されています。)
kubectl -n <portworx_namespace> exec -ti <portworx_pod> -- /bin/bash

また、トークンの有効期限はデフォルトで24時間です。有効期限が切れた後はコンテキストを更新する必要があります。

　

トークンを渡してPVCを作成する

先ほどPX-Secureを有効化した後にGuest Roleのアクセスを無効化したため、トークンを渡さずにPVCを作ろうとするとPendingになってしまっていました。 今度はトークンを渡してPVCを作成してみたいと思います。 今回はPVCを作成するにあたってSecret "px-user-token"を利用します。

まずはStorageClassを作成します。 先ほどCSIを利用したStorageClassを作成していましたが、CSIを利用したStorageClassの場合、以下のようにオペレーションごとに使用するSecretを指定することが可能です。 Secretの名前とSecretが存在するNamespaceの組み合わせで指定しています。(各キーの詳細についてはKubernetes CSIのドキュメントをご参照ください。) 非CSIのStorageClassについてはメーカーサイトをご参照ください。

さらに以下のPVCを"kubectl apply"します。

StorageClass / PVC / Secretの関係は下図のようになっています。

"kubectl get"コマンドでオブジェクトの状態を確認します。 PVCのStatusがBoundになっておりPVも作成されていることが分かります。

PXCLIによりPortworx側からもボリュームが存在していることが確認できます。

また、このボリュームのOwnershipを確認するとpx-user-tokenが設定されています。Ownershipが設定されているため、(Public Volumeではなく)Private Volumeが作成されたということですね。
　

まとめ

今回はPortworxのRBACやOwnershipの基礎についてご説明いたしました。 Portworxではトークンによって認証が行われます。トークンを渡してPVCを作成することでボリュームにOwnershipを設定しPrivateにできることをご紹介しました。

今回ご紹介した操作ではNamespace "portworx"内のSecret "px-user-token"を一律に利用するStorageClassを作成しましたが、複数のテナントでKubernetesクラスターを共同利用するような場合にはテナントごとに別のトークンを渡す手法がメーカーサイトで紹介されています。 Kubernetesクラスターの用途に応じてご利用頂ければと思います。

　

　

※ サービスや製品の仕様ならびに動作に関しては、予告なく改変される場合があります。
※ 本ブログにおける記載はPortworxバージョン2.12の情報に基づいています。 異なるバージョンにおけるサポート範囲 / 仕様変更等についてはメーカードキュメントをご確認ください。
※ 本ブログ記事でご紹介した操作はOperatorによりインストールされたPortworxを前提としています。 DaemonSetをご利用の環境では手順が異なる場合がございます。