Falco OperatorによるKubernetesのコンテナ"ランタイム"セキュリティ

この記事は[falco-operator](https://github.com/mumoshu/falco-operator)の日本語による紹介記事です。

<blockquote class="twitter-tweet" data-lang="ja"><p lang="en" dir="ltr">Kubernetes Operator for Falco by <a href="https://twitter.com/mumoshu?ref_src=twsrc%5Etfw">@mumoshu</a>. Create Falco rules through a Kubernetes resource “FalcoRule” <a href="https://t.co/Ucg6Z9Q95e">https://t.co/Ucg6Z9Q95e</a></p>&mdash; Michael Ducy (@mfdii) <a href="https://twitter.com/mfdii/status/1048209757310537728?ref_src=twsrc%5Etfw">2018年10月5日</a></blockquote>

# TL;DR;

Kubernetes以後の世界で「コンテナへの侵入検知」をもれなくやりたい。そのために、Falco Operatorを使ってコンテナランタイムセキュリティの民主化と、監査のシステム化を達成する。

# なぜFalco Operatorが必要か?

コンテナへの「侵入検知」のためです。

# なぜ「コンテナへの侵入検知」が必要か?

Kubernetesによってアプリケーションがコンテナ化されると、これまで各社がVMベースのインフラでは実現できていた、「侵入検知」が十分にできなくなります。

例えば、VMベースのインフラでは、基本的なところでも「特定のファイルへの読み書きの監視」や「特定のプロセスの存在チェック」はよく行われていると思います。

しかし、そういうインフラにコンテナを導入したタイミングで、「コンテナの中で起きたことが監視できていない」という状態になりがちです。

例えば、多層防御の考え方をKubernetes以後のインフラに適用すると、以下のようなものが思いつくのではないでしょうか。

- 入口対策の一環として、Kubernetes API Serverをインターネットに公開しないようにうる
- 内部対策として可能な限り `readOnlyRootFilesystem` を利用したり、host volumeは `readOnly` でマウントするようにする、
- 出口対策としてL7のNetwork Egress Policyを利用する

入口対策や出口対策はこれまでVMベースのインフラでも利用していたものも使えます。例えば、入口対策にWAFを使う、などです。また、内部対策としてホスト向けのIDSは引き続き利用することができます。

しかし、コンテナの内部となると話は別です。例えば「コンテナへの侵入検知」ができないと、「コンテナ上で動いているWebアプリケーションの脆弱性を通して、コンテナにバックドアを仕込まれた。しかし、いつまでたっても開発者が気づけない」といった状態になってしまいます。

# Falco Operatorとは何か？

Falco Operatorは[Falco](https://sysdig.com/opensource/falco/)をKubernetes Operator化したものです。ねらいは「コンテナランタイムセキュリティの民主化」と「監査のシステム化」の２つです。

## コンテナランタイムセキュリティの民主化

Falco Operatorを使うと、コンテナへの侵入検知ルールのようなものもコンテナと同様、気軽にデプロイすることができます。

これによってコンテナのランタイムセキュリティをより多くの開発者が設定できるように民主化し、結果的に侵入検知の機会を増やそう、というのが一つの目的です。

たとえば、Kubernetesでは「YAMLを少し書いてkubectlコマンドに食わせるだけで、コンテナをデプロイできる」・・・というようなイメージは多くの方が持っていると思います。nginxをデプロイする場合は以下のような記述になります。

```yaml:nginx.deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.4
        ports:
        - containerPort: 80
```

一方、Falco Operatorがあれば、以下のような記述をするだけでコンテナ挙動監視を行うことができます。

```yaml:bash.falcorule.yaml
apiVersion: "mumoshu.github.io/v1alpha1"
kind: "FalcoRule"
metadata:
  name: "bash"
  namespace: "default"
spec:
  rule: shell_in_container
  desc: notice shell activity within a container
  condition: container.id != host and proc.name = bash
  output: shell in a container (user=%user.name container_id=%container.id container_name=%container.name shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline)
  priority: WARNING
```

## 監査のシステム化

Operatorパターンに則ることで、どんな監視ルールを（K8S Object)、どこに誰が作れるか（RBAC)、作ったか(Audit）、ということもKubernetesの枠組みで管理することができます。

そのおかげで、例えばどのアプリケーションで監視ルールが漏れているか、などを簡単に検知することができます。「適用されている監視ルールを人力で定期的に棚卸ししてぬけもれを確認する」というような運用に比べれば、「FalcoRuleがあるかどうか、やその内容の自動的なチェック」でカバーし、残りを人力て監査する、という方法のほうが持続的だと考えています。

# Falco Operatorの使い方

READMEの「Getting Started」の手順にそってfalco-operatorをインストールします。

https://github.com/mumoshu/falco-operator#getting-started

次に、`FalcoRule` というKubernetesオブジェクトを作成すると、その内容をFalco Operatorが自動的に取り込んでコンテナの監視を始めてくれます。

例えば、以下は「あらゆるコンテナで `bash` が起動したらアラートをあげる」という意味合いのルールです。

```yaml:bash.falcorule.yaml
apiVersion: "mumoshu.github.io/v1alpha1"
kind: "FalcoRule"
metadata:
  name: "bash"
  namespace: "default"
spec:
  rule: shell_in_container
  desc: notice shell activity within a container
  condition: container.id != host and proc.name = bash
  output: shell in a container (user=%user.name container_id=%container.id container_name=%container.name shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline)
  priority: WARNING
```

FalcoRuleの `spec` 部分には、Falcoの設定ファイルに書く監視ルールと同じ記法を使うことができます。

https://github.com/falcosecurity/falco/wiki/Falco-Rules

# その他のソリューション

Kubenetesに対応しているものに絞ると、筆者の知る限りOSSでは１つだけ、Auditbeatがあります。

AuditbeatはElasticsearchやKibanaで有名なElastic社によるOSSです。KubernetesのDaemonSetとしてデプロイすることができ、ファイルの変更検知とauditdに対応しています。後者については、auditdルールを書くことで、auditbeatが各ホストのauditdを駆動してくれる、という仕組みになっています。auditdができること、つまりLinuxのシステムコールの監視、はなんでも可能です。

SaaSであれば、Aqua Security、Twistlock、Sysdig Secureがよく知られていると思います。特にSysdig SecureはFalcoがベースになっているので、自分で監視ルールを拡張したいような場合は選択肢に入れるとよいかもしれません。

# まとめ

コンテナランタイムセキュリティの民主化と、システム化を目的にFalco Operatorを開発しました。

OSSでコンテナへの侵入検知などを行いたい場合は、ぜひ選択肢の一つにしてみてください。

# 補足

この記事では「コンテナの侵入検知」という表現を多用しましたが、表題にもある「コンテナランタイムセキュリティ」はいわゆる侵入検知だけではありません。日本語でうまい説明ができなかったためこうなっていますが、よりコンテナセキュリティに詳しい方は補足いただけるとうれしいです。

# 参考情報

FalcoとKubernetes Operatorについて詳しく知りたい方は、それぞれ以下のリンク先を参照してください。

SysdigによるFalcoの紹介ページ
https://sysdig.com/opensource/falco/

CoreOS社によるOperator紹介ページ
[Kubernetes Operators](https://coreos.com/operators/)