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

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

ワークロードはワークロードの作成者によって作成され、データコラボレーターが使用する機密データを処理します。

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

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

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

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

始める前に

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

データコラボレーターと話し合う

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

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

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

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 機能
ディスクとメモリの上限
有効期限切れの OIDC トークン
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 で無効になっています。そのため、メモリを過剰に使用するとワークロードがクラッシュする可能性があります。マシンを選択する際は、ディスクの完全性オーバーヘッドに加えて、ワークロードのメモリ使用量をサポートしていることを確認してください。

有効期限切れの 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 イメージ情報から取得できます。

公開されたポートはコンソールにログインされ、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-memory-monitoring-enable` メタデータ変数。	定義された文字列	`tee-memory-monitoring-enable` がワークロードオペレーターによって `true` に設定されている場合、ワークロードのメモリ使用量のモニタリングの仕組みを決定します。有効な値は次のとおりです。 `debugonly`（デフォルト）: デバッグイメージを使用する場合のみ、メモリ使用量のモニタリングを許可します。 `always`: メモリ使用量のモニタリングを常に許可します。 `never`: メモリ使用量のモニタリングを許可しません。注意: メモリ使用量のモニタリングを許可すると、ワークロードオペレーターは Cloud Logging と Metrics Explorer でワークロードのメモリ使用量の指標を確認できます。ワークロードが、メモリ使用量の合計から機密情報が漏洩しないように記述されていない場合は、本番環境のワークロードでこの機能をブロックします。

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

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

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

名前空間付き cgroup

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

ワークロードコンテナ内の cgroup を管理するには、tee-cgroup-ns を使用します。これにより、コンテナのファイルシステムの /sys/fs/cgroup にマウントが作成されます。

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

再現可能な方法でコンテナイメージを構築すると、当事者間の信頼度が高まります。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 をご覧ください。