インスタンスからのサービスのコール

このトピックでは、Oracle Cloud Infrastructureでサービスをコールするためにインスタンスを認可する方法について説明します。

概要

この手順では、Oracle Cloud InfrastructureサービスでAPIコールを実行するためにインスタンスを認可する方法について説明します。必要なリソースおよびポリシーの設定後、インスタンスで実行されているアプリケーションは、Oracle Cloud Infrastructureパブリック・サービスをコールでき、ユーザー資格証明または構成ファイルを構成する必要がなくなります。

概念

動的グループ
動的グループを使用すると、ユーザー・グループと同様に、Oracle Cloud Infrastructureインスタンスをプリンシパルのアクターとしてグループ化できます。その後、これらのグループのインスタンスに対してOracle Cloud InfrastructureサービスへのAPIコールを許可するポリシーを作成できます。グループ内のメンバーシップは、一致ルールと呼ばれる、ユーザーが定義する基準のセットによって決定されます。
一致ルール
動的グループを設定するときは、グループのメンバーシップのルールも定義します。ルール基準に一致するリソースが動的グループのメンバーになります。一致ルールには特定の構文が使用されます。動的グループを定義するための一致ルールの記述を参照してください。
インスタンス・プリンシパル
インスタンスを認可者(またはプリンシパル)にでき、サービス・リソースに対するアクションを実行できるIAMサービス機能。各コンピュート・インスタンスは、自身のアイデンティティを持ち、追加された証明書を使用して認証を行います。これらの証明書は自動的に作成され、インスタンスに割り当てられてローテーションされ、ホストに資格証明を配布してローテーションする必要がなくなります。

セキュリティに関する考慮事項

インスタンスにアクセスできるユーザー(インスタンスへのSSHを実行できるユーザー)は、インスタンスに付与された権限を自動的に継承します。この手順を使用してインスタンスに権限を付与する前に、誰がそのインスタンスにアクセスできるかを認識し、インスタンスに付与する権限を付与する必要があります。

すべてのコンピュート・インスタンス・プリンシパルには、compartment_inspect権限が付与されます。この権限は取り消せません。この権限により、テナンシ内のListCompartmentsへのインスタンスは、次の情報を取得できます:

  • コンパートメント名
  • コンパートメントの説明
  • コンパートメントに適用されたフリーフォーム・タグ
  • コンパートメントに適用された自動タグ・デフォルト。CreatedByやCreatedOnなどのこれらのタグは、Oracle-Tagネームスペースにあり、Oracleによって自動的に追加されます。

プロセス概要

次のステップでは、インスタンスをプリンシパルとして設定および使用するプロセス・フローの概要を示します。以降の項で、詳細を説明します。

  1. 動的グループを作成します。動的グループ定義で、サービスに対するAPIコールを実行できるインスタンスを指定する一致ルールを指定します。

  2. テナンシ(またはコンパートメント)のサービスにアクセスするための動的グループへの権限を付与するポリシーを作成します。

  3. 組織の開発者は、Oracle Cloud Infrastructure SDKを使用して構築されたアプリケーションを構成し、インスタンス・プリンシパル・プロバイダを使用して認証します。開発者は、動的グループに属するすべてのインスタンスにアプリケーションおよびSDKをデプロイします。

  4. デプロイされたSDKは、Oracle Cloud Infrastructure APIへのコールをポリシーによって許可されたとおりに(API資格証明を構成する必要なしで)行います。

  5. インスタンスによって行われた各APIコールに対して、監査サービスはイベントのログを記録し、インスタンスのOCIDをイベント・ログ内のprincipalIdの値として記録します。詳細は、「監査ログ・イベントの内容」を参照してください。

インスタンスによるサービスのコールを有効化するステップ

インスタンスがサービスをコールできるようにするには、次のタスクを実行します。

動的グループと一致ルールの作成

動的グループに対するポリシーの作成

SDK、CLIまたはTerraformの構成

動的グループに対するポリシーの作成

動的グループを作成した後、動的グループによるOracle Cloud Infrastructureサービスへのアクセスを許可するポリシーを作成する必要があります。

動的グループのポリシーは、ポリシーの仕組みで説明されている構文に従います。そのトピックを確認して、基本的なポリシー機能について理解します。

コンパートメント内のリソースへの動的グループ・アクセスを許可する構文は、次のとおりです。

Allow dynamic-group <dynamic_group_name> to <verb> <resource-type> in compartment <compartment_name>

テナンシへの動的グループ・アクセスを許可する構文は、次のとおりです。

Allow dynamic-group <dynamic_group_name> to <verb> <resource-type> in tenancy

次にいつくかポリシーの例を示します。

動的グループ(FrontEnd)で特定のコンパートメント(ProjectA)内のロード・バランサを使用できるようにするには:

Allow dynamic-group FrontEnd to use load-balancers in compartment ProjectA

動的グループが特定のコンパートメントのインスタンスを起動できるようにするには:

Allow dynamic-group FrontEnd to manage instance-family in compartment ProjectA
Allow dynamic-group FrontEnd to use volume-family in compartment ProjectA
Allow dynamic-group FrontEnd to use virtual-network-family in compartment ProjectA

ポリシーのサンプルは、共通ポリシーを参照してください。

SDK、CLIまたはTerraformの構成

Java SDKの場合:

Java SDKで、InstancePrincipalsAuthenticationDetailsProviderオブジェクトを作成します。例:

public static void main(String[] args) throws Exception {

   InstancePrincipalsAuthenticationDetailsProvider provider =

      InstancePrincipalsAuthenticationDetailsProvider.builder().build();

   IdentityClient identityClient = new IdentityClient(provider);

...

SDK for Pythonの場合:

SDK for Pythonで、oci.auth.signers.InstancePrincipalsSecurityTokenSignerオブジェクトを作成します。例:

# By default this will hit the auth service in the region returned by http://169.254.169.254/opc/v1/instance/region on the instance.
			
signer = oci.auth.signers.InstancePrincipalsSecurityTokenSigner()
identity_client = oci.identity.IdentityClient(config={}, signer=signer)

...

待機せずにトークンをリフレッシュするには、次のコマンドを使用します。

signer.refresh_security_token()

CLIに対するインスタンス・プリンシパル認可の有効化

CLIからインスタンス・プリンシパル認可を有効にするには、コマンドに対して認可オプション(--auth)を設定できます。例:

oci os ns get --auth instance_principal

または、次の環境変数を設定できます。

OCI_CLI_AUTH=instance_principal

両方を設定した場合は、--authに設定された値が環境変数より優先されることに注意してください。

CLIの使用の詳細は、コマンドライン・インタフェースの作業を参照してください。

Terraformに対するインスタンス・プリンシパル認可の有効化

Terraformでインスタンス・プリンシパル認可を有効にするには、次の例に示すように、プロバイダ定義でauth属性を「InstancePrincipal」に設定できます。

variable "region" {}

provider "oci" {
   auth = "InstancePrincipal"  
   region = "${var.region}"

}

インスタンス・プリンシパル認可を使用する場合は、tenancy_ociduser_ocidfingerprintおよびprivate_key_path属性を含める必要はありません。

FAQ

401-Not Authenticatedエラーが表示された場合はどうなりますか。
401-Not Authenticatedエラーが表示された場合は、次の問題を確認してください。
  • コマンドを再度実行してください。証明書のローテーションとリクエストが同時に実行される場合があります。
  • 証明書が期限切れになっている可能性があります。証明書が有効であることを確認してください。
証明書がローテーションされる頻度を変更できますか。

いいえ。証明書のローテーション頻度は変更できません。ただし、動的グループ上のポリシーを変更できます。インスタンスが危険にさらされていると思われる場合は、動的グループのポリシーを変更して、グループのすべてのメンバーの権限を取り消すか、または動的グループからインスタンスを削除できます。動的グループからインスタンスを削除できますか。を参照してください。

証明書が長時間実行される操作の途中でローテーションされるとどうなりますか。

トークンの有効期限は、証明書の有効期限とは関係ありません。また、操作するアプリケーションによっても異なります。たとえば、オブジェクト・ストレージにマルチパートPUT操作がない場合、操作の実行時間に影響はありません。

インスタンスのすべてのユーザーが証明書にアクセスできますか。

はい。動的グループに付与したアクセス権を付与する必要があるユーザーのみがインスタンスにアクセスできることを確認してください。

動的グループからインスタンスを削除できますか。

はい。これを削除するには、一致ルールを変更して削除できます。例については、次を参照してください。

コンパートメント内の特定のインスタンスを動的グループから除外できますか。

はい。たとえば、コンパートメント内の2つの特定のインスタンスを動的グループから除外するとします。次のような一致ルールを記述します。

All {instance.compartment.id = '<compartment_ocid>',
 instance.id != '<instance1_to_exclude_ocid>', instance.id != '<instance2_to_exclude_ocid>'}

前述のルールには、OCIDが指定されたものを除く、コンパートメント内のすべてのインスタンスが含まれています。