merge master
This commit is contained in:
YAMADA Kazuaki
commit
5ac264c20b
|
|
@ -393,6 +393,19 @@ Used on: PersistentVolumeClaim
|
|||
|
||||
This annotation will be added to dynamic provisioning required PVC.
|
||||
|
||||
### volumes.kubernetes.io/controller-managed-attach-detach
|
||||
|
||||
Used on: Node
|
||||
|
||||
If a node has set the annotation `volumes.kubernetes.io/controller-managed-attach-detach`
|
||||
on itself, then its storage attach and detach operations are being managed
|
||||
by the _volume attach/detach_
|
||||
{{< glossary_tooltip text="controller" term_id="controller" >}} running within the
|
||||
{{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}.
|
||||
|
||||
The value of the annotation isn't important; if this annotation exists on a node,
|
||||
then storage attaches and detaches are controller managed.
|
||||
|
||||
### node.kubernetes.io/windows-build {#nodekubernetesiowindows-build}
|
||||
|
||||
Example: `node.kubernetes.io/windows-build: "10.0.17763"`
|
||||
|
|
|
|||
|
|
@ -2,8 +2,8 @@
|
|||
title: Kubernetesのコンポーネント
|
||||
content_type: concept
|
||||
description: >
|
||||
Kubernetesクラスターはコントロールプレーンやノードと呼ばれるマシン群といったコンポーネントからなります。
|
||||
weight: 20
|
||||
Kubernetesクラスターはコントロールプレーンのコンポーネントとノードと呼ばれるマシン群で構成されています。
|
||||
weight: 30
|
||||
card:
|
||||
name: concepts
|
||||
weight: 20
|
||||
|
|
@ -15,11 +15,7 @@ Kubernetesをデプロイすると、クラスターが展開されます。
|
|||
|
||||
このドキュメントでは、Kubernetesクラスターが機能するために必要となるさまざまなコンポーネントの概要を説明します。
|
||||
|
||||
すべてのコンポーネントが結び付けられたKubernetesクラスターの図を次に示します。
|
||||
|
||||
|
||||
|
||||
|
||||
{{< figure src="/images/docs/components-of-kubernetes.svg" alt="Kubernetesのコンポーネント" caption="Kubernetesクラスターを構成するコンポーネント" class="diagram-large" >}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
@ -28,7 +24,7 @@ Kubernetesをデプロイすると、クラスターが展開されます。
|
|||
コントロールプレーンコンポーネントは、クラスターに関する全体的な決定(スケジューリングなど)を行います。また、クラスターイベントの検出および応答を行います(たとえば、deploymentの`replicas`フィールドが満たされていない場合に、新しい {{< glossary_tooltip text="Pod" term_id="pod">}} を起動する等)。
|
||||
|
||||
コントロールプレーンコンポーネントはクラスター内のどのマシンでも実行できますが、シンプルにするため、セットアップスクリプトは通常、すべてのコントロールプレーンコンポーネントを同じマシンで起動し、そのマシンではユーザーコンテナを実行しません。
|
||||
マルチマスター VMセットアップの例については、[高可用性クラスターの構築](/docs/admin/high-availability/) を参照してください。
|
||||
複数のマシンにまたがって実行されるコントロールプレーンのセットアップ例については、[kubeadmを使用した高可用性クラスターの構築](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/) を参照してください。
|
||||
|
||||
### kube-apiserver
|
||||
|
||||
|
|
@ -49,24 +45,26 @@ Kubernetesをデプロイすると、クラスターが展開されます。
|
|||
コントローラーには以下が含まれます。
|
||||
|
||||
* ノードコントローラー：ノードがダウンした場合の通知と対応を担当します。
|
||||
* レプリケーションコントローラー：システム内の全レプリケーションコントローラーオブジェクトについて、Podの数を正しく保つ役割を持ちます。
|
||||
* エンドポイントコントローラー：エンドポイントオブジェクトを注入します(つまり、ServiceとPodを紐付けます)。
|
||||
* サービスアカウントとトークンコントローラー：新規の名前空間に対して、デフォルトアカウントとAPIアクセストークンを作成します。
|
||||
* Jobコントローラー：単発タスクを表すJobオブジェクトを監視し、そのタスクを実行して完了させるためのPodを作成します。
|
||||
* EndpointSliceコントローラー：EndpointSliceオブジェクトを作成します(つまり、ServiceとPodを紐付けます)。
|
||||
* ServiceAccountコントローラー：新規の名前空間に対して、デフォルトのServiceAccountを作成します。
|
||||
|
||||
### cloud-controller-manager
|
||||
|
||||
{{< glossary_definition term_id="cloud-controller-manager" length="short" >}}
|
||||
|
||||
cloud-controller-managerは、クラウドプロバイダー固有のコントローラーのみを実行します。
|
||||
KubernetesをオンプレミスあるいはPC内での学習環境で動かす際には、クラスターにcloud controller managerはありません。
|
||||
Kubernetesをオンプレミスあるいは個人のPC内での学習環境で動かす際には、クラスターにcloud controller managerはありません。
|
||||
|
||||
kube-controller-managerを使用すると、cloud-controller-managerは複数の論理的に独立したコントロールループをシングルバイナリにまとめ、これが一つのプロセスとして動作します。パフォーマンスを向上させるあるいは障害に耐えるために水平方向にスケールする(一つ以上のコピーを動かす)ことができます。
|
||||
|
||||
次のコントローラーには、クラウドプロバイダーへの依存関係を持つ可能性があります。
|
||||
kube-controller-managerと同様に、cloud-controller-managerは複数の論理的に独立したコントロールループをシングルバイナリにまとめ、一つのプロセスとして動作します。パフォーマンスを向上させるあるいは障害に耐えるために水平方向にスケールする(一つ以上のコピーを動かす)ことができます。
|
||||
|
||||
次のコントローラーは、クラウドプロバイダーへの依存関係を持つことがあります。
|
||||
|
||||
* Nodeコントローラー：ノードが応答を停止した後、クラウドで削除されたかどうかを判断するため、クラウドプロバイダーをチェックします。
|
||||
* Routeコントローラー：基盤であるクラウドインフラでルーティングを設定します。
|
||||
* Serviceコントローラー：クラウドプロバイダーのロードバランサーの作成、更新、削除を行います。
|
||||
|
||||
* ノードコントローラー：ノードが応答を停止した後、クラウドで削除されたかどうかを判断するため、クラウドプロバイダーをチェックします。
|
||||
* ルーティングコントローラー：基盤であるクラウドインフラでルーティングを設定します。
|
||||
* サービスコントローラー：クラウドプロバイダーのロードバランサーの作成、更新、削除を行います。
|
||||
## ノードコンポーネント {#node-components}
|
||||
|
||||
ノードコンポーネントはすべてのノードで実行され、稼働中のPodの管理やKubernetesの実行環境を提供します。
|
||||
|
|
@ -105,11 +103,11 @@ Kubernetesによって開始されたコンテナは、DNS検索にこのDNSサ
|
|||
|
||||
### コンテナリソース監視
|
||||
|
||||
[コンテナリソース監視](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)は、コンテナに関する一般的な時系列メトリックを中央データベースに記録します。また、そのデータを閲覧するためのUIを提供します。
|
||||
[コンテナリソース監視](/ja/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)は、コンテナに関する一般的な時系列メトリックを中央データベースに記録します。また、そのデータを閲覧するためのUIを提供します。
|
||||
|
||||
### クラスターレベルログ
|
||||
### クラスターレベルのロギング
|
||||
|
||||
[クラスターレベルログ](/docs/concepts/cluster-administration/logging/)メカニズムは、コンテナのログを、検索／参照インターフェイスを備えた中央ログストアに保存します。
|
||||
[クラスターレベルのロギング](/ja/docs/concepts/cluster-administration/logging/)メカニズムは、コンテナのログを、検索／参照インターフェイスを備えた中央ログストアに保存します。
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
|
|
|||
|
|
@ -0,0 +1,444 @@
|
|||
---
|
||||
title: Podとコンテナにセキュリティコンテキストを設定する
|
||||
content_type: task
|
||||
weight: 80
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
セキュリティコンテキストはPod・コンテナの特権やアクセスコントロールの設定を定義します。
|
||||
セキュリティコンテキストの設定には以下のものが含まれますが、これらに限定はされません。
|
||||
|
||||
* 任意アクセス制御: [user ID (UID) と group ID (GID)](https://wiki.archlinux.org/index.php/users_and_groups)に基づいて、ファイルなどのオブジェクトに対する許可を行います。
|
||||
|
||||
* [Security Enhanced Linux (SELinux)](https://ja.wikipedia.org/wiki/Security-Enhanced_Linux):
|
||||
オブジェクトにセキュリティラベルを付与します。
|
||||
|
||||
* 特権または非特権として実行します。
|
||||
|
||||
* [Linux Capabilities](https://linux-audit.com/linux-capabilities-hardening-linux-binaries-by-removing-setuid/):
|
||||
rootユーザーのすべての特権ではなく、一部の特権をプロセスに与えます。
|
||||
|
||||
* [AppArmor](/docs/tutorials/security/apparmor/):
|
||||
プロファイルを用いて、個々のプログラムのcapabilityを制限します。
|
||||
|
||||
* [Seccomp](/docs/tutorials/security/seccomp/): プロセスのシステムコールを限定します。
|
||||
|
||||
* `allowPrivilegeEscalation`: あるプロセスが親プロセスよりも多くの特権を得ることができるかを制御します。 この真偽値は、コンテナプロセスに
|
||||
[`no_new_privs`](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt)
|
||||
フラグが設定されるかどうかを直接制御します。
|
||||
コンテナが以下の場合、`allowPrivilegeEscalation`は常にtrueになります。
|
||||
- コンテナが特権で動いている
|
||||
- `CAP_SYS_ADMIN`を持っている
|
||||
|
||||
* `readOnlyRootFilesystem`: コンテナのルートファイルシステムが読み取り専用でマウントされます。
|
||||
|
||||
上記の項目は全てのセキュリティコンテキスト設定を記載しているわけではありません。
|
||||
より広範囲なリストは[SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)を確認してください。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Podにセキュリティコンテキストを設定する
|
||||
|
||||
Podにセキュリティ設定を行うには、Podの設定に`securityContext`フィールドを追加してください。
|
||||
`securityContext`フィールドは[PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core)オブジェクトが入ります。
|
||||
Podに設定したセキュリティ設定はPod内の全てのコンテナに適用されます。こちらは`securityContext`と`emptyDir`ボリュームを持ったPodの設定ファイルです。
|
||||
|
||||
{{< codenew file="pods/security/security-context.yaml" >}}
|
||||
|
||||
設定ファイルの中の`runAsUser`フィールドは、Pod内のコンテナに対して全てのプロセスをユーザーID 1000で実行するように指定します。
|
||||
`runAsGroup`フィールドはPod内のコンテナに対して全てのプロセスをプライマリーグループID 3000で実行するように指定します。このフィールドが省略されたときは、コンテナのプライマリーグループIDはroot(0)になります。`runAsGroup`が指定されている場合、作成されたファイルもユーザー1000とグループ3000の所有物になります。
|
||||
また`fsGroup`も指定されているため、全てのコンテナ内のプロセスは補助グループID 2000にも含まれます。`/data/demo`ボリュームとこのボリュームに作成されたファイルはグループID 2000になります。
|
||||
|
||||
Podを作成してみましょう。
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/security/security-context.yaml
|
||||
```
|
||||
|
||||
Podのコンテナが実行されていることを確認します。
|
||||
|
||||
```shell
|
||||
kubectl get pod security-context-demo
|
||||
```
|
||||
|
||||
実行中のコンテナでshellを取ります。
|
||||
|
||||
```shell
|
||||
kubectl exec -it security-context-demo -- sh
|
||||
```
|
||||
|
||||
shellで、実行中のプロセスの一覧を確認します。
|
||||
|
||||
```shell
|
||||
ps
|
||||
```
|
||||
|
||||
`runAsUser`で指定した値である、ユーザー1000でプロセスが実行されていることが確認できます。
|
||||
|
||||
```none
|
||||
PID USER TIME COMMAND
|
||||
1 1000 0:00 sleep 1h
|
||||
6 1000 0:00 sh
|
||||
...
|
||||
```
|
||||
|
||||
shellで`/data`に入り、ディレクトリの一覧を確認します。
|
||||
|
||||
```shell
|
||||
cd /data
|
||||
ls -l
|
||||
```
|
||||
|
||||
`fsGroup`で指定した値であるグループID 2000で`/data/demo`ディレクトリが作成されていることが確認できます。
|
||||
|
||||
```none
|
||||
drwxrwsrwx 2 root 2000 4096 Jun 6 20:08 demo
|
||||
```
|
||||
|
||||
shellで`/data/demo`に入り、ファイルを作成します。
|
||||
|
||||
```shell
|
||||
cd demo
|
||||
echo hello > testfile
|
||||
```
|
||||
|
||||
`/data/demo`ディレクトリでファイルの一覧を確認します。
|
||||
|
||||
```shell
|
||||
ls -l
|
||||
```
|
||||
|
||||
`fsGroup`で指定した値であるグループID 2000で`testfile`が作成されていることが確認できます。
|
||||
|
||||
```none
|
||||
-rw-r--r-- 1 1000 2000 6 Jun 6 20:08 testfile
|
||||
```
|
||||
|
||||
以下のコマンドを実行してください。
|
||||
|
||||
```shell
|
||||
id
|
||||
```
|
||||
|
||||
出力はこのようになります。
|
||||
|
||||
```none
|
||||
uid=1000 gid=3000 groups=2000
|
||||
```
|
||||
|
||||
出力から`runAsGroup`フィールドと同じく`gid`が3000になっていることが確認できるでしょう。`runAsGroup`が省略された場合、`gid`は0(root)になり、そのプロセスはグループroot(0)とグループroot(0)に必要なグループパーミッションを持つグループが所有しているファイルを操作することができるようになります。
|
||||
|
||||
shellから抜けましょう。
|
||||
|
||||
```shell
|
||||
exit
|
||||
```
|
||||
|
||||
## Podのボリュームパーミッションと所有権変更ポリシーを設定する
|
||||
|
||||
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
|
||||
|
||||
デフォルトでは、Kubernetesはボリュームがマウントされたときに、Podの`securityContext`で指定された`fsGroup`に合わせて再帰的に各ボリュームの中の所有権とパーミッションを変更します。
|
||||
大きなボリュームでは所有権の確認と変更に時間がかかり、Podの起動が遅くなります。
|
||||
`securityContext`の中の`fsGroupChangePolicy`フィールドを設定することで、Kubernetesがボリュームの所有権・パーミッションの確認と変更をどう行うかを管理することができます。
|
||||
|
||||
**fsGroupChangePolicy** - `fsGroupChangePolicy`は、ボリュームがPod内部で公開される前に所有権とパーミッションを変更するための動作を定義します。
|
||||
このフィールドは`fsGroup`で所有権とパーミッションを制御することができるボリュームタイプにのみ適用されます。このフィールドは以下の2つの値を取ります。
|
||||
|
||||
* _OnRootMismatch_: ルートディレクトリのパーミッションと所有権がボリュームに設定したパーミッションと一致しない場合のみ、パーミッションと所有権を変更します。ボリュームの所有権とパーミッションを変更するのにかかる時間が短くなる可能性があります。
|
||||
* _Always_: ボリュームがマウントされたときに必ずパーミッションと所有権を変更します。
|
||||
|
||||
例：
|
||||
|
||||
```yaml
|
||||
securityContext:
|
||||
runAsUser: 1000
|
||||
runAsGroup: 3000
|
||||
fsGroup: 2000
|
||||
fsGroupChangePolicy: "OnRootMismatch"
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
このフィールドは
|
||||
[`secret`](/docs/concepts/storage/volumes/#secret)、
|
||||
[`configMap`](/docs/concepts/storage/volumes/#configmap)、
|
||||
[`emptydir`](/docs/concepts/storage/volumes/#emptydir)
|
||||
のようなエフェメラルボリュームタイプに対しては効果がありません。
|
||||
{{< /note >}}
|
||||
|
||||
## CSIドライバーにボリュームパーミッションと所有権を移譲する
|
||||
|
||||
{{< feature-state for_k8s_version="v1.26" state="stable" >}}
|
||||
|
||||
`VOLUME_MOUNT_GROUP` `NodeServiceCapability`をサポートしている[Container Storage Interface (CSI)](https://github.com/container-storage-interface/spec/blob/master/spec.md)ドライバーをデプロイした場合、`securityContext`の`fsGroup`で指定された値に基づいてKubernetesの代わりにCSIドライバーがファイルの所有権とパーミッションの設定処理を行います。
|
||||
この場合Kubernetesは所有権とパーミッションの設定を行わないため`fsGroupChangePolicy`は無効となり、CSIで指定されている通りドライバーは`fsGroup`に従ってボリュームをマウントすると考えられるため、ボリュームは`fsGroup`に従って読み取り・書き込み可能になります。
|
||||
|
||||
## コンテナにセキュリティコンテキストを設定する
|
||||
|
||||
コンテナに対してセキュリティ設定を行うには、コンテナマニフェストに`securityContext`フィールドを含めてください。`securityContext`フィールドには[SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)オブジェクトが入ります。
|
||||
コンテナに指定したセキュリティ設定は個々のコンテナに対してのみ反映され、Podレベルの設定を上書きします。コンテナの設定はPodのボリュームに対しては影響しません。
|
||||
|
||||
こちらは一つのコンテナを持つPodの設定ファイルです。Podもコンテナも`securityContext`フィールドを含んでいます。
|
||||
|
||||
{{< codenew file="pods/security/security-context-2.yaml" >}}
|
||||
|
||||
Podを作成します。
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/security/security-context-2.yaml
|
||||
```
|
||||
|
||||
Podのコンテナが実行されていることを確認します。
|
||||
|
||||
```shell
|
||||
kubectl get pod security-context-demo-2
|
||||
```
|
||||
|
||||
実行中のコンテナでshellを取ります。
|
||||
|
||||
```shell
|
||||
kubectl exec -it security-context-demo-2 -- sh
|
||||
```
|
||||
|
||||
shellの中で、実行中のプロセスの一覧を表示します。
|
||||
|
||||
```shell
|
||||
ps aux
|
||||
```
|
||||
|
||||
ユーザー2000として実行されているプロセスが表示されました。これはコンテナの`runAsUser`で指定された値です。Podで指定された値である1000を上書きしています。
|
||||
|
||||
```
|
||||
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
|
||||
2000 1 0.0 0.0 4336 764 ? Ss 20:36 0:00 /bin/sh -c node server.js
|
||||
2000 8 0.1 0.5 772124 22604 ? Sl 20:36 0:00 node server.js
|
||||
...
|
||||
```
|
||||
|
||||
shellから抜けます。
|
||||
|
||||
```shell
|
||||
exit
|
||||
```
|
||||
|
||||
## コンテナにケーパビリティを設定する
|
||||
|
||||
[Linuxケーパビリティ](https://man7.org/linux/man-pages/man7/capabilities.7.html)を用いると、プロセスに対してrootユーザーの全権を渡すことなく特定の権限を与えることができます。
|
||||
コンテナに対してLinuxケーパビリティを追加したり削除したりするには、コンテナマニフェストの`securityContext`セクションの`capabilities`フィールドに追加してください。
|
||||
|
||||
まず、`capabilities`フィールドを含まない場合どうなるかを見てみましょう。
|
||||
こちらはコンテナに対してケーパビリティを渡していない設定ファイルです。
|
||||
|
||||
{{< codenew file="pods/security/security-context-3.yaml" >}}
|
||||
|
||||
Podを作成します。
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/security/security-context-3.yaml
|
||||
```
|
||||
|
||||
Podが実行されていることを確認します。
|
||||
|
||||
```shell
|
||||
kubectl get pod security-context-demo-3
|
||||
```
|
||||
|
||||
実行中のコンテナでshellを取ります。
|
||||
|
||||
```shell
|
||||
kubectl exec -it security-context-demo-3 -- sh
|
||||
```
|
||||
|
||||
shellの中で、実行中のプロセスの一覧を表示します。
|
||||
|
||||
```shell
|
||||
ps aux
|
||||
```
|
||||
|
||||
コンテナのプロセスID(PID)が出力されます。
|
||||
|
||||
```
|
||||
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
|
||||
root 1 0.0 0.0 4336 796 ? Ss 18:17 0:00 /bin/sh -c node server.js
|
||||
root 5 0.1 0.5 772124 22700 ? Sl 18:17 0:00 node server.js
|
||||
```
|
||||
|
||||
shellの中で、プロセス1のステータスを確認します。
|
||||
|
||||
```shell
|
||||
cd /proc/1
|
||||
cat status
|
||||
```
|
||||
|
||||
プロセスのケーパビリティビットマップが表示されます。
|
||||
|
||||
```
|
||||
...
|
||||
CapPrm: 00000000a80425fb
|
||||
CapEff: 00000000a80425fb
|
||||
...
|
||||
```
|
||||
|
||||
ケーパビリティビットマップのメモを取った後、shellから抜けます。
|
||||
|
||||
```shell
|
||||
exit
|
||||
```
|
||||
|
||||
次に、追加のケーパビリティを除いて上と同じ設定のコンテナを実行します。
|
||||
|
||||
こちらは1つのコンテナを実行するPodの設定ファイルです。
|
||||
`CAP_NET_ADMIN`と`CAP_SYS_TIME`ケーパビリティを設定に追加しました。
|
||||
|
||||
{{< codenew file="pods/security/security-context-4.yaml" >}}
|
||||
|
||||
Podを作成します。
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/security/security-context-4.yaml
|
||||
```
|
||||
|
||||
実行中のコンテナでshellを取ります。
|
||||
|
||||
```shell
|
||||
kubectl exec -it security-context-demo-4 -- sh
|
||||
```
|
||||
|
||||
shellの中で、プロセス1のケーパビリティを確認します。
|
||||
|
||||
```shell
|
||||
cd /proc/1
|
||||
cat status
|
||||
```
|
||||
|
||||
プロセスのケーパビリティビットマップが表示されます。
|
||||
|
||||
```
|
||||
...
|
||||
CapPrm: 00000000aa0435fb
|
||||
CapEff: 00000000aa0435fb
|
||||
...
|
||||
```
|
||||
|
||||
2つのコンテナのケーパビリティを比較します。
|
||||
|
||||
```
|
||||
00000000a80425fb
|
||||
00000000aa0435fb
|
||||
```
|
||||
|
||||
1つ目のコンテナのケーパビリティビットマップでは、12, 25ビット目がクリアされています。2つ目のコンテナでは12, 25ビット目がセットされています。12ビット目は`CAP_NET_ADMIN`、25ビット目は`CAP_SYS_TIME`です。
|
||||
ケーパビリティの定数の定義は[capability.h](https://github.com/torvalds/linux/blob/master/include/uapi/linux/capability.h)を確認してください。
|
||||
|
||||
{{< note >}}
|
||||
Linuxケーパビリティの定数は`CAP_XXX`形式です。
|
||||
ただしコンテナのマニフェストでケーパビリティを記述する際は、定数の`CAP_`の部分を省いてください。
|
||||
例えば、`CAP_SYS_TIME`を追加したい場合はケーパビリティに`SYS_TIME`を追加してください。
|
||||
{{< /note >}}
|
||||
|
||||
## コンテナにSeccompプロフィールを設定する
|
||||
|
||||
コンテナにSeccompプロフィールを設定するには、Pod・コンテナマニフェストの`securityContext`に`seccompProfile`フィールドを追加してください。
|
||||
`seccompProfile`フィールドは[SeccompProfile](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#seccompprofile-v1-core)オブジェクトで、`type`と`localhostProfile`で構成されています。
|
||||
`type`では`RuntimeDefault`、`Unconfined`、`Localhost`が有効です。
|
||||
`localhostProfile`は`type: Localhost`のときのみ指定可能です。こちらはノード上で事前に設定されたプロファイルのパスを示していて、kubeletのSeccompプロファイルの場所(`--root-dir`フラグで設定したもの)からの相対パスです。
|
||||
|
||||
こちらはノードのコンテナランタイムのデフォルトプロフィールをSeccompプロフィールとして設定した例です。
|
||||
|
||||
```yaml
|
||||
...
|
||||
securityContext:
|
||||
seccompProfile:
|
||||
type: RuntimeDefault
|
||||
```
|
||||
|
||||
こちらは`<kubelet-root-dir>/seccomp/my-profiles/profile-allow.json`で事前に設定したファイルをSeccompプロフィールに設定した例です。
|
||||
|
||||
```yaml
|
||||
...
|
||||
securityContext:
|
||||
seccompProfile:
|
||||
type: Localhost
|
||||
localhostProfile: my-profiles/profile-allow.json
|
||||
```
|
||||
|
||||
## コンテナにSELinuxラベルをつける
|
||||
|
||||
コンテナにSELinuxラベルをつけるには、Pod・コンテナマニフェストの`securityContext`セクションに`seLinuxOptions`フィールドを追加してください。
|
||||
`seLinuxOptions`フィールドは[SELinuxOptions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#selinuxoptions-v1-core)オブジェクトが入ります。
|
||||
こちらはSELinuxレベルを適用する例です。
|
||||
|
||||
```yaml
|
||||
...
|
||||
securityContext:
|
||||
seLinuxOptions:
|
||||
level: "s0:c123,c456"
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
SELinuxラベルを適用するには、ホストOSにSELinuxセキュリティモジュールが含まれている必要があります。
|
||||
{{< /note >}}
|
||||
|
||||
### 効率的なSELinuxのボリューム再ラベル付け
|
||||
|
||||
{{< feature-state for_k8s_version="v1.25" state="alpha" >}}
|
||||
|
||||
デフォルトでは、コンテナランタイムは全てのPodのボリュームの全てのファイルに再帰的にSELinuxラベルを付与します。処理速度を上げるために、Kubernetesはマウントオプションで`-o context=<label>`を使うことでボリュームのSELinuxラベルを即座に変更することができます。
|
||||
|
||||
この高速化の恩恵を受けるには、以下の全ての条件を満たす必要があります。
|
||||
|
||||
* Alphaフィーチャーゲートの`ReadWriteOncePod`と`SELinuxMountReadWriteOncePod`を有効にすること
|
||||
* Podが`accessModes: ["ReadWriteOncePod"]`でPersistentVolumeClaimを使うこと
|
||||
* Pod(またはPersistentVolumeClaimを使っている全てのコンテナ)に`seLinuxOptions`が設定されていること
|
||||
* 対応するPersistentVolumeが{{< glossary_tooltip text="CSI" term_id="csi" >}}ドライバーを利用するボリュームか、レガシー`iscsi`ボリュームタイプを利用するボリュームであること
|
||||
* CSIドライバーを利用するボリュームを利用している場合、そのCSIドライバーがCSIドライバーインスタンスで`spec.seLinuxMount: true`を指定したときに`-o context`でマウントを行うとアナウンスしていること
|
||||
|
||||
それ以外のボリュームタイプでは、コンテナランタイムはボリュームに含まれる全てのinode(ファイルやディレクトリ)に対してSELinuxラベルを再帰的に変更します。
|
||||
ボリューム内のファイルやディレクトリが増えるほど、ラベリングにかかる時間は増加します。
|
||||
|
||||
{{< note >}}
|
||||
Kubernetes 1.25では、kubeletは再起動後にボリュームラベルを追跡できなくなります。言い換えると、kubeletはPodの中のラベルのコンフリクトが解消されるまで"conflicting
|
||||
SELinux labels of volume"というようなエラーでPodの起動を拒否する可能性があるということです。Kubeletを再起動する前に必ずノードを[完全にdrain](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/)された状態にしてください。
|
||||
{{< /note >}}
|
||||
|
||||
## 議論
|
||||
|
||||
PodのセキュリティコンテキストはPodのコンテナや、適用可能であればPodのボリュームに対しても適用されます。
|
||||
特に`fsGroup`と`seLinuxOptions`は以下のようにボリュームに対して適用されます。
|
||||
|
||||
* `fsGroup`: 所有権管理をサポートしているボリュームは`fsGroup`で指定されているGIDで所有権・書き込み権限が設定されます。詳しくは[Ownership Management design document](https://git.k8s.io/design-proposals-archive/storage/volume-ownership-management.md)を確認してください。
|
||||
|
||||
* `seLinuxOptions`: SELinuxラベリングをサポートしているボリュームでは`seLinuxOptions`で指定されているラベルでアクセス可能になるように貼り直されます。通常、`level`セクションのみ設定する必要があります。
|
||||
これはPod内の全てのボリュームとコンテナに対し[Multi-Category Security (MCS)](https://selinuxproject.org/page/NB_MLS)ラベルを設定します。
|
||||
|
||||
{{< warning >}}
|
||||
Podに対してMCSラベルを指定すると、同じラベルを持つ全てのPodがボリュームにアクセスすることができます。
|
||||
Pod内の保護が必要な場合、それぞれのPodに対して一意なMCSラベルを割り当ててください。
|
||||
{{< /warning >}}
|
||||
|
||||
## クリーンアップ
|
||||
|
||||
Podを削除します。
|
||||
|
||||
```shell
|
||||
kubectl delete pod security-context-demo
|
||||
kubectl delete pod security-context-demo-2
|
||||
kubectl delete pod security-context-demo-3
|
||||
kubectl delete pod security-context-demo-4
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core)
|
||||
* [SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)
|
||||
* [最新の強化されたセキュリティでDockerを調整する](https://github.com/containerd/containerd/blob/main/docs/cri/config.md)
|
||||
* [Security Contexts design document](https://git.k8s.io/design-proposals-archive/auth/security_context.md)
|
||||
* [Ownership Management design document](https://git.k8s.io/design-proposals-archive/storage/volume-ownership-management.md)
|
||||
* [PodSecurity Admission](/docs/concepts/security/pod-security-admission/)
|
||||
* [AllowPrivilegeEscalation design document](https://git.k8s.io/design-proposals-archive/auth/no-new-privs.md)
|
||||
* Linuxのセキュリティについてさらに知りたい場合は、[Overview of Linux Kernel Security Features](https://www.linux.com/learn/overview-linux-kernel-security-features)を確認してください(注: 一部の情報は古くなっています)。
|
||||
|
|
@ -2,7 +2,7 @@ schedules:
|
|||
- release: 1.26
|
||||
releaseDate: 2022-12-09
|
||||
maintenanceModeStartDate: 2023-12-28
|
||||
endOfLifeDate: 2024-02-24
|
||||
endOfLifeDate: 2024-02-28
|
||||
next:
|
||||
release: 1.26.1
|
||||
cherryPickDeadline: 2022-01-06
|
||||
|
|
@ -10,7 +10,7 @@ schedules:
|
|||
- release: 1.25
|
||||
releaseDate: 2022-08-23
|
||||
maintenanceModeStartDate: 2023-08-28
|
||||
endOfLifeDate: 2023-10-27
|
||||
endOfLifeDate: 2023-10-28
|
||||
next:
|
||||
release: 1.25.6
|
||||
cherryPickDeadline: 2023-01-13
|
||||
|
|
|
|||
|
|
@ -1,19 +0,0 @@
|
|||
id: code-contributor
|
||||
name: Code Contributor
|
||||
glossary_id: code-contributor
|
||||
index: 0
|
||||
foundational:
|
||||
- label: "Read the Developer Guide"
|
||||
icon: fa-book
|
||||
url: "https://github.com/kubernetes/community/blob/master/contributors/devel/README.md"
|
||||
intermediate:
|
||||
- label: "Learn about the Kubernetes Enhancement Proposal (KEP) process"
|
||||
icon: fa-upload
|
||||
url: "https://github.com/kubernetes/enhancements/blob/master/keps/0001-kubernetes-enhancement-proposal-process.md"
|
||||
- label: "Understand the API conventions"
|
||||
icon: fa-map-o
|
||||
url: "https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md"
|
||||
advanced:
|
||||
- label: "Learn about the release process"
|
||||
icon: fa-code-fork
|
||||
url: "https://github.com/kubernetes/release/blob/master/README.md"
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
id: community-contributor
|
||||
name: Community Contributor
|
||||
short_desc: A person who works to build the Kubernetes community (e.g. by organizing meetups).
|
||||
index: 1
|
||||
foundational:
|
||||
- label: "Contribute to the Kubernetes OSS project"
|
||||
icon: fa-users
|
||||
url: "https://github.com/kubernetes/community/blob/master/contributors/guide/README.md"
|
||||
- label: "Find out about mentoring initiatives"
|
||||
icon: fa-graduation-cap
|
||||
url: "https://github.com/kubernetes/community/blob/master/mentoring/README.md"
|
||||
intermediate:
|
||||
- label: "Apply for community membership as a member, reviewer, approver, owner, or maintainer"
|
||||
icon: fa-user-plus
|
||||
url: "https://github.com/kubernetes/community/blob/master/community-membership.md"
|
||||
advanced:
|
||||
- label: "Learn about Kubernetes community governance"
|
||||
icon: fa-gavel
|
||||
url: "https://github.com/kubernetes/community/blob/master/governance.md"
|
||||
|
|
@ -1,40 +0,0 @@
|
|||
id: docs-contributor
|
||||
name: Docs Contributor
|
||||
short_desc: A person who writes documentation for the Kubernetes project (e.g. this site).
|
||||
index: 2
|
||||
foundational:
|
||||
- label: "Contribute to the Kubernetes documentation"
|
||||
icon: fa-users
|
||||
url: "/editdocs/"
|
||||
- label: "Learn about documentation style"
|
||||
icon: fa-book
|
||||
url: "/docs/home/contribute/style-guide/"
|
||||
- label: "Review documentation issues"
|
||||
icon: fa-bug
|
||||
url: "/docs/home/contribute/review-issues/"
|
||||
- label: "Create a documentation pull request (PR)"
|
||||
icon: fa-pencil-square-o
|
||||
url: "/docs/contribute/start/"
|
||||
- label: "Stage documentation changes"
|
||||
icon: fa-eye
|
||||
url: "/docs/home/contribute/stage-documentation-changes/#staging-a-pull-request"
|
||||
intermediate:
|
||||
- label: "Write a new topic"
|
||||
icon: fa-plus-circle
|
||||
url: "/docs/home/contribute/write-new-topic/"
|
||||
- label: "Stage documentation changes locally"
|
||||
icon: fa-cloud-download
|
||||
url: "/docs/home/contribute/stage-documentation-changes/#staging-locally-using-docker"
|
||||
- label: "Apply page templates"
|
||||
icon: fa-clone
|
||||
url: "/docs/home/contribute/page-templates/"
|
||||
- label: "Add callout formatting"
|
||||
icon: fa-exclamation-circle
|
||||
url: "/docs/home/contribute/style-guide/#callout-formatting"
|
||||
advanced:
|
||||
- label: "Add feature state tags"
|
||||
icon: fa-tag
|
||||
url: "/docs/home/contribute/includes/#feature-state"
|
||||
- label: "Add tabs to display multiple flavors of content"
|
||||
icon: fa-folder-o
|
||||
url: "/docs/home/contribute/includes/#tabs"
|
||||
|
|
@ -1,24 +0,0 @@
|
|||
id: docker-compose-swarm
|
||||
name: Migrating from Docker Compose and Swarm
|
||||
index: 1
|
||||
foundational:
|
||||
- label: "b1: foundational stuff"
|
||||
url: "#"
|
||||
- label: "b2: foundational stuff"
|
||||
url: "#"
|
||||
- label: "b3: foundational stuff"
|
||||
url: "#"
|
||||
intermediate:
|
||||
- label: "b1: intermediate stuff"
|
||||
url: "#"
|
||||
- label: "b2: intermediate stuff"
|
||||
url: "#"
|
||||
- label: "b3: intermediate stuff"
|
||||
url: "#"
|
||||
advanced:
|
||||
- label: "b1: advanced stuff"
|
||||
url: "#"
|
||||
- label: "b2: advanced stuff"
|
||||
url: "#"
|
||||
- label: "b3: advanced stuff"
|
||||
url: "#"
|
||||
|
|
@ -1,24 +0,0 @@
|
|||
id: heroku
|
||||
name: Migrating from Heroku (PaaS)
|
||||
index: 2
|
||||
foundational:
|
||||
- label: "c1: foundational stuff"
|
||||
url: "#"
|
||||
- label: "c2: foundational stuff"
|
||||
url: "#"
|
||||
- label: "c3: foundational stuff"
|
||||
url: "#"
|
||||
intermediate:
|
||||
- label: "c1: intermediate stuff"
|
||||
url: "#"
|
||||
- label: "c2: intermediate stuff"
|
||||
url: "#"
|
||||
- label: "c3: intermediate stuff"
|
||||
url: "#"
|
||||
advanced:
|
||||
- label: "c1: advanced stuff"
|
||||
url: "#"
|
||||
- label: "c2: advanced stuff"
|
||||
url: "#"
|
||||
- label: "c3: advanced stuff"
|
||||
url: "#"
|
||||
|
|
@ -1,24 +0,0 @@
|
|||
id: mesos
|
||||
name: Migrating from Apache Mesos
|
||||
index: 3
|
||||
foundational:
|
||||
- label: "d1: foundational stuff"
|
||||
url: "#"
|
||||
- label: "d2: foundational stuff"
|
||||
url: "#"
|
||||
- label: "d3: foundational stuff"
|
||||
url: "#"
|
||||
intermediate:
|
||||
- label: "d1: intermediate stuff"
|
||||
url: "#"
|
||||
- label: "d2: intermediate stuff"
|
||||
url: "#"
|
||||
- label: "d3: intermediate stuff"
|
||||
url: "#"
|
||||
advanced:
|
||||
- label: "d1: advanced stuff"
|
||||
url: "#"
|
||||
- label: "d2: advanced stuff"
|
||||
url: "#"
|
||||
- label: "d3: advanced stuff"
|
||||
url: "#"
|
||||
|
|
@ -1,24 +0,0 @@
|
|||
id: vmware-openstack
|
||||
name: Migrating from VMware and/or OpenStack
|
||||
index: 0
|
||||
foundational:
|
||||
- label: "a1: foundational stuff"
|
||||
url: "#"
|
||||
- label: "a2: foundational stuff"
|
||||
url: "#"
|
||||
- label: "a3: foundational stuff"
|
||||
url: "#"
|
||||
intermediate:
|
||||
- label: "a1: intermediate stuff"
|
||||
url: "#"
|
||||
- label: "a2: intermediate stuff"
|
||||
url: "#"
|
||||
- label: "a3: intermediate stuff"
|
||||
url: "#"
|
||||
advanced:
|
||||
- label: "a1: advanced stuff"
|
||||
url: "#"
|
||||
- label: "a2: advanced stuff"
|
||||
url: "#"
|
||||
- label: "a3: advanced stuff"
|
||||
url: "#"
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
id: cluster-operator
|
||||
name: Cluster Operator
|
||||
glossary_id: cluster-operator
|
||||
index: 1
|
||||
advanced:
|
||||
- label: "Connect to managed services using Service Catalog"
|
||||
icon: fa-puzzle-piece
|
||||
url: "/docs/concepts/service-catalog/"
|
||||
- label: "Extend a Kubernetes cluster"
|
||||
icon: fa-arrows
|
||||
url: "/docs/concepts/overview/extending/"
|
||||
- label: "Create a Pod Security Policy"
|
||||
icon: fa-lock
|
||||
url: "/docs/concepts/policy/pod-security-policy/"
|
||||
- label: "Define a Resource Quota"
|
||||
icon: fa-tachometer
|
||||
url: "/docs/concepts/policy/resource-quotas/"
|
||||
Loading…
Reference in New Issue