30 cephx
を使用した認証 #
クライアントを識別して中間者攻撃を防御するため、Cephはcephx
認証システムを提供します。このコンテキストの「クライアント」とは、人間のユーザ(管理者ユーザなど)またはCeph関連サービス/デーモン(たとえば、OSD、Monitor、Object Gateway)のどちらかです。
cephx
プロトコルは、TLS/SSLと異なり、転送中のデータ暗号化には対応していません。
30.1 認証アーキテクチャ #
cephx
は、認証に共有秘密鍵を使用します。つまり、クライアントとCeph Monitorの両方がクライアントの秘密鍵のコピーを持ちます。この認証プロトコルでは、実際に鍵を公開することなく、両者が鍵のコピーを持っていることをお互いに証明できます。これによって相互認証が提供されます。つまり、クラスタはユーザが秘密鍵を所有していることを信頼し、ユーザはクラスタが秘密鍵を持っていることを信頼します。
Cephの重要なスケーラビリティ機能は、Ceph Object Storeへの中央インタフェースの必要がないところです。つまり、CephクライアントはOSDと直接対話できます。データを保護するため、Cephはcephx
認証システムを備えており、これによってCephクライアントを認証します。
各Monitorでクライアントを認証して鍵を配布することができ、この結果cephx
の使用時にSPOF (single point of failure)やボトルネックがなくなります。Monitorは、Cephサービスを利用する際に使用するセッションキーが含まれる認証データ構造を返します。このセッションキー自体がクライアントの永続的な秘密鍵で暗号化されているため、そのクライアントのみがCeph Monitorにサービスを要求できます。その後、クライアントはセッションキーを使用して必要なサービスをMonitorに要求し、Monitorは、データを実際に処理するOSDに対してクライアントを認証するチケットをクライアントに提供します。CephのMonitorとOSDは秘密を共有するので、クライアントは、Monitorが提供するチケットをクラスタ内の任意のOSDまたはメタデータサーバで使用できます。cephx
チケットは期限切れになるため、攻撃者が不正に入手した期限切れのチケットやセッションキーを使用することはできません。
cephx
を使用するには、まず管理者がクライアント/ユーザをセットアップする必要があります。次の図では、client.admin
ユーザがコマンドラインからceph auth get-or-create-key
を呼び出して、ユーザ名と秘密鍵を生成します。Cephのauth
サブシステムは、ユーザ名と鍵を生成してMonitorにコピーを保存し、ユーザの秘密をclient.admin
ユーザに戻します。つまり、クライアントとMonitorが秘密鍵を共有します。
cephx
基本認証 #Monitorで認証する場合、クライアントはMonitorにユーザ名を渡します。Monitorは、セッションキーを生成して、それをユーザ名に関連付けられている秘密鍵で暗号化し、暗号化されたチケットをクライアントに戻します。その後、クライアントは共有秘密鍵でデータを復号化して、セッションキーを取得します。このセッションキーは、現在のセッション中、ユーザを識別します。次にクライアントは、このセッションキーによって署名された、ユーザに関連するチケットを要求します。Monitorはチケットを生成し、ユーザの秘密鍵で暗号化してクライアントに戻します。クライアントはチケットを復号化し、そのチケットを使用して、クラスタ全体のOSDとメタデータサーバに対する要求に署名します。
cephx
認証 #
cephx
プロトコルは、クライアントマシンとCephサーバとの間で進行中の通信を認証します。初期認証後にクライアントとサーバとの間で送信される各メッセージは、Monitor、OSD、およびメタデータサーバがその共有秘密で検証できるチケットを使用して署名されます。
cephx
認証 - MDSとOSD #この認証は、CephクライアントとCephクラスタホストとの間の保護を提供します。Cephクライアントより先は認証されません。ユーザがリモートホストからCephクライアントにアクセスする場合、ユーザのホストとクライアントホストとの間の接続にはCeph認証は適用されません。
30.2 キー管理 #
このセクションでは、Cephクライアントユーザ、およびCeph Storage Clusterでの認証と権限付与について説明します。「ユーザ」とは、個人、またはCephクライアントを使用してCeph Storage Clusterデーモンと対話するシステムアクタ(アプリケーションなど)のいずれかです。
認証と権限付与を有効にして(デフォルトで有効)Cephを実行している場合、ユーザ名と、指定したユーザの秘密鍵が含まれるキーリングを指定する必要があります(通常はコマンドラインを使用)。ユーザ名を指定しない場合、client.admin
がデフォルトのユーザ名として使用されます。キーリングを指定しない場合、Ceph設定ファイルのキーリング設定を使用してキーリングが検索されます。たとえば、ユーザ名またはキーリングを指定せずにceph health
コマンドを実行すると、Cephはコマンドを次のように解釈します。
cephuser@adm >
ceph -n client.admin --keyring=/etc/ceph/ceph.client.admin.keyring health
または、CEPH_ARGS
環境変数を使用して、ユーザ名と秘密の再入力を避けることができます。
30.2.1 予備知識 #
Cephクライアントのタイプ(たとえば、Block Device、Object Storage、File System、ネイティブAPI)に関係なく、Cephはすべてのデータを「プール」内にオブジェクトとして保存します。Cephユーザがデータを読み書きするには、プールに対するアクセスが必要です。さらに、Cephの管理コマンドを使用するための実行許可も必要です。Cephのユーザ管理を理解するには、次の概念が役立ちます。
30.2.1.1 ユーザ #
ユーザとは、個人またはシステムアクタ(アプリケーションなど)のいずれかです。ユーザを作成することによって、誰が(または何が)Ceph Storage Cluster、そのプール、およびプール内のデータにアクセスできるかを制御できます。
Cephでは、ユーザの「タイプ」を使用します。ユーザ管理の目的では、タイプは常にclient
です。Cephは、ユーザタイプとユーザIDで構成される、ピリオド(.)区切り形式でユーザを識別します。たとえば、TYPE.ID
、client.admin
、client.user1
などです。ユーザタイプを使用する理由は、Ceph Monitor、OSD、およびメタデータサーバもcephxプロトコルを使用しますが、これらはクライアントではないためです。ユーザタイプを区別すると、クライアントユーザと他のユーザを容易に区別でき、アクセス制御、ユーザのモニタリング、および追跡可能性が効率化されます。
場合によっては、Cephのユーザタイプがわかりにくいことがあります。Cephのコマンドラインでは、コマンドラインの使用法に応じて、タイプを指定しても指定しなくてもユーザを指定できるためです。--user
または--id
を指定する場合は、タイプを省略できます。そのため、client.user1
を単にuser1
として入力できます。--name
または-n
を指定する場合は、client.user1
のようにタイプと名前を指定する必要があります。ベストプラクティスとして、可能な限りタイプと名前を使用することをお勧めします。
Ceph Storage Clusterユーザは、Ceph Object StorageユーザやCeph File Systemユーザと同じではありません。Ceph Object Gatewayは、ゲートウェイデーモンとStorage Clusterとの間の通信にCeph Storage Clusterユーザを使用しますが、ゲートウェイにはエンドユーザ向けの独自のユーザ管理機能があります。Ceph File SystemはPOSIXセマンティクスを使用します。そこに関連付けられているユーザスペースは、Ceph Storage Clusterユーザと同じでありません。
30.2.1.2 権限付与とケーパビリティ #
Cephでは、認証ユーザにMonitor、OSD、およびメタデータサーバの機能を実行する権限を付与することを説明するために、「ケーパビリティ(cap)」という用語を使用します。ケーパビリティはプールまたはプールネームスペース内のデータへのアクセスを制限することもできます。ユーザの作成または更新時にCeph管理者ユーザがユーザのケーパビリティを設定します。
ケーパビリティの構文は次の形式に従います。
daemon-type 'allow capability' [...]
次に、各サービスタイプのケーパビリティのリストを示します。
- Monitorのケーパビリティ
r
、w
、x
、およびallow profile cap
を含めます。mon 'allow rwx' mon 'allow profile osd'
- OSDのケーパビリティ
r
、w
、x
、class-read
、class-write
、およびprofile osd
を含めます。さらに、プールとネームスペースも設定できます。osd 'allow capability' [pool=poolname] [namespace=namespace-name]
- MDSのケーパビリティ
allow
または空白のみが必要です。mds 'allow'
次のエントリで各ケーパビリティについて説明します。
- allow
デーモンのアクセス設定の前に付けます。MDSの場合にのみ、暗黙的に
rw
を示します。- r
ユーザに読み込みアクセスを付与します。CRUSHマップを取得するためにMonitorで必要です。
- w
ユーザにオブジェクトへの書き込みアクセスを付与します。
- x
クラスメソッドを呼び出すためのケーパビリティ(読み込みと書き込みの両方)、およびMonitorで
auth
操作を実行するためのケーパビリティをユーザに付与します。- class-read
クラス読み込みメソッドを呼び出すためのケーパビリティをユーザに付与します。
x
のサブセットです。- class-write
クラス書き込みメソッドを呼び出すためのケーパビリティをユーザに付与します。
x
のサブセットです。- *
特定のデーモン/プールに対する読み込み、書き込み、および実行の許可と、管理コマンドの実行機能をユーザに付与します。
- profile osd
他のOSDまたはMonitorにOSDとして接続するための許可をユーザに付与します。OSDがレプリケーションハートビートトラフィックと状態レポートを処理できるようにするために、OSDに付与されます。
- profile mds
他のMDSまたはMonitorにMDSとして接続するための許可をユーザに付与します。
- profile bootstrap-osd
OSDをブートするための許可をユーザに付与します。展開ツールに対して委任され、OSDのブート時にキーを追加するための許可を展開ツールに付与します。
- profile bootstrap-mds
メタデータサーバをブートするための許可をユーザに付与します。展開ツールに対して委任され、メタデータサーバのブート時にキーを追加するための許可を展開ツールに付与します。
30.2.1.3 プール #
プールは、ユーザがデータを保存する論理パーティションです。Cephの展開環境では、一般的に、類似するデータタイプ用の論理パーティションとしてプールを作成します。たとえば、CephをOpenStackのバックエンドとして展開する場合、標準的な展開には、ボリューム、イメージ、バックアップ、および仮想マシン用のプールと、client.glance
やclient.cinder
などのユーザが存在します。
30.2.2 ユーザの管理 #
ユーザ管理機能により、Cephクラスタ管理者は、Cephクラスタ内でユーザを直接作成、更新、および削除できます。
Cephクラスタ内でユーザを作成または削除する場合、キーをクライアントに配布して、キーリングに追加できるようにする必要があります。詳細については30.2.3項 「キーリングの管理」を参照してください。
30.2.2.1 ユーザの一覧 #
クラスタ内のユーザを一覧にするには、次のコマンドを実行します。
cephuser@adm >
ceph auth list
クラスタ内のすべてのユーザが一覧にされます。たとえば、2ノードのクラスタでは、ceph auth list
の出力は次のようになります。
installed auth entries: osd.0 key: AQCvCbtToC6MDhAATtuT70Sl+DymPCfDSsyV4w== caps: [mon] allow profile osd caps: [osd] allow * osd.1 key: AQC4CbtTCFJBChAAVq5spj0ff4eHZICxIOVZeA== caps: [mon] allow profile osd caps: [osd] allow * client.admin key: AQBHCbtT6APDHhAA5W00cBchwkQjh3dkKsyPjw== caps: [mds] allow caps: [mon] allow * caps: [osd] allow * client.bootstrap-mds key: AQBICbtTOK9uGBAAdbe5zcIGHZL3T/u2g6EBww== caps: [mon] allow profile bootstrap-mds client.bootstrap-osd key: AQBHCbtT4GxqORAADE5u7RkpCN/oo4e5W0uBtw== caps: [mon] allow profile bootstrap-osd
ユーザのTYPE.ID
表記は、osd.0
の場合、タイプがosd
のユーザを指定し、そのIDが0
になるように適用されることに注意してください。client.admin
の場合は、タイプがclient
のユーザで、そのIDはadmin
です。さらに、各エントリにkey: value
のエントリと1つ以上のcaps:
エントリもあることにも注意してください。
-o filename
オプションとceph auth list
を使用して、出力をファイルに保存できます。
30.2.2.2 ユーザに関する情報の取得 #
特定のユーザ、キー、およびケーパビリティを取得するには、次のコマンドを実行します。
cephuser@adm >
ceph auth get TYPE.ID
例:
cephuser@adm >
ceph auth get client.admin
exported keyring for client.admin
[client.admin]
key = AQA19uZUqIwkHxAAFuUwvq0eJD4S173oFRxe0g==
caps mds = "allow"
caps mon = "allow *"
caps osd = "allow *"
開発者の場合は次のコマンドを実行することもできます。
cephuser@adm >
ceph auth export TYPE.ID
auth export
コマンドはauth get
と同じですが、内部の認証IDも出力します。
30.2.2.3 ユーザの追加 #
ユーザを追加すると、ユーザの作成に使用するコマンドで指定したユーザ名(TYPE.ID
)、秘密鍵、およびケーパビリティが作成されます。
ユーザのキーにより、ユーザはCeph Storage Clusterで認証できます。ユーザのケーパビリティは、Ceph Monitor (mon)、Ceph OSD (osd)、またはCeph Metadata Server (mds)に対する読み込み、書き込み、および実行の各権限をユーザに付与します。
次のように、ユーザを追加する場合、いくつかのコマンドを利用できます。
ceph auth add
ユーザを追加する場合の標準の方法です。ユーザを作成してキーを生成し、指定したケーパビリティを追加します。
ceph auth get-or-create
このコマンドはユーザ名(かっこ内)とキーが含まれるキーファイルフォーマットを返すため、多くの場合、ユーザを作成する場合に最も便利な方法です。ユーザがすでに存在する場合は、単にユーザ名とキーをキーファイルフォーマットで返します。
-o filename
オプションを使用して、出力をファイルに保存できます。ceph auth get-or-create-key
ユーザを作成して、そのユーザのキー(のみ)を返す場合に便利です。キーのみが必要なクライアント(たとえば、
libvirt
)で役立ちます。ユーザがすでに存在する場合は、単にキーを返します。-o filename
オプションを使用して、出力をファイルに保存できます。
クライアントユーザを作成する際に、ケーパビリティを持たないユーザを作成できます。ケーパビリティを持たないユーザは、認証はできますが、それ以上の操作は実行できません。このようなクライアントはMonitorからクラスタマップを取得できません。ただし、ケーパビリティの追加を延期する場合、後でceph auth caps
コマンドを使用して、ケーパビリティを持たないユーザを作成できます。
通常のユーザは、少なくともCeph Monitorに対する読み込みケーパビリティと、Ceph OSDに対する読み込みおよび書き込みのケーパビリティを持ちます。さらに、ほとんどの場合、ユーザのOSD許可は特定のプールへのアクセスに制限されます。
cephuser@adm >
ceph auth add client.john mon 'allow r' osd \ 'allow rw pool=liverpool'cephuser@adm >
ceph auth get-or-create client.paul mon 'allow r' osd \ 'allow rw pool=liverpool'cephuser@adm >
ceph auth get-or-create client.george mon 'allow r' osd \ 'allow rw pool=liverpool' -o george.keyringcephuser@adm >
ceph auth get-or-create-key client.ringo mon 'allow r' osd \ 'allow rw pool=liverpool' -o ringo.key
OSDに対するケーパビリティをユーザに提供しながら、特定のプールにアクセスを制限「しない」場合、そのユーザはクラスタ内の「すべて」のプールへのアクセスを持ちます。
30.2.2.4 ユーザのケーパビリティの変更 #
ceph auth caps
コマンドを使用して、ユーザを指定してそのユーザのケーパビリティを変更できます。新しいケーパビリティを設定すると、現在のケーパビリティは上書きされます。現在のケーパビリティを表示するには、ceph auth get USERTYPE.USERID
。ケーパビリティを追加するには、次の形式を使用する際に既存のケーパビリティを指定する必要もあります。
cephuser@adm >
ceph auth caps USERTYPE.USERID daemon 'allow [r|w|x|*|...] \
[pool=pool-name] [namespace=namespace-name]' [daemon 'allow [r|w|x|*|...] \
[pool=pool-name] [namespace=namespace-name]']
例:
cephuser@adm >
ceph auth get client.johncephuser@adm >
ceph auth caps client.john mon 'allow r' osd 'allow rw pool=prague'cephuser@adm >
ceph auth caps client.paul mon 'allow rw' osd 'allow r pool=prague'cephuser@adm >
ceph auth caps client.brian-manager mon 'allow *' osd 'allow *'
ケーパビリティを削除する場合、ケーパビリティをリセットできます。すでに設定されている、特定のデーモンへのアクセスをユーザに付与しない場合、空の文字列を指定します。
cephuser@adm >
ceph auth caps client.ringo mon ' ' osd ' '
30.2.2.5 ユーザの削除 #
ユーザを削除するには、ceph auth del
を使用します。
cephuser@adm >
ceph auth del TYPE.ID
ここで、TYPEはclient
、osd
、mon
、またはmds
のいずれかで、IDはデーモンのユーザ名またはIDです。
存在しなくなったプール専用の許可を持つユーザを作成した場合は、それらのユーザの削除も検討することをお勧めします。
30.2.2.6 ユーザのキーの出力 #
ユーザの認証キーを標準出力に出力するには、次のコマンドを実行します。
cephuser@adm >
ceph auth print-key TYPE.ID
ここで、TYPEはclient
、osd
、mon
、またはmds
のいずれかで、IDはデーモンのユーザ名またはIDです。
ユーザのキーを出力すると、クライアントソフトウェアにユーザのキー(libvirt
など)を入力する必要がある場合に便利です。次に例を示します。
#
mount -t ceph host:/ mount_point \
-o name=client.user,secret=`ceph auth print-key client.user`
30.2.2.7 ユーザのインポート #
1人以上のユーザをインポートするには、ceph auth import
を使用し、キーリングを指定します。
cephuser@adm >
ceph auth import -i /etc/ceph/ceph.keyring
Ceph Storage Clusterは、新しいユーザ、キー、およびケーパビリティを追加し、既存のユーザ、キー、およびケーパビリティを更新します。
30.2.3 キーリングの管理 #
CephクライアントでCephにアクセスすると、クライアントはローカルキーリングを検索します。Cephにより、デフォルトで次の4つのキーリング名を使用してキーリング設定が事前設定されるため、デフォルトを上書きする場合を除き、ユーザがCeph設定ファイルでキーリングを設定する必要はありません。
/etc/ceph/cluster.name.keyring /etc/ceph/cluster.keyring /etc/ceph/keyring /etc/ceph/keyring.bin
clusterメタ変数は、Ceph設定ファイルの名前で定義されているCephクラスタ名です。ceph.conf
は、クラスタ名がceph
であるため、ceph.keyring
になることを意味します。nameメタ変数は、ユーザタイプとユーザID(たとえば、client.admin
)であるため、ceph.client.admin.keyring
になります。
ユーザ(たとえば、client.ringo
)を変更した後、キーを取得してCephクライアント上のキーリングに追加し、ユーザがCeph Storage Clusterにアクセスできるようにする必要があります。
Ceph Storage Cluster内でユーザを直接一覧、取得、追加、変更、および削除する方法の詳細については、30.2項 「キー管理」を参照してください。ただし、Cephには、Cephクライアントからキーリングを管理できるceph-authtool
ユーティリティも用意されています。
30.2.3.1 キーリングの作成 #
30.2項 「キー管理」の手順を使用してユーザを作成した場合、ユーザのキーをCephクライアントに提供し、クライアントが指定のユーザのキーを取得してCeph Storage Clusterで認証できるようにする必要があります。Cephクライアントは、キーリングにアクセスしてユーザ名を検索し、ユーザのキーを取得します。
cephuser@adm >
ceph-authtool --create-keyring /path/to/keyring
複数のユーザが含まれるキーリングを作成する場合は、キーリングのファイル名にクラスタ名(たとえば、cluster.keyring)を使用して、/etc/ceph
ディレクトリに保存することをお勧めします。これにより、Ceph設定ファイルのローカルコピーで指定しなくても、キーリング設定のデフォルト設定でこのファイル名が選択されます。たとえば、次のコマンドを実行して、ceph.keyring
を作成します。
cephuser@adm >
ceph-authtool -C /etc/ceph/ceph.keyring
1人のユーザが含まれるキーリングを作成する場合は、クラスタ名、ユーザタイプ、およびユーザ名を指定して、/etc/ceph
ディレクトリに保存することをお勧めします。たとえば、ユーザがの場合は、
ceph.client.admin.keyringclient.admin
とします。
30.2.3.2 キーリングにユーザを追加 #
Ceph Storage Clusterにユーザを追加する場合(30.2.2.3項 「ユーザの追加」を参照)、ユーザ、キー、およびケーパビリティを取得して、そのユーザをキーリングに保存できます。
1つのキーリングにつき1人のユーザのみを使用する場合は、ceph auth get
コマンドを-o
オプションと共に使用して、出力をキーリングファイルフォーマットで保存します。たとえば、client.admin
ユーザのキーリングを作成するには、次のコマンドを実行します。
cephuser@adm >
ceph auth get client.admin -o /etc/ceph/ceph.client.admin.keyring
キーリングにユーザをインポートする場合は、ceph-authtool
を使用して、インポート先のキーリングとインポート元のキーリングを指定します。
cephuser@adm >
ceph-authtool /etc/ceph/ceph.keyring \
--import-keyring /etc/ceph/ceph.client.admin.keyring
キーリングがセキュリティ侵害を受けた場合は、/etc/ceph
ディレクトリからキーを削除し、30.2.3.1項 「キーリングの作成」と同じ手順を使用して新しいキーを再作成してください。
30.2.3.3 ユーザの作成 #
Cephでは、Ceph Storage Cluster内でユーザを直接作成するためのceph auth add
コマンドが提供されています。ただし、Cephクライアントのキーリング上でユーザ、キー、およびケーパビリティを直接作成することもできます。その後、ユーザをCeph Storage Clusterにインポートできます。
cephuser@adm >
ceph-authtool -n client.ringo --cap osd 'allow rwx' \
--cap mon 'allow rwx' /etc/ceph/ceph.keyring
キーリングの作成と、そのキーリングに新しいユーザを追加する操作を同時に行うこともできます。
cephuser@adm >
ceph-authtool -C /etc/ceph/ceph.keyring -n client.ringo \
--cap osd 'allow rwx' --cap mon 'allow rwx' --gen-key
前のシナリオでは、新しいユーザclient.ringo
はキーリング内にのみ存在します。新しいユーザをCeph Storage Clusterに追加するには、同じようにクラスタに新しいユーザを追加する必要があります。
cephuser@adm >
ceph auth add client.ringo -i /etc/ceph/ceph.keyring
30.2.3.4 ユーザの変更 #
キーリング内のユーザレコードのケーパビリティを変更するには、キーリングとユーザ、およびその後にケーパビリティを指定します。
cephuser@adm >
ceph-authtool /etc/ceph/ceph.keyring -n client.ringo \
--cap osd 'allow rwx' --cap mon 'allow rwx'
変更したユーザをCephクラスタ環境内で更新するには、Cephクラスタ内でキーリングからユーザエントリに変更をインポートする必要があります。
cephuser@adm >
ceph auth import -i /etc/ceph/ceph.keyring
キーリングからCeph Storage Clusterユーザを更新する方法の詳細については、30.2.2.7項 「ユーザのインポート」を参照してください。
30.2.4 コマンドラインの使用法 #
ceph
コマンドは、ユーザ名と秘密の操作に関連する次のオプションをサポートします。
--id
または--user
Cephは、ユーザをタイプとIDで識別します(TYPE.ID。
client.admin
またはclient.user1
など)。id
、name
、および-n
のオプションを使用して、ユーザ名のID部分を指定できます(たとえば、admin
やuser1
)。--idでユーザを指定して、タイプを省略できます。たとえば、ユーザclient.fooを指定するには、次のコマンドを入力します。cephuser@adm >
ceph --id foo --keyring /path/to/keyring healthcephuser@adm >
ceph --user foo --keyring /path/to/keyring health--name
または-n
Cephは、ユーザをタイプとIDで識別します(TYPE.ID。
client.admin
またはclient.user1
など)。--name
および-n
のオプションを使用して、完全修飾ユーザ名を指定できます。ユーザタイプ(通常はclient
)とユーザIDを指定する必要があります。cephuser@adm >
ceph --name client.foo --keyring /path/to/keyring healthcephuser@adm >
ceph -n client.foo --keyring /path/to/keyring health--keyring
1つ以上のユーザ名と秘密が含まれるキーリングのパス。
--secret
オプションも同じ機能を提供しますが、Object Gatewayでは動作しません。Object Gatewayでは、--secret
は別の目的で使用されます。ceph auth get-or-create
を使用してキーリングを取得し、ローカルに保存できます。キーリングのパスを切り替えずにユーザ名を切り替えることができるため、お勧めの方法です。cephuser@adm >
rbd map --id foo --keyring /path/to/keyring mypool/myimage