コンテナ技術の基礎（3）namespaceとcgroupで下から見るKubernetes

Kubeneresとcgroups

Kubernetesでコンテナのリソースの上限を指定するのに使われるlimitはcgroupを使って実現されています。

      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
        resources:
          limits:
            cpu: 100m
            memory: 125Mi
          requests:
            cpu: 90m
            memory: 115Mi

nginxのmasterプロセスのPIDは14611でした。このプロセスのcgroupがどこに定義されているかは、/proc/プロセスID/cgroupを見れば分かります。

cat /proc/14611/cgroup

7:memory:/kubepods/burstable/pod0684166a-df5e-4c54-b489-5b1e3c38dd1d/f66dd3c1e442f0da10aaf0d6954fcafa4d3533da5f3bb597ca7003c66bbb437d
3:cpu,cpuacct:/kubepods/burstable/pod0684166a-df5e-4c54-b489-5b1e3c38dd1d/f66dd3c1e442f0da10aaf0d6954fcafa4d3533da5f3bb597ca7003c66bbb437d
CPU

まずは、CPUから確認していきましょう。cgroupのtasksをみると、nginxのmasterプロセスの14611とworkerプロセスの14656が対象になっています。

cat /hostroot/sys/fs/cgroup/cpu,cpuacct/kubepods/burstable/pod0684166a-df5e-4c54-b489-5b1e3c38dd1d/f66dd3c1e442f0da10aaf0d6954fcafa4d3533da5f3bb597ca7003c66bbb437d/tasks

14611
14656

limitのcpu: 100mは以下の2つの値で表現されています。

cpu.cfs_quota_us 10000
cpu.cfs_period_us 100000
cat /hostroot/sys/fs/cgroup/cpu,cpuacct/kubepods/burstable/pod0684166a-df5e-4c54-b489-5b1e3c38dd1d/f66dd3c1e442f0da10aaf0d6954fcafa4d3533da5f3bb597ca7003c66bbb437d/cpu.cfs_quota_us

10000
cat /hostroot/sys/fs/cgroup/cpu,cpuacct/kubepods/burstable/pod0684166a-df5e-4c54-b489-5b1e3c38dd1d/f66dd3c1e442f0da10aaf0d6954fcafa4d3533da5f3bb597
ca7003c66bbb437d/cpu.cfs_period_us
100000
メモリ

次に、メモリを確認します。memory.limit_in_bytesを見てみると131072000と出てきますね。計算すると分かりますが、これは125MBのことです。想定どおり、limitの値が反映されていることが分かります。

cat /hostroot/sys/fs/cgroup/memory/kubepods/burstable/pod0684166a-df5e-4c54-b489-5b1e3c38dd1d/f66dd3c1e442f0da10aaf0d6954fcafa4d3533da5f3bb597ca700

3c66bbb437d/memory.limit_in_bytes
131072000
KubeneresとCapability

確認したように、User namespaceは分離されていません。したがって、ホストのrootはコンテナのrootと違うものではありません。その状態でコンテナの権限を制限しているのはCapabilityです。nginxのプロセスのCapabilityを確認してみましょう。getcapsコマンドを使います。

nginxのプロセスには、cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcapだけを許可されていることが分かります。

$ nsenter --target 1 --all
$ getpcaps 1
Capabilities for 1': = cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read+ep
$ getpcaps 14611
Capabilities for14611': = cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap+eip

許可されているものの一覧は、以下になります。説明はMan page of CAPABILITIESからの引用です。

許可されているものの一覧は、以下になります。説明はMan page of CAPABILITIESからの引用です。

今回は、コンテナセキュリティを学ぶ上での基礎となる技術について説明しました。次回は、Kubernetes クラスタの保護について説明します。