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

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

特権ユーザーとして、インスタンス・ファイアウォール構成を変更して、インスタンスが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番目のエントリが必要です。

構成の変更を永続的にする

インスタンスの再起動後もファイアウォール構成の変更を保持するには、次の手順を使用します。

1. 更新されたIP表構成を保存します。

   iptables-save > /etc/sysconfig/iptables.rules

2. リブート時に現在の(変更された)ファイアウォール構成を自動的に復元するスクリプトを作成します。

   この例の場合、スクリプト名は/sbin/restore-iptables.shです。ファイル/sbin/restore-iptables.shの内容は次のとおりです。

   #!/bin/sh
   /sbin/iptables-restore < /etc/sysconfig/iptables.rules

3. スクリプトの実行可能ビットを設定します。

   chmod +x /sbin/restore-iptables.sh

4. 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

5. systemdマネージャ構成をリロードし、起動時にサービスを実行できるようにします。

   systemctl daemon-reload
   systemctl enable restore-iptables

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

OSが信頼するCAによって署名された証明書がある場合は、その証明書を提供するようにRoving Edgeを構成します。

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

trust list --filter=ca-anchors

独自の証明書を提供する方法については、「CA Trust Chainを使用した外部インタフェースへのアクセス」を参照してください。

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

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

1. アプライアンスのiaasエンドポイントから証明書を取得します。

   curl --insecure -sS -o external_ca.crt --noproxy "*" https://iaas.pca_name.domain_name/cachain

   このコマンドは、--user-data-fileオプションまたはuser_dataフィールドを指定した--metadataオプションのいずれかを使用して、起動時にインスタンスに渡されるスクリプト内に存在する可能性があります。スクリプトはinit中にインスタンス内でcloud-initによって実行されるため、多数のインスタンスでこの証明書ファイルを手動で取得する手間が省けます。

2. external_ca.crtファイルに保存されているCAバンドルの内容を確認します。

3. 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バンドルがトラスト・チェーンに追加されます。

1. アプライアンスのiaasエンドポイントから証明書を取得します。

   curl --insecure -sS -o external_ca.crt --noproxy "*" https://iaas.pca_name.domain_name/cachain

2. external_ca.crtファイルに保存されているCAバンドルの内容を確認します。

3. グローバル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によって実行されるため、多数のインスタンスでこれらのステップを手動で実行する手間が節約されます。

Python SDKのInstance Principal認可の有効化

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に対するインスタンス・プリンシパル認可の有効化

次の例に示すように、コマンドの認可オプション(--auth)を設定します。

oci os ns get --auth instance_principal

あるいは、次の環境変数を設定します。

OCI_CLI_AUTH=instance_principal

両方を設定した場合、--authに設定された値が環境変数より優先されます。

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

次の例に示すように、プロバイダ定義でauth属性を「InstancePrincipal」に設定してください。

variable "region" {}

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

}

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