Skip to main content
このページでは、サンドボックスポリシーのすべてのフィールドを説明します。ポリシーは、マネージドランナー上で policy フィールドとして保持され、クラスターは最大で 1 つのランナーをホストするため、1 つのポリシーが 1 つのクラスターを管理します。 タスク指向の手順ガイドについては、サンドボックスポリシーを設定する を参照してください。実例については、ポリシーの例 を参照してください。

トップレベルフィールド

空のポリシーも有効で、制限が一切ないポスチャーを宣言します。base と constraints はどちらもオプションです。そのため、クラスターのポスチャーは常に明示的に宣言され、意図せず継承されることはありません。

解決順序

サンドボックスは2つの段階で解決されます。
  1. Base. ランタイムのデフォルト、base、サンドボックスの spec の順に適用されます。個々の値についてはサンドボックスの値が優先されます。base のリスト型のアタッチメントは常に適用されます。
  2. Constraints. クランプは、完全に解決された spec に対して検証されます。違反があった場合は拒否され、暗黙的に書き換えられることはありません。
制約は送信された spec ではなく解決後の spec に対して検証を行うため、base が指定した値も、サンドボックスが指定した値と同じ条件でチェックされます。

base

ランタイムのデフォルトとアタッチメントのフラグメントです。Kubernetes ランナー上では、これは Pod spec のフラグメントです。 base は、サンドボックスが宣言すべきではないインフラストラクチャー設定が存在する場所です: スケジューラー、ノードセレクター、トレランス、優先度クラス、トポロジスプレッド、サービスアカウント、イメージプルシークレット、プラットフォームボリューム、DNS 設定、およびピン留めされたアノテーションなどの Pod メタデータです。セキュリティ上重要なフィールドは、 affinity、Pod およびコンテナーの securityContext、 runtimeClassName、および initContainers を含め、即座に拒否されます。

constraints

PolicyConstraints は、ポリシーが強制する型付きのクランプをグループ化します。各グループはオプションで、省略されたグループは制限を適用しません。

ResourceConstraints

上限は最大値とは異なります。max_cpuは1つのコンテナーのリクエストを制限しますが、cpu_ceilingは解決済みの合計を制限します。これはbaseが独自のコンテナーを提供する場合に重要です。

ImageConstraints

NetworkConstraints

ネットワーク制約は、サンドボックスがリクエストできるアクセスの許可リストを定義します。サンドボックスが外向き通信を宣言した場合、ポリシーはその宣言を拡張せずに、受け入れるか拒否するかを判断します。サンドボックスが外向き通信を宣言しない場合は、サンドボックスで deny_egress が設定されていない限り、ポリシーによって default_egress が適用されます。プラットフォームの DNS とストレージへのアクセスは別途付与されます。 許可リストが空でない場合、包含関係は送信先またはソースのタイプとポートに基づいてチェックされます。宣言された CIDR は、許可された CIDR 範囲を合わせた範囲内、または any ルールの範囲内に収まる必要があります。テナントスコープを宣言するには、一致するテナントルールまたは any ルールが必要です。また、any を宣言するには any ルールが必要です。

EgressRule

各ルールで指定する送信先は 1 つだけです。必要に応じて、ポートで絞り込むこともできます。 ホスト名ルールで許可されるのは HTTPS アクセスであり、DNS クエリは対象外です。allowed_egress が空でない場合、宣言するホスト名は、除外を適用した後の許可済みホスト名パターン、または any ルールのいずれかに当てはまる必要があります。CIDR のみで構成された許可リストでは、ホスト名を宣言できません。再利用するホスト名のグラントは、default_egress ではなく サンドボックステンプレート に記述してください。 dns_egress は、UDP/TCP ポート 53 への外向き通信を個別に制御します。DNS_EGRESS_MODE_ALLOW は、プラットフォームのリゾルバーへのアクセスを許可します。その他のリゾルバーを使用するには、外向き通信ルールが必要です。DNS_EGRESS_MODE_DENY は、他のルールで許可されている場合でも、ポート 53 への外向き通信をブロックします。ただし、ローカルで応答されるルックアップや、HTTPS など許可されている他のトランスポートを経由する DNS はブロックされません。

IngressRule

イングレス ルールはソースを名前で指定することはありません。インバウンドパケットには名前が含まれていないためです。

CidrBlock

PortRange

TenantScope

SelectorBlock

一致判定はラベルペアの完全一致で行われますが、宣言側でラベルを追加することもできます。外向き通信の許可リストが空でない場合、宣言されたセレクターには、一致するセレクタールールのラベルペアがすべて含まれている必要があります。namespace ラベルは、両方のセレクターで省略するか、両方で指定する必要があります。指定する場合は、必要な namespace ラベルペアがすべて宣言側に含まれている必要があります。any ルールはセレクターには適用されませんが、許可リストが空の場合はセレクターを宣言できます。

SecurityConstraints

allowed_runtime_classes は、空が「何もなし」を意味する唯一のリストであり、「何でも」を意味するわけではない。サンドボックスは、明示的に指定したランタイムクラスのみを選択できる。 ホストに到達する設定はポリシーのみで、サンドボックスの spec には表示されない。使用する分離方式に関係なく。

InstanceConstraints

LifecycleConstraints

ポリシーは有効期間の上限を持ちません。プラットフォームの最大値 (現在30日) がすべてのサンドボックスを制限します:それを超える作成リクエストは拒否されます。max_lifetime_seconds フィールドはポリシードキュメントから削除され、cwic はそれを含むポリシーを拒否します。

MetadataConstraints

VolumeConstraints

StorageMedium

allowed_media から STORAGE_MEDIUM_MEMORY を省略して、RAMバックアップのボリュームを禁止します。

検証ルール

ポリシーは、以下のいずれかに該当する場合に拒否されます:
  • エンコードされたドキュメントが256 KiBを超える。
  • ポリシーがnullです。設定されたポリシーはクリアできず、置き換えることのみ可能です。
  • default_egress に https_hostname ルールが含まれている。
  • デフォルトの外向き通信ルールまたはイングレスルールが、対応する許可リストの範囲外にある。

関連項目

最終更新日 2026年10月15日