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

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

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

ワークロードの作成者は、次のリソースを組み合わせてワークロードを作成する必要があります。

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

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

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

始める前に

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

データ共同編集者と話す

アプリケーションの作成を開始する前に、データコラボレーターと、作業する非公開データについて話し合う必要があります。次のような質問をすることができます。

関連する組織 ID
関連するプロジェクト番号は何ですか？
アクセスする必要がある Google Cloud リソースは何か。その ID と名前は何か。
Google CloudIAM で管理されていないリソースにアクセスする必要がありますか？
使用する証明書サービス（Google Cloud Attestation または Intel Trust Authority）
アプリケーションはどのように個人データを比較して処理すべきですか。
出力はどのような形式にする必要がありますか？
出力の保存場所と、暗号化の有無
すべてのデータコラボレーターが同じ結果を見ているか、それとも出力はそれぞれに固有か。

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

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

最初の Confidential Space 環境を作成するのように、適切な権限を持つ 2 つ（またはそれ以上）のプロジェクトをテスト環境として設定すると便利です。データコラボレーターのプロジェクト設定をできるだけ忠実に再現してください。これにより、プロジェクト間の権限を付与し、特定の Google Cloud リソースから必要なデータを取得する経験を積むことができます。また、ワークロードオペレーターとデータコラボレーターのロールとその責任についても理解できます。

初期の構築フェーズでは、次のプラクティスを遵守することをおすすめします。

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

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

テスト環境でワークロードが正しく動作することを確認したら、データコラボレーターのプロジェクトで実際のリソースを使用してテストに切り替えることができます。ただし、データコラボレーターにすべての動作をデモンストレーションできるように、ダミーデータを使用します。この時点で、独立したワークロードオペレーターとの連携を開始できます。

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

出力に注意する

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

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

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

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

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

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

追加の 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 シグナルを送信してワークロードを正常にシャットダウンしようとします。受信すると、ワークロードは最大 120 秒以内にクリーンアップを実行してから、Confidential Space Launcher がシャットダウンプロセスを開始します。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 で受信ポートを開いたままにするように指定できます。

ポートを開くには、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 イメージ情報から取得することもできます。

公開されたポートはコンソールにログインされ、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_capabilities` 操作対象: ワークロードオペレーター: `tee-added-capabilities` メタデータ変数。	ブール値（デフォルトは `false`）	ワークロードオペレーターがワークロードコンテナに Linux 機能を追加できるかどうかを決定します。
`tee.launch_policy.allow_cgroups` 操作対象: ワークロードオペレーター: `tee-cgroup-ns` メタデータ変数。	ブール値（デフォルトは `false`）	ワークロードコンテナに、`/sys/fs/cgroup` で名前空間化された 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 でワークロードのメモリ使用量の指標を確認できます。メモリ使用量の合計から機密情報が漏洩しないようにワークロードが作成されていない場合は、本番環境のワークロードでこの機能をブロックします。
`tee.launch_policy.nonroot_container` 操作対象: ワークロードオペレーター: `tee-nonroot-container` メタデータ変数。	定義済みの文字列	コンテナの実行権限を制限するかどうかを決定します。有効な値は次のとおりです。 `unrestricted`（デフォルト）: ワークロードの作成者は、コンテナを root または root 以外として実行することを許可します。ワークロードオペレーターは、 `tee-nonroot-container` を使用して選択します。 `nonrootonly`: ワークロードの作成者は、コンテナを root 以外のユーザーとして実行する必要があります。ワークロードオペレーターは、 `tee-nonroot-container` を `true` に設定する必要があります。設定しない場合、VM はワークロードを起動できません。注: Confidential Space イメージ `confidential-space-261001` 以降でサポートされています。以前のイメージで使用すると、このポリシーは無視され、コンテナは root として実行されます。

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

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

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

名前空間 cgroup

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

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

非 root コンテナの実行

必要に応じて、コンテナを root 以外のユーザーとして実行し、コンテナブレイクアウトの影響を軽減できます。root 以外のコンテナの実行が有効になっている場合、Confidential Space はワークロードの Linux ユーザー名前空間とネットワーク名前空間を構成します。コンテナの UID と GID 0～65535 は、Confidential VM の 100000 から始まる非特権 ID にマッピングされます。コンテナ内で root として実行されるプロセス、またはコンテナをエスケープするプロセスは、VM への非特権アクセスのみを持ちます。Dockerfile に USER 命令を追加する必要はありません。

非 root 実行には、Confidential Space イメージ confidential-space-261001 以降が必要です。このフィールドは、オプションまたは必須として構成できます。

ワークロード作成者: コンテナイメージで tee.launch_policy.nonroot_container 起動ポリシーラベルを使用します。このポリシーを nonrootonly に設定すると、ワークロードオペレーターはコンテナを root ユーザー以外のユーザーとして実行する必要があります。
ワークロードオペレーター: VM の作成時に tee-nonroot-container=true メタデータ変数を渡します。ワークロードの作成者が nonrootonly を設定している場合、このメタデータ変数は必須です。設定されていない場合、VM はワークロードを起動できません。

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

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

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

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

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

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

公開鍵を使用してコンテナイメージに署名できます。データコラボレーターは、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 をご覧ください。