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

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

インスタンスを認可されたアクター(またはプリンシパル)にし、サービス・リソースに対するアクションを実行できるようにする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
```

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

デフォルトでは、Private Cloud Applianceエンドポイント(iaasやidentityなど)は、そのアプライアンスに固有のCAによって署名された証明書を提供します。デフォルトでは、オペレーティング・システムは、このPrivate Cloud Applianceに固有のCAによって署名された証明書を信頼しません。提供される証明書をOSが信頼しない場合、OCI SDKまたはOCI CLIを使用しようとすると、CERTIFICATE_VERIFY_FAILEDエラーで失敗します。

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

ノート:

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

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

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

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

trust list --filter=ca-anchors

独自の証明書を提供する方法の詳細は、「Oracle Private Cloud Appliance管理者ガイド」の「ハードウェア管理」の章にある、「CAトラスト・チェーンを使用した外部インタフェースへのアクセス」に関する項を参照してください。

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

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

アプライアンスのiaasエンドポイントから証明書を取得します。
```
curl --insecure -sS -o external_ca.crt --noproxy "*" https://iaas.pca_name.domain_name/cachain
```
このコマンドは、起動時にインスタンスに渡されるスクリプトに、--user-data-fileオプションまたはuser_dataフィールドを指定した--metadataオプションのいずれかを使用して含めることができます。スクリプトは、初期化中にインスタンス内で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: Private Cloud Appliance CAバンドルをグローバルに信頼

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

ノート:

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

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

curl --insecure -sS -o external_ca.crt --noproxy "*" https://iaas.pca_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によって実行されるため、多数のインスタンスでこれらのステップを手動で実行する手間が省けます。

Instance Principals用のPython SDKおよびOCI CLIの構成

このトピックでは、Python SDK、OCI CLIまたはTerraformのインスタンス・プリンシパル認可を有効にする方法について説明します。

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()

OCI CLIに対するInstance Principal認可の有効化

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

oci os ns get --auth instance_principal

または、次の環境変数を設定します:

OCI_CLI_AUTH=instance_principal

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

Terraformに対するInstance Principal認可の有効化

次の例に示すように、プロバイダ定義でauth属性を「InstancePrincipal」に設定します:

variable "region" {}

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

}

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