Update: ja/docs/concepts/services-networking/network-policies.md

content/ja/docs/concepts/services-networking/network-policies.md

@@ -6,9 +6,17 @@ weight: 50
 
 <!-- overview -->
 
-ネットワークポリシーは、{{< glossary_tooltip text="Pod" term_id="pod">}}のグループが、Pod相互や他のネットワークエンドポイントと通信する場合に許可を与える方法を指定するための仕様です。
+IPアドレスまたはポートのレベル(OSI参照モデルのレイヤ3または4)でトラフィックフローを制御したい場合、クラスター内の特定のアプリケーションにKubernetesのネットワークポリシーを使用することを検討してください。ネットワークポリシーはアプリケーション中心の構造であり、{{<glossary_tooltip text="Pod" term_id="pod">}}がネットワークを介して多様な「エンティティ」(「エンドポイント」や「Service」のようなKubernetesに含まれる特定の意味を持つ共通の用語との重複を避けるため、ここではエンティティという単語を使用します。)と通信する方法を指定できます。
 
-NetworkPolicyリソースは、{{< glossary_tooltip text="ラベル" term_id="label">}}を使用してPodを選択し、選択したPodに対してどんなトラフィックを許可するかを指定するルールを定義します。
+Podが通信できるエンティティは以下の3つの識別子の組み合わせによって識別されます。
+
+1. 許可されている他のPod (例外: Podはそれ自体へのアクセスをブロックできません)
+2. 許可されている名前空間
+3. IPブロック (例外: PodまたはノードのIPアドレスに関係なく、Podが実行されているノードとの間のトラフィックは常に許可されます。)
+
+Podベースもしくは名前空間ベースのネットワークポリシーを定義する場合、{{<glossary_tooltip text="セレクター" term_id="selector">}}を使用してセレクターに一致するPodとの間で許可されるトラフィックを指定します。
+
+一方でIPベースのネットワークポリシーが作成されると、IPブロック(CIDRの範囲)に基づいてポリシーが定義されます。
 
 <!-- body -->
 ## 前提条件
@@ -186,14 +194,33 @@ __ipBlock__: 特定のIPのCIDRの範囲を選択して、ingressの送信元ま
 
 ## SCTPのサポート
 
-{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}
 
-この機能を利用するには、クラスター管理者がAPIサーバーで`--feature-gates=SCTPSupport=true,…`と指定して、`SCTPSupport`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にする必要があります。フィーチャーゲートが有効になれば、NetworkPolicyの`protocol`フィールドに`SCTP`が指定できるようになります。
+ベータ版の機能として、これはデフォルトで有効化されます。
+クラスターレベルでSCTPを無効化するために、クラスター管理者はAPIサーバーで`--feature-gates=SCTPSupport=false,…`と指定して、`SCTPSupport`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を無効にする必要があります。
 
 {{< note >}}
 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" >}}で指定することができます。これは多くの場合で実行可能な回避策です。)
+- サードパーティによって実行される「ポリシー要求」の作成または管理
+- 全ての名前空間もしくはPodに適用されるデフォルトのポリシー (これを実現できるサードパーティのKubernetesディストリビューションとプロジェクトがいくつか存在します。)
+- 高度なポリシークエリと到達可能性ツール
+- 単一のポリシー宣言でポートの範囲を指定する機能
+- ネットワークセキュリティイベント(例えばブロックされた接続や受け入れられた接続)をログに記録する機能
+- ポリシーを明示的に拒否する機能 (現在、ネットワークポリシーのモデルはデフォルトで拒否されており、許可ルールを追加する機能のみが存在します。)
+- ループバックまたは内向きのホストトラフィックを拒否する機能 (Podは現在localhostのアクセスやそれらが配置されているノードからのアクセスをブロックすることはできません。)
+
 ## {{% heading "whatsnext" %}}
 
 - [ネットワークポリシーを宣言する](/ja/docs/tasks/administer-cluster/declare-network-policy/)で追加の例の説明を読む。