ネットワークセキュリティー
OpenShift Dedicated におけるネットワークトラフィックの保護とネットワークポリシーの適用
概要
第1章 ネットワークポリシー API について リンクのコピーリンクがクリップボードにコピーされました!
ネットワークポリシーは、クラスタースコープと namespace スコープの両方のネットワークポリシー API を使用して定義されます。これらのさまざまなレベルにわたってネットワークポリシーを定義することで、完全なマルチテナント分離を含む、クラスターの高度なネットワークセキュリティー設定を作成できます。
1.1. ネットワークポリシーとその範囲 リンクのコピーリンクがクリップボードにコピーされました!
- クラスタースコープのネットワークポリシー
クラスターおよびネットワーク管理者は、AdminNetworkPolicy を使用してクラスターレベルでネットワークポリシーを定義できます。AdminNetworkPolicy 機能は、
AdminNetworkPolicyAPI とBaselineAdminNetworkPolicyAPI の 2 つの API で構成されます。これらの API は、クラスター全体に適用できるルール、または namespace スコープのNetworkPolicyに委譲できるルールを設定するために使用されます。AdminNetworkPolicyAPI を使用して定義されたポリシーは、「許可」または「拒否」に設定されている場合、他のすべてのポリシータイプよりも優先されます。ただし、管理者は "Pass" を使用して、特定のポリシーの責任を namespace スコープのNetworkPolicyに委譲し、アプリケーション開発者と namespace テナントが、プロジェクトのネットワークセキュリティーの特定の側面を制御できるようにすることもできます。BaselineAdminNetworkPolicyAPI を使用して定義されたポリシーは、他のネットワークポリシーによってオーバーライドされない場合にのみ適用されます。AdminNetworkPolicyAPI を使用して、ネットワークポリシーの側面を namespace スコープのNetworkPolicyに委譲する場合は、BaselineAdminNetworkPolicyで適切な最小限の制限も定義する必要があります。これにより、namespace のNetworkPolicyが十分な保護を提供しない場合に、クラスターレベルでネットワークセキュリティーのベースラインレベルが確保されます。- namespace スコープのネットワークポリシー
-
アプリケーション開発者と namespace テナントは、
NetworkPolicyAPI を使用して、特定の namespace のネットワークポリシールールを定義できます。namespace のNetworkPolicy内のルールは、BaselineAdminNetworkPolicy API を使用して設定されたクラスター全体のルール、またはクラスター全体のAdminNetworkPolicyAPI から委譲または「渡された」クラスター全体のルールよりも優先されます。
1.2. ネットワークポリシーの評価と適用方法 リンクのコピーリンクがクリップボードにコピーされました!
ネットワーク接続が確立されると、ネットワークプロバイダー (デフォルト: OVN-Kubernetes) は、接続の詳細をネットワークポリシールールと照合して、接続の処理方法を決定します。
OVN-Kubernetes は、次の順序でネットワークポリシーオブジェクトに対する接続を評価します。
AdminNetworkPolicy 層で一致を確認します。
-
接続が
AllowまたはDenyルールに一致する場合、そのルールに従って評価を停止します。 -
接続が
Passルールに一致する場合は、NetworkPolicy 層に移動します。
-
接続が
NetworkPolicy 層で一致を確認します。
- 接続がルールに一致する場合、そのルールに従って評価を停止します。
- 一致するものが見つからない場合は、BaselineAdminNetworkPolicy 層に移動します。
- BaselineAdminNetworkPolicy 層の一致するルールに従います。
図1.1 OVN-Kubernetes によるネットワークポリシーの評価
1.3. AdminNetworkPolicy と NetworkPolicy カスタムリソースの主な違い リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Dedicated のクラスターまたはネームスペースに適したネットワークポリシー API を選択するには、AdminNetworkPolicy と NetworkPolicy CR を、スコープ、ルールアクション、優先順位、ピアオプションの観点から比較できます。
以下の参照表は、ポリシーを適用できるユーザー、トラフィックの許可または拒否方法、および OVN-Kubernetes が各 API を評価する方法の違いをまとめたものです。
| ポリシーの要素 | AdminNetworkPolicy | NetworkPolicy |
|---|---|---|
| 対象ユーザー | クラスター管理者または同等の権限 | namespace の所有者 |
| スコープ | Cluster | namespace |
| トラフィックのドロップ |
明示的な |
ポリシー作成時に暗黙的に |
| トラフィックの委譲 |
| 該当なし。 |
| トラフィックの許可 |
明示的に | すべてのルールに対するデフォルトのアクションは allow です。 |
| ポリシー内のルールの優先順位 | ANP 内で表示される順序によって異なります。ルールの位置が高いほど、優先順位が高くなります。 | ルールは加算的です。 |
| ポリシーの優先順位 |
ANP 間では、 | ポリシー間にポリシー順序はありません。 |
| 機能の優先順位 | 最初に Tier 1 ACL を介して評価され、最後に BANP が Tier 3 ACL を介して評価されます。 | ANP の後、BANP の前に適用され、ACL の Tier 2 で評価されます。 |
| Pod 選択の一致 | namespace 間で異なるルールを適用できます。 | 1 つの namespace 内の Pod に異なるルールを適用できます。 |
| クラスターの Egress トラフィック |
|
受け入れられた CIDR 構文とともに |
| クラスター Ingress トラフィック | サポート対象外。 | サポート対象外。 |
| 完全修飾ドメイン名 (FQDN) ピアサポート | サポート対象外。 | サポート対象外。 |
| namespace セレクター |
|
|
第2章 ネットワークポリシー リンクのコピーリンクがクリップボードにコピーされました!
2.1. ネットワークポリシーの作成 リンクのコピーリンクがクリップボードにコピーされました!
ワークロード間のトラフィックを制限し、アプリケーションのセキュリティーを向上させるには、クラスターの NetworkPolicy オブジェクトを設定します。ネットワークポリシーは、選択された Pod に対して許可される Ingress および送信接続を定義し、名前空間内のアプリケーションを分離するのに役立ちます。
開発者は、クラスター内の Pod へのトラフィックを制限するネットワークポリシーを定義できます。
2.1.1. ネットワークポリシーについて リンクのコピーリンクがクリップボードにコピーされました!
ワークロード間のトラフィックを制御し、ネットワークの分離性を向上させるには、プロジェクトの NetworkPolicy オブジェクトを設定してください。ネットワークポリシーは、選択した Pod に対して許可される Ingress および送信接続を定義し、クラスター内のアプリケーションのセキュリティーを確保するのに役立ちます。
デフォルトで、プロジェクトのすべての Pod は他の Pod およびネットワークのエンドポイントからアクセスできます。プロジェクトで 1 つ以上の Pod を分離するには、そのプロジェクトで NetworkPolicy オブジェクトを作成し、許可する着信接続を指定します。プロジェクト管理者は独自のプロジェクト内で NetworkPolicy オブジェクトの作成および削除を実行できます。
OpenShift Dedicated 4.22 以降、OpenShift Dedicated はデフォルトで一部のネームスペースに NetworkPolicy オブジェクトを含めるようになりました。この組み込みにより、全体的なセキュリティーが向上し、コントロールプレーンのコンポーネントがより適切に保護されます。OpenShift Dedicated がデフォルトで独自のネームスペースに含めている NetworkPolicy オブジェクトは変更しないでください。オブジェクトがデフォルトで含まれる名前空間を確認するには、次のコマンドを実行します。
$ oc get networkpolicies --all-namespaces
OpenShift Dedicated 4.22 リリースでは、これらのオブジェクトはすべての OpenShift Dedicated 名前空間に含まれていません。今後の OpenShift Dedicated リリースでは、これらのオブジェクトが追加の名前空間に含まれる可能性があります。
デフォルトでは、プロジェクト内のすべての Pod は、どのネットワークエンドポイントからもアクセス可能です。
Pod が 1 つ以上の NetworkPolicy オブジェクトのセレクターと一致する場合、Pod はそれらの NetworkPolicy オブジェクトの少なくとも 1 つにより許可された接続だけを使用できます。いずれの NetworkPolicy オブジェクトにも選択されていない Pod は、完全にアクセス可能な状態を維持します。
2.1.1.1. 政策の加法性 リンクのコピーリンクがクリップボードにコピーされました!
NetworkPolicy オブジェクトは加算されるものです。つまり、複数の NetworkPolicy オブジェクトを組み合わせて複雑なネットワーク要件を満すことができます。
たとえば、同じプロジェクト内で allow-same-namespace ポリシーと allow-http-and-https ポリシーの両方を定義した場合、role=frontend ラベルを持つ Pod は、どちらかのポリシーで許可されている接続をすべて受け入れます。
これは、Pod が以下を受け入れることを意味します。
- 同じ名前空間内の Pod からの任意のポートへの接続。
-
任意のネームスペース内の Pod からのポート
80および443への接続。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-from-router
spec:
ingress:
- from:
- namespaceSelector:
matchLabels:
policy-group.network.openshift.io/ingress: ""
podSelector: {}
policyTypes:
- Ingress
policy-group.network.openshift.io/Ingress:"" ラベルは、OVN-Kubernetes をサポートします。
クラスターの攻撃対象領域を縮小し、予測可能なネットワーク動作を確保するために、OpenShift Dedicated は重要なネットワークコンポーネントに対して最小限の特権ネットワークポリシーを適用します。
クラスター DNS とクラスター Ingress を管理するオペレーターは、それぞれの名前空間にデフォルトのすべて拒否 NetworkPolicy オブジェクトを自動的にインストールおよび維持します。
トラフィックは、以下の名前空間における対象を絞った許可ポリシーを使用して制御されます。
DNS コンポーネントの名前空間 (
openshift-dnsおよびopenshift-dns-operator):- 送信は API サーバーと必要な DNS ポートに限定されます。
- イングレスは、必要不可欠な DNS トラフィックとメトリクスに限定されます。
Ingress コンポーネントの名前空間 (
openshift-Ingressおよびopenshift-ingress-operator):- 送信は API サーバー、DNS ポート、およびルーティングエンドポイントに限定されます。
- Ingress は HTTP/HTTPS トラフィックとメトリクスに限定されます。
これらの名前空間では、管理対象外の Pod やカスタム Pod を実行しないでください。これらの名前空間はデフォルトで拒否するモデルで動作するため、これらの名前空間で実行されている管理対象外のコンテナーのネットワークトラフィックはすべてブロックされます。
2.1.2. OVN-Kubernetes ネットワークプラグインによるネットワークポリシーの最適化 リンクのコピーリンクがクリップボードにコピーされました!
OVN-Kubernetes のネットワークポリシーを最適化してフロー数を削減し、必要な場合に外部 IP トラフィックを許可する方法を学びましょう。
ネットワークポリシーを設計する場合は、以下のガイドラインを参照してください。
-
同じ
spec.podSelector仕様を持つネットワークポリシーの場合、ingressルールまたはegressルールを持つ複数のネットワークポリシーを使用するよりも、複数のIngressルールまたはegressルールを持つ 1 つのネットワークポリシーを使用する方が効率的です。 podSelectorまたはnamespaceSelector仕様に基づくすべてのIngressまたはegressルールは、number of pods selected by network policy + number of pods selected by ingress or egress ruleに比例する数の OVS フローを生成します。そのため、Pod ごとに個別のルールを作成するのではなく、1 つのルールで必要な数の Pod を選択できるpodSelectorまたはnamespaceSelector仕様を使用することが推奨されます。たとえば、以下のポリシーには 2 つのルールが含まれています。
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-network-policy spec: podSelector: {} ingress: - from: - podSelector: matchLabels: role: frontend - from: - podSelector: matchLabels: role: backend以下のポリシーは、上記と同じ 2 つのルールを 1 つのルールとして表現しています。
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-network-policy spec: podSelector: {} ingress: - from: - podSelector: matchExpressions: - {key: role, operator: In, values: [frontend, backend]}同じガイドラインが
spec.podSelector仕様に適用されます。異なるネットワークポリシーに同じingressルールまたはegressルールがある場合、共通のspec.podSelector仕様で 1 つのネットワークポリシーを作成する方が効率的な場合があります。たとえば、以下の 2 つのポリシーには異なるルールがあります。apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: policy1 spec: podSelector: matchLabels: role: db ingress: - from: - podSelector: matchLabels: role: frontend --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: policy2 spec: podSelector: matchLabels: role: client ingress: - from: - podSelector: matchLabels: role: frontend以下のネットワークポリシーは、上記と同じ 2 つのルールを 1 つのルールとして表現しています。
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: policy3 spec: podSelector: matchExpressions: - {key: role, operator: In, values: [db, client]} ingress: - from: - podSelector: matchLabels: role: frontendこの最適化は、複数のセレクターを 1 つのセレクターとして表現する場合に限り適用できます。セレクターが異なるラベルに基づいている場合、この最適化は適用できない可能性があります。その場合は、ネットワークポリシーの最適化に特化して新規ラベルをいくつか適用することを検討してください。
2.1.2.1. OVN-Kubernetes の NetworkPolicy CR と外部 IP リンクのコピーリンクがクリップボードにコピーされました!
OVN-Kubernetes では、NetworkPolicy カスタムリソース (CR) によって厳密な分離ルールが適用されます。サービスが外部 IP を使用して公開されている場合、トラフィックを許可するように明示的に設定されていない限り、ネットワークポリシーによって他の namespace からのアクセスがブロックされる可能性があります。
namespace をまたいで外部 IP へのアクセスを許可するには、必要な namespace からの Ingress を明示的に許可し、指定されたサービスポートへのトラフィックが許可されるようにする NetworkPolicy CR を作成します。必要なポートへのトラフィックを許可しなければ、アクセスが制限される可能性があります。
出力例
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
annotations:
name: <policy_name>
namespace: openshift-ingress
spec:
ingress:
- ports:
- port: 80
protocol: TCP
- ports:
- port: 443
protocol: TCP
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: <my_namespace>
podSelector: {}
policyTypes:
- Ingress
ここでは、以下のようになります。
<policy_name>- ポリシーの名前を指定します。
<my_namespace>- ポリシーがデプロイされる namespace の名前を指定します。
詳細は、「ネットワークポリシーについて」を参照してください。
2.2. ネットワークポリシーの作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、namespace のネットワークポリシーを作成できます。
2.2.1. サンプル NetworkPolicy オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
このオブジェクトの設定方法については、サンプルとなる NetworkPolicy オブジェクトを参照してください。
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: allow-27107
spec:
podSelector:
matchLabels:
app: mongodb
ingress:
- from:
- podSelector:
matchLabels:
app: app
ports:
- protocol: TCP
port: 27017
ここでは、以下のようになります。
name- NetworkPolicy オブジェクトの名前。
spec.podSelector- ポリシーが適用される Pod を説明するセレクター。ポリシーオブジェクトは NetworkPolicy オブジェクトが定義されるプロジェクトの Pod のみを選択できます。
ingress.from.podSelector- ポリシーオブジェクトが入力トラフィックを許可する Pod に一致するセレクター。セレクターは、NetworkPolicy と同じ namespace にある Pod を照合して検索します。
ingress.ports- トラフィックを受け入れる 1 つ以上の宛先ポートのリスト。
2.2.2. CLI を使用したネットワークポリシーの作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスターの namespace に許可される Ingress または Egress ネットワークトラフィックを記述する詳細なルールを定義するには、ネットワークポリシーを作成できます。
cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の namespace でネットワークポリシーを作成できます。
前提条件
-
クラスターが、
mode: NetworkPolicyが設定されたNetworkPolicyオブジェクトをサポートするネットワークプラグイン (OVN-Kubernetes ネットワークプラグインなど) を使用している。 -
OpenShift CLI (
oc) がインストールされている。 -
あなたは
管理者権限を持つユーザー特権でクラスターにログインしました。 - ネットワークポリシーが適用される namespace で作業している。
手順
ポリシールールを作成します。
<policy_name>.yamlファイルを作成します。$ touch <policy_name>.yamlここでは、以下のようになります。
<policy_name>- ネットワークポリシーファイル名を指定します。
作成したファイルにネットワークポリシーを定義します。次の例では、全 namespace 内の全 Pod からの Ingress トラフィックを拒否します。これは基本的なポリシーであり、他のネットワークポリシーの設定によって許可されたクロス Pod トラフィック以外のすべてのクロス Pod ネットワーキングをブロックします。
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 spec: podSelector: {} policyTypes: - Ingress ingress: []次の設定例では、同じ namespace 内の全 Pod からの Ingress トラフィックを許可します。
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-same-namespace spec: podSelector: ingress: - from: - podSelector: {} # ...次の例では、特定の namespace から 1 つの Pod への Ingress トラフィックを許可します。このポリシーは
、名前空間 yで実行されている Pod から、pod-aラベルを持つ Pod へのトラフィックを許可します。kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-traffic-pod spec: podSelector: matchLabels: pod: pod-a policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: namespace-y # ...次の設定例では、サービスへのトラフィックを制限します。このポリシーを適用すると、
app=bookstoreとrole=apiの両方のラベルを持つすべての Pod に、app=bookstoreというラベルを持つ Pod のみがアクセスできるようになります。この例では、アプリケーションは、ラベルapp=bookstoreおよびrole=apiでマークされた REST API サーバーである可能性があります。この設定例は、次のユースケースに対応しています。
- サービスへのトラフィックを、それを使用する必要がある他のマイクロサービスのみに制限します。
データベースへの接続を制限して、それを使用するアプリケーションのみを許可します。
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: api-allow spec: podSelector: matchLabels: app: bookstore role: api ingress: - from: - podSelector: matchLabels: app: bookstore # ...
ネットワークポリシーオブジェクトを作成するには、以下のコマンドを入力します。正常に処理された場合、ポリシーオブジェクトの名前と
作成ステータスが表示されます。$ oc apply -f <policy_name>.yaml -n <namespace>ここでは、以下のようになります。
<policy_name>- ネットワークポリシーファイル名を指定します。
<namespace>- オプションのパラメーター。現在の namespace とは異なる namespace でオブジェクトを定義した場合、パラメーターは namespace を指定します。
正常に処理された場合、ポリシーオブジェクトの名前と
作成ステータスが表示されます。注記cluster-admin権限で Web コンソールにログインする場合、YAML で、または Web コンソールのフォームから、クラスターの任意の namespace でネットワークポリシーを直接作成できます。
2.2.3. デフォルトの全拒否ネットワークポリシーの作成 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトの全拒否ネットワークポリシーは、デプロイされた他のネットワークポリシーの設定によって許可されるネットワークトラフィックと、ホストネットワークを使用する Pod 間のトラフィック以外のすべての Pod 間ネットワークをブロックします。
この手順では、my-project 名前空間に デフォルトで拒否する ポリシーを適用することにより、強力な拒否ポリシーを強制します。
トラフィック通信を許可する NetworkPolicy カスタムリソース (CR) を設定しない場合、以下のポリシーはクラスター全体で通信問題を引き起こす可能性があります。
前提条件
-
クラスターが、
mode: NetworkPolicyが設定されたNetworkPolicyオブジェクトをサポートするネットワークプラグイン (OVN-Kubernetes ネットワークプラグインなど) を使用している。 -
OpenShift CLI (
oc) がインストールされている。 -
あなたは
管理者権限を持つユーザー特権でクラスターにログインしました。 - ネットワークポリシーが適用される namespace で作業している。
手順
すべての namespace におけるすべての Pod からの Ingress を拒否する
deny-by-defaultポリシーを定義する次の YAML を作成します。YAML をdeny-by-default.yamlファイルに保存します。kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: deny-by-default namespace: my-project spec: podSelector: {} ingress: []ここでは、以下のようになります。
namespace-
ポリシーをデプロイする namespace を指定します。たとえば、
my-project という名前空間。 podSelector-
このフィールドが空の場合、設定はすべての Pod と一致します。したがって、このポリシーは
my-project名前空間内のすべての Pod に適用されます。 ingress-
[]は、イングレスルールが指定されていないことを示します。これにより、着信トラフィックがすべての Pod にドロップされます。
次のコマンドを入力して、ポリシーを適用します。正常に処理された場合、ポリシーオブジェクトの名前と
作成ステータスが表示されます。$ oc apply -f deny-by-default.yaml
2.2.4. 外部クライアントからのトラフィックを許可するネットワークポリシーの作成 リンクのコピーリンクがクリップボードにコピーされました!
deny-by-default ポリシーを設定すると、外部クライアントからラベル app=web を持つ Pod へのトラフィックを許可するポリシーの設定に進むことができます。
cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の namespace でネットワークポリシーを作成できます。
この手順に従って、パブリックインターネットから直接、またはロードバランサーを使用して Pod にアクセスすることにより、外部サービスを許可するポリシーを設定します。トラフィックは、ラベル app=web を持つ Pod にのみ許可されます。
前提条件
-
クラスターが、
mode: NetworkPolicyが設定されたNetworkPolicyオブジェクトをサポートするネットワークプラグイン (OVN-Kubernetes ネットワークプラグインなど) を使用している。 -
OpenShift CLI (
oc) がインストールされている。 -
あなたは
管理者権限を持つユーザー特権でクラスターにログインしました。 - ネットワークポリシーが適用される namespace で作業している。
手順
パブリックインターネットからのトラフィックが直接、またはロードバランサーを使用して Pod にアクセスできるようにするポリシーを作成します。YAML を
web-allow-external.yamlファイルに保存します。kind: NetworkPolicy apiVersion: networking.k8s.io/v1 spec: policyTypes: - Ingress podSelector: matchLabels: app: web ingress: - {}次のコマンドを入力して、ポリシーを適用します。正常に処理された場合、ポリシーオブジェクトの名前と
作成ステータスが表示されます。$ oc apply -f web-allow-external.yamlこのポリシーは、次の図に示すように、外部トラフィックを含むすべてのリソースからのトラフィックを許可します。
2.2.5. すべての namespace からアプリケーションへのトラフィックを許可するネットワークポリシーを作成する リンクのコピーリンクがクリップボードにコピーされました!
全 namespace 内の全 Pod から特定のアプリケーションへのトラフィックを許可するポリシーを設定できます。
cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の namespace でネットワークポリシーを作成できます。
前提条件
-
クラスターが、
mode: NetworkPolicyが設定されたNetworkPolicyオブジェクトをサポートするネットワークプラグイン (OVN-Kubernetes ネットワークプラグインなど) を使用している。 -
OpenShift CLI (
oc) がインストールされている。 -
あなたは
管理者権限を持つユーザー特権でクラスターにログインしました。 - ネットワークポリシーが適用される namespace で作業している。
手順
すべての namespace のすべての Pod から特定のアプリケーションへのトラフィックを許可するポリシーを作成します。YAML を
web-allow-all-namespaces.yamlファイルに保存します。apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: web-allow-all-namespaces namespace: default spec: podSelector: matchLabels: app: web policyTypes: - Ingress ingress: - from: - namespaceSelector: {}ここでは、以下のようになります。
app-
デフォルト名前空間の
app:webPod にのみポリシーを適用します。 namespaceSelectorすべての namespace のすべての Pod を選択します。
注記デフォルトでは、ポリシーオブジェクトで
namespaceSelectorパラメーターを指定しない場合、名前空間は選択されません。これは、そのネットワークポリシーがデプロイされている namespace からのみのトラフィックを許可することを意味します。
次のコマンドを入力して、ポリシーを適用します。正常に処理された場合、ポリシーオブジェクトの名前と
作成ステータスが表示されます。$ oc apply -f web-allow-all-namespaces.yaml
検証
次のコマンドを入力して、
defaultの名前空間で Web サービスを開始します。$ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80次のコマンドを実行して、
alpineイメージをsecondary名前空間にデプロイし、シェルを開始します。$ oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- shシェルで次のコマンドを実行し、サービスがリクエストを許可することを確認します。
# wget -qO- --timeout=2 http://web.default<!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> html { color-scheme: light dark; } body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html>
2.2.6. namespace からアプリケーションへのトラフィックを許可するネットワークポリシーの作成 リンクのコピーリンクがクリップボードにコピーされました!
特定の名前空間から、ラベルが アプリケーション=web の Pod へのトラフィックを許可するポリシーを設定できます。
この設定は、次のユースケースで役立ちます。
- 実稼働データベースへのトラフィックを、実稼働ワークロードがデプロイされている namespace のみに制限します。
- 特定の namespace にデプロイされた監視ツールを有効にして、現在の namespace からメトリクスをスクレイピングします。
cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の namespace でネットワークポリシーを作成できます。
前提条件
-
クラスターが、
mode: NetworkPolicyが設定されたNetworkPolicyオブジェクトをサポートするネットワークプラグイン (OVN-Kubernetes ネットワークプラグインなど) を使用している。 -
OpenShift CLI (
oc) がインストールされている。 -
あなたは
管理者権限を持つユーザー特権でクラスターにログインしました。 - ネットワークポリシーが適用される namespace で作業している。
network.openshift.io/policy-group: ingress ラベルをカスタム名前空間またはプロジェクトに適用しないでください。このラベルは Operator が管理し、OpenShift Dedicated のネットワーク機能専用に予約されています。システムによって作成された名前空間では、これを変更してはいけません。
このラベルを使用すると、断続的なネットワーク接続の切断、意図しないシステム NetworkPolicies リソースの適用、またはオペレーターが状態を調整しようとする際に設定のずれが発生する可能性があります。カスタムトラフィックグループを作成する場合は、必ず以下の手順に示すように、一意のユーザー定義ラベルを使用してください。
手順
ラベルが
Purpose=productionの特定の名前空間内のすべての Pod からのトラフィックを許可するポリシーを作成します。YAML をweb-allow-prod.yamlファイルに保存します。kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: web-allow-prod namespace: default spec: podSelector: matchLabels: app: web policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: purpose: productionここでは、以下のようになります。
app-
デフォルトの名前空間の
app:webPod にのみポリシーを適用します。 purpose-
ラベルが
purpose=productionの名前空間内の Pod のみにトラフィックを制限します。
次のコマンドを入力して、ポリシーを適用します。正常に処理された場合、ポリシーオブジェクトの名前と
作成ステータスが表示されます。$ oc apply -f web-allow-prod.yaml
検証
次のコマンドを入力して、
defaultの名前空間で Web サービスを開始します。$ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80次のコマンドを実行して、
prodnamespace を作成します。$ oc create namespace prod次のコマンドを実行して、
prod名前空間にラベルを付けます。$ oc label namespace/prod purpose=production次のコマンドを実行して、
dev名前空間を作成します。$ oc create namespace dev次のコマンドを実行して、
dev名前空間にラベルを付けます。$ oc label namespace/dev purpose=testing次のコマンドを実行して、
alpineイメージをdev名前空間にデプロイし、シェルを開始します。$ oc run test-$RANDOM --namespace=dev --rm -i -t --image=alpine -- shシェルで次のコマンドを実行し、ブロックされた要求の理由を確認します。たとえば、期待される出力は
wget: download timed out です。# wget -qO- --timeout=2 http://web.default次のコマンドを実行して、
alpineイメージをprodnamespace にデプロイし、シェルを開始します。$ oc run test-$RANDOM --namespace=prod --rm -i -t --image=alpine -- shシェルで次のコマンドを実行し、リクエストが許可されていることを確認します。
# wget -qO- --timeout=2 http://web.default<!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> html { color-scheme: light dark; } body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html>
2.2.7. OpenShift Cluster Manager を使用したネットワークポリシーの作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスターの namespace に許可される Ingress または egress ネットワークトラフィックを記述する詳細なルールを定義するには、ネットワークポリシーを作成できます。
前提条件
- OpenShift Cluster Manager にログインしている。
- OpenShift Dedicated クラスターを作成している。
- クラスターにアイデンティティープロバイダーを設定している。
- 設定したアイデンティティープロバイダーにユーザーアカウントを追加している。
- OpenShift Dedicated クラスター内にプロジェクトを作成しました。
手順
- OpenShift Cluster Manager から、アクセスするクラスターをクリックします。
- コンソールを開く をクリックして、OpenShift Web コンソールに移動します。
- ご利用のアイデンティティープロバイダーをクリックし、認証情報を入力してクラスターにログインしてください。
- 管理者の観点から、Networking の下の NetworkPolicies をクリックします。
- NetworkPolicy の作成 をクリックします。
- ポリシー名 欄にポリシーの名前を入力してください。
- オプション: このポリシーが 1 つまたは複数の特定の Pod にのみ適用される場合は、特定の Pod のラベルとセレクターを指定できます。特定の Pod を選択しない場合、このポリシーはクラスター上のすべての Pod に適用されます。
- オプション: Deny all ingress traffic または Deny all egress traffic チェックボックスを使用して、すべてのイングレストラフィックとエグレストラフィックをブロックできます。
- イングレスルールとエグレスルールの任意の組み合わせを追加して、承認するポート、名前空間、または IP ブロックを指定することもできます。
Ingress ルールをポリシーに追加します。
Add ingress rule を選択して新規ルールを設定します。この操作により、受信トラフィックを制限する方法を指定するための 許可された送信元を追加 ドロップダウンメニューを含む新しい イングレスルール 行が作成されます。ドロップダウンメニューでは、Ingress トラフィックを制限する 3 つのオプションを利用できます。
- Allow pods from the same namespace では、空間内の Pod へのトラフィックが制限されます。namespace に Pod を指定できますが、このオプションは空のままにすると namespace の Pod からのすべてのトラフィックを許可します。
- Allow pods from inside the cluster では、ポリシーと同じクラスター内の Pod へのトラフィックが制限されます。インバウンドトラフィックを許可する名前空間と Pod を指定できます。このオプションを空白のままにすると、このクラスター内のすべての名前空間と Pod からのインバウンドトラフィックが許可されます。
- IP ブロックによるピアの許可 は、指定された Classless Inter-Domain Routing (CIDR) IP ブロックからのトラフィックを制限します。例外オプションを使用して、特定の IP をブロックできます。CIDR フィールドを空白のままにすると、すべての外部ソースからのすべてのインバウンドトラフィックが許可されます。
- すべての受信トラフィックをポートに制限できます。ポートを追加しない場合、トラフィックはすべてのポートにアクセスできます。
ネットワークポリシーにエグレスルールを追加します。
Add egress rule を選択し、新しいルールを設定します。この操作により、送信トラフィックを制限する方法を指定するための 許可された宛先を追加 ドロップダウンメニューを持つ新しい 送信ルール 行が作成されます。ドロップダウンメニューには、下りトラフィックを制限する 3 つのオプションがあります。
- Allow pods from the same namespace では、同じ namespace 内の Pod へのトラフィックが制限されます。namespace に Pod を指定できますが、このオプションは空のままにすると namespace の Pod からのすべてのトラフィックを許可します。
- Allow pods from inside the cluster では、ポリシーと同じクラスター内の Pod へのトラフィックが制限されます。アウトバウンドトラフィックを許可する namespace および Pod を指定できます。このオプションを空白のままにすると、このクラスター内のすべての名前空間と Pod からのアウトバウンドトラフィックが許可されます。
- Allow peers by IP block すると、指定された CIDR IP ブロックからのトラフィックが制限されます。例外オプションを使用して、特定の IP をブロックできます。CIDR フィールドを空白のままにすると、すべての外部ソースからのすべてのアウトバウンドが許可されます。
- すべてのアウトバウンドトラフィックをポートに制限できます。ポートを追加しない場合、トラフィックはすべてのポートにアクセスできます。
2.3. ネットワークポリシーの表示 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、namespace のネットワークポリシーを表示できます。
2.3.1. サンプル NetworkPolicy オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
このオブジェクトの設定方法については、サンプルとなる NetworkPolicy オブジェクトを参照してください。
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: allow-27107
spec:
podSelector:
matchLabels:
app: mongodb
ingress:
- from:
- podSelector:
matchLabels:
app: app
ports:
- protocol: TCP
port: 27017
ここでは、以下のようになります。
name- NetworkPolicy オブジェクトの名前。
spec.podSelector- ポリシーが適用される Pod を説明するセレクター。ポリシーオブジェクトは NetworkPolicy オブジェクトが定義されるプロジェクトの Pod のみを選択できます。
ingress.from.podSelector- ポリシーオブジェクトが入力トラフィックを許可する Pod に一致するセレクター。セレクターは、NetworkPolicy と同じ namespace にある Pod を照合して検索します。
ingress.ports- トラフィックを受け入れる 1 つ以上の宛先ポートのリスト。
2.3.2. CLI を使用したネットワークポリシーの表示 リンクのコピーリンクがクリップボードにコピーされました!
namespace のネットワークポリシーを検査できます。
cluster-admin 特権でログインすると、クラスター内の任意のネームスペースのネットワークポリシーを編集できます。
cluster-admin 特権でログインすると、クラスター内の任意のネームスペースのネットワークポリシーを編集できます。Web コンソールでは、YAML 形式で直接ポリシーを編集するか、アクション メニューを使用して編集できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
admin権限を持つユーザーとしてクラスターにログインしている。 - ネットワークポリシーが存在する namespace で作業している。
手順
namespace 内のネットワークポリシーをリスト表示します。
次のコマンドを入力し、namespace 内に定義されているネットワークポリシーオブジェクトを表示します。
$ oc get networkpolicyオプション: 特定のネットワークポリシーを調べるには、次のコマンドを入力します。
$ oc describe networkpolicy <policy_name> -n <namespace>ここでは、以下のようになります。
<policy_name>- 検査するネットワークポリシーの名前を指定します。
<namespace>オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
$ oc describe networkpolicy allow-same-namespaceName: allow-same-namespace Namespace: ns1 Created on: 2021-05-24 22:28:56 -0400 EDT Labels: <none> Annotations: <none> Spec: PodSelector: <none> (Allowing the specific traffic to all pods in this namespace) Allowing ingress traffic: To Port: <any> (traffic allowed to all ports) From: PodSelector: <none> Not affecting egress traffic Policy Types: Ingress
2.3.3. OpenShift Cluster Manager を使用したネットワークポリシーの表示 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Cluster Manager でネットワークポリシーの設定の詳細を表示できます。
前提条件
- OpenShift Cluster Manager にログインしている。
- OpenShift Dedicated クラスターを作成している。
- クラスターにアイデンティティープロバイダーを設定している。
- 設定したアイデンティティープロバイダーにユーザーアカウントを追加している。
- ネットワークポリシーを作成しました。
手順
-
OpenShift Cluster Manager Web コンソールの 管理者 視点から、[ネットワーク] の下にある
[ネットワークポリシー]をクリックします。 - 表示するネットワークポリシーを選択してください。
- ネットワークポリシー の詳細ページで、関連付けられたすべての Ingress および egress ルールを表示できます。
ネットワークポリシーの詳細で YAML を選択して、ポリシー設定を YAML 形式で表示します。
注記これらのポリシーの詳細のみを表示できます。これらのポリシーは編集できません。
2.4. ネットワークポリシーの削除 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、namespace からネットワークポリシーを削除できます。
2.4.1. CLI を使用したネットワークポリシーの削除 リンクのコピーリンクがクリップボードにコピーされました!
namespace のネットワークポリシーを削除できます。
cluster-admin 特権でログインすると、クラスター内の任意の名前空間にあるネットワークポリシーを削除できます。
cluster-admin 特権でログインすると、クラスター内の任意の名前空間にあるネットワークポリシーを削除できます。Web コンソールでは、YAML 形式で直接ポリシーを削除するか、アクション メニューを使用してポリシーを削除できます。
前提条件
-
クラスターが、
mode: NetworkPolicyが設定されたNetworkPolicyオブジェクトをサポートするネットワークプラグイン (OVN-Kubernetes ネットワークプラグインなど) を使用している。 -
OpenShift CLI (
oc) がインストールされている。 -
あなたは
管理者権限を持つユーザー特権でクラスターにログインしました。 - ネットワークポリシーが存在する namespace で作業している。
手順
ネットワークポリシーオブジェクトを削除するには、以下のコマンドを入力します。正常に処理された場合、ポリシーオブジェクトの名前と
削除ステータスが表示されます。$ oc delete networkpolicy <policy_name> -n <namespace>ここでは、以下のようになります。
<policy_name>- ネットワークポリシーの名前を指定します。
<namespace>- オプションのパラメーター。現在の namespace とは異なる namespace でオブジェクトを定義した場合、パラメーターは namespace を指定します。
2.4.2. OpenShift Cluster Manager を使用したネットワークポリシーの削除 リンクのコピーリンクがクリップボードにコピーされました!
namespace のネットワークポリシーを削除できます。
前提条件
- OpenShift Cluster Manager にログインしている。
- OpenShift Dedicated クラスターを作成している。
- クラスターにアイデンティティープロバイダーを設定している。
- 設定したアイデンティティープロバイダーにユーザーアカウントを追加している。
手順
- OpenShift Cluster Manager Web コンソールの Administrator パースペクティブから、Networking の下にある NetworkPolicies をクリックします。
ネットワークポリシーを削除するには、次のいずれかの方法を使用します。
ネットワークポリシー テーブルからポリシーを削除します。
- ネットワークポリシー テーブルから、削除するネットワークポリシーの行にあるスタックメニューを選択し、NetworkPolicy の削除 をクリックします。
個々のネットワークポリシーの詳細から アクション ドロップダウンメニューを使用してポリシーを削除します。
- ネットワークポリシーの アクション ドロップダウンメニューをクリックしてください。
- メニューから Delete NetworkPolicy を選択します。
2.5. ネットワークポリシーを使用したマルチテナント分離の設定 リンクのコピーリンクがクリップボードにコピーされました!
マルチテナントクラスター内のプロジェクト間でネットワークトラフィックを分離するために、ネットワークポリシーを設定できます。この分離により、異なる名前空間にあるワークロード間の不正な通信を防ぐことができます。
クラスター管理者は、マルチテナントネットワークの分離を実行するようにネットワークポリシーを設定できます。
このセクションで説明するようにネットワークポリシーを設定すると、以前のバージョンの OpenShift Dedicated における OpenShift SDN のマルチテナントモードと同様のネットワーク分離が実現します。
2.5.1. ネットワークポリシーを使用したマルチテナント分離の設定 リンクのコピーリンクがクリップボードにコピーされました!
ネットワークポリシーを設定することで、プロジェクト内のワークロードを、他の名前空間の Pod やサービスから分離できます。この分離により、プロジェクト間のネットワークトラフィックを制御し、クラスター内のマルチテナントセキュリティーを向上させることができます。
前提条件
-
クラスターが、
mode: NetworkPolicyが設定されたNetworkPolicyオブジェクトをサポートするネットワークプラグイン (OVN-Kubernetes ネットワークプラグインなど) を使用している。 -
OpenShift CLI (
oc) がインストールされている。 -
admin権限を持つユーザーとしてクラスターにログインしている。
手順
以下の
NetworkPolicyオブジェクトを作成します。allow-from-openshift-ingressという名前のポリシー:$ cat << EOF| oc create -f - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-ingress spec: ingress: - from: - namespaceSelector: matchLabels: policy-group.network.openshift.io/ingress: "" podSelector: {} policyTypes: - Ingress EOF注記policy-group.network.openshift.io/ingress: ""は、OVN-Kubernetes の推奨される namespace セレクターラベルです。allow-from-openshift-monitoringという名前のポリシー。$ cat << EOF| oc create -f - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-monitoring spec: ingress: - from: - namespaceSelector: matchLabels: network.openshift.io/policy-group: monitoring podSelector: {} policyTypes: - Ingress EOFallow-same-namespaceという名前のポリシー:$ cat << EOF| oc create -f - kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-same-namespace spec: podSelector: ingress: - from: - podSelector: {} EOFallow-from-kube-apiserver-operatorという名前のポリシー:$ cat << EOF| oc create -f - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-kube-apiserver-operator spec: ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: openshift-kube-apiserver-operator podSelector: matchLabels: app: kube-apiserver-operator policyTypes: - Ingress EOF詳細は、新規の New
kube-apiserver-operatorwebhook controller validating health of webhook を参照してください。
オプション: 以下のコマンドを実行し、ネットワークポリシーオブジェクトが現在のプロジェクトに存在することを確認します。
$ oc describe networkpolicy出力例
Name: allow-from-openshift-ingress Namespace: example1 Created on: 2020-06-09 00:28:17 -0400 EDT Labels: <none> Annotations: <none> Spec: PodSelector: <none> (Allowing the specific traffic to all pods in this namespace) Allowing ingress traffic: To Port: <any> (traffic allowed to all ports) From: NamespaceSelector: policy-group.network.openshift.io/ingress: Not affecting egress traffic Policy Types: Ingress Name: allow-from-openshift-monitoring Namespace: example1 Created on: 2020-06-09 00:29:57 -0400 EDT Labels: <none> Annotations: <none> Spec: PodSelector: <none> (Allowing the specific traffic to all pods in this namespace) Allowing ingress traffic: To Port: <any> (traffic allowed to all ports) From: NamespaceSelector: network.openshift.io/policy-group: monitoring Not affecting egress traffic Policy Types: Ingress
第3章 OpenShift Dedicated クラスターのネットワーク検証 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Dedicated クラスターを既存の Virtual Private Cloud (VPC) にデプロイするとき、またはクラスターに新しいサブネットを持つ追加のマシンプールを作成するときに、ネットワーク検証チェックが自動的に実行します。このチェックによりネットワーク設定が検証され、エラーが強調表示されるため、クラスターのデプロイメント前に設定の問題を解決できます。ネットワーク検証チェックを手動で実行して、既存のクラスターの設定を検証することもできます。
3.1. OpenShift Dedicated クラスターのネットワーク検証について リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Dedicated クラスターを既存の Virtual Private Cloud (VPC) にデプロイするか、クラスターに新しいサブネットを持つ追加のマシンプールを作成すると、ネットワーク検証が自動的に実行します。これは、クラスターをデプロイメントする前に設定の問題を特定して解決する上で役立ちます。
Red Hat OpenShift Cluster Manager を使用してクラスターをインストールする準備をする場合は、Virtual Private Cloud (VPC) subnet settings ページのサブネット ID フィールドにサブネットを入力した後に自動チェックが実行します。
クラスターに新規のサブネットを持つマシンプールを追加すると、自動ネットワーク検証機能がサブネットをチェックし、マシンプールをプロビジョニングする前にネットワーク接続が利用可能であることを確認します。
自動ネットワーク検証が完了すると、システムはサービスログに記録を送信します。レコードには、ネットワーク設定エラーを含む検証チェックの結果が示されます。特定された問題をデプロイメント前に解決すると、デプロイメントが成功する可能性が高くなります。
既存のクラスターに対してネットワーク検証を手動で実行し、設定変更後にネットワーク設定を確認することもできます。ネットワーク検証チェックを手動で実行する手順は、ネットワーク検証を手動で実行する を参照してください。
3.2. ネットワーク検証チェックの範囲 リンクのコピーリンクがクリップボードにコピーされました!
ネットワーク検証には、次の各要件のチェックが含まれます。
- 親の Virtual Private Cloud (VPC) がある。
- 指定されたすべてのサブネットは VPC に属している。
-
VPC で
enableDnsSupportが有効になっている。 -
VPC で
enableDnsHostnamesが有効になっている。 - 必要なドメインとポートの組み合わせに対して、データ送信が可能です。
3.3. 自動ネットワーク検証のバイパス リンクのコピーリンクがクリップボードにコピーされました!
既知のネットワーク設定の問題がある OpenShift Dedicated クラスターを既存の Virtual Private Cloud (VPC) にデプロイする場合は、自動ネットワーク検証を回避できます。
クラスターの作成時にネットワーク検証を回避すると、クラスターのサポートステータスは制限されます。インストール後、問題を解決してからネットワーク検証を手動で実行できます。検証が成功すると、限定サポート状況が解除されます。
Red Hat OpenShift Cluster Manager を使用して既存の VPC にクラスターをインストールする時に、Virtual Private Cloud (VPC) subnet settings ページで Bypass network verification を選択することで自動検証を回避できます。
3.4. ネットワーク検証を手動で実行する リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Cluster Manager を使用して、既存の OpenShift Dedicated クラスターのネットワーク検証チェックを手動で実行できます。
前提条件
- 既存の OpenShift Dedicated クラスターがある。
- クラスター所有者になっているか、クラスター編集者のロールがある。
手順
- OpenShift Cluster Manager に移動し、クラスターを選択します。
- Actions ドロップダウンメニューから Verify networking を選択します。