このページは Cloud Translation API によって翻訳されました。

ワークロードを作成してカスタマイズする

ワークロードの作成者

ワークロードはワークロードの作成者によって作成され、データコラボレーションパートナーが操作する機密データを処理します。

ワークロード作成者は、ワークロードを作成するために次のリソースをまとめる必要があります。

機密データを処理するアプリケーション。任意の言語でアプリケーションを記述できます。ただし、その言語をサポートするコンテナ化されたイメージをビルドする必要があります。
Docker を使用してアプリケーションをパッケージ化するコンテナ化イメージ。
Docker イメージを保存する Artifact Registry のリポジトリ。
コンテナイメージに設定された起動ポリシー。ワークロードの実行方法を制御し、悪意のあるワークロードオペレーターの機能を制限します。

ワークロードをデプロイするには、Confidential Space イメージに基づいてワークロードオペレーターが Confidential VM を実行します。これにより、Artifact Registry からコンテナ化されたイメージが取得され、実行されます。

データコラボレーションパートナーは、データにアクセスする前にワークロードの構成証明を検証する必要があります。

始める前に

Confidential Space のワークロードの作成は、単なるコードとデバッグではありません。また、データコラボレーションパートナーと連携してニーズを評価し、環境を設定し、コードをコンテナ化されたイメージにパッケージ化する必要があります。また、ワークロードオペレーターと連携して、すべてが正しくデプロイされるようにする必要があります。

データコラボレーションパートナーに相談する

アプリケーションの作成を開始する前に、データコラボレーションパートナーと、処理する必要がある機密データについて話し合う必要があります。次のような質問をします。

関連する組織 ID は何ですか？
関連するプロジェクト番号を教えてください。
アクセスする必要がある Google Cloud リソースと、その ID と名前は何ですか？
Google CloudIAM で管理されていないリソースにアクセスする必要がありますか？
アプリは非公開データをどのように比較して処理する必要がありますか？
出力の形式
出力をどこに保存し、暗号化する必要がありますか？
すべてのデータコラボレータに同じ結果が表示されますか？それとも、出力はそれぞれ固有ですか？

また、各データコラボレータには、満たす必要がある独自のプライバシー要件がある場合があります。ワークロードの結果として機密データが漏洩しないようにすることが非常に重要です。

Confidential Space ソリューションを構築する

最初の Confidential Space 環境を作成するのように、適切な権限を持つ 2 つ（またはそれ以上）のプロジェクトをテスト環境として設定すると便利です。データコラボレーションパートナーのプロジェクト設定をできるだけミラーリングするようにしてください。これにより、プロジェクト間の権限を学習し、特定の Google Cloud リソースから必要なデータを取得できます。また、ワークロードオペレーターとデータコラボレーターの役割とその責任を理解することもできます。

初期の構築フェーズでは、次の方法をおすすめします。

データ共同編集者として作業する場合は、開発速度を重視して構成証明の検証を最小限に抑えます。
ワークロードオペレーターとして作業する場合は、ワークロードをデプロイするときに本番環境ではなく Confidential Space デバッグイメージを使用します。これにより、ワークロードのトラブルシューティングを行う方法が増えます。

アプリケーションが成熟し、状態が予測可能になるにつれて、構成証明の検証と起動ポリシーを使用してソリューションをロックダウンし、本番環境の Confidential Space イメージに切り替えることができます。

テスト環境でワークロードが正しく動作したら、実際のリソースではなく偽のデータを使用してデータコラボレーションパートナーのプロジェクトでテストに切り替え、すべての動作をデータコラボレーションパートナーに示すことができます。この時点で、独立したワークロードオペレータの使用を開始できます。

すべてが正常に動作し、出力が想定どおりであれば、本番環境データでのテストを開始できます。テストが完了し、すべての関係者が結果に同意すると、ワークロードは本番環境に導入する準備が整います。

出力に注意する

コードをテストするときに、STDOUT または STDERR に印刷してデバッグしたくなることがあります。公開する場合は、他のユーザーがログにアクセスして読み取れる機密データを公開しないように注意してください。コードが本番環境で動作を開始する前に、厳密に必要なもの以外を出力していないことを確認してください。

最終出力についても同様です。元のデータのプライバシーと機密性を損なわない最終結果のみを提供します。

Docker でコンテナ化イメージをビルドする

アプリケーションは、Docker によってビルドされたコンテナ化されたイメージにパッケージ化され、Artifact Registry に保存する必要があります。ワークロードがデプロイされると、Confidential Space イメージによって Docker イメージが Artifact Registry リポジトリから pull され、実行されます。これにより、アプリケーションは適切なプロジェクトリソースでの処理を開始できます。

Docker イメージをビルドする際は、次の点を考慮してください。

ディスクとメモリの上限
有効期限切れの OIDC トークン
Google Cloud IAM によって管理されていないリソース
受信ポート
リリースポリシー
複数のワークロードの実行
再現可能なコンテナイメージ
署名付きコンテナイメージ

ディスクとメモリの上限

大きなブートディスクサイズを使用する場合、Confidential Space はブートディスクのステートフルパーティションのサイズを自動的に変更します。パーティションサイズは、ブートディスクのサイズから 5 GB を引いた値になります。

Confidential Space の整合性ファイルシステム保護の一環として、Confidential Space はディスク整合性タグをメモリに保存します。これにより、ディスクバイトごとに約 1% のメモリオーバーヘッドが発生します。たとえば、100 GB のディスクには 1 GB のメモリが必要で、10 TB のディスクには 100 GB のメモリが必要です。

VM のメモリ上限を超えないようにしてください。スワップメモリが Confidential Space VM で無効になっています。そのため、メモリを過剰に使用するとワークロードがクラッシュする可能性があります。マシンの選択が、ディスク完全性のオーバーヘッドに加えてワークロードのメモリ使用量をサポートしていることを確認します。

有効期限切れの OIDC トークン

ワークロードの開始時に、ワークロードで OIDC トークンが使用できるようになります。ワークロードの VM に関する検証済みの構成証明クレームが含まれており、ワークロードコンテナの /run/container_launcher/attestation_verifier_claims_token に保存されます。トークンは 60 分経過すると期限切れになります。

トークンの有効期限が切れた場合、指数バックオフを使用してバックグラウンドで更新が試行され、成功するまで続けられます。更新が失敗した場合（ネットワークの問題、証明書サービスの停止などにより）、ワークロードコードはその障害に対処できる必要があります。

ワークロードは、次のいずれかの方法でトークンの更新エラーを処理できます。

有効期限切れのトークンは、最初の使用後に不要になったと見なして無視します。
期限切れのトークンが正常に更新されるまで待ちます。
ワークロードを終了します。

インメモリスクラッチマウント

Confidential Space は、メモリ内スクラッチ空間の追加をサポートしています。これにより、Confidential Space VM で使用可能なメモリが使用されます。スクラッチ空間は Confidential VM のメモリを使用するため、Confidential VM と同じ完全性と機密性のプロパティを持ちます。

tee-dev-shm-size を使用すると、ワークロードの /dev/shm 共有メモリマウントのサイズを増やすことができます。/dev/shm のサイズは KB 単位で指定します。

tee-mount を使用すると、実行中のコンテナでセミコロンで区切られた構成を使用して tmpfs マウントを指定できます。type と source は常に tmpfs です。destination はマウントポイントで、tee.launch_policy.allow_mount_destinations 起動ポリシーとやり取りします。必要に応じて、tmpfs のサイズをバイト単位で指定できます。デフォルトのサイズは VM メモリの 50% です。

受信ポート

デフォルトでは、Confidential Space VM はファイアウォールルールで動作し、すべてのインバウンドポートをブロックします。バージョンが 230600 以降の Confidential Space イメージを使用する場合は、ワークロードイメージを作成するときに Dockerfile で受信ポートを開いたままにするように指定できます。

ポートを開くには、Dockerfile に EXPOSE キーワードを追加し、開いたままにするポート番号と、オプションのプロトコル（tcp または udp）を追加します。ポートのプロトコルを指定しない場合、TCP と UDP の両方が許可されます。受信ポートを公開する Dockerfile の例を次に示します。

FROM alpine:latest
EXPOSE 80
EXPOSE 443/tcp
EXPOSE 81/udp
WORKDIR /test
COPY salary /test
ENTRYPOINT ["/test/salary"]
CMD []

使用するベースイメージによっては、一部のポートがすでに公開されている場合があります。Dockerfile は追加のポートのみを公開します。ベースイメージによってすでに開かれているポートをブロックすることはできません。

ワークロードオペレーターは、ワークロードを実行する前に、公開されているポートが VPC ファイアウォールで開いていることを確認する必要があります。ポート番号は、ワークロードの作成者が指定することも、Docker イメージ情報から pull することもできます。

公開されたポートはコンソールにログインされ、tee-container-log-redirect メタデータ変数を使用すると Cloud Logging にリダイレクトされます。

起動ポリシー

起動ポリシーは、ワークロードオペレーターが設定した VM メタデータ変数をオーバーライドして、悪意のあるアクションを制限します。ワークロード作成者は、コンテナイメージのビルドの一環として、ラベルを使用してポリシーを設定できます。

たとえば、Dockerfile では:

LABEL "tee.launch_policy.allow_cmd_override"="true"

Bazel BUILD ファイルでは:

container_image(
    ...
    labels={"tee.launch_policy.allow_cmd_override":"true"}
    ...
)

次の表に、利用可能な起動ポリシーを示します。

ポリシー	タイプ	説明
`tee.launch_policy.allow_cmd_override` 関連する項目: ワークロードオペレーター: `tee-cmd` メタデータ変数。データコラボレータ: `container.cmd_override` アサーション。	ブール値（デフォルトは `false`）	ワークロードコンテナの `Dockerfile` で指定された `CMD` が、ワークロード演算子によって `tee-cmd` メタデータ値でオーバーライドされるかどうかを決定します。
`tee.launch_policy.allow_env_override` 関連する項目: ワークロードオペレーター: `tee-env-ENVIRONMENT_VARIABLE_NAME` メタデータ変数。データの共同編集者: `container.env` アサーションと `container.env_override` アサーション。	カンマ区切りの文字列	`tee-env-ENVIRONMENT_VARIABLE_NAME` メタデータ値を使用してワークロードオペレーターが設定できる、許可された環境変数名のカンマ区切り文字列。
`tee.launch_policy.allow_mount_destinations` 関連する項目: ワークロードオペレーター: `tee-mount` メタデータ変数。	コロンで区切られた文字列	ワークロードオペレーターが `tee-mount` を使用してマウントできる、許可されたマウントディレクトリのコロンで区切られた文字列。例: `/run/tmp:/var/tmp:/tmp`
`tee.launch_policy.log_redirect` 関連する項目: ワークロードオペレーター: `tee-container-log-redirect` メタデータ変数。	定義された文字列	ワークロードオペレーターによって `tee-container-log-redirect` が `true` に設定されている場合、ロギングの動作を決定します。有効な値は次のとおりです。 `debugonly`（デフォルト）: デバッグイメージを使用する場合、`stdout` リダイレクトと `stderr` リダイレクトのみを許可します。 `always`: `stdout` リダイレクトと `stderr` リダイレクトを常に許可します。 `never`: `stdout` リダイレクトと `stderr` リダイレクトは許可しません。
`tee.launch_policy.monitoring_memory_allow` 関連する項目: データコラボレータ: `monitoring_enabled.memory` アサーション。ワークロードオペレーター: `tee-memory-monitoring-enable` メタデータ変数。	定義された文字列	ワークロードオペレーターによって `tee-memory-monitoring-enable` が `true` に設定されている場合、ワークロードのメモリ使用量モニタリングがどのように機能するかを決定します。有効な値は次のとおりです。 `debugonly`（デフォルト）: デバッグイメージを使用する場合にのみ、メモリ使用量のモニタリングを許可します。 `always`: メモリ使用量のモニタリングを常に許可します。 `never`: メモリ使用量のモニタリングを許可しない。注意: メモリ使用量のモニタリングを許可すると、ワークロードオペレーターは Cloud Logging と Metrics Explorer でワークロードのメモリ使用量の指標を確認できます。ワークロードが、メモリの総使用量から機密情報が漏洩しないように記述されていない場合は、本番環境ワークロードでこの機能をブロックします。

複数のワークロードの実行

クリーンな環境を確保するため、VM を再起動してワークロードを再起動する必要があります。これにより、VM ディスクがエフェメラル鍵で暗号化され、ディスク上のワークロードイメージがダウンロードされて測定された後に変更されるという攻撃ベクトルに対処できます。

これにより、起動時間や各ワークロード実行へのワークロードイメージの pull などのオーバーヘッドも増加します。これらのオーバーヘッドがワークロードのパフォーマンスに大きな影響を与える場合は、リスクプロファイルの増加を犠牲にして、ワークロード再起動をワークロード自体にコーディングできます。

再現可能なコンテナイメージ

再現可能な方法でコンテナイメージを構築すると、当事者間の信頼度が高まります。Bazel を使用して再現可能なイメージをビルドできます。

Google Cloud IAM によって管理されていないリソース

Google Cloud IAM によって管理されていないリソースにアクセスするには、ワークロードでカスタムオーディエンスを指定する必要があります。

詳細については、 Google Cloud IAM によって管理されていないリソースにアクセスするをご覧ください。

署名付きコンテナイメージ

公開鍵を使用してコンテナイメージに署名できます。データコラボレータは、WIP ポリシーでイメージダイジェストを指定する代わりに、この署名を構成証明に使用できます。

つまり、データ共同編集者はワークロードが更新されるたびに WIP ポリシーを更新する必要はなく、ワークロードは保護されたリソースに中断なくアクセスし続けることができます。

Sigstore Cosign を使用してコンテナイメージに署名できます。Confidential Space が署名を取得できるようにするには、ワークロードオペレーターはワークロードをデプロイする前に、署名情報を tee-signed-image-repos メタデータ変数に追加する必要があります。

実行時に、署名は検証のために Confidential Space 構成証明サービスに送信されます。構成証明サービスは、検証済みの署名クレームを含む構成証明クレームトークンを返します。署名の申し立ての例を次に示します。

"image_signatures": [
  {
    "key_id": "hexadecimal-sha256-fingerprint-public-key1",
    "signature": "base64-encoded-signature",
    "signature_algorithm": "RSASSA_PSS_SHA256"
  },
  {
    "key_id": "hexadecimal-sha256-fingerprint-public-key2",
    "signature": "base64-encoded-signature",
    "signature_algorithm": "RSASSA_PSS_SHA256",
  },
  {
    "key_id": "hexadecimal-sha256-fingerprint-public-key3",
    "signature": "base64-encoded-signature",
    "signature_algorithm": "RSASSA_PSS_SHA256",
  }
],

コンテナイメージの署名を構成するには、署名付きコンテナイメージの Codelab をご覧ください。