Apache Polarisとは？IcebergカタログのRBACとDocker導入手順【1.7.0対応】

Apache Polarisは、Apache Icebergテーブルの「どこにあるか」と「誰が触ってよいか」を1か所に集めるオープンソースのRESTカタログです。2026年2月にApacheソフトウェア財団のインキュベーターを卒業してトップレベルプロジェクトとなり、2026年8月2日に1.7.0が公開されました。この記事では、Polarisが引き受ける責務の範囲、Docker Composeでの起動、SparkとTrinoからの接続設定、RBACの権限粒度、クライアントへ払い出される一時資格情報（credential vending）までを、公式ドキュメントとリリース成果物で確認した値だけで解説します。

まとめ：Apache Polaris 1.7.0の要点

• PolarisはIceberg REST仕様を実装したカタログサーバーで、テーブルの所在（メタデータの位置）と権限を持ちます。データファイルそのものは持ちません。
• 2026年2月にトップレベルプロジェクトへ昇格し、1.4.0以降は版名からincubatingが外れました。最新は1.7.0（2026年8月2日公開）です。
• 評価用ならDocker Composeのワンライナー1行で起動し、カタログとプリンシパルまで自動生成されます。ただし永続化されません。
• 認可はプリンシパル、プリンシパルロール、カタログロール、権限の4層で、権限はテーブル/ビュー/名前空間/カタログ/ポリシーの5系統に分かれます。
• 本番投入では既定値のままでは足りず、RSA鍵の固定、realmヘッダー必須化、PostgreSQL永続化、bootstrap、FILEストレージ無効化の5点を変更します。
• Web UIはサーバー本体に同梱されず、別リポジトリのPolaris Consoleを立てる構成です。

以下、各項目を実際の設定値まで落として説明します。

Icebergテーブルの所在と権限を担うRESTカタログ

Icebergが決める範囲とPolarisが決める範囲

Icebergはテーブルフォーマットの仕様であり、スキーマ、パーティション、スナップショットの表現方法を定めます。一方で「そのテーブルの現在のメタデータファイルはどれか」を指し示す役割はカタログの担当で、Iceberg本体には含まれません。Polarisはこのカタログ層をIceberg REST仕様の実装として提供します。ファイル形式との層の違いはApache IcebergとParquetの違い｜テーブル形式とファイル形式の関係を整理で整理しています。

Polarisが独自に足しているのは認可です。Hive MetastoreやAWS Glueをカタログに使う構成では、権限はエンジン側やストレージ側のIAMで別途組む必要がありました。Polarisはカタログ自身がRBACを持ち、認可の結果として一時的なストレージ資格情報をクライアントへ払い出します。権限をストレージ側に寄せる代表例はAWS Lake Formationとは？データレイクの権限管理・使い方・料金と実装判断を解説【2026年版】です。

Snowflake Open Catalogとの関係

Snowflake Open Catalogは、SnowflakeのドキュメントにSnowflake Open Catalog is a managed service for Apache Polaris™.と明記されているとおり、Polarisのマネージドサービスです。自前でサーバーを運用するか、Snowflakeのインフラ上のホスト型を使うかの違いで、クライアントから見えるプロトコルはどちらもIceberg RESTです。

ただし新規に選べる選択肢ではなくなりました。同じページにCustomers who haven't previously created a Snowflake Open Catalog account can't sign up for their first Open Catalog account.とあり、新規顧客の案内先はSnowflake Horizon Catalogとは？機能と設定SQLを解説で扱うHorizon Catalogに切り替わっています。既存アカウントを持たない組織がマネージドを検討するなら、比較対象はOpen CatalogではなくHorizon Catalogです。Databricks側の同種レイヤーとの比較軸はUnity Catalogとは？3レベル名前空間と権限継承・移行判断を実装視点で解説【2026年版】で扱っています。

インキュベーション卒業から1.7.0までのリリース推移

Polarisは2024年7月にSnowflakeがオープンソースとして公開し、その後Apacheのインキュベーターに入りました。昇格の日付は情報源で割れており、ASFインキュベーターのステータスページは2026-02-15 Graduation as TLP.、プロジェクト自身の告知ブログは2026年2月19日付です。実務上は2026年2月に卒業したと押さえれば足ります。目に見える変化は版名で、1.4.0以降は-incubating接尾辞が付きません。版と接尾辞を見れば、参照している解説記事がどの時点の情報かを判別できます。

1.7.0では、払い出される資格情報のプロパティ名を網羅した「Vended Credentials Reference」が独立したページとして新設され、Trino向けの導入ガイドも追加されました。いずれも後述します。

Docker Composeでの起動とトークン取得の手順

評価目的であれば、公式のQuickstartがdocker-compose.ymlを標準入力へ流し込む1行で完結します。PolarisとS3互換ストレージのRustFSが起動し、quickstart_catalogという名前のカタログと、カタログ内容の操作権限（CATALOG_MANAGE_CONTENT）を与えたquickstart_userというプリンシパルが自動的に作られます。

curl -s https://raw.githubusercontent.com/apache/polaris/refs/heads/main/site/content/guides/quickstart/docker-compose.yml | docker compose -p polaris-quickstart -f - up -d

# 自動生成された資格情報とサンプルコマンドはログに出力される
docker compose -p polaris-quickstart logs

# 停止
docker compose -p polaris-quickstart down

起動後のエンドポイントは、Polaris REST APIがhttp://localhost:8181、RustFSのコンソールがhttp://localhost:9001です。この構成のメタストアはインメモリのため、コンテナを落とすと作成したカタログや権限設定は消えます。公式ドキュメント自身が本番利用を想定しない構成と明記しているので、動作確認用と割り切ってください。

APIを直接叩く場合は、OAuth2のclient credentialsフローでアクセストークンを取得します。realmを明示しないと設定リストの先頭が既定として使われるため、複数realmを運用するならヘッダーを付けます。

curl -X POST http://localhost:8181/api/catalog/v1/oauth/tokens \
  -H "Polaris-Realm: POLARIS" \
  -d "grant_type=client_credentials" \
  -d "client_id=<client-id>" \
  -d "client_secret=<client-secret>" \
  -d "scope=PRINCIPAL_ROLE:ALL"

{
  "access_token": "...",
  "token_type": "bearer",
  "issued_token_type": "urn:ietf:params:oauth:token-type:access_token",
  "expires_in": 3600
}

ただしこのエンドポイントを恒久的な認証基盤にしてはいけません。1.7.0のAPI仕様（spec/polaris-catalog-apis/oauth-tokens-api.yaml）はGet a token using an OAuth2 flow (DEPRECATED for REMOVAL)と題し、deprecated: trueを明示しています。Iceberg（Java）2.0で仕様から削除される予定なので、動作確認や初期設定に留め、運用では外部IdPを立ててクライアント側にoauth2-server-uriを明示する構成へ寄せてください。

管理操作をコマンドラインで行うなら、PyPIで配布されているCLIが使えます。パッケージ名はapache-polarisで、2026年9月8日時点の最新は1.7.0、対応Pythonは3.10以上3.15未満です。PyPIへの公開は1.4.0からで、それ以前の版はリポジトリのソースから使う形でした。

pip install apache-polaris
polaris principals list
polaris catalogs update --set-property foo=bar some_catalog

SparkとTrinoからの接続設定

Sparkのtype=restとcatalog-implの使い分け

Icebergのクライアント設定では、カタログの実装をtypeとcatalog-implのどちらで指定するかで迷いやすい箇所です。Iceberg公式のSpark設定リファレンスはcatalog-implについてThe custom Iceberg catalog implementation. If type is null, catalog-impl must not be null.と定義しており、typeにrestを指定するならcatalog-implは不要です。Polarisの公式ノートブックもtype=restを使っています。catalog-implはtypeを空にしたうえでカスタム実装クラスを指す場合の口であり、両方を書く設定ではありません。

from pyspark.sql import SparkSession

spark = (SparkSession.builder
  .config("spark.jars.packages",
          "org.apache.iceberg:iceberg-spark-runtime-3.5_2.12:1.10.1,org.apache.iceberg:iceberg-aws-bundle:1.10.1")
  .config("spark.sql.catalog.polaris", "org.apache.iceberg.spark.SparkCatalog")
  .config("spark.sql.catalog.polaris.type", "rest")
  .config("spark.sql.catalog.polaris.uri", "http://localhost:8181/api/catalog")
  .config("spark.sql.catalog.polaris.warehouse", "quickstart_catalog")
  .config("spark.sql.catalog.polaris.credential", "<client-id>:<client-secret>")
  .config("spark.sql.catalog.polaris.scope", "PRINCIPAL_ROLE:ALL")
  .config("spark.sql.catalog.polaris.token-refresh-enabled", "true")
  .config("spark.sql.catalog.polaris.header.X-Iceberg-Access-Delegation", "vended-credentials")
  .config("spark.sql.catalog.polaris.io-impl", "org.apache.iceberg.io.ResolvingFileIO")
  ).getOrCreate()

URIのlocalhostは、前節のQuickstartをホスト側から叩く前提の値です。公式ノートブックはCompose内から接続するためpolaris:8181を使っています。Icebergの版もノートブックの記載に合わせており、Iceberg本体は1.11系まで進んでいるので、実運用ではSparkとの対応表を見て上げてください。warehouseにはPolaris側のカタログ名を渡します。ストレージのアクセスキーをSpark側に置かずに済ませたい場合は、header.X-Iceberg-Access-Delegationにvended-credentialsを指定してPolarisから一時資格情報を受け取る形にします。

Polaris Spark Clientの守備範囲と制限

Polarisは上記のIceberg標準クライアントとは別に、独自のSparkクライアント（org.apache.polaris.spark.SparkCatalog）も配布しています。こちらはIceberg以外のテーブルをGeneric Tablesとして扱うためのもので、Icebergテーブルしか使わないなら導入する理由はありません。公式ドキュメントが明示している制限は次のとおりです。

• 対応形式はIcebergとDeltaのみで、CSVやJSONは対象外。
• Generic Tables APIはcredential vendingに未対応。
• Deltaテーブルに対してCTASが使えず、これに依存するsaveAsTableも使えない。
• Deltaテーブルは明示的なlocationなしでは作成できず、リネームとALTER TABLE ... SET LOCATIONも非対応。

Delta側の機能をそのまま期待すると外すので、Deltaも同じカタログに載せたい要件がある場合だけ検討対象になります。フォーマット側の性質はDelta Lakeとは？データレイクに信頼性を与えるオープンテーブルフォーマットを実装視点で解説を参照してください。

Trinoのカタログプロパティ

Trinoからは、Icebergコネクタのカタログ定義ファイルにRESTカタログとしてPolarisを指定します。1.7.0で追加された公式ガイドが挙げている主要プロパティは以下です。

security=OAUTH2を指定するならoauth2.credentialが対になります。ここを落とすとTrino側がカタログを初期化できないため、Polarisのcurl例だけを見て設定を組むと躓きやすい箇所です。iceberg.rest-catalog.http-headersでrealmヘッダーを送っている点も要注意で、これを落とすと既定ではrealmリストの先頭へフォールバックし、本番推奨のpolaris.realm-context.require-header=trueを入れている場合はPolarisが404 Not Foundを返します。このほか公式のカタログ定義ファイルにはfs.s3.enabled、s3.endpoint、s3.regionも含まれます。s3.path-style-accessはRustFSやMinIOのようなS3互換ストレージで必要になる設定です。Trino自体の役割はTrinoとは？分散SQLクエリエンジンの仕組み・Presto/Sparkとの違い・導入を解説にまとめています。

RBACの4層モデルと権限の粒度

Polarisの認可は、権限を直接ユーザーへ与えない設計です。権限はカタログロールに付与し、カタログロールをプリンシパルロールへ付与し、プリンシパルロールをプリンシパルへ付与します。プリンシパルとプリンシパルロール、プリンシパルロールとカタログロールはいずれも多対多です。カタログロールは特定のカタログに属するため、カタログをまたぐ権限は「カタログごとのカタログロール」を1つのプリンシパルロールに束ねて表現します。

保護対象（securable object）はカタログ、名前空間、Icebergテーブル、ビュー、ポリシーの5種類で、権限はそれぞれに対応する系統で定義されています。主要なものは次のとおりです。

設計上の要点は、データ本体への到達権であるTABLE_READ_DATAとTABLE_WRITE_DATAがTABLE_FULL_METADATAに含まれないことです。メタデータの完全管理権を渡してもデータは読めないので、「テーブル定義は触れるがデータは見せない」役割を素直に表現できます。逆にCATALOG_MANAGE_CONTENTはこの2つを内包するため、カタログ管理者向けの強い権限です。

もう1点、公式ドキュメントが警告しているのがテーブルプロパティの扱いです。TABLE_READ_PROPERTIESやVIEW_READ_PROPERTIESを持つプリンシパルはプロパティを読めるため、パスワードやアクセスキーをテーブルプロパティに保存してはいけません。同じ理由でカタログプロパティもIceberg RESTの/config応答としてクライアントに返るため、機密を置く場所ではありません。

credential vendingで払い出される資格情報の中身

クライアントがX-Iceberg-Access-Delegationヘッダーにvended-credentialsを付けてテーブルをロードすると、Polarisは呼び出し元が認可された範囲だけにスコープした短命の資格情報を返します。S3であればAWS STSのAssumeRoleをインラインセッションポリシー付きで実行した結果、Azureであればコンテナとパス接頭辞に限定したUser Delegation SASトークン、GCSであればCredential Access Boundaryでダウンスコープしたアクセストークンです。

Azureのキー名が3系統あるのは、クライアントが使うIceberg SDKの世代によって期待するキーが違うためです。Polarisは全形式を同時に返すので、クライアントごとにサーバー設定を切り替える必要はありません。

運用上の制約も押さえておきます。AzureのUser Delegation SASは有効期間の上限が7日と決まっています。また前述のとおりGeneric Tables APIはcredential vendingに未対応です。有効期限前に更新したいクライアント向けにはclient.refresh-credentials-endpointのような更新用エンドポイントが同じ応答に含まれます。ストレージ側をMinIOのようなS3互換で組む場合は、s3.endpointとs3.path-style-accessが追加で返る点も押さえておいてください。この構成の前提はMinIOとは？S3互換オブジェクトストレージの仕組みとOSS版アーカイブ後の採用判断【2026年8月時点】にまとめています。

本番構成で既定値から変更する5点

公式ドキュメントは既定構成を開発・テスト向けと明言し、本番向けのチェックリストを提示しています。順に、OAuth2鍵の設定、realmヘッダーの必須化、耐久性のあるメタストアの利用、realmのbootstrap、FILEストレージの無効化です。

5点目のFILEストレージは、polaris.features."SUPPORTED_CATALOG_STORAGE_TYPES"に必要な型だけを列挙し、FILEを書かないことで塞ぎます。ローカルファイルシステムをカタログのストレージに使える状態は検証には便利ですが、本番では外します。

とくに落とし穴になるのが鍵の扱いです。既定のrsa-key-pairはランダム生成されるため、レプリカを複数立てるとレプリカごとに鍵が変わり、トークンを発行したノードと別のノードにルーティングされた時点で検証に失敗します。事前生成した鍵をファイルで渡してください。

openssl genpkey -algorithm RSA -out private.key -pkeyopt rsa_keygen_bits:2048
openssl rsa -in private.key -pubout -out public.key

polaris.authentication.token-broker.type=rsa-key-pair
polaris.authentication.token-broker.rsa-key-pair.public-key-file=/tmp/public.key
polaris.authentication.token-broker.rsa-key-pair.private-key-file=/tmp/private.key
polaris.realm-context.require-header=true

永続化のバックエンドは3種類あり、本番で実用段階なのはRelational JDBCです（MongoDBを使うnosqlも選べますが、1.7.0時点でExperimental扱いです）。Relational JDBCが対応するのはPostgreSQLとH2で、ドキュメントが手順を用意しているのはPostgreSQLだけです。既定のインメモリのままでは再起動でデータが消え、複数レプリカ構成も成立しません。バックエンドを設定したうえで、realmごとに1回だけ管理ツールでbootstrapを実行します。

docker run --rm -it \
  --env="polaris.persistence.type=relational-jdbc" \
  --env="quarkus.datasource.username=<user>" \
  --env="quarkus.datasource.password=<password>" \
  --env="quarkus.datasource.jdbc.url=<jdbc-url-of-postgres>" \
  apache/polaris-admin-tool:1.7.0 bootstrap -r POLARIS -c POLARIS,<client-id>,<client-secret>

ここでイメージ名に注意が必要です。1.7.0のGitHubリリースノートは配布イメージをapache/polaris-adminと書いていますが、Docker Hubに実在するのはapache/polaris-admin-toolで、apache/polaris-adminというリポジトリは2026年9月8日時点で存在しません。ドキュメント側の記載が正しく、リリースノートからコピーするとpullで失敗します。なおタグは、ドキュメントのlatestではなく再現性のために版で固定しています。

Kubernetesへ載せる場合は公式Helmリポジトリが使えます。1.5.0までのドキュメントには、1.3.0-incubating以前では--develが必要という注記がありました（-incubating接尾辞をHelmがプレリリースと解釈するためです）。この注記は1.6.0で削除され、1.7.0のドキュメントには残っていません。

helm repo add polaris https://downloads.apache.org/polaris/helm-chart
helm repo update
helm upgrade --install polaris polaris/polaris --namespace polaris --create-namespace

運用面で最も負担が大きいのはスキーマ移行です。Polarisは自動マイグレーションを持たず、bootstrap時に完全なスキーマスクリプトを適用してバージョンを記録するだけで、既存DBを新しいスキーマへ上げるのは運用者の手作業になります。1.7.0で導入されたスキーマv5への移行は次のSQLを自分で流す必要があります。

ALTER TABLE polaris_schema.events ALTER COLUMN catalog_id DROP NOT NULL;
UPDATE polaris_schema.events SET catalog_id = NULL WHERE catalog_id = '__realm__';
UPDATE polaris_schema.version SET version_value = 5 WHERE version_key = 'version';

未実施でもサーバーは起動時に古いスキーマ版を検知して旧挙動のまま動き続けるため障害にはなりませんが、版を重ねるほど適用漏れが積み上がります。Polarisを本番で使うなら、アップグレード手順書にスキーマ移行SQLの確認を毎回組み込む前提で計画してください。ここを軽く見積もると、マネージドサービスとの運用コスト差が想定より大きく出ます。

Web UI（Polaris Console）と周辺ツールの現在地

「Polarisの管理画面はどこか」は実際に検索されている疑問ですが、サーバー本体にWeb UIは同梱されません。Quickstartが案内するURLもREST APIとオブジェクトストレージのコンソールだけです。GUIが必要な場合は、公式サイトのToolsセクションにもページがあるPolaris Consoleを、apache/polaris-toolsリポジトリから別途デプロイします。React、TypeScript、TanStack Query、Tailwind CSSで作られた単体のフロントエンドで、Node.js 20.19以上（または22.13以上）が前提です。

VITE_POLARIS_API_URL=http://localhost:8181
VITE_POLARIS_REALM=POLARIS
VITE_POLARIS_PRINCIPAL_SCOPE=PRINCIPAL_ROLE:ALL

ConsoleはブラウザからPolarisのAPIを直接呼ぶ構成のため、サーバー側でCORSを開けないと動きません。Quarkusベースなのでapplication.propertiesか環境変数、Helmならvalues.yamlのcorsセクションで設定します。許可ヘッダーにPolaris-Realmを含める点を忘れると、realmヘッダー付きのリクエストがプリフライトで弾かれます。

quarkus.http.cors.enabled=true
quarkus.http.cors.origins=https://console.polaris.service
quarkus.http.cors.methods=GET,POST,PUT,DELETE,PATCH,OPTIONS
quarkus.http.cors.headers=Content-Type,Authorization,Polaris-Realm

同じリポジトリには、他カタログからの移行に使うIceberg Catalog Migrator、カタログ間の同期を行うPolaris Synchronizer、性能計測用のPolaris Benchmarks、そしてMCP対応クライアントからPolarisのREST APIを操作できるPolaris MCP Serverが揃っています。

Polarisを採用しない判断基準

Polarisが効くのは、複数のエンジンが同じIcebergテーブルを読み書きし、その権限を1か所で統制したい場合です。逆に次の条件に当てはまるなら、導入しない方が総コストは下がります。

最も分かりやすいのは、使うエンジンが1つだけのケースです。SparkだけあるいはTrinoだけで完結するなら、Glueや既存のHive Metastore、エンジン内蔵のカタログで用は足ります。Polarisを足した瞬間に、サーバー、PostgreSQL、鍵、realm、RBACの設計と運用が丸ごと増えます。マルチエンジンという前提が無いなら、この追加コストに見合う便益はありません。

スキーマ移行を手作業で回す体制が無いときも見送りです。自動マイグレーションが無いため、版を上げるたびに移行SQLの要否を判断できる担当が要ります。マネージドに逃がす道はありますが、Snowflake Open Catalogは新規契約を受け付けていないため、現時点の案内先はHorizon Catalogになります。

Icebergそのものの採用がまだ決まっていない段階も同様です。テーブルフォーマットの選定が済まないうちにカタログ層を固めると、後戻りのコストが大きくなります。選定軸はオープンテーブルフォーマットとは？Iceberg・Delta Lake・Hudiの違いと選び方を実装視点で解説【2026年版】を先に読んでください。

なお外部カタログとの連携（フェデレーション）を当てにする場合は、公式イメージのままでは足りない点を先に確認してください。ドキュメントが導入手順を用意しているのはIceberg REST、Hive Metastore、BigQuery Metastoreの3系統ですが、機能自体がpolaris.features."ENABLE_CATALOG_FEDERATION"で既定オフです。さらにpolaris.features."SUPPORTED_CATALOG_CONNECTION_TYPES"の既定値は[ICEBERG_REST]なので、Hive・BigQueryはこのリストへの追加も必要です。決定的なのはビルドで、Hiveのファクトリはpackaged as an optional extension and is not baked into default server buildsとされ、-PNonRESTCatalogs=HIVEを付けて自前ビルドしないと使えません。apache/polarisの公式イメージをpullしてHive連携を前提に計画すると、この時点で止まります。Iceberg RESTフェデレーションもIcebergテーブルのみが対象で、Generic Tablesのフェデレーションは未実装です。

よくある質問

Apache Polarisのライセンスと費用は？

Apache License 2.0のオープンソースソフトウェアで、ソフトウェア自体の利用料はかかりません。費用が発生するのは、Polarisサーバーを動かす計算資源、メタストアに使うPostgreSQL、そしてマネージド提供を選んだ場合のサービス利用料です。

spark.sql.catalog.polaris.catalog-implには何を指定しますか？

Polarisへ接続する標準的な構成では使いません。本文で触れたとおりtypeにrestを指定するのが公式の構成です。両方を書くと動かない点も押さえておいてください。Iceberg本体のCatalogUtilはtypeとcatalog-implが同時に設定されているとCannot create catalog %s, both type and catalog-impl are setで例外を投げます。catalog-implを使うのは、typeを空にして独自のカタログ実装クラスを読ませる場合だけです。

Docker Composeで作ったカタログは再起動後も残りますか？

残りません。Quickstartはインメモリメタストアで動くため、コンテナを落とした時点でカタログも権限設定も消えます。残したい場合の手順は本文の本番構成の節を参照してください。

Snowflake Open Catalogとの違いは何ですか？

差は運用責任の所在です。サーバーの可用性設計、鍵やrealmの管理、スキーマ移行やバージョン追随を自分で持つのがセルフホストのPolaris、Snowflakeに預けるのがOpen Catalogという関係になります。ただしOpen Catalogは既存アカウントを持たない顧客の新規申込を受け付けていないため、これから契約する場合の比較対象はHorizon Catalogです。

「Polaris」という名前の他の製品と混同しないためには？

Polarisは北極星を指す一般名詞で、同名のOSSや業務システム、車両ブランドが複数存在します。Icebergのカタログを指す場合は「Apache Polaris」または「Polaris Catalog」と表記し、リポジトリがgithub.com/apache/polaris、公式サイトがpolaris.apache.orgであることを確認するのが確実です。

関連記事

• Apache IcebergとParquetの違い｜テーブル形式とファイル形式の関係を整理
• オープンテーブルフォーマットとは？Iceberg・Delta Lake・Hudiの違いと選び方を実装視点で解説【2026年版】
• Unity Catalogとは？3レベル名前空間と権限継承・移行判断を実装視点で解説【2026年版】
• Trinoとは？分散SQLクエリエンジンの仕組み・Presto/Sparkとの違い・導入を解説
• Delta Lakeとは？データレイクに信頼性を与えるオープンテーブルフォーマットを実装視点で解説