エンクレーブとインタフェース

クラウド・ユーザーの観点から見ると、Private Cloud Appliance 「コンピュート・エンクレーブ」はOracle Cloud Infrastructureとほぼ同じ操作性を提供します。ただし、アプライアンスでは、「サービス・エンクレーブ」と呼ばれる独自の個別の管理領域も実行されます。この項では、異なるユーザー・グループと、明確に異なるアクセス・プロファイルを持つ管理者を対象とした、エンクレーブとそのインタフェース間の境界について説明します。

エンクレーブ境界

「コンピュート・エンクレーブ」は、Oracle Cloud Infrastructureとの互換性を最大にするために意図的に設計されています。「コンピュート・エンクレーブ」のユーザーには、クラウド・リソースを作成および管理するための特定の権限があります。通常、これらの権限はグループ・メンバーシップに基づきます。「コンピュート・エンクレーブ」は、ワークロードが作成、構成およびホストされる場所です。ユーザーの処分における主要なビルディング・ブロックは、コンピュート・インスタンスと関連するネットワーク・リソースおよびストレージ・リソースです。

コンピュート・インスタンスは、事前構成済のオペレーティング・システムおよびオプションの追加ソフトウェアが含まれる「コンピュート・イメージ」から作成されます。コンピュート・インスタンスには、CPUやメモリーなどの仮想ハードウェア・リソースのテンプレートである特定の「シェイプ」があります。最小限の操作では、コンピュート・インスタンスにブート・ボリュームと仮想クラウド・ネットワーク(VCN)への接続が必要です。ワークロード用の仮想インフラストラクチャの構築を続けるにつれ、より多くのコンピュート・インスタンスの追加、プライベートおよびパブリック・ネットワーク・インタフェースの割当て、NFS共有またはオブジェクト・ストレージ・バケットの設定などを行うことができます。これらのリソースはすべてOracle Cloud Infrastructureと完全に互換性があり、プライベート・クラウド環境とパブリック・クラウド環境の間で移植できます。

「サービス・エンクレーブ」は、アプライアンス・インフラストラクチャが制御されるシステムの一部です。アクセスは厳密に監視され、特権管理者に制限されます。 3つの管理ノードのクラスタで実行されます。 Private Cloud ApplianceはOracle Cloud Infrastructureから操作的に切断されるため、アプライアンスの設計およびスケールに固有のコントロール・プレーンが必要です。 APIはPrivate Cloud Applianceに固有で、アクセスは厳密に制御されています。「サービス・エンクレーブ」が提供する機能には、ハードウェアおよび容量の管理、サービスの提供、サービスおよびサポートのためのモニタリングおよびツールが含まれます。

両方のエンクレーブが互いに厳密に分離されています。各enclaveは、独自のインタフェース・セットを提供: web UI、CLI、およびエンクレーブごとのAPI。「サービス・エンクレーブ」へのフル・アクセスを持つ管理者アカウントには、「コンピュート・エンクレーブ」には権限がありません。管理者は、初期アクセス用のプライマリ・ユーザー・アカウントを持つテナンシを作成しますが、テナンシのコンテンツおよびアクティビティに関する情報はありません。「コンピュート・エンクレーブ」のユーザーには、クラウド・リソースを使用、管理および作成する権限が付与されますが、ユーザーが作業するテナンシ、または仮想リソースが存在するハードウェアを制御することはできません。

アクセス・プロファイル

各エンクレーブには独自のインタフェースがあります。「コンピュート・エンクレーブ」にアクセスするには、「コンピュートWeb UI」またはOCI CLIを使用します。「サービス・エンクレーブ」にアクセスするには、「サービスWeb UI」または「サービスCLI」を使用します。

ノート:

webブラウザを使用して、両方のエンクレイブのグラフィカル・インタフェースにアクセスします。サポート情報については、「Oracleソフトウェアwebブラウザのサポート・ポリシー」を参照してください。

アカウントのプロパティによって、実行が承認されている操作と、表示、管理または作成できるリソースが決まります。 web UIを使用する場合もCLIを使用する場合も、権限に関して違いはありません。すべての操作によって、エンクレーブの3番目の中央インタフェースへのリクエストが発生: API。 Service Enclave APIまたはCompute Enclave APIからの受信リクエストは評価され、その後APIサービスによって認可または拒否されます。

ユーザーの様々なカテゴリが、異なる目的でアプライアンスと対話します。エンクレーブ・レベルでは、アプライアンス・インフラストラクチャの管理者と、一方の手のテナンシ内のクラウド・リソースを管理するユーザーを区別します。各エンクレーブには、異なる権限を提供する異なるアクセス・プロファイルが存在します。

「サービス・エンクレーブ」では、管理者の選択チームのみにフル・アクセス権を付与する必要があります。システムのモニタリング、容量計画、可用性、アップグレードなど、アクセスが制限されているその他の管理者ロールがあります。管理者ロールの詳細は、「管理者アクセス」を参照してください。 Oracleが「サービス・エンクレーブ」にアクセスしてサービスおよびサポート操作を実行する場合は常に、フル・アクセス権を持つアカウントを使用する必要があります。

テナンシが作成されると、「コンピュート・エンクレーブ」ユーザー・アカウントは1つのみになります: テナンシ管理者。テナンシ内のすべてのリソースへの完全なアクセス権を持ちます。実際には、テナンシへのアクセス権を持つすべての追加アカウントは、通常の「コンピュート・エンクレーブ」ユーザー・アカウントであり、グループ・メンバーシップやポリシー定義に応じて、制限の多い権限または少ない権限を持ちます。テナンシ管理者が、追加のユーザー・アカウントおよびユーザー・グループを設定し、リソース組織および管理戦略を定義し、その戦略を適用するポリシーを作成するタスクです。

リソース管理戦略が定義され、ユーザー、グループおよびコンパートメントの基本構成が存在すると、テナンシ管理者は、昇格された権限を持つ他のユーザーに責任を委任できます。管理者のグループが組織全体のリソースを管理できるようにする単純なポリシーを使用するか、より詳細なアプローチを使用するかを決定できます。たとえば、チームまたはプロジェクトごとにコンパートメント内のリソースを編成し、コンパートメント管理者がそのリソースを管理できるようにします。さらに、ネットワーク・リソースとストレージ・リソースをそれぞれネットワーク管理者とストレージ管理者によって制御される独自のコンパートメント内に格納しておくこともできます。 Identity and Access Managementサービスのポリシー・フレームワークには、リソースを編成し、リソースへのアクセスを制御するための様々なオプションが用意されています。詳細は、「Identity and Access Management概要」の章を参照してください。

APIと直接対話するスクリプトまたは自動化ツールを作成する場合は、開発者が認証および認可の原則と、完全分離を理解していることを確認してください。基本APIリファレンス・ドキュメントは、両方のエンクレーブで使用可能です。

API参照を表示するには、「コンピュートWeb UI」または「サービスWeb UI」のベースURLに/api-referenceを追加します。たとえば:

「サービスWeb UI」ベースURL: https://adminconsole.myprivatecloud.example.com.

「サービス・エンクレーブ」 APIリファレンス: https://adminconsole.myprivatecloud.example.com/api-reference.
「コンピュートWeb UI」ベースURL: https://console.myprivatecloud.example.com.

「コンピュート・エンクレーブ」 APIリファレンス: https://console.myprivatecloud.example.com /api-reference.