From 8dc5b5ed9c9629244c177f068aeb87e59dab72f2 Mon Sep 17 00:00:00 2001 From: Soichiro KAWAMURA Date: Tue, 10 Nov 2020 00:32:25 +0900 Subject: [PATCH 1/3] add ja translation of concepts/security/pod-security-standards.md --- .../security/pod-security-standards.md | 297 ++++++++++++++++++ 1 file changed, 297 insertions(+) create mode 100644 content/ja/docs/concepts/security/pod-security-standards.md diff --git a/content/ja/docs/concepts/security/pod-security-standards.md b/content/ja/docs/concepts/security/pod-security-standards.md new file mode 100644 index 0000000000..67b088cf37 --- /dev/null +++ b/content/ja/docs/concepts/security/pod-security-standards.md @@ -0,0 +1,297 @@ +--- +title: Podセキュリティの標準 +content_type: concept +weight: 10 +--- + + + +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定義のセキュリティに関する設定を制御します。 + +しかし、PodSecurityPolicyを拡張したり代替する、ポリシーを強制するための多くの方法が生まれてきました。 +このページの意図は、推奨されるPodのセキュリティプロファイルを特定の実装から切り離して詳しく説明することです。 + + + + + +## ポリシーの種別 + +まず、幅広いセキュリティの範囲をカバーできる、基礎となるポリシーの定義が必要です。 +それらは強く制限をかけるものから自由度の高いものまでをカバーすべきです。 + +- **_特権_** - 制限のかかっていないポリシーで、可能な限り幅広い許可を与えます。このポリシーは既知の特権昇格を認めます。 +- **_ベースライン、デフォルト_** - 制限は最小限にされたポリシーですが、既知の特権昇格を防止します。デフォルト（最小の指定）のPod設定を許容します。 +- **_制限_** - 厳しく制限されたポリシーで、Podを強化するための現在のベストプラクティスに沿っています。 + +## ポリシー + +### 特権 + +特権ポリシーは意図的に開放されていて、完全に制限がかけられていません。この種のポリシーは、特権ユーザーまたは信頼されたユーザーが管理する、システムまたはインフラレベルのワークロードに対して適用されることを意図しています。 + +特権ポリシーは制限がないことと定義されます。gatekeeperのようにデフォルトで許可される仕組みでは、特権プロファイルはポリシーを設定せず、何も制限を適用しないことにあたります。 +一方で、Pod Security Policyのようにデフォルトで拒否される仕組みでは、特権ポリシーでは全ての制限を無効化してコントロールできるようにする必要があります。 + +### ベースライン、デフォルト + +ベースライン、デフォルトのプロファイルは一般的なコンテナ化されたランタイムに適用しやすく、かつ既知の特権昇格を防ぐことを意図しています。 +このポリシーはクリティカルではないアプリケーションの運用者または開発者を対象にしています。 +次の項目は強制、または無効化すべきです。 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ベースラインポリシーの定義
項目ポリシー
ホストのネームスペース + ホストのネームスペースの共有は無効化すべきです。
+
制限されるフィールド:
+ spec.hostNetwork
+ spec.hostPID
+ spec.hostIPC
+
認められる値: false
+
特権コンテナ + 特権を持つPodはほとんどのセキュリティ機構を無効化できるので、禁止すべきです。
+
制限されるフィールド:
+ spec.containers[*].securityContext.privileged
+ spec.initContainers[*].securityContext.privileged
+
認められる値: false, undefined/nil
+
ケーパビリティー + デフォルトよりも多くのケーパビリティーを与えることは禁止すべきです。
+
制限されるフィールド:
+ spec.containers[*].securityContext.capabilities.add
+ spec.initContainers[*].securityContext.capabilities.add
+
認められる値: 空 (または既知のリストに限定)
+
HostPathボリューム + HostPathボリュームは禁止すべきです。
+
制限されるフィールド:
+ spec.volumes[*].hostPath
+
認められる値: undefined/nil
+
ホストのポート + HostPortは禁止するか、最小限の既知のリストに限定すべきです。
+
制限されるフィールド:
+ spec.containers[*].ports[*].hostPort
+ spec.initContainers[*].ports[*].hostPort
+
認められる値: 0, undefined (または既知のリストに限定)
+
AppArmor (任意) + サポートされるホストでは、AppArmorの'runtime/default'プロファイルがデフォルトで適用されます。デフォルトのポリシーはポリシーの上書きや無効化を防ぎ、許可されたポリシーのセットを上書きできないよう制限すべきです。
+
制限されるフィールド:
+ metadata.annotations['container.apparmor.security.beta.kubernetes.io/*']
+
認められる値: 'runtime/default', undefined
+
SELinux (任意) + SELinuxのオプションをカスタムで設定することは禁止すべきです。
+
制限されるフィールド:
+ spec.securityContext.seLinuxOptions
+ spec.containers[*].securityContext.seLinuxOptions
+ spec.initContainers[*].securityContext.seLinuxOptions
+
認められる値: undefined/nil
+
/procマウントタイプ + 攻撃対象を縮小するため/procのマスクを設定し、必須とすべきです。
+
制限されるフィールド:
+ spec.containers[*].securityContext.procMount
+ spec.initContainers[*].securityContext.procMount
+
認められる値: undefined/nil, 'Default'
+
Sysctl + Sysctlはセキュリティ機構を無効化したり、ホストの全てのコンテナに影響を与えたりすることが可能なので、「安全」なサブネットを除いては禁止すべきです。 + コンテナまたはPodの中にsysctlがありネームスペースが分離されていて、同じノードの別のPodやプロセスから分離されている場合はsysctlは安全だと考えられます。
+
制限されるフィールド:
+ spec.securityContext.sysctls
+
認められる値:
+ kernel.shm_rmid_forced
+ net.ipv4.ip_local_port_range
+ net.ipv4.tcp_syncookies
+ net.ipv4.ping_group_range
+ undefined/empty
+
+ +### 制限 + +制限ポリシーはいくらかの互換性を犠牲にして、Podを強化するためのベストプラクティスを強制することを意図しています。 +セキュリティ上クリティカルなアプリケーションの運用者または開発者、また信頼度の低いユーザーを対象にしています。 +下記の項目を強制、無効化すべきです。 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
制限ポリシーの定義
項目ポリシー
デフォルトプロファイルにある項目全て
Volumeタイプ + HostPathボリュームの制限に加え、制限プロファイルではコアでない種類のボリュームの利用をPersistentVolumeにより定義されたものに限定します。
+
制限されるフィールド:
+ spec.volumes[*].hostPath
+ spec.volumes[*].gcePersistentDisk
+ spec.volumes[*].awsElasticBlockStore
+ spec.volumes[*].gitRepo
+ spec.volumes[*].nfs
+ spec.volumes[*].iscsi
+ spec.volumes[*].glusterfs
+ spec.volumes[*].rbd
+ spec.volumes[*].flexVolume
+ spec.volumes[*].cinder
+ spec.volumes[*].cephFS
+ spec.volumes[*].flocker
+ spec.volumes[*].fc
+ spec.volumes[*].azureFile
+ spec.volumes[*].vsphereVolume
+ spec.volumes[*].quobyte
+ spec.volumes[*].azureDisk
+ spec.volumes[*].portworxVolume
+ spec.volumes[*].scaleIO
+ spec.volumes[*].storageos
+ spec.volumes[*].csi
+
認められる値: undefined/nil
+
特権昇格 + 特権昇格(ファイルモードのset-user-IDまたはset-group-IDのような方法による)は禁止すべきです。
+
制限されるフィールド:
+ spec.containers[*].securityContext.allowPrivilegeEscalation
+ spec.initContainers[*].securityContext.allowPrivilegeEscalation
+
認められる値: false
+
root以外での実行 + コンテナはroot以外のユーザーで実行することを必須とすべきです。
+
制限されるフィールド:
+ spec.securityContext.runAsNonRoot
+ spec.containers[*].securityContext.runAsNonRoot
+ spec.initContainers[*].securityContext.runAsNonRoot
+
認められる値: true
+
root以外のグループ (任意) + コンテナのプライマリまたは補助のGIDをrootにすることを禁止すべきです。
+
制限されるフィールド:
+ spec.securityContext.runAsGroup
+ spec.securityContext.supplementalGroups[*]
+ spec.securityContext.fsGroup
+ spec.containers[*].securityContext.runAsGroup
+ spec.initContainers[*].securityContext.runAsGroup
+
認められる値:
+ 0以外
+ undefined / nil (`*.runAsGroup`を除く)
+
Seccomp + SeccompのRuntimeDefaultを必須とする、または特定の追加プロファイルを許可することが必要です。
+
制限されるフィールド:
+ spec.securityContext.seccompProfile.type
+ spec.containers[*].securityContext.seccompProfile
+ spec.initContainers[*].securityContext.seccompProfile
+
認められる値:
+ 'runtime/default'
+ undefined / nil
+
+ +## ポリシーの実例 + +ポリシーの定義とポリシーの実装を切り離すことによって、ポリシーを強制する機構とは独立して、汎用的な理解や複数のクラスターにわたる共通言語とすることができます。 + +機構が成熟してきたら、ポリシーごとに下記に定義されます。それぞれのポリシーを強制する方法についてはここでは定義しません。 + +[**PodSecurityPolicy**](/docs/concepts/policy/pod-security-policy/) + +- [特権](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/policy/privileged-psp.yaml) +- [ベースライン](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/policy/baseline-psp.yaml) +- [制限](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/policy/restricted-psp.yaml) + +## FAQ + +### 特権とデフォルトの間のプロファイルがないのはどうしてですか? + +ここで定義されている3つのプロファイルは最も安全(制限)から最も安全ではない(特権)まで、直線的に段階が設定されており、幅広いワークロードをカバーしています。 +ベースラインを超える特権が必要な場合、その多くはアプリケーションに特化しているため、その限られた要求に対して標準的なプロファイルを提供することはできません。 +これは、このような場合に必ず特権プロファイルを使用すべきだという意味ではなく、場合に応じてポリシーを定義する必要があります。 + +将来、他のプロファイルの必要性が明らかになった場合、SIG Authはこの方針について再考する可能性があります。 + +### セキュリティポリシーとセキュリティコンテキストの違いは何ですか? + +[Security Context](/docs/tasks/configure-pod-container/security-context/)は実行時のコンテナやPodを設定するものです。 +Security contextはPodのマニフェストの中でPodやコンテナの仕様の一部として定義され、コンテナランタイムへ渡されるパラメータを示します。 + +セキュリティポリシーはコントロールプレーンの機構で、Security Contextとそれ以外も含め、特定の設定を強制するものです。 +2020年2月時点では、ネイティブにサポートされているポリシー強制の機構は[Pod Security +Policy](/docs/concepts/policy/pod-security-policy/)です。これはクラスター全体にわたってセキュリティポリシーを中央集権的に強制するものです。 +セキュリティポリシーを強制する他の手段もKubernetesのエコシステムでは開発が進められています。例えば[OPA +Gatekeeper](https://github.com/open-policy-agent/gatekeeper)があります。 + +### WindowsのPodにはどのプロファイルを適用すればよいですか? + +Kubernetesでは、Linuxベースのワークロードと比べてWindowsの使用は制限や差異があります。 +特に、PodのSecurityContextフィールドは[Windows環境では効果がありません](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-podsecuritycontext)。 +したがって、現段階では標準化されたセキュリティポリシーは存在しません。 + +### サンドボックス化されたPodはどのように扱えばよいでしょうか? + +現在のところ、Podがサンドボックス化されているかどうかによって制御できるAPIの標準はありません。 +サンドボックス化されたPodはサンドボックス化されたランタイム（例えばgVisorやKata Containers）を使用していることで特定することは可能ではありますが、サンドボックス化されたランタイムの標準的な定義は存在しません。 + +サンドボックス化されたランタイムに対して必要な保護は、それ以外に対するものとは異なります。 +例えば、ワークロードがその基になるカーネルと分離されている場合、特権を制限する必要性は小さくなります。 +これは、強い権限を必要とするワークロードが隔離された状態にある状態を実現します。 + +加えて、サンドボックス化されたワークロードの保護はサンドボックス化の実装に強く依存します。 +したがって、全てのサンドボックス化されたワークロードに推奨される単一のポリシーは存在しません。 From 7bd6c3f53e69161410d89cca4cccb04ca3d67a4e Mon Sep 17 00:00:00 2001 From: translucens Date: Thu, 12 Nov 2020 00:16:25 +0900 Subject: [PATCH 2/3] Update content/ja/docs/concepts/security/pod-security-standards.md Co-authored-by: Tim Bannister --- content/ja/docs/concepts/security/pod-security-standards.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/security/pod-security-standards.md b/content/ja/docs/concepts/security/pod-security-standards.md index 67b088cf37..63ca43ae28 100644 --- a/content/ja/docs/concepts/security/pod-security-standards.md +++ b/content/ja/docs/concepts/security/pod-security-standards.md @@ -141,7 +141,7 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義 net.ipv4.ip_local_port_range
net.ipv4.tcp_syncookies
net.ipv4.ping_group_range
- undefined/empty
+ undefined/空文字列
From d53952b961953bab09249bb945d85ecf6f25ee11 Mon Sep 17 00:00:00 2001 From: translucens Date: Sun, 15 Nov 2020 12:52:43 +0900 Subject: [PATCH 3/3] Apply suggestions from code review Co-authored-by: bells17 Co-authored-by: Keita Akutsu --- .../security/pod-security-standards.md | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/content/ja/docs/concepts/security/pod-security-standards.md b/content/ja/docs/concepts/security/pod-security-standards.md index 63ca43ae28..7b0f16dff1 100644 --- a/content/ja/docs/concepts/security/pod-security-standards.md +++ b/content/ja/docs/concepts/security/pod-security-standards.md @@ -6,7 +6,7 @@ weight: 10 -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,7 +23,7 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義 まず、幅広いセキュリティの範囲をカバーできる、基礎となるポリシーの定義が必要です。 それらは強く制限をかけるものから自由度の高いものまでをカバーすべきです。 -- **_特権_** - 制限のかかっていないポリシーで、可能な限り幅広い許可を与えます。このポリシーは既知の特権昇格を認めます。 +- **_特権_** - 制限のかかっていないポリシーで、可能な限り幅広い権限を提供します。このポリシーは既知の特権昇格を認めます。 - **_ベースライン、デフォルト_** - 制限は最小限にされたポリシーですが、既知の特権昇格を防止します。デフォルト（最小の指定）のPod設定を許容します。 - **_制限_** - 厳しく制限されたポリシーで、Podを強化するための現在のベストプラクティスに沿っています。 @@ -31,7 +31,7 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義 ### 特権 -特権ポリシーは意図的に開放されていて、完全に制限がかけられていません。この種のポリシーは、特権ユーザーまたは信頼されたユーザーが管理する、システムまたはインフラレベルのワークロードに対して適用されることを意図しています。 +特権ポリシーは意図的に開放されていて、完全に制限がかけられていません。この種のポリシーは通常、特権ユーザーまたは信頼されたユーザーが管理する、システムまたはインフラレベルのワークロードに対して適用されることを意図しています。 特権ポリシーは制限がないことと定義されます。gatekeeperのようにデフォルトで許可される仕組みでは、特権プロファイルはポリシーを設定せず、何も制限を適用しないことにあたります。 一方で、Pod Security Policyのようにデフォルトで拒否される仕組みでは、特権ポリシーでは全ての制限を無効化してコントロールできるようにする必要があります。 @@ -150,7 +150,7 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義 ### 制限 制限ポリシーはいくらかの互換性を犠牲にして、Podを強化するためのベストプラクティスを強制することを意図しています。 -セキュリティ上クリティカルなアプリケーションの運用者または開発者、また信頼度の低いユーザーを対象にしています。 +セキュリティ上クリティカルなアプリケーションの運用者や開発者、また信頼度の低いユーザーも対象にしています。 下記の項目を強制、無効化すべきです。 @@ -206,7 +206,7 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義 root以外での実行 - コンテナはroot以外のユーザーで実行することを必須とすべきです。
+ コンテナはroot以外のユーザーで実行する必要があります。

制限されるフィールド:
spec.securityContext.runAsNonRoot
spec.containers[*].securityContext.runAsNonRoot
@@ -217,7 +217,7 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義 root以外のグループ (任意) - コンテナのプライマリまたは補助のGIDをrootにすることを禁止すべきです。
+ コンテナをrootのプライマリまたは補助GIDで実行することを禁止すべきです。

制限されるフィールド:
spec.securityContext.runAsGroup
spec.securityContext.supplementalGroups[*]
@@ -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）の使用により特定することは可能ですが、サンドボックス化されたランタイムの標準的な定義は存在しません。 サンドボックス化されたランタイムに対して必要な保護は、それ以外に対するものとは異なります。 例えば、ワークロードがその基になるカーネルと分離されている場合、特権を制限する必要性は小さくなります。 -これは、強い権限を必要とするワークロードが隔離された状態にある状態を実現します。 +これにより、強い権限を必要とするワークロードが隔離された状態を維持できます。 加えて、サンドボックス化されたワークロードの保護はサンドボックス化の実装に強く依存します。 したがって、全てのサンドボックス化されたワークロードに推奨される単一のポリシーは存在しません。