Apply suggestions from code review

Co-authored-by: bells17 <[email protected]>
Co-authored-by: Keita Akutsu <[email protected]>

Author: 3 people

content/ja/docs/concepts/security/pod-security-standards.md

@@ -6,7 +6,7 @@ weight: 10
 
 <!-- overview -->
 
-Podに対するセキュリティの設定は一般に[Security Context](/docs/tasks/configure-pod-container/security-context/)を適用することによります。Security ContextはPod単位での特権の定義やアクセスコントロールを実現します。
+Podに対するセキュリティの設定は通常[Security Context](/docs/tasks/configure-pod-container/security-context/)を使用して適用されます。Security ContextはPod単位での特権やアクセスコントロールの定義を実現します。
 
 クラスターにおけるSecurity Contextの強制やポリシーベースの定義は[Pod Security Policy](/docs/concepts/policy/pod-security-policy/)によって実現されてきました。
 _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義のセキュリティに関する設定を制御します。
@@ -23,15 +23,15 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
 まず、幅広いセキュリティの範囲をカバーできる、基礎となるポリシーの定義が必要です。
 それらは強く制限をかけるものから自由度の高いものまでをカバーすべきです。
 
-- **_特権_** - 制限のかかっていないポリシーで、可能な限り幅広い許可を与えます。このポリシーは既知の特権昇格を認めます。
+- **_特権_** - 制限のかかっていないポリシーで、可能な限り幅広い権限を提供します。このポリシーは既知の特権昇格を認めます。
 - **_ベースライン、デフォルト_** - 制限は最小限にされたポリシーですが、既知の特権昇格を防止します。デフォルト（最小の指定）のPod設定を許容します。
 - **_制限_** - 厳しく制限されたポリシーで、Podを強化するための現在のベストプラクティスに沿っています。
 
 ## ポリシー
 
 ### 特権
 
-特権ポリシーは意図的に開放されていて、完全に制限がかけられていません。この種のポリシーは、特権ユーザーまたは信頼されたユーザーが管理する、システムまたはインフラレベルのワークロードに対して適用されることを意図しています。
+特権ポリシーは意図的に開放されていて、完全に制限がかけられていません。この種のポリシーは通常、特権ユーザーまたは信頼されたユーザーが管理する、システムまたはインフラレベルのワークロードに対して適用されることを意図しています。
 
 特権ポリシーは制限がないことと定義されます。gatekeeperのようにデフォルトで許可される仕組みでは、特権プロファイルはポリシーを設定せず、何も制限を適用しないことにあたります。
 一方で、Pod Security Policyのようにデフォルトで拒否される仕組みでは、特権ポリシーでは全ての制限を無効化してコントロールできるようにする必要があります。
@@ -150,7 +150,7 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
 ### 制限
 
 制限ポリシーはいくらかの互換性を犠牲にして、Podを強化するためのベストプラクティスを強制することを意図しています。
-セキュリティ上クリティカルなアプリケーションの運用者または開発者、また信頼度の低いユーザーを対象にしています。
+セキュリティ上クリティカルなアプリケーションの運用者や開発者、また信頼度の低いユーザーも対象にしています。
 下記の項目を強制、無効化すべきです。
 
 
@@ -206,7 +206,7 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
 		<tr>
 			<td>root以外での実行</td>
 			<td>
-				コンテナはroot以外のユーザーで実行することを必須とすべきです。<br>
+				コンテナはroot以外のユーザーで実行する必要があります。<br>
 				<br><b>制限されるフィールド:</b><br>
 				spec.securityContext.runAsNonRoot<br>
 				spec.containers[*].securityContext.runAsNonRoot<br>
@@ -217,7 +217,7 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
 		<tr>
 			<td>root以外のグループ <em>(任意)</em></td>
 			<td>
-				コンテナのプライマリまたは補助のGIDをrootにすることを禁止すべきです。<br>
+				コンテナをrootのプライマリまたは補助GIDで実行することを禁止すべきです。<br>
 				<br><b>制限されるフィールド:</b><br>
 				spec.securityContext.runAsGroup<br>
 				spec.securityContext.supplementalGroups[*]<br>
@@ -270,7 +270,7 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
 ### セキュリティポリシーとセキュリティコンテキストの違いは何ですか?
 
 [Security Context](/docs/tasks/configure-pod-container/security-context/)は実行時のコンテナやPodを設定するものです。
-Security contextはPodのマニフェストの中でPodやコンテナの仕様の一部として定義され、コンテナランタイムへ渡されるパラメータを示します。
+Security ContextはPodのマニフェストの中でPodやコンテナの仕様の一部として定義され、コンテナランタイムへ渡されるパラメータを示します。
 
 セキュリティポリシーはコントロールプレーンの機構で、Security Contextとそれ以外も含め、特定の設定を強制するものです。
 2020年2月時点では、ネイティブにサポートされているポリシー強制の機構は[Pod Security
@@ -286,12 +286,12 @@ Kubernetesでは、Linuxベースのワークロードと比べてWindowsの使
 
 ### サンドボックス化されたPodはどのように扱えばよいでしょうか?
 
-現在のところ、Podがサンドボックス化されているかどうかによって制御できるAPIの標準はありません。
-サンドボックス化されたPodはサンドボックス化されたランタイム（例えばgVisorやKata Containers）を使用していることで特定することは可能ではありますが、サンドボックス化されたランタイムの標準的な定義は存在しません。
+現在のところ、Podがサンドボックス化されていると見なされるかどうかを制御できるAPI標準はありません。
+サンドボックス化されたPodはサンドボックス化されたランタイム（例えばgVisorやKata Containers）の使用により特定することは可能ですが、サンドボックス化されたランタイムの標準的な定義は存在しません。
 
 サンドボックス化されたランタイムに対して必要な保護は、それ以外に対するものとは異なります。
 例えば、ワークロードがその基になるカーネルと分離されている場合、特権を制限する必要性は小さくなります。
-これは、強い権限を必要とするワークロードが隔離された状態にある状態を実現します。
+これにより、強い権限を必要とするワークロードが隔離された状態を維持できます。
 
 加えて、サンドボックス化されたワークロードの保護はサンドボックス化の実装に強く依存します。
 したがって、全てのサンドボックス化されたワークロードに推奨される単一のポリシーは存在しません。