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
再現可能なコンテナイメージ
署名付きコンテナイメージ

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

ポートを開くには、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 でワークロードのメモリ使用量の指標を確認できます。ワークロードが、メモリ使用量の合計から機密情報が漏洩しないように記述されていない場合は、本番環境ワークロードでこの機能をブロックします。

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

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

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

名前空間方式の cgroup

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

ワークロードコンテナ内の cgroup を管理するには、tee-cgroup-ns を使用します。このメタデータキーは、コンテナファイルシステムの /sys/fs/cgroup にマウントを作成するように 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 をご覧ください。