概要
- Podにconfigmapでマウントした設定ファイルのパーミッション・所有者が何なのか疑問に思ったので調べてみた
環境
- minikube version: 1.33.1
- Ubuntu 22.04.4 LTS（WSL）
- Kubernetes v1.30.0
調べる範囲
- 調べないこと
- dockerfile等でイメージから所有者・グループ・パーミッションを変更する方法
- KubernetesでPodを起動する際にcommandとかでShellを実行して更新する方法
- 調べること
- KubernetesのPodのマニフェストの書き方で所有者・グループ・パーミッションを変更する方法
調べた結果
- Pod内部で公開される前に、ボリュームの所有権とパーミッションは、
fsGroupChangePolicy:Always(デフォルト)が設定されていることで更新されているようです- ※secret、ConfigMap、emptyDir などの一時ボリュームタイプは適用外
。
-
Podのグループや所有者について
- 調べてみるとsecurityContext でグループや所有者を設定できるみたい
- 注意点としては、以下なので元からあるファイルやディレクトリは、変更されないようです
- 既存ファイルには影響は与えない
- 新規ファイルはこの設定が反映される
- もし、既存を変更したい際には、dockerfileやcommandとかで変更する方法が必要ですね
-
所有者・グループの一覧
| 値 | 意味 |
|---|---|
| runAsUser | Pod内のコンテナに対して全てのプロセス実行するユーザを設定 |
| runAsGroup | Pod内のコンテナに対して全てのプロセスをプライマリーグループを設定 |
| fsGroup | 全てのコンテナ内のプロセスは補助グループを設定 |
-
パーミッションについて
- パーミッションについて、Kubernetesの公式サイトで明確に記載されている
箇所を見つけることはできませんでしたがconfigMap を explain コマンドで確認すると以下のようです。- defaultMode でパーミッションを任意に設定可能
- ※emptyDir のボリュームは、defaultModeは設定できない
- デフォルトは0644
- defaultMode でパーミッションを任意に設定可能
- パーミッションについて、Kubernetesの公式サイトで明確に記載されている
-
詳細は以下ドキュメントとexplain コマンドで確認した結果が参考になりました
-
explain コマンド結果
#runAsUser
tech-0222@MSI:~$ kubectl explain pod.spec.securityContext.runAsUser
KIND: Pod
VERSION: v1
FIELD: runAsUser <integer>
DESCRIPTION:
The UID to run the entrypoint of the container process. Defaults to user
specified in image metadata if unspecified. May also be set in
SecurityContext. If set in both SecurityContext and PodSecurityContext, the
value specified in SecurityContext takes precedence for that container. Note
that this field cannot be set when spec.os.name is windows.
tech-0222@MSI:~$
#翻訳
コンテナプロセスのエントリーポイントを実行するためのUID（ユーザーID）です。
指定されていない場合は、イメージのメタデータで指定されたユーザーがデフォルトで使用されます。
SecurityContextでも設定可能で、SecurityContextとPodSecurityContextの両方で設定されている場合、
そのコンテナにはSecurityContextの値が優先されます。
なお、このフィールドはspec.os.nameがWindowsの場合には設定できません。
#runAsGroup
tech-0222@MSI:~$ kubectl explain pod.spec.securityContext.runAsGroup
KIND: Pod
VERSION: v1
FIELD: runAsGroup <integer>
DESCRIPTION:
The GID to run the entrypoint of the container process. Uses runtime default
if unset. May also be set in SecurityContext. If set in both
SecurityContext and PodSecurityContext, the value specified in
SecurityContext takes precedence for that container. Note that this field
cannot be set when spec.os.name is windows.
tech-0222@MSI:~$
#翻訳
コンテナプロセスのエントリーポイントを実行するためのGID（グループID）です。
設定されていない場合は、ランタイムのデフォルトが使用されます。
また、SecurityContextで設定することも可能です。SecurityContextとPodSecurityContextの両方で設定されている場合、
そのコンテナに対してはSecurityContextの値が優先されます。
なお、このフィールドはspec.os.nameがWindowsの場合には設定できません。
#fsGroup
tech-0222@MSI:~$ kubectl explain pod.spec.securityContext.fsGroup
KIND: Pod
VERSION: v1
FIELD: fsGroup <integer>
DESCRIPTION:
A special supplemental group that applies to all containers in a pod. Some
volume types allow the Kubelet to change the ownership of that volume to be
owned by the pod:
1. The owning GID will be the FSGroup 2. The setgid bit is set (new files
created in the volume will be owned by FSGroup) 3. The permission bits are
OR'd with rw-rw----
If unset, the Kubelet will not modify the ownership and permissions of any
volume. Note that this field cannot be set when spec.os.name is windows.
tech-0222@MSI:~$
#翻訳
説明:
Pod内のすべてのコンテナに適用される特別な補助グループです。
一部のボリュームタイプでは、Kubeletがそのボリュームの所有権をPodが所有するように変更できます。
所有するGIDはFSGroupになります。
setgidビットが設定され、ボリューム内の新しいファイルはFSGroupによって所有されます。
パーミッションビットはrw-rw----で論理和が取られます。
このフィールドが設定されていない場合、Kubeletは所有権やパーミッションを変更しません。
spec.os.nameがWindowsの場合、このフィールドは設定できません。
$
tech-0222@MSI:~$ kubectl explain pod.spec.volumes.configMap.defaultMode
KIND: Pod
VERSION: v1
FIELD: defaultMode <integer>
DESCRIPTION:
defaultMode is optional: mode bits used to set permissions on created files
by default. Must be an octal value between 0000 and 0777 or a decimal value
between 0 and 511. YAML accepts both octal and decimal values, JSON requires
decimal values for mode bits. Defaults to 0644. Directories within the path
are not affected by this setting. This might be in conflict with other
options that affect the file mode, like fsGroup, and the result can be other
mode bits set.
tech-0222@MSI:~$
#和訳
defaultModeは任意設定であり、作成されるファイルにデフォルトで設定されるパーミッションビットを指定します。
値は0000から0777の8進数、または0から511の10進数で指定します。
YAMLでは8進数と10進数の両方が許容されますが、JSONでは10進数が必要です。デフォルトは0644です。
この設定はパス内のディレクトリには影響しません。
また、fsGroupなど他のファイルモードに影響を与えるオプションと競合する可能性があり、
その結果として異なるモードビットが設定されることがあります。
tech-0222@MSI:~$
tech-0222@MSI:~$ kubectl explain pod.spec.securityContext.fsGroupChangePolicy
KIND: Pod
VERSION: v1
FIELD: fsGroupChangePolicy <string>
ENUM:
Always
OnRootMismatch
DESCRIPTION:
fsGroupChangePolicy defines behavior of changing ownership and permission of
the volume before being exposed inside Pod. This field will only apply to
volume types which support fsGroup based ownership(and permissions). It will
have no effect on ephemeral volume types such as: secret, configmaps and
emptydir. Valid values are "OnRootMismatch" and "Always". If not specified,
"Always" is used. Note that this field cannot be set when spec.os.name is
windows.
Possible enum values:
- `"Always"` indicates that volume's ownership and permissions should
always be changed whenever volume is mounted inside a Pod. This the default
behavior.
- `"OnRootMismatch"` indicates that volume's ownership and permissions will
be changed only when permission and ownership of root directory does not
match with expected permissions on the volume. This can help shorten the
time it takes to change ownership and permissions of a volume.
#和訳
fsGroupChangePolicyは、Pod内部で公開される前に、ボリュームの所有権とパーミッションの変更動作を定義します。
このフィールドは、fsGroup ベースの所有権 (およびパーミッション) をサポートするボリュームタイプにのみ適用されます。
シークレット、ConfigMap、emptyDir などの一時ボリュームタイプには影響しません。
有効な値は "OnRootMismatch" と "Always" です。指定されていない場合は "Always" が使用されます。
spec.os.name が windows の場合は、このフィールドを設定できません。
考えられる列挙値:
"Always": ボリュームが Pod 内にマウントされるたびに、ボリュームの所有権とパーミッションを常に変更するように指示します。
これがデフォルトの動作です。
"OnRootMismatch": ボリュームのルートディレクトリのパーミッションと所有権が、ボリュームで期待されるパーミッションと一致しない場合のみ、
ボリュームの所有権とパーミッションが変更されるように指示します。
これにより、ボリュームの所有権とパーミッションを変更する時間を短縮することができる場合があります。
tech-0222@MSI:~$ kubectl explain pod.spec.volumes.emptyDir
KIND: Pod
VERSION: v1
FIELD: emptyDir <EmptyDirVolumeSource>
DESCRIPTION:
emptyDir represents a temporary directory that shares a pod's lifetime. More
info: https://kubernetes.io/docs/concepts/storage/volumes#emptydir
Represents an empty directory for a pod. Empty directory volumes support
ownership management and SELinux relabeling.
FIELDS:
medium <string>
medium represents what type of storage medium should back this directory.
The default is "" which means to use the node's default medium. Must be an
empty string (default) or Memory. More info:
https://kubernetes.io/docs/concepts/storage/volumes#emptydir
sizeLimit <Quantity>
sizeLimit is the total amount of local storage required for this EmptyDir
volume. The size limit is also applicable for memory medium. The maximum
usage on memory medium EmptyDir would be the minimum value between the
SizeLimit specified here and the sum of memory limits of all containers in a
pod. The default is nil which means that the limit is undefined. More info:
https://kubernetes.io/docs/concepts/storage/volumes#emptydir
tech-0222@MSI:~$やってみる
テスト用でPODを起動して、実際の動作を確認してみたいと思います
PODを起動してsecurityContext設定の有り・無しの状態でファイルやディレクトリを作成してみる
securityContext 無しのPodを確認してみる
- テスト環境をデプロイする
- Podにセキュリティコンテキストを設定するをベースにsecurityContextの箇所を削除
# テスト用マニフェスト
tech-0222@MSI:tmp$ cat demo.yaml
apiVersion: v1
kind: Pod
metadata:
name: demo
spec:
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
tech-0222@MSI:tmp$
# デプロイ
tech-0222@MSI:tmp$ kubectl apply -f demo.yaml
pod/demo created
tech-0222@MSI:tmp$
tech-0222@MSI:tmp$ kubectl get po demo
NAME READY STATUS RESTARTS AGE
demo 1/1 Running 0 6s
- 実行ユーザは何か調べてみましょう
- ベースはrootで実行されるみたいですね
# コンテナにログイン
tech-0222@MSI:tmp$ kubectl exec demo -it -- sh
/ #
#プロセスはrootで起動してますね
/ # ps
PID USER TIME COMMAND
1 root 0:00 sleep 1h
13 root 0:00 sh
19 root 0:00 ps
/ #
#デフォルトはroot
/ # id
uid=0(root) gid=0(root) groups=0(root),10(wheel)
/ #
/ # whoami
root
#ディレクトリの所有者・グループがroot
/ # ls -la
total 48
drwxr-xr-x 1 root root 4096 Aug 9 21:34 .
drwxr-xr-x 1 root root 4096 Aug 9 21:34 ..
-rwxr-xr-x 1 root root 0 Aug 9 21:34 .dockerenv
drwxr-xr-x 2 root root 12288 May 22 2018 bin
drwxr-xr-x 3 root root 4096 Aug 9 21:34 data
drwxr-xr-x 5 root root 360 Aug 9 21:34 dev
drwxr-xr-x 1 root root 4096 Aug 9 21:34 etc
drwxr-xr-x 2 nobody nogroup 4096 May 22 2018 home
dr-xr-xr-x 362 root root 0 Aug 9 21:34 proc
drwx------ 1 root root 4096 Aug 9 21:58 root
dr-xr-xr-x 11 root root 0 Aug 8 22:21 sys
drwxrwxrwt 1 root root 4096 Aug 9 21:34 tmp
drwxr-xr-x 3 root root 4096 May 22 2018 usr
drwxr-xr-x 1 root root 4096 Aug 9 21:34 var
/ #
- 所有者・グループ・パーミションを確認すると以下でした
- volumesでマウントしたディレクトリは、umaskの設定と違うみたいですね
- 結果
| 対象 | 所有者 | グループ | パーミッション |
|---|---|---|---|
| マウントvolumes（/data/demo/） | root | root | 777 |
| 新規ファイル（testfile） | root | root | 644 |
| 新規ディレクトリ（testdir） | root | root | 755 |
- umask コマンドについての詳細は以下が参考になります
#マウントしたディレクトリ
/ # ls -la /data/
total 12
drwxr-xr-x 3 root root 4096 Aug 9 21:34 .
drwxr-xr-x 1 root root 4096 Aug 9 21:34 ..
drwxrwxrwx 2 root root 4096 Aug 8 22:21 demo
/ # ls -la /data/demo/
total 8
drwxrwxrwx 2 root root 4096 Aug 8 22:21 .
drwxr-xr-x 3 root root 4096 Aug 9 21:34 ..
/ #
/ # cd /data/demo/
/data/demo #
/data/demo # ls -la
total 8
drwxrwxrwx 2 root root 4096 Aug 8 22:21 .
drwxr-xr-x 3 root root 4096 Aug 9 21:34 ..
/data/demo #
#ファイル作成
/data/demo # echo hello > testfile
/data/demo #
/data/demo # ls -la
total 12
drwxrwxrwx 2 root root 4096 Aug 9 21:59 .
drwxr-xr-x 3 root root 4096 Aug 9 21:34 ..
-rw-r--r-- 1 root root 6 Aug 9 21:59 testfile
/data/demo #
#ディレクトリ作成
/data/demo # mkdir testdir
/data/demo #
/data/demo # ls -la
total 16
drwxrwxrwx 3 root root 4096 Aug 9 22:23 .
drwxr-xr-x 3 root root 4096 Aug 9 21:34 ..
drwxr-xr-x 2 root root 4096 Aug 9 22:23 testdir
-rw-r--r-- 1 root root 6 Aug 9 21:59 testfile
/data/demo #
#パーミッション設定値を確認
/ # umask
0022
/ #
/ # v
/ # umask -S
u=rwx,g=rx,o=rx
/ #
/ #securityContext 有りのPodを確認してみる
- テスト環境をデプロイする
- Podにセキュリティコンテキストを設定するのサンプルをベースに名前だけ修正したもの
tech-0222@MSI:tmp$ cat security-demo.yaml
apiVersion: v1
kind: Pod
metadata:
name: security-demo
spec:
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
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
tech-0222@MSI:tmp$
tech-0222@MSI:tmp$ kubectl apply -f security-demo.yaml
pod/security-demo created
tech-0222@MSI:tmp$
tech-0222@MSI:tmp$ kubectl get po security-demo
NAME READY STATUS RESTARTS AGE
security-demo 1/1 Running 0 2m41s
tech-0222@MSI:tmp$- 実行ユーザは何か調べてみましょう
- プロセスが、runAsUser で設定したIDの1000 で実行されてますね
tech-0222@MSI:tmp$ kubectl exec security-demo -it -- /bin/sh
/ $
# プロセスの実行ユーザの確認
/ $ ps
PID USER TIME COMMAND
1 1000 0:00 sleep 1h
7 1000 0:00 /bin/sh
13 1000 0:00 ps
/ $
#ユーザ、グループを確認
/ $ id
uid=1000 gid=3000 groups=2000,3000
/ $
/ $ whoami
whoami: unknown uid 1000
/ $
tech-0222@MSI:tmp$ kubectl exec security-demo -it -- /bin/sh
/ $ ls -la
total 48
drwxr-xr-x 1 root root 4096 Aug 11 02:09 .
drwxr-xr-x 1 root root 4096 Aug 11 02:09 ..
-rwxr-xr-x 1 root root 0 Aug 11 02:09 .dockerenv
drwxr-xr-x 2 root root 12288 May 22 2018 bin
drwxr-xr-x 3 root root 4096 Aug 11 02:09 data
drwxr-xr-x 5 root root 360 Aug 11 02:09 dev
drwxr-xr-x 1 root root 4096 Aug 11 02:09 etc
drwxr-xr-x 2 nobody nogroup 4096 May 22 2018 home
dr-xr-xr-x 366 root root 0 Aug 11 02:09 proc
drwx------ 2 root root 4096 May 22 2018 root
dr-xr-xr-x 11 root root 0 Aug 11 02:09 sys
drwxrwxrwt 2 root root 4096 May 22 2018 tmp
drwxr-xr-x 3 root root 4096 May 22 2018 usr
drwxr-xr-x 1 root root 4096 Aug 11 02:09 var
/ $
# runAsUser、runAsGroup、fsGroup で設定したユーザ、グループが増えているわけではない
/ $ cat /etc/passwd
root:x:0:0:root:/root:/bin/sh
daemon:x:1:1:daemon:/usr/sbin:/bin/false
bin:x:2:2:bin:/bin:/bin/false
sys:x:3:3:sys:/dev:/bin/false
sync:x:4:100:sync:/bin:/bin/sync
mail:x:8:8:mail:/var/spool/mail:/bin/false
www-data:x:33:33:www-data:/var/www:/bin/false
operator:x:37:37:Operator:/var:/bin/false
nobody:x:65534:65534:nobody:/home:/bin/false
/ $ cat /etc/group
root:x:0:
daemon:x:1:
bin:x:2:
sys:x:3:
adm:x:4:
tty:x:5:
disk:x:6:
lp:x:7:
mail:x:8:
kmem:x:9:
wheel:x:10:root
cdrom:x:11:
dialout:x:18:
floppy:x:19:
video:x:28:
audio:x:29:
tape:x:32:
www-data:x:33:
operator:x:37:
utmp:x:43:
plugdev:x:46:
staff:x:50:
lock:x:54:
netdev:x:82:
users:x:100:
nogroup:x:65534:
/ $ - 所有者・グループ・パーミションを確認すると以下でした
- ドキュメント通り、新規は所有者とグループがsecurityContext の設定に変わってますね
| 対象 | 所有者 | グループ | パーミッション |
|---|---|---|---|
| マウントvolumes（/data/demo/） | root | 2000 | 777 |
| 新規ファイル（testfile） | 1000 | 2000 | 644 |
| 新規ディレクトリ（testdir） | 1000 | 2000 | 2755 |
- パーミションの「s」が setgidビットなので、このパーミッション（2755）です
- 詳細は以下が参考になります
/ $
/ $ ls -la /data/
total 12
drwxr-xr-x 3 root root 4096 Aug 11 02:09 .
drwxr-xr-x 1 root root 4096 Aug 11 02:09 ..
drwxrwsrwx 2 root 2000 4096 Aug 11 02:09 demo
/ $ ls -la /data/demo/
total 8
drwxrwsrwx 2 root 2000 4096 Aug 11 02:09 .
drwxr-xr-x 3 root root 4096 Aug 11 02:09 ..
/ $umask
0022
/ $
/ $ umask -S
u=rwx,g=rx,o=rx
/ $
/ $ cd /data/demo/
/data/demo $ pwd
/data/demo
#fsGroupで指定した値であるグループID 2000でtestfileが作成されていることが確認できます。
/data/demo $ echo hello > testfile
/data/demo $ ls -la
total 12
drwxrwsrwx 2 root 2000 4096 Aug 11 02:11 .
drwxr-xr-x 3 root root 4096 Aug 11 02:09 ..
-rw-r--r-- 1 1000 2000 6 Aug 11 02:11 testfile
/data/demo $ mkdir testdir
/data/demo $
/data/demo $ ls -la
total 16
drwxrwsrwx 3 root 2000 4096 Aug 11 02:11 .
drwxr-xr-x 3 root root 4096 Aug 11 02:09 ..
drwxr-sr-x 2 1000 2000 4096 Aug 11 02:11 testdir
-rw-r--r-- 1 1000 2000 6 Aug 11 02:11 testfile
/data/demo $
PODを起動してconfigmapのファイルをマウントしてsecurityContext設定の有り・無しの状態を確認してみる
configmapでファイルをマウントした際にPodでどんな変化があるか、確認してみたいと思います
テスト環境の準備
- configmapにテスト用のファイルを準備する
tech-0222@MSI:tmp$ echo "test data" > test-file
tech-0222@MSI:tmp$
tech-0222@MSI:tmp$ cat test-file
test data
tech-0222@MSI:tmp$- configmapにする
tech-0222@MSI:tmp$ kubectl create cm test --from-file=test-file --dry-run=client -o yaml
apiVersion: v1
data:
test-file: |
test data
kind: ConfigMap
metadata:
creationTimestamp: null
name: test
tech-0222@MSI:tmp$
tech-0222@MSI:tmp$ kubectl create cm test --from-file=test-file
configmap/test created
tech-0222@MSI:tmp$
tech-0222@MSI:tmp$ kubectl get cm
NAME DATA AGE
kube-root-ca.crt 1 11d
test 1 8s
tech-0222@MSI:tmp$securityContext 無しのPodを確認してみる
- 以下を参考にテスト用のyamlにconfigmapでファイルをマウントする設定を追記してデプロイします
tech-0222@MSI:tmp$ cat demo-2.yaml
apiVersion: v1
kind: Pod
metadata:
name: demo-2
spec:
volumes:
- name: sec-ctx-vol
emptyDir: {}
- name: test-data
configMap:
name: test
containers:
- name: sec-ctx-demo
image: busybox:1.28
command: [ "sh", "-c", "sleep 1h" ]
volumeMounts:
- name: sec-ctx-vol
mountPath: /data/demo
- name: test-data
mountPath: /tmp/test-file
subPath: test-file
tech-0222@MSI:tmp$
tech-0222@MSI:tmp$ kubectl apply -f demo-2.yaml
pod/demo-2 created
tech-0222@MSI:tmp$
tech-0222@MSI:tmp$ kubectl get po demo-2
NAME READY STATUS RESTARTS AGE
demo-2 1/1 Running 0 11s
tech-0222@MSI:tmp$- securityContext がない状態だと以下で、umaskの設定通りですね
| 対象 | 所有者 | グループ | パーミッション |
|---|---|---|---|
| マウントファイル（test-file） | root | root | 644 |
#所有者・グループはrootでパーミッションは644ですね
tech-0222@MSI:tmp$ kubectl exec demo-2 -it -- /bin/sh
/ # ls -dl tmp/
drwxrwxrwt 1 root root 4096 Aug 11 02:13 tmp/
/ # ls -la tmp/
total 12
drwxrwxrwt 1 root root 4096 Aug 11 02:13 .
drwxr-xr-x 1 root root 4096 Aug 11 02:13 ..
-rw-r--r-- 1 root root 10 Aug 11 02:13 test-file
/ #
/ # cat tmp/test-file
test data
/ #
securityContext 有りのPodを確認してみる
- これもテスト用のyamlを修正してデプロイします
tech-0222@MSI:tmp$ cat security-demo-2.yaml
apiVersion: v1
kind: Pod
metadata:
name: security-demo-2
spec:
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
volumes:
- name: sec-ctx-vol
emptyDir: {}
- name: test-data
configMap:
name: test
containers:
- name: sec-ctx-demo
image: busybox:1.28
command: [ "sh", "-c", "sleep 1h" ]
volumeMounts:
- name: sec-ctx-vol
mountPath: /data/demo
- name: test-data
mountPath: /tmp/test-file
subPath: test-file
securityContext:
allowPrivilegeEscalation: false
tech-0222@MSI:tmp$
tech-0222@MSI:tmp$ kubectl apply -f security-demo-2.yaml
pod/security-demo-2 created
tech-0222@MSI:tmp$
tech-0222@MSI:tmp$ kubectl get po security-demo-2
NAME READY STATUS RESTARTS AGE
security-demo-2 1/1 Running 0 6m43s
tech-0222@MSI:tmp$- securityContext が有る状態だと以下です
- グループは、securityContextの設定通りで、パーミションはumaskの設定通りですね
| 対象 | 所有者 | グループ | パーミッション |
|---|---|---|---|
| マウントファイル（test-file） | root | 2000 | 644 |
tech-0222@MSI:tmp$ kubectl exec security-demo-2 -it -- /bin/sh
/ $ ls -dl tmp/
drwxrwxrwt 1 root root 4096 Aug 11 02:15 tmp/
/ $
/ $ ls -la tmp/
total 12
drwxrwxrwt 1 root root 4096 Aug 11 02:15 .
drwxr-xr-x 1 root root 4096 Aug 11 02:15 ..
-rw-r--r-- 1 root 2000 10 Aug 11 02:15 test-file
/ $configmapでマウントしたファイルのパーミションを変更してみる
-
configmapでマウントしたファイルは、pod.spec.volumes.configMap.defaultMode でパーミションを変更できるので試してみます
- ※securityContext 有無は関係ないので無しだけで確認
-
テスト用のyamlを修正してデプロイする
- defaultMode: 0777 で設定してみる
tech-0222@MSI:tmp$ cat demo-4.yaml
apiVersion: v1
kind: Pod
metadata:
name: demo-4
spec:
volumes:
- name: sec-ctx-vol
emptyDir: {}
- name: test-data
configMap:
name: test
defaultMode: 0777
containers:
- name: sec-ctx-demo
image: busybox:1.28
command: [ "sh", "-c", "sleep 1h" ]
volumeMounts:
- name: sec-ctx-vol
mountPath: /data/demo
- name: test-data
mountPath: /tmp/test-file
subPath: test-file
tech-0222@MSI:tmp$
tech-0222@MSI:tmp$ kubectl apply -f demo-4.yaml
pod/demo-4 created
tech-0222@MSI:tmp$
tech-0222@MSI:tmp$ kubectl get po demo-4
NAME READY STATUS RESTARTS AGE
demo-4 1/1 Running 0 43s
tech-0222@MSI:tmp$
- PODのマウントファイルを確認すると、644だったパーミションが設定した777に変わってますね
tech-0222@MSI:tmp$ kubectl exec demo-4 -it -- /bin/sh
/ # ls -la
total 48
drwxr-xr-x 1 root root 4096 Aug 11 02:17 .
drwxr-xr-x 1 root root 4096 Aug 11 02:17 ..
-rwxr-xr-x 1 root root 0 Aug 11 02:17 .dockerenv
drwxr-xr-x 2 root root 12288 May 22 2018 bin
drwxr-xr-x 3 root root 4096 Aug 11 02:17 data
drwxr-xr-x 5 root root 360 Aug 11 02:17 dev
drwxr-xr-x 1 root root 4096 Aug 11 02:17 etc
drwxr-xr-x 2 nobody nogroup 4096 May 22 2018 home
dr-xr-xr-x 373 root root 0 Aug 11 02:17 proc
drwx------ 1 root root 4096 Aug 11 02:17 root
dr-xr-xr-x 11 root root 0 Aug 11 02:17 sys
drwxrwxrwt 1 root root 4096 Aug 11 02:17 tmp
drwxr-xr-x 3 root root 4096 May 22 2018 usr
drwxr-xr-x 1 root root 4096 Aug 11 02:17 var
/ #
#パーミッションが777に変わってますね
/ # ls -la tmp/
total 12
drwxrwxrwt 1 root root 4096 Aug 11 02:17 .
drwxr-xr-x 1 root root 4096 Aug 11 02:17 ..
-rwxrwxrwx 1 root root 10 Aug 11 02:17 test-file
/ #
