はじめに
こんにちは、nayaaaaです！
最近はなかなか手を動かして学習する時間が取れなかったのですが、
その分、以前から読んでいた本や記事を通じて得た知識の中で、個人的に面白いと思った内容を、今回は記事としてまとめてみました。
テーマは以下の3つです。
- コンテナにroot権限を与えないことの重要性
- Falcoについて
- Terraformのファイル管理の面白さ
コンテナにroot権限を与えないことの重要性
一般的にはコンテナビルド時にroot権限は渡さないことが推奨されています。
その理由としては 「コンテナ内のプロセスが root 権限で実行されていると、万が一コンテナの脆弱性を突かれた際に、ホスト側のシステムまで影響を及ぼす可能性がある」というざっくりした認識でした。
しかし、実際なぜコンテナホストが乗っ取られるのか？ とか どうしてroot乗っ取られたらなんでも操作できるのか？ みたいな具体的なところってずっと想像ぐらいでの認識だったんですよね。
最近読んだ本ではこの点について詳しく書かれており、
コンテナ内では、root ユーザーとして動作している場合でも、capability（ケーパビリティ）という機能によって、ある程度の権限制限がかけられているそうです。
ただし、コンテナ内のrootユーザーがコンテナホストにアクセスできる状況にあると、そのユーザーはコンテナホスト側ではcapability（ケーパビリティ）がない、ただのroot 権限で操作できてしまうため、非常に危険とのことです。
Dockerでは明示的にユーザーを指定しない場合、デフォルトでrootユーザーとしてコンテナが実行される仕様になっています。
この状態で何が問題かというと、仮に悪意のある第三者がコンテナにアクセスした場合、
➀不正にコンテナアクセス⇒➁rootユーザーでコンテナホストにアクセス⇒➂コンテナホストを乗っ取り
というような最終的にコンテナホスト側のシステムをroot権限で操作できてしまうリスクがあるという点が危険とのことです。
読んでた本👇 今回の話は第3部に書いてます。
特にcapability（ケーパビリティ）の機能について勉強する良い機会になりました。
このようにKubernetesを使用しなくてもコンテナ技術を扱う方であれば読んでみると面白いと思います。
Falcoについて
Falcoは、Linuxカーネルやコンテナランタイム（Docker、containerdなど）の振る舞いを監視することで、不審な活動を検知して警告することが可能です。機能としてはLinuxカーネルのシステムコールを監視して、ユーザが定義したルールに基づいて異常な挙動にフラグをたてることで警告を発報します。
また、実行中のコンテナ内の異常なプロセスや、コンテナエスケープ（コンテナからコンテナホストに侵入すること）の脆弱性を悪用したり、機密データにアクセスしようとする試みも検知することが可能です。
※似たようなツールでTetragonというのもあるそうですね。
Kubenetesの技術書を見ていたら必ずと言っていいほどセキュリティ関連ツールでFalcoが記述されており、以前から気になって記事やドキュメントを見ていたのですが、
ルールのカスタマイズも多岐にわたることで扱う難易度やセキュリティ面で考慮することが多く、エンジニア業界でもセキュリティエンジニアが少ないという傾向からも業務に取り入れるというのはとても難しいのかなと思いました。
でも、名前がかっこいいですよね！！
子供のころ「ブラッディマンデイ」という漫画原作のドラマが好きで、
話の内容的には天才ハッカーの主人公がそのハッキング能力を駆使してテロリスト集団に立ち向かっていくというお話なのですが、その主人公のコードネームが「ファルコン」なんですよね。
その名前が記憶に残っていて、今回も自然と紐づいて、より興味が湧きましたね。
Terraformのファイル管理の面白さ
こちらについては、現在まさに勉強中なのですが、Terraform のファイル管理において最近感じるのは、「どのような環境でTerraformを使うか」が非常に重要になってくる、ということです。
1つのファイルにすべてをまとめれば、別ファイルから変数やモジュールを呼び出す必要がなくなるのでシンプルではありますが、可読性が低くなったり、コード変更の影響範囲が大きくなってしまうというデメリットも考えられます。
一方で、ファイルを分割したり、モジュール化を取り入れたりすることで、
- チーム全体での開発スピードが上がる（一斉編集が可能になるため）
- 一斉編集時のコンフリクト（競合）を防げる
- 環境ごとに分けて効率的なデプロイが可能になる
※各ディレクトリ単位で担当を分け、環境ごとに独立してデプロイできるため、チームでの作業効率が向上します。 - コード変更の影響範囲を機能単位に抑えることができる
といったメリットがあると思います。ただしその分、設計や設定の難易度は多少上がりますし、モジュールや設定がどこから呼び出されているかが把握しづらく、初見の人が構成を理解しにくいという可能性もあると感じています。
こういった構成の選び方には、本当にさまざまなパターンがあり、実際の業務環境や自分のプロジェクトに、どの構成が最適なのかを判断するのが非常に難しいのかなと感じています。
これは、プロダクトに導入する技術を選定する際にも通じる部分があるかなと思います。
まとめ
最近はこういった知識については、本や記事を通じて何とか補ってはいるのですが、
実際に手を動かして試す機会が減ってしまっているので、今後はもう少し増やしていきたいなと感じています。
それでは、最後まで読んでいただきありがとうございました〜