サービスを呼び出すためのインスタンスの構成
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によって実行されるため、多くのインスタンスでこれらのステップを手動で実行する作業が節約されます。