1.4. キーマネージャーポリシーの表示
barbican はポリシーを使用して、キーの追加または削除など、シークレットに対してアクションを実行できるユーザーを決定します。これらのコントロールを実装するには、以前に作成した creator などの keystone プロジェクトロールは barbican 内部パーミッションにマッピングされます。その結果、これらのプロジェクトロールに割り当てられるユーザーは、対応する barbican パーミッションを受信します。
デフォルトのポリシーはコードで定義されるため、通常は修正は必要ありません。ポリシーが変更されていない場合は、環境内の既存のコンテナーを使用してデフォルトポリシーを表示できます。デフォルトポリシーに変更が加えられた場合には、デフォルトを確認する場合は、別のシステムを使用して openstack-barbican-api コンテナーを最初にプルします。
前提条件
- OpenStack Key Manager がデプロイされ、実行している。
手順
Red Hat 認証情報を使用して podman にログインします。
podman login username: ******** password: ********
openstack-barbican-apiコンテナーをプルします。podman pull \ registry.redhat.io/rhosp-rhel8/openstack-barbican-api:17.1
現在の作業ディレクトリーにポリシーファイルを生成します。
podman run -it \ registry.redhat.io/rhosp-rhel8/openstack-barbican-api:17.1 \ oslopolicy-policy-generator \ --namespace barbican > barbican-policy.yaml
検証
barbican-policy.yaml ファイルをチェックして、barbican が使用するポリシーを確認します。ポリシーは、ユーザーがシークレットおよびシークレットメタデータと対話する方法を定義する 4 つの異なるロールによって実装されます。ユーザーは、特定のロールに割り当てられているパーミッションを受け取ります。
admin- admin ロールは、すべてのプロジェクトでシークレットの読み取り、作成、編集、削除を実行できます。
creator- creator ロールは、作成者がスコープ指定されているプロジェクトのシークレットの読み取り、作成、編集、削除を実行できます。
observer- observer ロールは、シークレットの読み取りのみ実行できます。
audit- audit ロールは、メタデータの読み取りのみ実行できます。audit ロールは、シークレットの読み取りは実行できません。
たとえば、以下のエントリーは、各プロジェクトの admin、observer、および creator の keystone ロールをリスト表示します。右側には、role:admin、role:observer、および role:creator パーミッションが割り当てられていることを確認します。
# #"admin": "role:admin" # #"observer": "role:observer" # #"creator": "role:creator"
これらのロールは barbican でグループ化することもできます。たとえば、admin_or_creator を指定するルールは、rule:admin または rule:creator のメンバーに適用できます。
ファイル内では、secret:put および secret:delete のアクションがあります。右側には、これらのアクションを実行するパーミッションがあるロールについて確認してください。以下の例では、secret:delete は、admin および creator ロールメンバーのみがシークレットエントリーを削除できることを意味します。さらに、ルールは、そのプロジェクトの admin または creator ロールのユーザーがそのプロジェクトのシークレットを削除できることを示しています。プロジェクトのマッチは、ポリシーにも定義される secret_project_match ルールで定義されます。
secret:delete": "rule:admin_or_creator and rule:secret_project_match"
