kubernetes

Vault の Agent Sidecar Injector を使うと Vault に格納された Secret を Sidecar 経由で Pod に渡したりすることができます。 https://github.com/hashicorp/vault-k8s ここでは、Agent SIdecar Injector の概要を把握し、Vault の PKI Secret Engine で生成した証明書を nginx が動く Pod に動的に配置して、クライアント証明書認証を行うまで試してみます。 概要 ドキュメントは https://www.vaultproject.io/docs/platform/k8s/injector/index.html にあります。 また、https://qiita.com/ryysud/items/ec8de49aa39a2f9fbceb でも丁寧に解説されてありますので、参照すると良さそうです。 Vault Agent Injector は Pod の CREATE と UPDATE イベントをインターセプトして、 [vault.hashicorp.com/agent-inject:](http://vault.hashicorp.com/agent-inject:) true という Annotation があれば Vault から Secret を取得するための Vault Agent コンテナを InitContainer として追加する Mutation Webhook Controller です。 これは Annotation で実現することもできますし、Vault Agent の設定ファイルを用いることでも可能です。 ref : https://d33wubrfki0l68.

falco のルールは、そこそこ柔軟に書けるのだが、故にバイパスできてしまうよという話。 1. /proc/self/root を使う falco のデフォルトルールに /etc/shadow などが開かれたことを検知するルールがある。 https://github.com/falcosecurity/falco/blob/dev/rules/falco_rules.yaml#L1405 抜粋するとこういうルール。 - list: sensitive_file_names items: [/etc/shadow, /etc/sudoers, /etc/pam.conf, /etc/security/pwquality.conf] - macro: sensitive_files condition: > fd.name startswith /etc and (fd.name in (sensitive_file_names) or fd.directory in (/etc/sudoers.d, /etc/pam.d)) - rule: Read sensitive file untrusted desc: > an attempt to read any sensitive file (e.g. files containing user/password/authentication information). Exceptions are made for known trusted programs. condition: > sensitive_files and open_read and proc_name_exists これは fd.

Kubernetes の secrets や configMap を管理する際に気をつけることがいくつかあります。 例えば manifests に base64 エンコードされた値が記載されてしまうため、GitOps の場合はリポジトリに平文同然の manifests が置かれることになり、あまりセキュアとは言えません。 この場合 sealed-secrets などを使って暗号化するという方法などがあります。 sealed-secrets も扱いやすいのですが、 kubectl get secrets -o yaml などすると平文で取得できてしまいます。 「暗号化したまま保存し Pod のアプリケーションから平文の値を取得できるようにしたい」「できるだけ Kubernetes との連携が簡単なものを選びたい」というときに kamus が便利そうでした。 Install helm でインストールします。また、CLIクライアントも合わせてインストールします。 $ helm repo add soluto https://charts.soluto.io $ helm upgrade --install kamus soluto/kamus $ npm install -g @soluto-asurion/kamus-cli 暗号化する ここでは super-secret という文字列を暗号化します。 暗号化するエンドポイントとやり取りするために port-forward しておきます。 $ export POD_NAME=(kubectl get pods --namespace default -l "app=kamus,release=kamus,component=encryptor" -o jsonpath="{.items[0].metadata.name}") $ kubectl port-forward $POD_NAME 12345:9999 $ kamus-cli encrypt \ --secret super-secret \ --service-account kamus-sa \ --namespace default \ --kamus-url http://localhost:12345 --allow-insecure-url [info kamus-cli]: Encryption started.

以前 は BPF を使ってコンテナの中のイベントを取得する cxray を作った話を書いた。 cxray で現在取得できるイベントは次の4つ。 起動したプロセス 開かれたファイル TCPv4 での接続先 TCPv4 での network listener cxray のユースケースとして、生成されたイベントをホワイトリストとして定義し、別のモニタリングツールのルールなどに利用することを想定している。 ここではシンプルな Rails 環境を動かし、falco のルールを作るところまでやってみる。 環境 次のような docker-compose.yml を用意し、rails が起動するところまでのイベントを取得する。 version: "3" services: app: build: . ports: - "3000:3000" environment: - "DATABASE_HOST=db" - "DATABASE_PORT=5432" - "DATABASE_USER=postgres" - "DATABASE_PASSWORD=password" links: - db volumes: - "./:/app" stdin_open: true db: image: postgres:10.1 ports: - "5432:5432" environment: - "POSTGRES_USER=postgres" - "POSTGRES_PASSWORD=password" cxray を起動し、 docker-compose up する。

前回は bcc を使ってコンテナ内の execve を取得する方法について書きました。 最近 falco などを使い、Kubernetes の Pod の安全性を高めているのですが、そのルールを定義するのが難しいと感じていました。 例えば NIST の Application Container Security Guide の 4.4.4 節では次のイベントが発生することを検知できるようにしたほうが良いと書かれています。 Invalid or unexpected process execution, Invalid or unexpected system calls, Changes to protected configuration files and binaries, Writes to unexpected locations and file types, Creation of unexpected network listeners, Traffic sent to unexpected network destinations, and Malware storage or execution. ref : https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-190.pdf 「期待していないプロセス」「期待していない通信先」などと言われても列挙するのは難しいと思います。 そこで、BPF を使って特定のシステムコールを取得すれば、ある程度ホワイトリスト化できるのではないかと思い、 cxray というツールを作りはじめました。