Skip to main content
このページでは、一般的なクラスターのポスチャーに対応する5つの完全なポリシーをまとめています。そのため、ゼロから作成するのではなく、機能するドキュメントから開始できます。 クラスターにはポリシーが1つだけ存在するため、これらのサンプルは組み合わせて使用するものではなく、代替となるものです。クラスターの目的に合ったポスチャーを選択し、調整してください。各サンプルは完全なポリシードキュメントです。cwic sandbox runner policy edit [RUNNER-ID] -f policy.json を使用して適用するか、ランナー更新の policy フィールドとして送信します。[RUNNER-ID] をポリシーを編集したいランナーの ID に置き換え、イメージレジストリのサンプルの [GITHUB-ORG] を GitHub Container Registry の組織名またはユーザー名に置き換えてください。 フィールドごとの詳細な手順については、サンドボックスポリシーを設定するを参照してください。

GPU データサイエンスクラスター

ユーザーごとの長期的な作業向けのクラスターです。十分なコンピュート、GPU Node に加え、データセットやパッケージをプルするためのインターネットアクセスを備えています。ただし、インスタンスメタデータエンドポイントへのアクセスは除外されています。
policy.json
allowedRuntimeClasses はフェイルクローズで動作するため、両方のランタイムクラスを列挙しています。サンドボックスが固定できるのは明示的に指定したクラスのみで、クラスを固定しない場合にどのクラスが割り当てられるかは、2 つのデフォルトによって決まります。

許可リスト付き外向き通信を備えた共有エージェントクラスター

組織内のエージェントワークロード向けのマルチテナントクラスターです。エージェントは組織内の固定された上流のセットと相互に到達可能で、それ以外には到達できません。
policy.json
何も宣言しないサンドボックスには、最初の CIDR のみが許可されます。組織内の他のサンドボックスと通信する必要があるサンドボックスは、テナントルールを自ら宣言します。このルールはポリシーの範囲内に収まるため、ポリシーによって許可されます。

エフェメラル CI クラスター

短命で、小規模かつ狭いものです。サンドボックスは test run の期間だけ存在します。
policy.json
15 分のデフォルトが有用な部分です。何も宣言しない CI ジョブはすぐに自己終了します。ポリシーに有効期間の上限はありません。プラットフォームの最大値である 30 日を超えるリクエストは作成時に拒否され、それ以下のものは許可されます。そのため、ハードなジョブごとの上限が必要な場合は、作成リクエストで max_lifetime_seconds を設定してください。

デフォルトの外向き通信がない VM 分離実行

このポリシーは VM 分離を必須とし、デフォルトの外向き通信ルールを定義しません。UDP/TCP ポート 53 宛ての外向き DNS トラフィックはブロックしますが、allowedEgress が空であるため、サンドボックスはその他の外向き通信を宣言できます。
policy.json
このポリシーは、完全なネットワーク分離を強制するものではありません。allowedEgress リストが空でも明示的な送信先ルールは許可されます。また、プラットフォームのストレージへのアクセスは別途付与されます。dnsEgress は外向きのポート 53 をブロックしますが、HTTPS など、許可されている他のトランスポートを経由した DNS はブロックしません。
allowedImages はレジストリ単位ではなく 1 つのイメージを固定するため、サンドボックスが信頼済みレジストリから任意のイメージを選択することはできません。

内部ワーカークラスター

組織内の他のサンドボックスからサービス経由でアクセスできる、長時間稼働するバックグラウンドワーカーです。サードパーティ API の呼び出し用に外部へのアクセスを備えています。
policy.json
外向き通信の範囲は、ワーカーがパブリックインターネットと組織内の同階層のサンドボックスに到達できるように設定されており、プライベートアドレス空間とメタデータアドレスは除外されています。
この例では外向き通信のみを設定します。可視性が CUSTOM のポートへの受信アクセスを制限するには、allowedIngress を追加し、必要に応じて defaultIngress も追加します。詳しくは、ネットワークアクセスを制限するを参照してください。

ベースレイヤーで管理者デフォルトを固定する

上記のどのポリシーにも base フラグメントを含めることができます。これは管理者が設定するアタッチメントで、サンドボックスが何を要求するかにかかわらず、ランナー上のすべてのサンドボックスに適用されます。次に示す内部ワーカーポリシーのバリエーションでは、ノードの選択、プライベートレジストリ用のイメージプルシークレット、コスト配分ラベルをすべてのサンドボックスに固定しています。
policy.json
base フラグメントは、周辺の制約フィールドとは異なり、camelCase キーを使用した Kubernetes の Pod 仕様のサブセットであり、不明なキーは拒否されます。受け入れるのはスケジューリングとランタイムの接続のみです: nodeSelector、tolerations、imagePullSecrets、volumes、topologySpreadConstraints、hostAliases、DNS 設定、name、env、envFrom、volumeMounts、volumeDevices に限定された単一の containers エントリ、および Pod のラベルとアノテーションです。セキュリティ上重要なフィールドは拒否されます: securityContext、runtimeClassName、initContainers、affinity、ホスト namespace、hostPath ボリューム、デフォルト以外のサービスアカウント、およびランナーが所有する namespace です。有効期間、イメージ、外向き通信などの型指定された項目は constraints に属し、base には属しません。 CKS クラスターでは、template attachments がテンプレートごとにこのフラグメントを特化します: imagePullSecrets と tolerations は結合され、重複排除され、他のリストは追加され、マップキーはキーごとに上書きされ、同じ名前の競合は作成を拒否します。base の現在の適用ステータスについては、ベースレイヤー を参照してください。

クラスター間でポスチャーを変える

ポリシーはクラスターに属するため、異なるポスチャーは1つのクラスター上の異なるドキュメントではなく、異なるクラスターとなります。オープンなデータサイエンス環境とロックダウンされた実行環境の両方を必要とするチームは、2つのクラスターを実行し、それぞれに一致するポリシーを割り当てます。 リージョンごとに1つのディメンションを変えるには、リージョン固有の値を変更した同じポリシーを各クラスターに適用します。共有または継承されたポリシードキュメントはないため、信頼できるソースをバージョン管理に保持し、クラスターごとに適用します。

関連項目

最終更新日 2026年10月15日