OS管理ハブの開始

インスタンスを登録する前に、サービスの前提条件が満たされていることを確認して、OS管理ハブの使用を開始します。

サービスを開始するには、次を完了します。

サポートされている環境

OS管理ハブは、OCIインスタンスおよびオンプレミスまたはサポートされているサードパーティ・クラウド・インスタンスを管理できます。OS管理ハブでは、OSベンダーによって使用可能になった更新が提供されます。使用可能な更新は、ベンダーのOSライフサイクルプログラムの対象となります。

テナンシ要件

  • OS管理ハブには、Oracle Cloud Infrastructureテナンシが必要です。
  • OS管理ハブは、Oracle Cloud Free Tierでは使用できません。

サブスクリプション要件

  • オンプレミスまたはサードパーティ・クラウド・インスタンスの場合、OS管理ハブを使用するには、有効なOracle Linux BasicおよびPremier Supportサブスクリプションが必要です。

サポートされているOSのバージョン

OCIインスタンス
  • Oracle Linux 6、7、8または9

  • Windows Server 2016、2019または2022 Standard、Datacenter
  • Oracle Autonomous Linux 7 or 8 (managed by the Autonomous Linux service which uses OS Management Hub for automated patching)

重要

OS管理ハブには、Oracle Cloud Agentバージョン1.40以上が必要です。2024年4月より前にリリースされたプラットフォーム・イメージを使用するインスタンスの場合、Oracle Cloud Agentを1.40以上にアップグレードします。
オンプレミスまたはサードパーティのクラウド・インスタンス
  • Oracle Linux 7、8または9

サポートされるサードパーティークラウド

OS管理ハブでは、次のサードパーティ・クラウドでOracle Linuxインスタンスを管理できます:

コンパートメントに関する考慮事項

次のリソースが存在するコンパートメントを指定できます。これは、コンパートメントごとにリソースへのアクセスを制限する場合に便利です。

  • ソフトウェア・ソース: ベンダー・ソフトウェア・ソースは常にルート・コンパートメントに存在しますが、他のコンパートメントにレプリケートできます。カスタム・ソフトウェア・ソースは、任意のコンパートメントに配置できます。
  • プロファイル: サービス提供のプロファイルおよびデフォルト・プロファイルは常にルート・コンパートメントに存在します。他のすべてのプロファイルは、任意のコンパートメントに配置できます。プロファイルの理解を参照してください。
  • 管理ステーション: 任意のコンパートメントに配置できます。
  • グループ: 任意のコンパートメントに配置できます。
  • ライフサイクル環境: 任意のコンパートメントに配置できます。

ベスト・プラクティス

グループまたはライフサイクル環境を作成する場合は、インスタンス・メンバーをグループまたはライフサイクル環境と同じコンパートメントに制限します。OS管理ハブには、一度に1つのコンパートメントのインスタンス・メンバー、ジョブおよびレポートが表示されます。すべてのインスタンス・メンバーが同じコンパートメント内にある場合、グループまたはライフサイクル環境に関連付けられているすべてのメンバー、ジョブおよびレポートの直接ビューが表示されます。

インスタンス・メンバーが複数のコンパートメントにある場合、インスタンス、ジョブおよびレポートのビューは選択したコンパートメントに制限されます。メンバーの表示、ジョブ・ログの確認およびレポートの実行時には、コンパートメント・スコープを変更する必要があります。たとえば、複数コンパートメント・グループのジョブを参照する場合は、コンパートメントを変更して、関連するすべての子ジョブを表示する必要があります。また、ポリシーによっては、インスタンス・メンバーのすべてのコンパートメントに対する権限がユーザーにない場合があります。これらのユーザーには、グループまたはライフサイクル環境の不完全なビューが表示されます。

コンパートメント間でのリソースの移動

ほとんどのリソースは、テナンシの同じリージョン内のコンパートメント間で移動できます。ただし、リソースに関連付けられたスケジュール済ジョブは宛先コンパートメントに移動されません。ソース・コンパートメントには引き続き存在します。たとえば、グループを移動した場合、グループに関連付けられたスケジュール済ジョブは古いコンパートメントに残ります。

リソースを移動する前に、誤ってリソースへのアクセスを失わないように、ポリシーおよび権限が正しく設定されていることを確認します。

リソースを移動するには、次の項を参照してください。

OCI内のコンパートメント間のリソースの移動に関する一般的な情報は、コンパートメント間のリソースの移動を参照してください。

ネットワークに関する考慮事項

OCIインスタンス

Oracle Linux

次のいずれかを含む仮想クラウド・ネットワーク(VCN)にインスタンスをアタッチします:

  • Oracle Services NetworkのCIDRラベルの<region>のすべてのサービスを使用するサービス・ゲートウェイを持つプライベート・サブネット。

  • NATゲートウェイを使用するプライベート・サブネット。

  • インターネット・ゲートウェイを使用するパブリック・サブネット。

詳細な手順は、Oracle Servicesへのアクセス: サービス・ゲートウェイを参照してください。

Windows

WindowsインスタンスがWindows更新サーバーにアクセスできるようにするセキュリティ・リストまたはネットワーク・ルールを定義します。詳細は、WindowsイメージのWindows OS更新を参照してください。

オンプレミスまたはサポートされているサードパーティ・クラウド・インスタンス

管理ステーションとして機能するインスタンスがOCIネットワークに到達できることを確認します。

  • Microsoft Azureの場合は、Azure Virtual Networkで、管理ステーションのプロキシおよびミラー・リスニング・ポートのトラフィックが許可されていることを確認します。
  • Amazon Web Services (AWS)の場合、Amazon Virtual Private Cloud (VPC)で管理ステーションのプロキシおよびミラー・リスニング・ポートのトラフィックが許可されていることを確認します。

詳細は、管理ステーションの作成を参照してください。

必要なIAMポリシー

ポリシー管理の場合は、ユーザーのグループとリソースの動的グループを定義します。次に、個々のユーザーまたはリソースではなくグループに権限を付与するポリシーを作成します。特定のユースケースについては、ポリシーの例を参照してください。ポリシーの詳細は、ポリシーの開始を参照してください。

推奨ユーザー・グループ

ユーザー・グループを作成して、テナンシ内のOS管理ハブ・サービスを管理します。グループに属するすべてのユーザーは、その特定のグループのポリシーと権限を自動的に継承します。ユーザー・グループの詳細は、グループの管理を参照してください。

必要な動的グループ

動的グループを作成して、OS管理ハブが管理するインスタンスを含めます。OCIインスタンスには、オンプレミスまたはサードパーティ・クラウド・インスタンス(OCI以外)とは異なる動的グループ・ルール文が必要です。複数のインスタンス・タイプを管理する場合は、両方の文を含めます。両方のインスタンス・タイプのルール文を含む単一の動的グループを使用できます。

新しいインスタンスがサービスに登録されると、動的グループにはルール文に基づくインスタンスが含まれます。動的グループ・ルールはコンパートメント固有であるため、OS管理ハブによって管理するインスタンスがあるすべてのコンパートメントおよびサブコンパートメントのルールを指定する必要があります。動的グループの詳細は、動的グループの管理 を参照してください。

ANYおよびALLの理解

動的グループを定義する場合は、グループで定義されているルールとグループがどのように一致するかを設定します。

  • 下で定義したルールに一致には、動的グループ内のいずれかのルールに一致するリソースが含まれます。複数のコンパートメントまたは複数のインスタンス・タイプ(OCIインスタンスやOCI以外のインスタンスなど)のルールを含むグループを定義する場合は、これを選択します。
  • 「下で定義したすべてのルールに一致」には、動的グループ内のすべてのルールに一致するリソースが含まれます。1つのコンパートメントのみを含む可変狭動的グループを定義する場合は、これを選択します。

動的グループ内で個々のルール文を定義する場合は、各文の条件を設定します。

  • 次のすべて(ALL)では、ルールのすべての条件に一致するリソースのみが含まれます。ALL文では、各条件がtrueである必要があります。それ以外の場合、ルールのリソースは含まれません。

  • 次のいずれか(ANY)では、ルールのいずれかの条件に一致するリソースが含まれます。

個々のルール文のANYおよびALLの例

OCI以外のインスタンスに使用されるルールについて考えてみます。

Correct usage:
ALL {resource.type='managementagent', resource.compartment.id='<compartment_ocid>'}

ALLを使用する場合、ルールには、指定されたコンパートメント内の管理エージェント・リソースのみが含まれます。

Incorrect usage. Do not use:
ANY {resource.type='managementagent', resource.compartment.id='<compartment_ocid>'}

ANYを使用する場合、ルールには、テナンシ全体内のすべての管理エージェント・リソースと、指定したコンパートメントに存在するすべてのOCIリソースが含まれます。文にはOS管理ハブに必要なリソースが含まれますが、これは非常に広範であり、通常は好ましくありません。

複数のコンパートメントを指定する場合は、OCIインスタンスに使用されるルールを考慮してください。

Correct usage:
ANY {instance.compartment.id='<compartment_ocid>',instance.compartment.id='<subcompartment_ocid>'}

ANYを使用する場合、ルールには、指定された各コンパートメント内のすべてのインスタンスが含まれます。

Incorrect usage. Do not use:
ALL {instance.compartment.id='<compartment_ocid>',instance.compartment.id='<subcompartment_ocid>'}

ALLを使用する場合、インスタンスは複数のコンパートメントに存在できないため、ルールにはインスタンスが含まれません。複数のコンパートメントがあるルール文では、ALLを使用しないでください。

動的グループの作成

重要

動的グループにALL条件およびANY条件を使用する場合の違いを理解します。「ANYおよびALLの理解」を参照してください。
  1. ステップに従って動的グループを作成するか、既存の動的グループを更新し、次のように一致ルールを構成します。

    ヒント

    1つのリソースは、最大5つの動的グループに属することができます。新しい動的グループを作成するかわりに、サービス全体で可能なかぎり同じ動的グループを再利用することをお薦めします。

  2. 照合ルール設定全体について、「次で定義したルールと一致」を選択します。

  3. OS管理ハブが管理するインスタンスのルール文を作成します。

    OCIインスタンスのルール

    インスタンスを含む各コンパートメント(およびサブコンパートメント)を含めるルール文を追加します。

    ANY {instance.compartment.id='<compartment_ocid>',instance.compartment.id='<subcompartment_ocid>'}

    このルールには、指定したコンパートメント内のすべてのOCIインスタンスが含まれます。

    OCI以外のインスタンスのルール

    インスタンスを含むコンパートメント(およびサブコンパートメント)ごとに別個のルール文を追加します。

    ALL {resource.type='managementagent', resource.compartment.id='<compartment_ocid>'}
    ALL {resource.type='managementagent', resource.compartment.id='<subcompartment_ocid>'}

    各ルール文には、指定したコンパートメント内のすべての管理エージェント・リソースが含まれます。OCI以外の各インスタンスには対応するエージェント・リソースがあるため、文にはコンパートメント内のOCI以外のインスタンスが含まれます。

必須のポリシー・ステートメント

インスタンスがOS管理ハブに登録し、ユーザーがサービスを管理および操作できるようにする文を含むポリシーを作成します。ポリシーを作成する前に、推奨ユーザー・グループおよび必須動的グループを作成します。OS管理ハブのIAMポリシーは、テナンシ・レベルまたはコンパートメント・レベルで設定できます。

ノート

グループ名または動的グループ名(<identity_domain_name>/<dynamic_group_name>など)の前にアイデンティティ・ドメインを定義しないかぎり、ポリシー・ステートメントはデフォルトのアイデンティティ・ドメインを使用します。詳細は、ポリシー構文を参照してください。
テナンシ・レベルのポリシー・ステートメント

テナンシ・レベルで必要なIAMポリシーを適用するには、次のポリシー・ステートメントを使用します:

allow dynamic-group <osmh_dynamic_group> to {OSMH_MANAGED_INSTANCE_ACCESS} in tenancy where request.principal.id = target.managed-instance.id
allow group <user_group> to manage osmh-family in tenancy

オンプレミスまたはサードパーティ・クラウド・インスタンスを管理する場合は、次の追加ステートメントを含めます。これらは、OCIインスタンスのみを管理する場合には必要ありません。

allow group <user_group> to manage management-agents in tenancy
allow group <user_group> to manage management-agent-install-keys in tenancy
コンパートメント・レベルのポリシー・ステートメント(テナンシ・レベルを使用しない場合)

テナンシ管理者がテナンシ・レベルでのIAMポリシーの設定を許可しない場合、OS管理ハブ・リソースの使用をコンパートメントとそのサブコンパートメントに制限できます(ポリシーはコンパートメント継承を使用します)。

IAMポリシーをテナント内のコンパートメントに適用するには、次のポリシー・ステートメントを使用します:

allow dynamic-group <osmh_dynamic_group> to {OSMH_MANAGED_INSTANCE_ACCESS} in compartment <compartment_name> where request.principal.id = target.managed-instance.id
allow group <user_group> to manage osmh-family in compartment <compartment_name>

オンプレミスまたはサードパーティ・クラウド・インスタンスを管理する場合は、次の追加ステートメントを含めます。これらは、OCIインスタンスのみを管理する場合には必要ありません。

allow group <user_group> to manage management-agents in compartment <compartment_name>
allow group <user_group> to manage management-agent-install-keys in compartment <compartment_name>
ヒント

ポリシーについて混同しますか。サンプルのユースケースについては、ポリシーの例を参照してください。

次の手順

  1. テナンシにベンダー・ソフトウェア・ソースを追加します。
  2. オンプレミスまたはサードパーティ・クラウドの場合は、管理ステーションを作成し、プロファイルを使用して管理ステーションを登録してOS管理ハブ・サービスをインスタンスとして登録します。
  3. プロファイルを作成して、特定のソフトウェア・ソース、ライフサイクル環境またはグループに関連付けられたコンテンツにインスタンスを登録します。
  4. インスタンスをOS管理ハブ・サービスに登録します。