Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

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

ワークロードはワークロード作成者が作成し、データ共同編集者が操作する機密データを処理します。

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

機密データを処理するアプリケーション。アプリケーションは任意の言語で記述できます。ただし、その言語をサポートするコンテナ化されたイメージをビルドする必要があります。
Docker を使用してアプリケーションをパッケージ化する Docker **コンテナ化されたイメージ**。
Artifact Registry 内の Docker イメージを保存するリポジトリ。
コンテナイメージに設定された {1

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

データ共同編集者は、ワークロードがデータにアクセスする前に、ワークロードのアテステーションを検証する必要があります。

始める前に

Confidential Space のワークロードの作成は、単なるコードの記述とデバッグではありません。データ共同編集者と話し合ってニーズを評価し、環境を設定し、コードをコンテナ化されたイメージにパッケージ化し、ワークロードオペレーターと協力してすべてが正しくデプロイされるようにする必要があります。

データ共同編集者と話し合う

アプリケーションの作成を開始する前に、データ共同編集者と、操作するプライベートデータについて話し合う必要があります。質問の例を次に示します。

関連する組織 ID は何ですか？
関連するプロジェクト番号は何ですか？
アクセスする必要がある Google Cloud リソースとその ID と名前は何ですか？
IAM で管理されていない、アクセスする必要があるリソースはありますか？ Google Cloud
使用するアテステーションサービスは、Google Cloud Attestation と Intel Trust Authority のどちらですか？
アプリケーションでプライベートデータを比較して処理する方法は？
出力の形式は何ですか？
出力の保存場所と、暗号化するかどうか？
すべてのデータ共同編集者に同じ結果が表示されますか、それとも出力はそれぞれ異なりますか？

また、データ共同編集者ごとに、満たす必要のある独自のプライバシー要件がある場合もあります。ワークロードの結果としてプライベートデータが公開されないようにすることが非常に重要です。

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

適切な権限を持つ 2 つ以上のプロジェクトをテスト環境として設定すると便利です。たとえば、最初の Confidential Space 環境を作成するで説明されているように、テスト環境として設定すると便利です。データ共同編集者のプロジェクト設定をできるだけ反映するようにしてください。これにより、プロジェクト間の権限や、特定の Google Cloud リソースから必要なデータを取得する方法を習得できます。また、ワークロードオペレーターとデータ共同編集者の役割と責任を理解することもできます。

初期のビルド段階では、次の方法が役立ちます。

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

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

テスト環境でワークロードが正しく動作したら、データ共同編集者のプロジェクトで実際のリソースを使用してテストに切り替えることができます。ただし、データ共同編集者にすべてがどのように機能するかを説明できるように、偽のデータを使用します。この時点で、独立したワークロードオペレーターとの連携を開始できます。

すべてが正常に動作し、出力が想定どおりになったら、本番環境データでテストを開始できます。テストが完了し、すべての関係者が結果に署名したら、ワークロードを本番環境に移行する準備が整います。

出力に注意する

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

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

Docker を使用してコンテナ化されたイメージをビルドする

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

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

追加の Linux 機能
ディスクとメモリの上限
IAM で管理されていないリソース Google Cloud
正常なシャットダウン
受信ポート
起動ポリシー
複数のワークロードの実行
名前空間方式の cgroup
再現可能なコンテナイメージ
署名付きのコンテナイメージ

追加の Linux 機能

Confidential Space ワークロードは、containerd を使用して Linux コンテナで実行されます。このコンテナは、デフォルトの Linux 機能を使用して実行されます。

機能を追加するには、 tee-added-capabilities を使用します。

ディスクとメモリの上限

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

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

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

正常なシャットダウン

オペレーターが Confidential Space VM のシャットダウンをリクエストすると、Confidential Space Launcher は SIGTERM シグナルを送信してワークロードを正常にシャットダウンしようとします。受信すると、Confidential Space Launcher がシャットダウンプロセスを開始するまでに、ワークロードはクリーンアップを実行するのに最大 120 秒かかります。 SIGTERM シグナル処理を実装していないワークロードは、シグナルを受信するとすぐに終了します。

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

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 で受信ポートを開いたままにするように指定できます。

ポートを開くには、EXPOSE キーワードを Dockerfile に追加します。開いたままにするポート番号と、必要に応じて 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 ファイアウォールで開いていることを確認する必要があります。ポート番号は、ワーク 101}ロード作成者が指定するか、 Docker イメージ情報から pull できます。

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

起動ポリシー

起動ポリシーは、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_capabilities` 連携する要素: ワークロードオペレーター: `tee-added-capabilities` メタデータ変数。	ブール値（デフォルトは `false`）	ワークロードオペレーターがワークロードコンテナに Linux 機能を追加できるかどうかを決定します。
`tee.launch_policy.allow_cgroups` 連携する要素: ワークロードオペレーター: `tee-cgroup-ns` メタデータ変数。	ブール値（デフォルトは `false`）	ワークロードコンテナで、名前空間方式の cgroup マウントを `/sys/fs/cgroup` に含めることができるかどうかを決定します。
`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-monitoring-memory-enable` メタデータ変数。	定義された文字列	ワークロードオペレーターが `tee-monitoring-memory-enable` を `true` に設定した場合のワークロードメモリ使用量のモニタリングの動作を決定します。有効な値は次のとおりです。 `debugonly`（デフォルト）: デバッグイメージを使用する場合にのみ、メモリ使用量のモニタリングを許可します。 `always`: メモリ使用量のモニタリングを常に許可します。 `never`: メモリ使用量のモニタリングを許可しません。注意: メモリ使用量のモニタリングを許可すると、ワークロードオペレーターは Cloud Logging と Metrics Explorer でワークロードのメモリ使用量の指標を確認できます。ワークロードが、メモリ使用量の合計から機密情報が漏洩しないように記述されていない場合は、本番環境ワークロードでこの機能をブロックしてください。

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

ワークロードを再実行するには、ワークロードオペレーターが VM インスタンスを再起動する必要があります。これにより、可能な限りクリーンな環境でワークロードが開始され、VM インスタンスのディスクが新しいエフェメラル鍵で暗号化されます。

再起動により、ダウンロードして測定した後にディスク上のワークロードイメージを変更するという攻撃ベクトルに対処できます。ただし、起動時間や各ワークロード実行へのワークロードイメージの pull などのオーバーヘッドも増加します。これらのオーバーヘッドがワークロードのパフォーマンスに大きな影響を与える場合は、リスクプロファイルの増加を犠牲にして、ワークロード再起動をワークロード自体にコーディングできます。

名前空間方式の cgroup

Confidential Space ワークロードは、デフォルトでは cgroup マウントなしで実行されます。

ワークロードコンテナ内の cgroup を管理するには、 tee-cgroup-nsを使用します。このメタデータキーは、コンテナファイルシステムの /sys/fs/cgroup にマウントを作成するように VM インスタンスに指示します。

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

再現可能な方法でコンテナイメージをビルドすると、関係者間の信頼を高めることができます。再現可能なイメージは Bazel でビルドできます。

IAM で管理されていないリソース Google Cloud

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

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

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

公開鍵を使用してコンテナイメージに署名できます。データ共同編集者は、WIP ポリシーでイメージダイジェストを指定する代わりに、アテステーションにこの公開鍵を使用できます。

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

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

実行時に、署名は検証のためにアテステーションサービスに送信されます。アテステーションサービスは、検証済みの署名クレームを含むアテステーションクレームトークンを返します。署名クレームの例を次に示します。

"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 をご覧ください。