Red Hatでサポートをしている石川と申します。OpenShift Advent Calendar 2024のエントリです。
近頃すっかり寒くなり、街中がクリスマスムードですね。毎年この時期になると娘のクリスマスプレゼントが悩みの種です。
昨今のプレゼント事情を探るため、娘にお友達はサンタさんに何をお願いしたのか尋ねてみました。すると、「サンタさん」との答え。
なるほど、ランプの精に願い事を増やしてもらう的な...子供の発想は柔軟ですね。
というわけで(?)、今回はそんな柔軟性を提供するネストされたコンテナ (Nested Container)を試してみます。
Linux User Namespaceを使用してNested Containerを起動する
ローカルマシンでコンテナアプリケーションの開発を行う場合、podmanやdockerでいつでもイメージをビルドしてコンテナを実行することができます。しかし、コンテナ上でコンテナを実行する場合、権限の昇格を行うとホストにも同様の権限でアクセスできてしまう問題がありました。これはOpenShift Dev Spacesを使用してコンテナ上で開発を行う際、セキリティの観点から望ましくありません。
また、追加でコンテナを起動する必要があるLocalStackやTestContainersなどのツールを利用するチームではこれはより大きな問題となります。
Linux User Namespaceの使用はそのような問題の解決策となります。
OpenShift 4.17で、Technology preview (TP)機能としてLinux User NamespaceでPodが実行可能になりました。
Linux User Namespaceを使用することで、コンテナはホストとは別のユーザーとグループのマッピングを持つことができるため、コンテナ内ではroot権限でプロセスを実行できますが、ホスト上ではnon-rootユーザーとしてプロセスを実行できます。
Nested Containerのサンプルを試してみる
OpenShift Dev SpacesでNested Containerを使用するサンプルが用意されているので、さっそく試していきます。
※Linux User NamespaceはTP機能ですので、お試しする場合は検証用のクラスターをお使いください。
今回の記事では以下の環境を使用しております。
Red Hat OpenShift Container Platform: 4.17.0 (vSphere IPI)
Red Hat OpenShift Dev Spaces: 3.17.0
DevWorkspace Operator: 0.31.2
ContainerRuntimeConfigでcrunをデフォルトのコンテナランタイムに設定します。今回はMulti Node Clusterのため、workerノードでのみ有効化します。
$ cat << EOF | oc apply -f -
apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
name: enable-crun-worker
spec:
machineConfigPoolSelector:
matchLabels:
pools.operator.machineconfiguration.openshift.io/worker: ""
containerRuntimeConfig:
defaultRuntime: crun
EOF
FeatureGateでProcMountTypeにUserNamespacesSupportを設定します。これにより、クラスターはアップデートを適用できなくなりますのでご注意ください。
$ oc patch FeatureGate cluster --type merge --patch '{"spec":{"featureSet":"CustomNoUpgrade","customNoUpgrade":{"enabled":["ProcMountType","UserNamespacesSupport"]}}}'
OpenShift Dev SpacesでNested Containerを使用するためのSecurityContextConstraint (SCC)を作成します。
$ cat << EOF | oc apply -f -
apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
metadata:
name: nested-podman-scc
priority: null
allowPrivilegeEscalation: true
allowedCapabilities:
- SETUID
- SETGID
fsGroup:
type: MustRunAs
ranges:
- min: 1000
max: 65534
runAsUser:
type: MustRunAs
uid: 1000
seLinuxContext:
type: MustRunAs
seLinuxOptions:
type: container_engine_t
supplementalGroups:
type: MustRunAs
ranges:
- min: 1000
max: 65534
EOF
OpenShift Dev Spaces Operatorをインストールします。既にインストール済みの場合はスキップしてください。
cat << EOF | oc apply -f -
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: devspaces
namespace: openshift-operators
spec:
channel: stable
installPlanApproval: Automatic
name: devspaces
source: redhat-operators
sourceNamespace: openshift-marketplace
EOF
CheClusterを作成し、nested-podman-scc SCCを使用するように設定します。
cat << EOF | oc apply -f -
apiVersion: v1
kind: Namespace
metadata:
name: devspaces
---
apiVersion: org.eclipse.che/v2
kind: CheCluster
metadata:
name: devspaces
namespace: devspaces
spec:
components:
cheServer:
debug: false
logLevel: INFO
metrics:
enable: true
pluginRegistry:
openVSXURL: https://open-vsx.org
containerRegistry: {}
devEnvironments:
startTimeoutSeconds: 600
secondsOfRunBeforeIdling: -1
maxNumberOfWorkspacesPerUser: -1
maxNumberOfRunningWorkspacesPerUser: 5
containerBuildConfiguration:
openShiftSecurityContextConstraint: nested-podman-scc
disableContainerBuildCapabilities: false
defaultComponents:
- name: dev-tools
container:
image: quay.io/cgruver0/che/dev-tools:latest
memoryLimit: 6Gi
mountSources: true
defaultEditor: che-incubator/che-code/latest
defaultNamespace:
autoProvision: true
template: <username>-devspaces
secondsOfInactivityBeforeIdling: 1800
storage:
pvcStrategy: per-workspace
gitServices: {}
networking: {}
EOF
OpenShift Dev Spacesのダッシュボードにログインし、https://github.com/cgruver/ocp-4-17-nested-container-tech-preview.gitリポジトリから新しいワークスペースを作成します。
podmanを使ってnginxをNested Containerとして実行します。ワークスペース上でターミナルを開き、以下を実行します。
podman run -d --rm --name webserver -p 8080:80 quay.io/libpod/banner
curl http://localhost:8080
ワークスペース上でコンテナを実行することができました！
もう少し詳しく調べてみる
ワークスペースのPodがどのように実行されているか調べてみます。今回はkubeadminユーザーを使ったので、Podは che-kube-admin-devspaces-sai8k3 というNamespaceに作成されていました。
$ oc project che-kube-admin-devspaces-sai8k3
Now using project "che-kube-admin-devspaces-sai8k3" on server "https://api.shishika.example.com:6443".
$ oc get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
workspace63b0516a11e94e96-6d8f9d65f-wtch5 2/2 Running 0 100s 10.131.1.175 shishika-fmhq4-worker-0-vtcng <none> <none>
Podのマニフェストを確認すると、hostUsersにfalseが設定されています。この設定により、Pod内のコンテナプロセスはUser Namespaceで動作します。
$ oc get pod workspace63b0516a11e94e96-6d8f9d65f-wtch5 -o yaml | grep hostUser
hostUsers: false
こちらの記事を参考に、User NamespaceにおけるUIDのマッピングを確認してみます。
/proc/self/uid_mapを見ると、コンテナ内のUID 0以降65536個のUIDが、ホスト上のUID 4147052544以降の65536個にマッピングされていることがわかります。
$ oc exec pod/workspace63b0516a11e94e96-6d8f9d65f-wtch5 -- cat /proc/self/uid_map
Defaulted container "dev-tools" out of: dev-tools, che-gateway, che-code-injector (init), project-clone (init)
0 4147052544 65536
該当のworkerノード(shishika-fmhq4-worker-0-vtcng)でPIDを調べます。
$ oc debug node/shishika-fmhq4-worker-0-vtcng -- chroot /host systemd-cgls -u kubepods-burstable-pod$(oc get pod workspace63b0516a11e94e96-6d8f9d65f-wtch5 -n che-kube-admin-devspaces-sai8k3 -o json | jq -r .metadata.uid | tr '-' '_').slice
Starting pod/shishika-fmhq4-worker-0-vtcng-debug-lbxrq ...
To use host binaries, run `chroot /host`
Unit kubepods-burstable-pod18233744_03cc_41b3_b4ad_1b6fafb2683f.slice (/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod18233744_03cc_41b3_b4ad_1b6fafb2683f.slice):
├─crio-conmon-56486d4e7b520bda967cd1b8174f1f1765def93e3229a3883759f27f9e684f62.scope … (#756473)
│ → user.delegate: 1
│ → trusted.delegate: 1
│ └─3689199 /usr/bin/conmon -b /run/containers/storage/overlay-containers/56486…
├─crio-conmon-4ae52e245b24e61f20a957b596e4f105ae0ea2e0019d3ce66d663347033e7708.scope … (#756681)
│ → user.delegate: 1
│ → trusted.delegate: 1
│ └─3689333 /usr/bin/conmon -b /run/containers/storage/overlay-containers/4ae52…
├─crio-56486d4e7b520bda967cd1b8174f1f1765def93e3229a3883759f27f9e684f62.scope … (#756544)
│ → user.delegate: 1
│ → trusted.delegate: 1
│ └─container (#756615)
│ ├─3689202 bash /entrypoint.sh tail -f /dev/null
│ ├─3689211 /bin/sh /checode/entrypoint-volume.sh
│ ├─3689222 /checode/bin/machine-exec --url 0.0.0.0:3333
│ ├─3689230 /usr/libexec/podman/catatonit -- tail -f /dev/null
│ ├─3689237 /usr/bin/coreutils --coreutils-prog-shebang=tail /usr/bin/tail -f…
│ ├─3689257 /checode/checode-linux-libc/ubi9/node ./launcher/entrypoint.js
│ ├─3689317 /checode/checode-linux-libc/ubi9/node out/server-main.js --host 1…
│ ├─3689766 /checode/checode-linux-libc/ubi9/node --dns-result-order=ipv4firs…
│ ├─3689836 /checode/checode-linux-libc/ubi9/node /checode/checode-linux-libc…
│ ├─3689930 /checode/checode-linux-libc/ubi9/node /checode/checode-linux-libc…
│ ├─3690025 /usr/bin/bash --init-file /checode/checode-linux-libc/ubi9/out/vs…
│ ├─3690498 catatonit -P
│ ├─3690708 /usr/bin/fuse-overlayfs -o lowerdir=/home/user/.local/share/conta…
│ ├─3690709 /usr/bin/slirp4netns --disable-host-loopback --mtu=65520 --enable…
│ ├─3690713 rootlessport
│ ├─3690719 rootlessport-child
│ ├─3690728 /usr/bin/conmon --api-version 1 -c 084108646a267f3cb83ca51716cf52…
│ ├─3690730 nginx: master process nginx -g daemon off;
│ ├─3690733 nginx: worker process
│ ├─3690734 nginx: worker process
│ ├─3690735 nginx: worker process
│ ├─3690736 nginx: worker process
│ ├─3690737 nginx: worker process
│ ├─3690738 nginx: worker process
│ ├─3690739 nginx: worker process
│ └─3690740 nginx: worker process
└─crio-4ae52e245b24e61f20a957b596e4f105ae0ea2e0019d3ce66d663347033e7708.scope … (#756752)
→ user.delegate: 1
→ trusted.delegate: 1
└─container (#756823)
└─3689336 /traefik
ワークスペースのコンテナはPID 3689202以降、nginxはworker processとしてPID 3690733以降で実行されているようです。
最後にノード上でそれぞれのプロセスを実行しているUIDを確認します。
# ps -o user= -p 3689202
4147053544
# ps -o user= -p 3690733
4147053644
どちらも /proc/self/uid_map で確認したUIDの範囲内で動いていることが確認できました。
今回はここまで！