policy フィールドとして保持され、そのランナーに配置されたサンドボックスを管理します。
タスク指向の手順ガイドについては、サンドボックスポリシーを設定する を参照してください。実例については、ポリシーの例 を参照してください。
トップレベルフィールド
空のポリシーも有効です。その場合、base のデフォルト値も明示的な制約も適用されません。ただし、プラットフォームの安全ゲートは引き続き適用されます。また、ランタイムクラスの許可リストがない場合、
runtime_class を具体的な値に固定することはできません。base、constraints、control_plane_access の各グループはいずれもオプションです。送信元 IP の許可リストを指定しない場合、送信元アドレスによる制限は追加されません。
解決順序
サンドボックスは2つの段階で解決されます。- Base. ランタイムのデフォルト、
base、サンドボックスの spec の順に適用されます。個々の値についてはサンドボックスの値が優先されます。baseのリスト型のアタッチメントは常に適用されます。 - Constraints. クランプは、完全に解決された spec に対して検証されます。違反があった場合は拒否され、暗黙的に書き換えられることはありません。
base が指定した値も、サンドボックスが指定した値と同じ条件でチェックされます。
base
ランタイムのデフォルトとアタッチメントのフラグメントです。Kubernetes ランナー上では、これは Pod spec のフラグメントです。
base は、サンドボックスが宣言すべきではないインフラストラクチャー設定が存在する場所です: スケジューラー、ノードセレクター、トレランス、優先度クラス、トポロジスプレッド、イメージプルシークレット、プラットフォームボリューム、DNS 設定、およびピン留めされたアノテーションなどの Pod メタデータです。セキュリティ上重要なフィールドは即座に拒否されます。対象には次のものが含まれます。
affinity- Pod およびコンテナーの
securityContext。 runtimeClassNameinitContainers- ホストの namespace。
hostPathボリューム。- デフォルト以外のサービスアカウント。
control_plane_access
ControlPlaneAccessPolicy は、ランナーを選択する Sandbox API リクエストと、そのランナー上に配置されたサンドボックスを対象とする Sandbox API リクエストを制限します。これらの制御は認証と認可を補完するものです。サンドボックスが公開するサービスに直接送信されるトラフィックは制限されません。
SourceIpAllowlist
API は接頭辞を正規化したうえで、重複するエントリと、より広い範囲のエントリに包含される接頭辞を削除します。ゾーン修飾付きの IPv6 アドレスなど、無効な CIDR は拒否されます。
0.0.0.0/0 を指定すると、すべての IPv4 ソースが明示的に許可されます。::/0 を指定すると、すべての IPv6 ソースが明示的に許可されます。
アクセス制御は、作成時の仕様解決とは別に、リクエスト時に評価されます。変更内容は、ポリシーキャッシュに反映された後、既存のサンドボックスに対する新しい操作から適用されます。許可リストの設定にかかわらず、管理者は引き続きポリシーを管理できます。設定、ストリームの動作、エラー、および復旧については、送信元 IP による Sandbox API アクセスの制限を参照してください。
constraints
PolicyConstraints は、ポリシーが強制する型付きのクランプをグループ化します。各グループはオプションです。グループを省略した場合、その種類の制約は明示的には追加されませんが、プラットフォームの安全ゲートと SecurityConstraints のランタイムクラス制限は引き続き適用されます。
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
イングレス ルールは、可視性が
CUSTOM の既存のポートに適用されます。サービスの可視性は変更されません。また、ホスト名やラベルでソースを選択することはできません。
CidrBlock
PortRange
TenantScope
SelectorBlock
一致判定はラベルペアの完全一致で行われますが、宣言側でラベルを追加することもできます。外向き通信の許可リストが空でない場合、宣言されたセレクターには、一致するセレクタールールのラベルペアがすべて含まれている必要があります。namespace ラベルは、両方のセレクターで省略するか、両方で指定する必要があります。指定する場合は、必要な namespace ラベルペアがすべて宣言側に含まれている必要があります。
any ルールはセレクターには適用されませんが、許可リストが空の場合はセレクターを宣言できます。
SecurityConstraints
ホストの namespace は、v1 ポリシーのセキュリティフィールドでは設定できません。以前の
allow_host_network フィールドと allow_host_pid フィールドは削除されました。レガシーの v1beta2 プロフィールについては、例: 特権プロフィールのポスチャーを許可する を参照してください。
allowed_runtime_classes はフェイルクローズドです。リストが空または存在しない場合、具体的な runtime_class のピン留めは一切許可されません。runtime_class_selection によるポータブルなクラス選択では、代わりに runtime_class_mappings が使用されます。
このポリシーにより、サンドボックスが要求できるゲスト内の特権と、選択できるランタイムクラスの範囲が制限されます。
RuntimeClassMapping
空でない runtime_class_mappings リストを指定すると、ポータブルなランタイムクラスの選択が有効になります。マッピングされた各クラスは、呼び出し元が選択できます。RUNTIME_CLASS_CPU_DEFAULT と RUNTIME_CLASS_GPU_DEFAULT は、それぞれのリソースファミリーでの自動選択にも使用されます。いずれかのデフォルトクラスを省略すると、そのファミリーでは自動選択が無効になります。マッピングされていないクラスは利用できず、runtime_class で具体的なクラスを固定指定すると拒否されます。
マッピングは、allowed_runtime_classes、default_cpu_runtime_class、default_gpu_runtime_class と併用できません。各ポータブルクラスは 1 回までしか指定できません。
InstanceConstraints
LifecycleConstraints
ポリシーは有効期間の上限を持ちません。プラットフォームの最大値 (現在30日) がすべてのサンドボックスを制限します：それを超える作成リクエストは拒否されます。
max_lifetime_seconds フィールドはポリシードキュメントから削除され、cwic はそれを含むポリシーを拒否します。
MetadataConstraints
VolumeConstraints
StorageMedium
allowed_media から STORAGE_MEDIUM_MEMORY を省略して、RAMバックアップのボリュームを禁止します。
検証ルール
ポリシーは、以下のいずれかに該当する場合に拒否されます：- エンコードされたドキュメントが256 KiBを超える。
- ポリシーがnullです。設定されたポリシーはクリアできず、置き換えることのみ可能です。
default_egressにhttps_hostnameルールが含まれている。- デフォルトの外向き通信ルールまたはイングレスルールが、対応する許可リストの範囲外にある。
- 送信元 IP の許可リストに無効な IPv4 または IPv6 CIDR が含まれている、エントリ数が 256 を超えている、または CIDR テキストが 16 KiB を超えている。
関連項目
- サンドボックスポリシーを設定する: このページの各グループについて、タスク別に手順を説明するガイドです。
- ポリシーの例: 一般的なクラスターのポスチャーに対応する 5 つの完全なポリシーです。
- ポリシーの概要: サンドボックスがポリシーに照らしてどのように解決されるかを説明します。
- ランナーのデプロイと管理: ポリシーの保存場所と設定方法を説明します。