プロジェクト Namespace レベルで仮想マシン(VM)ワークロードのネットワーク ポリシーを設定するには、ProjectNetworkPolicy
リソース(Google Distributed Cloud Air-Gapped(GDC)のマルチクラスタ ネットワーク ポリシー)を使用します。ポリシーを定義して、プロジェクト内、プロジェクト間、外部 IP アドレスへの通信を許可できます。
プロジェクト内のトラフィックの場合、GDC はデフォルトで、事前定義されたプロジェクト ネットワーク ポリシー(プロジェクト内ポリシー)を各プロジェクトに適用します。同じ組織内のプロジェクト間でトラフィックを有効にして制御するには、プロジェクト間のポリシーを定義します。複数のポリシーが存在する場合、GDC は各プロジェクトのルールを加算的に結合します。GDC では、ルールが 1 つでも一致すればトラフィックが許可されます。
権限とアクセス権をリクエストする
このページに記載されているタスクを実行するには、プロジェクトの NetworkPolicy 管理者のロールが必要です。プロジェクトの IAM 管理者に、VM が存在するプロジェクトの Namespace でプロジェクトの NetworkPolicy 管理者(project-networkpolicy-admin
)ロールを付与するよう依頼します。
プロジェクト内のトラフィック
デフォルトでは、プロジェクト Namespace の VM ワークロードは、VM が同じプロジェクト内の異なるクラスタに属していても、外部にサービスを公開することなく相互に通信できます。
上り(内向き)プロジェクト内トラフィック ネットワーク ポリシー
プロジェクトを作成すると、プロジェクト内の通信を許可するために、Management API サーバーにデフォルトのベース ProjectNetworkPolicy
が作成されます。このポリシーでは、同じプロジェクト内の他のワークロードからの上り(内向き)トラフィックが許可されます。削除できますが、プロジェクト内とコンテナ ワークロードの両方の通信が拒否されるため、削除する場合は注意してください。
プロジェクト内の下り(外向き)トラフィック ネットワーク ポリシー
デフォルトでは、下り(外向き)について対応する必要はありません。これは、下り(外向き)ポリシーがない場合、すべてのトラフィックが許可されるためです。ただし、単一のポリシーを設定すると、そのポリシーで指定されたトラフィックのみが許可されます。
データ漏洩防止を無効にして、外部リソースへのアクセスを防止するなど、プロジェクトに下り(外向き)ProjectNetworkPolicy
を適用する場合は、必要なポリシーを使用してプロジェクト内の下り(外向き)を許可します。
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
namespace: PROJECT_1
name: allow-intra-project-egress-traffic
spec:
policyType: Egress
ingress:
- from:
- projects:
matchNames:
- PROJECT_1
EOF
プロジェクト間(組織内)トラフィック
異なるプロジェクト名前空間の VM ワークロード(同じ組織内)は、クロス プロジェクト ネットワーク ポリシーを適用することで相互に通信できます。
上り(内向き)のプロジェクト間トラフィック ネットワーク ポリシー
プロジェクト ワークロードで別のプロジェクトの他のワークロードからの接続を許可するには、他のプロジェクト ワークロードでデータ転送を許可するように上り(内向き)ポリシーを構成する必要があります。
次のポリシーでは、PROJECT_1
プロジェクトのワークロードが PROJECT_2
プロジェクトのワークロードからの接続と、同じフローの戻りトラフィックを許可します。PROJECT_2
内の送信元から PROJECT_1
の VM にアクセスする場合にも、このポリシーを使用できます。次のコマンドを実行して、ポリシーを適用します。
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
namespace: PROJECT_1
name: allow-ingress-traffic-from-PROJECT_2
spec:
policyType: Ingress
subject:
subjectType: UserWorkload
ingress:
- from:
- projects:
matchNames:
- PROJECT_2
EOF
上記のコマンドでは、PROJECT_2
から PROJECT_1
へのアクセスは許可されますが、PROJECT_1
から PROJECT_2
への接続は許可されません。後者の場合は、PROJECT_2
プロジェクトに相互ポリシーが必要です。次のコマンドを実行して、相互ポリシーを適用します。
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
namespace: PROJECT_2
name: allow-ingress-traffic-from-PROJECT_1
spec:
policyType: Ingress
subject:
subjectType: UserWorkload
ingress:
- from:
- projects:
matchNames:
- PROJECT_1
EOF
これで、PROJECT_1
と PROJECT_2
との間で開始された接続が許可されました。
変数には次の定義を使用します。
変数 | 定義 |
---|---|
MANAGEMENT_API_SERVER | Management API サーバーの kubeconfig パス。 |
PROJECT_1 | 例の PROJECT_1 に対応する GDC プロジェクトの名前。 |
PROJECT_2 | 例の PROJECT_2 に対応する GDC プロジェクトの名前。 |
下り(外向き)のクロス プロジェクト トラフィック ネットワーク ポリシー
1 つのプロジェクト PROJECT_1
のワークロードに上り(内向き)のクロス プロジェクト トラフィック ポリシーを付与して、別のプロジェクト PROJECT_2
のワークロードからの接続を許可すると、同じフローの戻りトラフィックも付与されます。したがって、下り(外向き)のプロジェクト間トラフィック ネットワーク ポリシーは必要ありません。
組織間のトラフィック
VM ワークロードを、別の組織に存在するプロジェクト外の宛先に接続するには、明示的な承認が必要です。この承認は、GDC がデフォルトで有効にするデータ引き出し防止機能によるものです。この機能により、プロジェクトが属する組織外のワークロードへの下り(外向き)がプロジェクトで禁止されます。このセクションでは、特定の下り(外向き)ポリシーを追加してデータ漏洩を有効にする手順について説明します。
上り(内向き)の組織間トラフィック ネットワーク ポリシー
異なる組織間で上り(内向き)トラフィックを許可するには、組織の外部クライアントからプロジェクトへのトラフィックを許可する ProjectNetworkPolicy
を適用する必要があります(SSH を使用して VM に接続するなど)。
返信トラフィックには対応する下り(外向き)ポリシーは必要ありません。戻りトラフィックは暗黙的に許可されます。
VM が存在する組織外のソースから PROJECT_1
の VM にアクセスする場合は、次のポリシーを適用する必要があります。送信元 IP アドレスを含む CIDR
を取得して使用する必要があります。CIDR
は network/len
表記にする必要があります。たとえば、192.0.2.0/21
は有効です。
kubectl
の例に沿って、IngressProjectNetworkPolicy
を構成して適用します。PROJECT_1
のすべてのユーザー ワークロードにポリシーを適用します。これにより、組織外にあるCIDR
内のすべてのホストへの上り(内向き)トラフィックが許可されます。ProjectNetworkPolicy
構成を適用します。kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF apiVersion: networking.gdc.goog/v1 kind: ProjectNetworkPolicy metadata: namespace: PROJECT_1 name: allow-external-traffic spec: policyType: Ingress subject: subjectType: UserWorkload ingress: - from: - ipBlock: cidr: CIDR EOF
組織間の下り(外向き)トラフィック ネットワーク ポリシー
組織外のサービスへのデータ転送を有効にするには、プロジェクト ネットワーク ポリシー ProjectNetworkPolicy
をカスタマイズします。データ漏洩防止はデフォルトで有効になっているため、カスタマイズされた下り(外向き)ProjectNetworkPolicy
のステータス フィールドに検証エラーが表示され、データプレーンはそれを無視します。このプロセスは仕様どおりに動作します。
セキュリティと接続で説明したように、特定のプロジェクトでデータ漏洩を許可すると、ワークロードからデータが転送される可能性があります。外向きのデータ転送を許可するトラフィックは、プロジェクトに割り当てられた既知の IP アドレスを使用する送信元ネットワーク アドレス変換(NAT)です。セキュリティと接続には、プロジェクト ネットワーク ポリシー(ProjectNetworkPolicy
)の適用に関する詳細も記載されています。
返信トラフィックには対応する上り(内向き)ポリシーは必要ありません。戻りトラフィックは暗黙的に許可されます。
カスタマイズした上り(内向き)ポリシーを有効にします。
kubectl
の例に沿って、独自のカスタマイズされた上り(内向き)ProjectNetworkPolicy
を構成して適用します。PROJECT_1
のすべてのユーザー ワークロードにポリシーを適用します。これにより、組織外にあるCIDR
内のすべてのホストへの下り(外向き)トラフィックが許可されます。最初の試行では、必要なステータス エラーが発生します。これは想定どおりです。ProjectNetworkPolicy
構成を適用します。kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF apiVersion: networking.gdc.goog/v1 kind: ProjectNetworkPolicy metadata: namespace: PROJECT_1 name: allow-egress-traffic-to-NAME spec: policyType: Egress subject: subjectType: UserWorkload egress: - to: - ipBlock: cidr: CIDR EOF
完了したら、ステータスに検証エラーが表示されていることを確認します。
管理者ユーザーにデータ流出防止を無効にするよう依頼します。これにより、構成が有効になり、他のすべての下り(外向き)が防止されます。
作成した
ProjectNetworkPolicy
を確認し、検証ステータス フィールドのエラーが消え、ステータスReady
がTrue
になっていることを確認します。これは、ポリシーが有効であることを示しています。kubectl --kubeconfig MANAGEMENT_API_SERVER get projectnetworkpolicy allow-egress-traffic-to-NAME -n PROJECT_1 -o yaml
次の定義を使用して、変数を置き換えます。
変数 定義 MANAGEMENT_API_SERVER
Management API サーバーの kubeconfig パス。 PROJECT_1
GDC プロジェクトの名前。 CIDR
許可された宛先のクラスレス ドメイン間ルーティング(CIDR)ブロック。 NAME
リンク先に関連付けられた名前。 このポリシーを適用し、他の下り(外向き)ポリシーを定義していない場合、
PROJECT_1
の他のすべての下り(外向き)トラフィックは拒否されます。