サービスをコールするためのインスタンスの構成

Roving Edgeコンピュート・インスタンスは、インスタンスで実行されているアプリケーションがサービスを呼び出したり、Roving Edgeユーザーがリソースを管理するためのサービスを呼び出す方法に似たリソースを管理できるように構成できます。

インスタンスが認可済アクター(またはプリンシパル)となり、サービス・リソースに対するアクションを実行できるようにする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
```
systemd oneshotサービスを作成して、起動時に/sbin/restore-iptables.shスクリプトを実行します。

この例では、サービスの名前は/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
```

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

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

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

重要

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

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

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

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

trust list --filter=ca-anchors

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

このメソッドでは、Roving Edge固有のCAバンドルがインスタンスにコピーされますが、サーバーの証明書(--insecure)は検証されません。セキュリティを確保するには、取得したバンドル(external_ca.crt)の内容を確認します。

Roving Edgeのiaasエンドポイントから証明書を取得します。
```
curl --insecure -sS -o external_ca.crt --noproxy "*" https://iaas.ccc_name.domain_name/cachain
```
このコマンドは、--user-data-fileオプションまたはuser_dataフィールドを指定した--metadataオプションのいずれかを使用して、起動時にインスタンスに渡されるスクリプト内に存在する可能性があります。スクリプトは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: Roving Edge CAバンドルのグローバルな信頼

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

重要

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

Roving Edgeの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オプションまたはuser_dataフィールドを指定した--metadataオプションのいずれかを使用して、起動時にインスタンスに渡されるスクリプト内に存在する可能性があります。スクリプトはinit中にインスタンス内でcloud-initによって実行されるため、多くのインスタンスでこれらのステップを手動で実行する手間が省けます。