OSSのセキュリティや開発ツール、実行基盤などの最前線の最新情報・動向が得られる ―「DevConf.cz 2020」レポート

「DevConf.cz」は、チェコのブルノ(Brno)にてRed Hatをスポンサーとして毎年開催されているOSSコミュニティイベントだ。Red Hatのコミュニティ開発者が一堂に会する場でもあるため、同社が主導するOSSプロジェクトであるOpenShift、Fedora、JBoss等の開発の最前線を体感できるイベントである。

今年は、2020年1月24～26の3日間、ブルノ工科大学(Brno University of Technology)のキャンパスにて開催された。3日間で273のセッションがあり、最新の技術紹介からコミュニティの運営まで幅広い分野が取り扱われた。約1600人が参加し、終始会場はにぎわっていた。また、参加のための事前登録が登録開始からわずか36時間で全て埋まってしまうなど、非常に人気が高い。

DevConf.czの会場となったブルノ工科大学

行われたセッションはコンテナ関連や開発ツールに関するものが多く、これらは聴講者の入りも多かった。本稿では、多数行われたセッションのうち、コンテナやOSレベルのセキュリティに関するセッションと、認証OSS(Keycloak)に関するセッションを紹介する。

あのDan Walsh氏が登場! 「State of Container Security」

Daniel Walsh氏は、SELinuxの開発と普及活動において古くからの第一人者であり、昔からSELinuxに携わっている方ならばご存知であろうかと思う。彼はRed Hatのコンテナセキュリティの第一人者でもある。キーノートの会場が使われ、多数の聴講者が参加(300人超はいたように思われる)した。SELinux等Linuxカーネルセキュリティ機能を用いたコンテナ周りのセキュリティの最新動向について解説した。

まず、残念ながらコンテナにおいてセキュリティは無効にされていることが多いことが紹介された。

残念ながらSELinuxは無効にされていることが多い

例えば、「setenforce 0」(SELinuxを無効)にするコマンドも未だに多く使われている。セキュリティを最大限固められるようにしつつも、それだとセキュリティを無効にされてしまうため、本講演では「無効にされないようにするにはどうすれば良いか」というところが多く語られた。

また、コンテナセキュリティの原則として、Dockerに見られるような巨大なデーモンは問題であると指摘(SELinuxのような仕掛けを使ってもrootに近い権限を与えざるを得ないことから)。そこで、Red Hat Enterprise Linux(RHEL)では、Dockerのデーモン相当のものをpodman、skopeo、buildahに分割している(これらはRed Hatが主導するOSSプロジェクト)。本講演でもこれらが前提であり、Dockerとセキュリティ上の理由から決別していることが強調されていた。

以降では、コンテナセキュリティのための基盤技術が紹介された。

特権の分割：capability

Linuxのrootが持つ権限を分割して与えるための古くある考え方であり、現在では37種類がある。RHEL・OpenShiftのコンテナでは、以下の14種類のcapabilityがデフォルトで有効になっている。元々はDocker Projectでそうなっていたものを踏襲している形だ。

audit_write、chown、dac_override、fowner、fsetid、kill、mknod、net_bind_service、net_raw、setfcap、setgid、setpcap、setuid、sys_chroot

ここで、net_rawがデフォルトで与えられていることが緩いと思われる。pingで必要なためだが、古くから攻撃に利用されている。podmanでは一部のネットワークにのみnet_rawのcapabilityを付与可能、という設定もできるようになっている。また、開発者側で、イメージのビルド時に、必要なcapabilityのみセットできる機能もある。

ファイルシステムセキュリティ：SELinux

主にファイルシステムのセキュリティ(コンテナ→ホストへのアクセスの制限)として位置付けられている。本セッションでも紹介されたが、後述の「Custom SELinux container policies in OpenShift」セッションにて詳しく紹介するため、ここでは割愛する。

Communicationの制御：seccomp

Linuxカーネルのシステムコールの利用を制限する機能である。コンテナとLinuxカーネルとのcommunicationを制限する位置付けだ。デフォルトで使えるシステムコールは/usr/share/seccomp.jsonで設定されており、450あるシステムコールのうち300が使えるようになっている(32bit システムコールは使えないようになっている)。

なお、ある調査によるとアプリケーションあたり40～70個のシステムコールしか使われていないという説があるため、固くしようとすればさらに固めることも可能である。コンテナに必要最小限のシステムコールのみ許可するために、「oci-seccomp-bpf-hook」というツールでコンテナに使われているシステムコールを調査した上で、コンテナビルド時に必要なシステムコールのみを記載したseccomp.jsonを入れる、という手順が紹介された。

name space

rootをなくすためのLinuxカーネル機能である。一見root(uid=0)で動いているように見えるが、コンテナごとのname spaceを分けることで、各コンテナが実は違うuidで動いている状態にできる。つまりコンテナ間の分離を強化できるのだ(現状コンテナの分離はSELinuxのポリシーでも可能)。

podmanとしてはname spaceをサポートしているが、Kubernetesには十分に対応していないため、今後の課題であるとした。暫定的な対応策としてpodmanのuserns=auto機能が紹介されていた。

Podmanのnamespace対応

その他、コンテナセキュリティの新たな設定ファイルとして、containers.confというファイルを設けようとしているが、詳細はこれからである。

今回紹介されたpodmanなどのDocker代替ツールのセキュリティ機能については、Dockerにはないものが出てきており、セキュリティ面で独自に進化を遂げていることが伺えるものであった。Red HatもOpenShiftの差別化要素として打ち出しているように思われ、セキュアなコンテナ環境を構築・運用していく上でも要ウォッチである。

SELinuxの実績と開発状況
「Custom SELinux container policies in OpenShift」

Red HatのLukas Vrabec氏とJuan Antonio Osorio Roblesが登壇。前半はLukas氏よりコンテナ向けのSELinuxの最新状況が紹介された。Lukas氏は、Dan Walsh氏に続く二代目のSELinuxのエバンジェリストで、Red Hatチェコに所属している。

SELinuxが実際に役立った事例紹介

最初に、SELinuxのコンテナの主要な役割である、コンテナとホストの分離について紹介。SELinuxにより、コンテナのプロセスは/usr以下の読み込み権限と、ごく一部のファイル(container_file_tというラベルを明示的に付与されたファイル)への書き込み権限しか持たないようになっている。そのため、脆弱性があってもコンテナからホストへの悪意ある攻撃は難しくなっている。実際に、ここ数年のコンテナからの脱出を許す脆弱性についてもSELinuxがブロックしてきた。

コンテナ脱出脆弱性をSELinuxは全てブロックした実績

また、コンテナ同士もMCS(Multi Category Security)という仕組で分離されており、お互いに触れないようになっている。

コンテナ用SELinux設定ツールudica

現状のSELinuxのデフォルト設定では、コンテナアプリによっては設定が厳しすぎ(権限が足りずに動かない)たり、逆にデフォルト設定が甘めになることもある。設定が厳しいからと言ってSELinuxを無効にするのが最も良くない。このようなコンテナ向けのSELinux設定の過不足の問題を補うため、講演者が中心となり「udica」というツールを開発した。コンテナ内部を解析して必要な権限を洗い出し、権限に対応したSELinuxの設定を生成するツールだ。いくつかコマンドを打つだけでコンテナに必要なSELinuxの設定を作成できていた。また、既にudicaはRHEL8上で利用可能になっているとのことである。

udicaでコンテナ用のSELinuxの設定を生成

k8s環境でのSELinuxの開発状況

続いて、k8s環境でのSELinuxについて、Juan氏より最新の開発状況が紹介された。k8sにはOperator Frameworkという運用管理を自動化するための仕組みがあり、講演者がSELinuxに対応したOperatorの開発を進めている。「selinux-policy-helper-operator」はコンテナ開発者が簡単にコンテナ用のSELinuxの設定を生成できるようにするもので、特定のannotationを記載したpodの動作をウォッチしてSELinuxの設定を生成する。「selinux-operator」は生成されたSELinuxの設定のインストール・削除を自動化するものだ。これらはまだ開発途上であり、詳細は講演者のブログを参照してほしい。

SELinuxもしばらく開発が枯れているように見えていたが、udicaの登場やOperatorの開発が始まるなどコンテナ向けに新たなフェーズに入ったように思われる。今後はOpenShiftの運用やOpenShift上のコンテナを開発していく上でこれらの知識が必須になると思われるため、改めてSELinuxにも注目だ。