From f302697380322186706c93cbbbb3978671d75b38 Mon Sep 17 00:00:00 2001 From: JIIOryo Date: Sat, 24 Apr 2021 12:52:54 +0900 Subject: [PATCH] Fix parentheses in ja/docs/concepts/services-networking/network-policies.md --- .../services-networking/network-policies.md | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/network-policies.md b/content/ja/docs/concepts/services-networking/network-policies.md index d9897bcabe..b11bcead2b 100644 --- a/content/ja/docs/concepts/services-networking/network-policies.md +++ b/content/ja/docs/concepts/services-networking/network-policies.md @@ -10,9 +10,9 @@ IPアドレスまたはポートのレベル(OSI参照モデルのレイヤ3ま Podが通信できるエンティティは以下の3つの識別子の組み合わせによって識別されます。 -1. 許可されている他のPod (例外: Podはそれ自体へのアクセスをブロックできません) +1. 許可されている他のPod(例外: Podはそれ自体へのアクセスをブロックできません) 2. 許可されている名前空間 -3. IPブロック (例外: PodまたはノードのIPアドレスに関係なく、Podが実行されているノードとの間のトラフィックは常に許可されます。) +3. IPブロック(例外: PodまたはノードのIPアドレスに関係なく、Podが実行されているノードとの間のトラフィックは常に許可されます。) Podベースもしくは名前空間ベースのネットワークポリシーを定義する場合、{{}}を使用してセレクターに一致するPodとの間で許可されるトラフィックを指定します。 @@ -203,23 +203,23 @@ __ipBlock__: 特定のIPのCIDRの範囲を選択して、ingressの送信元ま SCTPプロトコルのネットワークポリシーをサポートする{{< glossary_tooltip text="CNI" term_id="cni" >}}プラグインを使用している必要があります。 {{< /note >}} -## ネットワークポリシーでできないこと (少なくともまだ) +## ネットワークポリシーでできないこと(少なくともまだ) Kubernetes1.20現在、ネットワークポリシーAPIに以下の機能は存在しません。 しかし、オペレーティングシステムのコンポーネント(SELinux、OpenVSwitch、IPTablesなど)、レイヤ7の技術(Ingressコントローラー、サービスメッシュ実装)、もしくはアドミッションコントローラーを使用して回避策を実装できる場合があります。 Kubernetesのネットワークセキュリティを初めて使用する場合は、ネットワークポリシーAPIを使用して以下ののユーザーストーリーを(まだ)実装できないことに注意してください。これらのユーザーストーリーの一部(全てではありません)は、ネットワークポリシーAPIの将来のリリースで活発に議論されています。 -- クラスター内トラフィックを強制的に共通ゲートウェイを通過させる (これは、サービスメッシュもしくは他のプロキシで提供するのが最適な場合があります。) -- TLS関連のもの (これにはサービスメッシュまたはIngressコントローラを使用します。) -- ノードの固有のポリシー (これらにはCIDR表記を使用できますが、Kubernetesのアイデンティティでノードを指定することはできません。) -- 名前空間またはサービスを名前で指定する (ただし、Podまたは名前空間を{{< glossary_tooltip text="ラベル" term_id="label" >}}で指定することができます。これは多くの場合で実行可能な回避策です。) +- クラスター内トラフィックを強制的に共通ゲートウェイを通過させる(これは、サービスメッシュもしくは他のプロキシで提供するのが最適な場合があります)。 +- TLS関連のもの(これにはサービスメッシュまたはIngressコントローラを使用します)。 +- ノードの固有のポリシー(これらにはCIDR表記を使用できますが、Kubernetesのアイデンティティでノードを指定することはできません)。 +- 名前空間またはサービスを名前で指定する(ただし、Podまたは名前空間を{{< glossary_tooltip text="ラベル" term_id="label" >}}で指定することができます。これは多くの場合で実行可能な回避策です)。 - サードパーティによって実行される「ポリシー要求」の作成または管理 -- 全ての名前空間もしくはPodに適用されるデフォルトのポリシー (これを実現できるサードパーティのKubernetesディストリビューションとプロジェクトがいくつか存在します。) +- 全ての名前空間もしくはPodに適用されるデフォルトのポリシー(これを実現できるサードパーティのKubernetesディストリビューションとプロジェクトがいくつか存在します)。 - 高度なポリシークエリと到達可能性ツール - 単一のポリシー宣言でポートの範囲を指定する機能 - ネットワークセキュリティイベント(例えばブロックされた接続や受け入れられた接続)をログに記録する機能 -- ポリシーを明示的に拒否する機能 (現在、ネットワークポリシーのモデルはデフォルトで拒否されており、許可ルールを追加する機能のみが存在します。) -- ループバックまたは内向きのホストトラフィックを拒否する機能 (Podは現在localhostのアクセスやそれらが配置されているノードからのアクセスをブロックすることはできません。) +- ポリシーを明示的に拒否する機能(現在、ネットワークポリシーのモデルはデフォルトで拒否されており、許可ルールを追加する機能のみが存在します)。 +- ループバックまたは内向きのホストトラフィックを拒否する機能(Podは現在localhostのアクセスやそれらが配置されているノードからのアクセスをブロックすることはできません)。 ## {{% heading "whatsnext" %}}