Podとコンテナにセキュリティコンテキストを設定する
セキュリティコンテキストはPod・コンテナの特権やアクセスコントロールの設定を定義します。 セキュリティコンテキストの設定には以下のものが含まれますが、これらに限定はされません。
任意アクセス制御: user ID (UID) と group ID (GID)に基づいて、ファイルなどのオブジェクトに対する許可を行います。
Security Enhanced Linux (SELinux): オブジェクトにセキュリティラベルを付与します。
特権または非特権として実行します。
Linux Capabilities: rootユーザーのすべての特権ではなく、一部の特権をプロセスに与えます。
AppArmor: プロファイルを用いて、個々のプログラムのcapabilityを制限します。
Seccomp: プロセスのシステムコールを限定します。
allowPrivilegeEscalation
: あるプロセスが親プロセスよりも多くの特権を得ることができるかを制御します。 この真偽値は、コンテナプロセスにno_new_privs
フラグが設定されるかどうかを直接制御します。 コンテナが以下の場合、allowPrivilegeEscalation
は常にtrueになります。- コンテナが特権で動いている
CAP_SYS_ADMIN
を持っている
readOnlyRootFilesystem
: コンテナのルートファイルシステムが読み取り専用でマウントされます。
上記の項目は全てのセキュリティコンテキスト設定を記載しているわけではありません。 より広範囲なリストはSecurityContextを確認してください。
始める前に
Kubernetesクラスターが必要、かつそのクラスターと通信するためにkubectlコマンドラインツールが設定されている必要があります。 このチュートリアルは、コントロールプレーンのホストとして動作していない少なくとも2つのノードを持つクラスターで実行することをおすすめします。 まだクラスターがない場合、minikubeを使って作成するか、 以下のいずれかのKubernetesプレイグラウンドも使用できます:
バージョンを確認するには次のコマンドを実行してください:kubectl version
.Podにセキュリティコンテキストを設定する
Podにセキュリティ設定を行うには、Podの設定にsecurityContext
フィールドを追加してください。
securityContext
フィールドはPodSecurityContextオブジェクトが入ります。
Podに設定したセキュリティ設定はPod内の全てのコンテナに適用されます。こちらはsecurityContext
とemptyDir
ボリュームを持ったPodの設定ファイルです。
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
spec:
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
supplementalGroups: [4000]
volumes:
- name: sec-ctx-vol
emptyDir: {}
containers:
- name: sec-ctx-demo
image: busybox:1.28
command: [ "sh", "-c", "sleep 1h" ]
volumeMounts:
- name: sec-ctx-vol
mountPath: /data/demo
securityContext:
allowPrivilegeEscalation: false
設定ファイルの中のrunAsUser
フィールドは、Pod内のコンテナに対して全てのプロセスをユーザーID 1000で実行するように指定します。
runAsGroup
フィールドはPod内のコンテナに対して全てのプロセスをプライマリーグループID 3000で実行するように指定します。このフィールドが省略されたときは、コンテナのプライマリーグループIDはroot(0)になります。runAsGroup
が指定されている場合、作成されたファイルもユーザー1000とグループ3000の所有物になります。
またfsGroup
も指定されているため、全てのコンテナ内のプロセスは補助グループID 2000にも含まれます。/data/demo
ボリュームとこのボリュームに作成されたファイルはグループID 2000になります。加えて、supplementalGroups
フィールドが指定されている場合、全てのコンテナ内のプロセスは指定されている補助グループIDにも含まれます。もしこのフィールドが指定されていない場合、空を意味します。
Podを作成してみましょう。
kubectl apply -f https://k8s.io/examples/pods/security/security-context.yaml
Podのコンテナが実行されていることを確認します。
kubectl get pod security-context-demo
実行中のコンテナでshellを取ります。
kubectl exec -it security-context-demo -- sh
shellで、実行中のプロセスの一覧を確認します。
ps
runAsUser
で指定した値である、ユーザー1000でプロセスが実行されていることが確認できます。
PID USER TIME COMMAND
1 1000 0:00 sleep 1h
6 1000 0:00 sh
...
shellで/data
に入り、ディレクトリの一覧を確認します。
cd /data
ls -l
fsGroup
で指定した値であるグループID 2000で/data/demo
ディレクトリが作成されていることが確認できます。
drwxrwsrwx 2 root 2000 4096 Jun 6 20:08 demo
shellで/data/demo
に入り、ファイルを作成します。
cd demo
echo hello > testfile
/data/demo
ディレクトリでファイルの一覧を確認します。
ls -l
fsGroup
で指定した値であるグループID 2000でtestfile
が作成されていることが確認できます。
-rw-r--r-- 1 1000 2000 6 Jun 6 20:08 testfile
以下のコマンドを実行してください。
id
出力はこのようになります。
uid=1000 gid=3000 groups=2000,3000,4000
出力からrunAsGroup
フィールドと同じくgid
が3000になっていることが確認できるでしょう。runAsGroup
が省略された場合、gid
は0(root)になり、そのプロセスはグループroot(0)とグループroot(0)に必要なグループパーミッションを持つグループが所有しているファイルを操作することができるようになります。また、groups
の出力に、gid
に加えて、fsGroups
、supplementalGroups
フィールドで指定したグループIDも含まれていることも確認できるでしょう。
shellから抜けましょう。
exit
コンテナイメージ内の/etc/group
から暗黙的にマージされるグループ情報
Kubernetesは、デフォルトでは、Podで定義された情報に加えて、コンテナイメージ内の/etc/group
のグループ情報をマージします。
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
spec:
securityContext:
runAsUser: 1000
runAsGroup: 3000
supplementalGroups: [4000]
containers:
- name: sec-ctx-demo
image: registry.k8s.io/e2e-test-images/agnhost:2.45
command: [ "sh", "-c", "sleep 1h" ]
securityContext:
allowPrivilegeEscalation: false
このPodはsecurity contextでrunAsUser
、runAsGroup
、supplementalGroups
フィールドが指定されています。しかし、コンテナ内のプロセスには、コンテナイメージ内の/etc/group
に定義されたグループIDが、補助グループとして付与されていることが確認できるでしょう。
Podを作成してみましょう。
kubectl apply -f https://k8s.io/examples/pods/security/security-context-5.yaml
Podのコンテナが実行されていることを確認します。
kubectl get pod security-context-demo
実行中のコンテナでshellを取ります。
kubectl exec -it security-context-demo -- sh
プロセスのユーザー、グループ情報を確認します。
$ id
出力はこのようになります。
uid=1000 gid=3000 groups=3000,4000,50000
groups
にグループID50000
が含まれていることが確認できるでしょう。これは、ユーザー(uid=1000
)がコンテナイメージで定義されており、コンテナイメージ内の/etc/group
でグループ(gid=50000
)に所属しているためです。
コンテナイメージの/etc/group
の内容を確認してみましょう。
$ cat /etc/group
ユーザー1000
がグループ50000
に所属していることが確認できるでしょう。
...
user-defined-in-image:x:1000:
group-defined-in-image:x:50000:user-defined-in-image
shellから抜けましょう。
exit
備考:
暗黙的にマージされる 補助グループはボリュームアクセスを行う際にセキュリティ上の懸念を引き起こすことがあります(詳細はkubernetes/kubernetes#112879を参照してください)。回避したい場合、次節を参照してください。Podにfine-grained(きめ細かい) SupplementalGroups controlを設定する
Kubernetes v1.31 [alpha]
この機能はkubeletとkube-apiseverにSupplementalGroupsPolicy
フィーチャーゲートを設定し、Podの.spec.securityContext.supplementalGroupsPolicy
フィールドを指定することで利用できます。
supplementalGroupsPolicy
フィールドは、Pod内のコンテナプロセスに付与される補助グループを、どのように決定するかを定義します。有効な値は次の2つです。
Merge
:/etc/group
で定義されている、コンテナのプライマリユーザーが所属するグループをマージします。指定されていない場合、このポリシーがデフォルトです。Strict
:fsGroup
、supplementalGroups
、runAsGroup
フィールドで指定されたグループのみ補助グループに指定されます。つまり、/etc/group
で定義された、コンテナのプライマリユーザーのグループ情報はマージされません。
この機能が有効な場合、.status.containerStatuses[].user.linux
フィールドで、コンテナの最初のプロセスに付与されたユーザー、グループ情報が確認出来ます。暗黙的なグループIDが付与されているかどうかを確認するのに便利でしょう。
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
spec:
securityContext:
runAsUser: 1000
runAsGroup: 3000
supplementalGroups: [4000]
supplementalGroupsPolicy: Strict
containers:
- name: sec-ctx-demo
image: registry.k8s.io/e2e-test-images/agnhost:2.45
command: [ "sh", "-c", "sleep 1h" ]
securityContext:
allowPrivilegeEscalation: false
このPodマニフェストはsupplementalGroupsPolicy=Strict
を指定しています。/etc/group
に定義されているグループ情報が、コンテナ内のプロセスの補助グループにマージされないことが確認できるでしょう。
Podを作成してみましょう。
kubectl apply -f https://k8s.io/examples/pods/security/security-context-6.yaml
Podのコンテナが実行されていることを確認します。
kubectl get pod security-context-demo
プロセスのユーザー、グループ情報を確認します。
kubectl exec -it security-context-demo -- id
出力はこのようになります。
uid=1000 gid=3000 groups=3000,4000
Podのステータスを確認します。
kubectl get pod security-context-demo -o yaml
status.containerStatuses[].user.linux
フィールドでコンテナの最初のプロセスに付与されたユーザー、グループ情報が確認出来ます。
...
status:
containerStatuses:
- name: sec-ctx-demo
user:
linux:
gid: 3000
supplementalGroups:
- 3000
- 4000
uid: 1000
...
備考:
status.containerStatuses[].user.linux
フィールドで公開されているユーザー、グループ情報は、コンテナの最初のプロセスに、最初に付与された 情報であることに注意してください。
もしそのプロセスが、自身のユーザー、グループ情報を変更できるシステムコール(例えば setuid(2)
,
setgid(2)
,
setgroups(2)
等)を実行する権限を持っている場合、プロセス自身で動的に変更が可能なためです。
つまり、実際にプロセスに付与されているユーザー、グループ情報は動的に変化します。利用可能な実装
下記のコンテナランタイムがfine-grained(きめ細かい) SupplementalGroups controlを実装しています。
CRI実装:
- containerd v2.0以降
- CRI-O v1.31以降
ノードのステータスでこの機能が利用可能かどうか確認出来ます。
apiVersion: v1
kind: Node
...
status:
features:
supplementalGroupsPolicy: true
Podのボリュームパーミッションと所有権変更ポリシーを設定する
Kubernetes v1.23 [stable]
デフォルトでは、Kubernetesはボリュームがマウントされたときに、PodのsecurityContext
で指定されたfsGroup
に合わせて再帰的に各ボリュームの中の所有権とパーミッションを変更します。
大きなボリュームでは所有権の確認と変更に時間がかかり、Podの起動が遅くなります。
securityContext
の中のfsGroupChangePolicy
フィールドを設定することで、Kubernetesがボリュームの所有権・パーミッションの確認と変更をどう行うかを管理することができます。
fsGroupChangePolicy - fsGroupChangePolicy
は、ボリュームがPod内部で公開される前に所有権とパーミッションを変更するための動作を定義します。
このフィールドはfsGroup
で所有権とパーミッションを制御することができるボリュームタイプにのみ適用されます。このフィールドは以下の2つの値を取ります。
- OnRootMismatch: ルートディレクトリのパーミッションと所有権がボリュームに設定したパーミッションと一致しない場合のみ、パーミッションと所有権を変更します。ボリュームの所有権とパーミッションを変更するのにかかる時間が短くなる可能性があります。
- Always: ボリュームがマウントされたときに必ずパーミッションと所有権を変更します。
例:
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
fsGroupChangePolicy: "OnRootMismatch"
CSIドライバーにボリュームパーミッションと所有権を移譲する
Kubernetes v1.26 [stable]
VOLUME_MOUNT_GROUP
NodeServiceCapability
をサポートしているContainer Storage Interface (CSI)ドライバーをデプロイした場合、securityContext
のfsGroup
で指定された値に基づいてKubernetesの代わりにCSIドライバーがファイルの所有権とパーミッションの設定処理を行います。
この場合Kubernetesは所有権とパーミッションの設定を行わないためfsGroupChangePolicy
は無効となり、CSIで指定されている通りドライバーはfsGroup
に従ってボリュームをマウントすると考えられるため、ボリュームはfsGroup
に従って読み取り・書き込み可能になります。
コンテナにセキュリティコンテキストを設定する
コンテナに対してセキュリティ設定を行うには、コンテナマニフェストにsecurityContext
フィールドを含めてください。securityContext
フィールドにはSecurityContextオブジェクトが入ります。
コンテナに指定したセキュリティ設定は個々のコンテナに対してのみ反映され、Podレベルの設定を上書きします。コンテナの設定はPodのボリュームに対しては影響しません。
こちらは一つのコンテナを持つPodの設定ファイルです。PodもコンテナもsecurityContext
フィールドを含んでいます。
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo-2
spec:
securityContext:
runAsUser: 1000
containers:
- name: sec-ctx-demo-2
image: gcr.io/google-samples/node-hello:1.0
securityContext:
runAsUser: 2000
allowPrivilegeEscalation: false
Podを作成します。
kubectl apply -f https://k8s.io/examples/pods/security/security-context-2.yaml
Podのコンテナが実行されていることを確認します。
kubectl get pod security-context-demo-2
実行中のコンテナでshellを取ります。
kubectl exec -it security-context-demo-2 -- sh
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から抜けます。
exit
コンテナにケーパビリティを設定する
Linuxケーパビリティを用いると、プロセスに対してrootユーザーの全権を渡すことなく特定の権限を与えることができます。
コンテナに対してLinuxケーパビリティを追加したり削除したりするには、コンテナマニフェストのsecurityContext
セクションのcapabilities
フィールドに追加してください。
まず、capabilities
フィールドを含まない場合どうなるかを見てみましょう。
こちらはコンテナに対してケーパビリティを渡していない設定ファイルです。
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo-3
spec:
containers:
- name: sec-ctx-3
image: gcr.io/google-samples/node-hello:1.0
Podを作成します。
kubectl apply -f https://k8s.io/examples/pods/security/security-context-3.yaml
Podが実行されていることを確認します。
kubectl get pod security-context-demo-3
実行中のコンテナでshellを取ります。
kubectl exec -it security-context-demo-3 -- sh
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のステータスを確認します。
cd /proc/1
cat status
プロセスのケーパビリティビットマップが表示されます。
...
CapPrm: 00000000a80425fb
CapEff: 00000000a80425fb
...
ケーパビリティビットマップのメモを取った後、shellから抜けます。
exit
次に、追加のケーパビリティを除いて上と同じ設定のコンテナを実行します。
こちらは1つのコンテナを実行するPodの設定ファイルです。
CAP_NET_ADMIN
とCAP_SYS_TIME
ケーパビリティを設定に追加しました。
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo-4
spec:
containers:
- name: sec-ctx-4
image: gcr.io/google-samples/node-hello:1.0
securityContext:
capabilities:
add: ["NET_ADMIN", "SYS_TIME"]
Podを作成します。
kubectl apply -f https://k8s.io/examples/pods/security/security-context-4.yaml
実行中のコンテナでshellを取ります。
kubectl exec -it security-context-demo-4 -- sh
shellの中で、プロセス1のケーパビリティを確認します。
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を確認してください。
備考:
Linuxケーパビリティの定数はCAP_XXX
形式です。
ただしコンテナのマニフェストでケーパビリティを記述する際は、定数のCAP_
の部分を省いてください。
例えば、CAP_SYS_TIME
を追加したい場合はケーパビリティにSYS_TIME
を追加してください。コンテナにSeccompプロフィールを設定する
コンテナにSeccompプロフィールを設定するには、Pod・コンテナマニフェストのsecurityContext
にseccompProfile
フィールドを追加してください。
seccompProfile
フィールドはSeccompProfileオブジェクトで、type
とlocalhostProfile
で構成されています。
type
ではRuntimeDefault
、Unconfined
、Localhost
が有効です。
localhostProfile
はtype: Localhost
のときのみ指定可能です。こちらはノード上で事前に設定されたプロファイルのパスを示していて、kubeletのSeccompプロファイルの場所(--root-dir
フラグで設定したもの)からの相対パスです。
こちらはノードのコンテナランタイムのデフォルトプロフィールをSeccompプロフィールとして設定した例です。
...
securityContext:
seccompProfile:
type: RuntimeDefault
こちらは<kubelet-root-dir>/seccomp/my-profiles/profile-allow.json
で事前に設定したファイルをSeccompプロフィールに設定した例です。
...
securityContext:
seccompProfile:
type: Localhost
localhostProfile: my-profiles/profile-allow.json
コンテナにAppArmorプロフィールを設定する
コンテナにAppArmorプロフィールを設定するには、securityContext
セクションにappAormorProfile
フィールドを含めてください。
appAormerProfile
フィールドには、type
フィールドとlocalhostProfile
フィールドから構成されるAppArmorProfileオブジェクトが入ります。type
フィールドの有効なオプションはRuntimeDefault
(デフォルト)、Unconfined
、Localhost
です。
localhostProfile
はtype
がLocalhost
のときには必ず設定しなければなりません。この値はノードで事前に設定されたプロフィール名を示します。Podは事前にどのノードにスケジュールされるかわからないため、指定されたプロフィールはPodがスケジュールされ得る全てのノードにロードされている必要があります。カスタムプロフィールをセットアップする方法はSetting up nodes with profilesを参照してください。
注意: containers[*].securityContext.appArmorProfile.type
が明示的にRuntimeDefault
に設定されている場合は、もしノードでAppArmorが有効化されていなければ、Podの作成は許可されません。
しかし、containers[*].securityContext.appArmorProfile.type
が設定されていない場合、AppArmorが有効化されていれば、デフォルト(RuntimeDefault
)が適用されます。もし、AppArmorが無効化されている場合は、Podの作成は許可されますが、コンテナにはRuntimeDefault
プロフィールの制限は適用されません。
これは、AppArmorプロフィールとして、ノードのコンテナランタイムのデフォルトプロフィールを設定する例です。
...
containers:
- name: container-1
securityContext:
appArmorProfile:
type: RuntimeDefault
これは、AppArmorプロフィールとして、k8s-apparmor-example-deny-write
という名前で事前に設定されたプロフィールを設定する例です。
...
containers:
- name: container-1
securityContext:
appArmorProfile:
type: Localhost
localhostProfile: k8s-apparmor-example-deny-write
より詳細な内容についてはRestrict a Container's Access to Resources with AppArmorを参照してください。
コンテナにSELinuxラベルをつける
コンテナにSELinuxラベルをつけるには、Pod・コンテナマニフェストのsecurityContext
セクションにseLinuxOptions
フィールドを追加してください。
seLinuxOptions
フィールドはSELinuxOptionsオブジェクトが入ります。
こちらはSELinuxレベルを適用する例です。
...
securityContext:
seLinuxOptions:
level: "s0:c123,c456"
備考:
SELinuxラベルを適用するには、ホストOSにSELinuxセキュリティモジュールが含まれている必要があります。効率的なSELinuxのボリューム再ラベル付け
Kubernetes v1.28 [beta]
備考:
Kubernetes v1.27で、ReadWriteOncePod
アクセスモードを使用するボリューム(およびPersistentVolumeClaim)にのみ、この機能の限定的な機能が早期提供されています。
Alphaフィーチャーとして、SELinuxMount
フィーチャーゲートを有効にすることで、以下で説明するように、他の種類のPersistentVolumeClaimにもパフォーマンス改善の範囲を広げる事ができます。
デフォルトでは、コンテナランタイムは全てのPodのボリュームの全てのファイルに再帰的にSELinuxラベルを付与します。処理速度を上げるために、Kubernetesはマウントオプションで-o context=<label>
を使うことでボリュームのSELinuxラベルを即座に変更することができます。
この高速化の恩恵を受けるには、以下の全ての条件を満たす必要があります。
- Alphaフィーチャーゲートの
ReadWriteOncePod
とSELinuxMountReadWriteOncePod
を有効にすること - Podが適用可能な
accessModes
でPersistentVolumeClaimを使うこと- ボリュームが
accessModes: ["ReadWriteOncePod"]
を持ち、フィーチャーゲートSELinuxMountReadWriteOncePod
が有効であること - または、ボリュームが他のアクセスモードを使用し、フィーチャーゲート
SELinuxMountReadWriteOncePod
とSELinuxMount
の両方が有効であること
- ボリュームが
- Pod(またはPersistentVolumeClaimを使っている全てのコンテナ)に
seLinuxOptions
が設定されていること - 対応するPersistentVolumeが以下のいずれかであること
- レガシーのin-treeボリュームの場合、
iscs
、rbd
、fc
ボリュームタイプであること - または、CSIドライバーを使用するボリュームで、そのCSIドライバーがCSIドライバーインスタンスで
spec.seLinuxMount: true
を指定したときに-o context
でマウントを行うとアナウンスしていること
- レガシーのin-treeボリュームの場合、
それ以外のボリュームタイプでは、コンテナランタイムはボリュームに含まれる全てのinode(ファイルやディレクトリ)に対してSELinuxラベルを再帰的に変更します。 ボリューム内のファイルやディレクトリが増えるほど、ラベリングにかかる時間は増加します。
/proc
ファイルシステムへのアクセスを管理する
Kubernetes v1.12 [alpha]
OCI runtime specificationに準拠するランタイムでは、コンテナはデフォルトで、いくつかの複数のパスはマスクされ、かつ、読み取り専用のモードで実行されます。 その結果、コンテナのマウントネームスペース内にはこれらのパスが存在し、あたかもコンテナが隔離されたホストであるかのように機能しますが、コンテナプロセスはそれらのパスに書き込むことはできません。 マスクされるパスおよび読み取り専用のパスのリストは次のとおりです。
マスクされるパス:
/proc/asound
/proc/acpi
/proc/kcore
/proc/keys
/proc/latency_stats
/proc/timer_list
/proc/timer_stats
/proc/sched_debug
/proc/scsi
/sys/firmware
/sys/devices/virtual/powercap
読み取り専用のパス:
/proc/bus
/proc/fs
/proc/irq
/proc/sys
/proc/sysrq-trigger
一部のPodでは、デフォルトでパスがマスクされるのを回避したい場合があります。このようなケースで最も一般的なのは、Kubernetesコンテナ(Pod内のコンテナ)内でコンテナを実行しようとする場合です。
securityContext
のprocMount
フィールドを使用すると、コンテナの/proc
をUnmasked
にしたり、コンテナプロセスによって読み書き可能な状態でマウントすることができます。この設定は、/proc
以外の/sys/firmware
にも適用されます。
...
securityContext:
procMount: Unmasked
備考:
procMount
をUnmaskedに設定するには、Podのspec.hostUsers
の値がfalse
である必要があります。
つまり、Unmaskedな/proc
やUnmaskedな/sys
を使用したいコンテナは、user namespace内で動作している必要があります。
Kubernetes v1.12からv1.29までは、この要件は強制されません。議論
PodのセキュリティコンテキストはPodのコンテナや、適用可能であればPodのボリュームに対しても適用されます。
特にfsGroup
とseLinuxOptions
は以下のようにボリュームに対して適用されます。
fsGroup
: 所有権管理をサポートしているボリュームはfsGroup
で指定されているGIDで所有権・書き込み権限が設定されます。詳しくはOwnership Management design documentを確認してください。seLinuxOptions
: SELinuxラベリングをサポートしているボリュームではseLinuxOptions
で指定されているラベルでアクセス可能になるように貼り直されます。通常、level
セクションのみ設定する必要があります。 これはPod内の全てのボリュームとコンテナに対しMulti-Category Security (MCS)ラベルを設定します。
警告:
Podに対してMCSラベルを指定すると、同じラベルを持つ全てのPodがボリュームにアクセスすることができます。 Pod内の保護が必要な場合、それぞれのPodに対して一意なMCSラベルを割り当ててください。クリーンアップ
Podを削除します。
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
次の項目
- PodSecurityContext
- SecurityContext
- 最新の強化されたセキュリティでDockerを調整する
- Security Contexts design document
- Ownership Management design document
- PodSecurity Admission
- AllowPrivilegeEscalation design document
- Linuxのセキュリティについてさらに知りたい場合は、Overview of Linux Kernel Security Featuresを確認してください(注: 一部の情報は古くなっています)。
- Linux pods向けのUser Namespacesについて確認してください。
- Masked Paths in the OCI Runtime Specification
このページの項目は、Kubernetesが必要とする機能を提供するサードパーティー製品またはプロジェクトです。Kubernetesプロジェクトの作者は、それらのサードパーティー製品またはプロジェクトに責任を負いません。詳しくは、CNCFウェブサイトのガイドラインをご覧ください。第三者のリンクを追加するような変更を提案する前に、コンテンツガイドを読むべきです。