サービスを呼び出すためのインスタンスの構成

Compute Cloud@Customerコンピュート・インスタンスは、インスタンスで実行されているアプリケーションがサービスをコールし、Compute Cloud@Customerユーザーがリソースを管理するためにサービスをコールする方法と同様のリソースを管理できるように構成できます。

インスタンスを認可済アクター(またはプリンシパル)にできるIAMサービス機能は、インスタンス・プリンシパルと呼ばれます。

インスタンスをプリンシパルとして設定および使用するには、次のステップを実行します。

インスタンスがサービス・エンドポイントにアクセスできるように、インスタンス・ファイアウォールを構成します。「サービスのコールを許可するインスタンス・ファイアウォールの構成」を参照してください。
必要なリソースにアクセスする権限を付与する動的グループ(テナンシで構成)にインスタンスが含まれていることを確認します。動的グループの管理を参照してください。

インスタンスは、動的グループの一致ルールで指定されたコンパートメントに作成または移動する必要があります。そうでない場合、インスタンスには、一致ルールで指定されたリソース・タグが割り当てられている必要があります。動的グループを定義するための一致ルールの書込みを参照してください。

サービスのコールを許可するインスタンス・ファイアウォールの構成

この項では、インスタンス・ファイアウォール構成を変更する方法と、システムが再起動した場合に変更をリストアするためのsystemdサービスを作成する方法について説明します。

ファイアウォール構成の変更

特権ユーザーとして、インスタンス・ファイアウォール構成を変更して、インスタンスがiaasやidentityなどのサービス・エンドポイントにアクセスできるようにします。
iptablesコマンドを使用して、次のBareMetalInstanceServicesルールをインスタンス・ファイアウォールに追加します。
```
iptables -I BareMetalInstanceServices 14 -p tcp -d 169.254.169.254 --dport 443 -j ACCEPT
iptables -I BareMetalInstanceServices 14 -p tcp -d 169.254.240.254 --dport 443 -j ACCEPT
```
最初のエントリはすべてのエンドポイントに必要です。オブジェクト・ストレージ・エンドポイントに接続するには、2番目のエントリが必要です。

構成変更を永続化

次の手順を使用して、これらのファイアウォール構成の変更をインスタンスの再起動後も維持します。

更新されたIPテーブル構成を保存します。
```
iptables-save > /etc/sysconfig/iptables.rules
```
リブート時に現在の(変更された)ファイアウォール構成を自動的に復元するスクリプトを作成します。

この例では、スクリプト名は/sbin/restore-iptables.shです。ファイル/sbin/restore-iptables.shの内容は次のとおりです。
```
#!/bin/sh
/sbin/iptables-restore < /etc/sysconfig/iptables.rules
```
スクリプトの実行可能ビットを設定します。
```
chmod +x /sbin/restore-iptables.sh
```
ブート時に/sbin/restore-iptables.shスクリプトを実行するsystemd oneshotサービスを作成します。

この例では、サービスの名前は/etc/systemd/system/restore-iptables.serviceです。ファイル/etc/systemd/system/restore-iptables.serviceの内容は次のとおりです。
```
[Unit]
Description=Restore IP Tables
After=cloud-final.service

[Service]
ExecStart=/sbin/restore-iptables.sh
User=root
Group=root
Type=oneshot

[Install]
WantedBy=multi-user.target
```
systemdマネージャ構成を再ロードし、起動時にサービスを実行できるようにします。
```
systemctl daemon-reload
systemctl enable restore-iptables
```

サービスのコールを許可するためのインスタンス証明書の構成

Compute Cloud@Customerでは、デフォルトでは、エンドポイント(iaasやidentityなど)は、そのCompute Cloud@Customerに固有のCAによって署名された証明書を提供します。デフォルトでは、OSは、このCompute Cloud@Customerに固有のCAによって署名された証明書を信頼しません。OSが提供された証明書を信頼しない場合、OCI SDKまたはCLIの使用の試行はCERTIFICATE_VERIFY_FAILEDエラーで失敗します。

インスタンスでOCI SDKまたはCLIを正常に使用するには、このトピックで説明するソリューションのいずれかを実装します。

重要

インスタンスにSSHを実行できるユーザーは、インスタンスに付与された権限を自動的に継承します。

オプション1: 証明書持込み(BYOC)

Compute Cloud@Customerでは、CAトラスト・チェーンを使用できる独自の認証局(CA)証明書を指定できます。独自の証明書を使用するには、サポート・リクエストを開き、独自の証明書の使用をリクエストします。「サポート・リクエストの作成」を参照してください。サポートにアクセスするには、OCIコンソールへのサインインの説明に従ってOracle Cloudコンソールにサインインします。

Linux OSでは、次のコマンドを実行すると、デフォルトで信頼されているCAが一覧表示されます。

trust list --filter=ca-anchors

オプション2: 使用するCAバンドルのSDKコードでの指定

この方法では、Compute Cloud@Customer固有のCAバンドルがインスタンスにコピーされますが、サーバーの証明書(--insecure)は検証されません。セキュリティを確保するには、取得したバンドルのコンテンツ(external_ca.crt)を確認します。

Compute Cloud@Customerインフラストラクチャのiaasエンドポイントから証明書を取得します。
```
curl --insecure -sS -o external_ca.crt --noproxy "*" https://iaas.ccc_name.domain_name/cachain
```
このコマンドは、--user-data-fileオプションまたは--metadataオプションをuser_dataフィールドとともに使用して、起動時にインスタンスに渡されるスクリプト内にある可能性があります。スクリプトは、init中にインスタンス内でcloud-initによって実行されるため、多くのインスタンスでこの証明書ファイルを手動で取得する作業が節約されます。
external_ca.crtファイルに保存されているCAバンドルの内容を確認します。

Python SDKコードにCAバンドルを指定します。

signer = oci.auth.signers.InstancePrincipalsSecurityTokenSigner(
    federation_client_cert_bundle_verify="/home/opc/external_ca.crt"
)
identity_client = oci.identity.IdentityClient(config={}, signer=signer)
identity_client.base_client.session.verify = "/home/opc/external_ca.crt"

オプション3: Oracle Compute Cloud@Customer CAバンドルのグローバルな信頼

この方法は、前述の方法と同じですが、次の違いがあります。SDKコードにCAバンドルを指定するかわりに、このメソッドはCAバンドルをトラスト・チェーンに追加します。

重要

CAバンドルがトラスト・チェーンに追加されると、このコンピュート・インスタンス上のすべてのアプリケーションは、このバンドルで指定されたCAで署名された証明書を信頼します。これが許容可能なセキュリティ・リスクであるかどうかを検討してください。

Compute Cloud@Customerインフラストラクチャのiaasエンドポイントから証明書を取得します。
```
curl --insecure -sS -o external_ca.crt --noproxy "*" https://iaas.ccc_name.domain_name/cachain
```
external_ca.crtファイルに保存されているCAバンドルの内容を確認します。

グローバルCA信頼チェーンを更新します。

cp external_ca.crt /etc/pki/ca-trust/source/anchors/
update-ca-trust extract

このメソッドのステップ1および3は、--user-data-fileオプションまたは--metadataオプションをuser_dataフィールドとともに使用して、起動時にインスタンスに渡されるスクリプトに含めることができます。スクリプトは、init中にインスタンス内でcloud-initによって実行されるため、多くのインスタンスでこれらのステップを手動で実行する作業が節約されます。