The Twelve-Factor App(コンテナのベストプラクティス)
クラウド上でコンテナを動かすためのベストプラクティスに「The Twelve-Factor App」というものがあり、特に重要な考え方としては下記のようなものになります。Herokuの中の人が提唱しました。
設定とビルドは分離する。
設置値はイメージに入れずに、環境変数で外から注入する。
例
- ECSで開発、ステージング、本番全て同じイメージを使うのであれば設定を環境変数化するのは必須になる。
- 他コンテナへの接続情報、DB接続情報、ログ出力のレベル
データベースのようなステーテトフル要素はコンテナを使わない。
コンテナのストレージデータは揮発性なので落ちてしまうとデータが消えてしまう。永続化の必要のあるデータはバックエンドサービス(RDS)を使用するのが望ましいです。
ログはファイルに書かず、ストリームで外に出す。
- ステートレスにするためにログは外に出す。
- STDOUT/STDERRに出力するだけで良い。（Cloud Watch Logs)
- バッファリングせずにそのまま吐き出す。
- 各コンテナのログドライバで受け取る。
セキュリティ対策
作成されたコンテナイメージ
アプリケーションをCode Buildなどでビルドしたイメージにはアプリケーション自体に加えて、アプリケーションに必要なライブラリが静的なアーカイブとして同梱されます。
時間が経つにつれて、ライブラリのバージョンは古くなっていき脆弱性が埋め込まれる形になっていきます。
対策
ECRによる脆弱性スキャン
追加費用なしで導入できます。以下、二つの方法があるが脆弱性スキャンは自動化することが重要なので、ECRリポジトリプッシュ時に「プッシュ時スキャン」をすることが推奨されています。
- プッシュ時スキャン
- 手動スキャン
ただ、プッシュ時スキャンだけだとアップデートが少ないシステムの場合は、脆弱性の発見が遅れることになります。その場合は手動スキャンも交えるようにすると良いでしょう。
Trivyによる脆弱性スキャン
ベースイメージへのOSスキャンだけでなく、Python(pip)、Ruby(gem)などアプリケーションの依存関係のスキャンもしてくれる。
基本的にはCICD時にCodeBuildなどでスキャンするようにすると良いでしょう。
Dockerfileへのセキュリティ対策
アプリケーションはrootユーザーで実行しないこと。
もし、rootユーザーで実行されていると以下のような操作ができてしまい侵害時の影響が増える。
- システム領域への書き込み
- プロセス操作
ECSタスク定義でルートファイルシステムアクセスを読み取り専用にする。
この設定をしておくことで、仮に不正なプログラムが混入した場合でも、ファイル改竄に対する脅威を小さくできる。
もし、アプリケーション側の仕様としてルートファイルシステムへの書き込みが発生しないようであれば設定しておくのが望ましい。
ベストプラクティス
The Center for Internet Security(CIS)や、Docker社ではコンテナイメージ作成時のベストプラクティスを公開している。
https://www.cisecurity.org/benchmark/docker/
https://docs.docker.com/develop/develop-images/dockerfile_best-practices/
ただ、これを開発者皆が把握するのは大変でしょう。
ベストプラクティスチェックツール
dockle
オープンソースのベストプラクティスチェックツールです。CISベンチマークやDocker社のベストプラクティスに適しているかチェックできます。CI/CDに設定しても良いです。
この記事へのコメントはありません。