Dockerは、セキュリティを最大限に高めつつ本番環境に最適化したコンテナイメージ「Docker Hardend Images」の提供開始を発表しました。
Docker、CVE脆弱性がほぼゼロのセキュリティ強化型コンテナイメージ「Docker Hardend Images」提供開始 － Publickey
そしてDocker自身がパッチの自動適用を提供することで最新の状態を維持し、既存のCVE脆弱性がほぼゼロの状態で提供されると説明されています。
Docker、CVE脆弱性がほぼゼロのセキュリティ強化型コンテナイメージ「Docker Hardend Images」提供開始 － Publickey
⇧ パッチの自動適用してくれるのは大いに結構なのだが、動作保証してくれるのかが気になりますな...
障害が発生したら本末転倒な気がしますしな...
後は、障害発生時の原因調査がし易いのかとかも気になりますな...
内部的には、ディストリビューションレスの哲学に基づいて、シェル、パッケージマネージャ、デバッグツールといった一般的にリスクをもたらす不要なコンポーネントを排除している。また、アプリケーションの実行に必要な基本的なランタイム依存関係のみを組み込むことによって、より軽量で高速なコンテナを実現するとともにセキュリティと保守を容易にし、攻撃対象領域の大幅な削減によるセキュリティ体制の強化を実現した。
Docker、公式ブログにて安全なコンテナイメージ「Docker Hardened Images」を紹介|CodeZine（コードジン）
⇧ う～む...
「シェル」とか無いとなると、「Ansible」とかで上手く機能しないとか出てこないか気になる...
それに、Dockerfileとかでカスタマイズできないと痒い所に手が届かない使い勝手の悪い感じになりそうな気がするのよね…
セキュリティを堅牢にしてくれるのはありがたいのだが、実現したいことができなくなるだと厳しい...
問題の構造的に、
- 業務のフローをシステムに合わせて変更する
- システムを業務のフローに合わせて変更する
の話を彷彿とさせますな...
当然、「1. 業務のフローをシステムに合わせて変更する」が望ましいのだが…
ちなみに、「独立行政法人情報処理推進機構（IPA：Information-technology Promotion Agency, Japan）」の公開している情報で、
⇧「非機能要件記述とアーキテクチャ記述ガイド（2010年3月）(PDF:597 KB)」によると、
(2) アーキテクチャ設計に関連する非機能要件
2008 年版非機能要求記述ガイドでは、Zou‐Pavlovski[1]によって導入されたコントロールケースを拡張し、特に効率性及び回復性についてコントロールケースを用いた記述方法について述べた。
本ガイドでは、2008 年版非機能要求記述ガイドをベースに、対象とする非機能要件の種類を 10 種類に拡張した。
これらの非機能要件は、本 WG でのディスカッションを通じ、IT システムのアーキテクチャへの影響が大きく、アーキテクチャ構築時に特に考慮すべきものとして優先的に採り上げた。
また、「制約」は、IT システム構築プロジェクトの前提条件であるが、非機能要件として整理するか否かは議論が分かれるところである。
https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ps6vr700000077he-att/000005155.pdf
しかし、IT システム・アーキテクチャ構築時には、必ず考慮すべき項目であることから、本ガイドでは、次の 10 種類の非機能要件と同様に整理した。
- 可用性(Availability)
- 障害許容性(Fault tolerance)
- 回復性(Recoverability)
- 効率性 (Efficiency)
- 適時性(Timeliness)
- 最新性(Data Currency)
- 管理容易性(Manageability)
- セキュリティ (Security)
- 性能拡張性(Scalability)
- 機能拡張性(Extensibility)
- 制約(Constraints)
https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ps6vr700000077he-att/000005155.pdf
⇧ とありますと。
- 機能
- 非機能
の「トレードオフ」もさることながら、「非機能」同士の「トレードオフ」も悩ましい限りですな...
Linuxのパッケージのリポジトリの仕組みもクライアントサーバーモデルという話
インフラレイヤーのことは意識することが無かったのだが、独自のリポジトリを利用するための設定をする機会を得たことで（クライアント側のみだが）、
- クライアント
- サーバー
の構成になっていることが意識できたので、備忘録として。
「クライアントサーバーモデル」とは？
クライアントサーバモデル（英: client-server model）は、機能やサービスを提供するサーバと、それを利用するクライアントとを分離し、ネットワーク通信によって接続する、コンピュータネットワークのソフトウェアモデル（ソフトウェアアーキテクチャ）である。単にクライアント・サーバと呼ばれたり、C/Sなどと表記されたりすることも多い。俗にクラサバと略されることもある。
⇧ とあるように、Wikipediaの図だと語弊を招きやすいのだが、
| No | クライアント | サーバー |
|---|---|---|
| 1 | クライアント | XXサーバー |
| 2 | XXサーバー | XXサーバー |
⇧ のような形で、「クライアント」が何某かの「サーバー」になることがあり得るわけで、複数台のマシンで構成されることが一般的な「DNSサーバー」で考えるとイメージし易いかと。
⇧ 上図の例だと、
| No | クライアント | サーバー |
|---|---|---|
| 1 | 送信元PC | 3LDのDNSサーバー |
| 2 | 3LDのDNSサーバー | 2LDのDNSサーバー |
| 3 | 2LDのDNSサーバー | TLDのDNSサーバー |
| 4 | TLDのDNSサーバー | ルートDNSサーバー |
⇧ のような形で、別のサーバーに処理を委譲していく形になっているので、区間によって、
- クライアント
- サーバー
の役割を担うマシンが変わってくるわけだ。
話が脱線しましたが、「Linuxディストリビューション」の「パッケージ」の「リポジトリ」の仕組みについても、「クライアントサーバーモデル」であるので、独自に「Linuxディストリビューション」の「パッケージ」の「リポジトリサーバー」を構築する場合、
⇧ 上記サイト様にありますように、
の両方で対応が必要になって来るわけだ。
独自の「Linuxディストリビューション」の「パッケージ」の「リポジトリサーバー」の構成のイメージは、
⇧ 上記サイト様の図がイメージし易いかと。
上図だと、「本番サーバー群」のマシンが、「リポジトリクライアント」に該当し、「社内用のリポジトリ兼検証用サーバー」が「リポジトリサーバー」に該当する感じかと。
ちなみに、自前で「Linuxディストリビューション」の「パッケージ」の「リポジトリサーバー」を構築するメリットとしては、
などがありそう。
ちなみに、「サーバー（リポジトリのあるマシン）」側の設定が済んでいる前提の話にはなるのだが、「クライアント（リポジトリを参照したいマシン）」が「RHEL（Red Hat Enterprise Linux）」系の場合（勿論、「サーバー（リポジトリのあるマシン）」側も「RHEL（Red Hat Enterprise Linux）」系の前提）、
といった作業が必要になると思うのだが、
■/etc/yum.repos.d/extra-package.repo
[extra-lib] name=Imade Yum Repository baseurl=http://10.1.0.5/repo gpgcheck=0 enable=1 [extra-api] name=Imade Yum Repository baseurl=http://10.1.0.6/repo gpgcheck=0 enable=1 [extra-batch] name=Imade Yum Repository baseurl=http://10.1.0.7/repo gpgcheck=0 enable=1
⇧ のように複数のリポジトリを定義している場合、[]の中の名前のprefix（先頭の文字）を統一しておくと、
sudo yum --disablerepo=* --enablerepo="extra-*" repolist
⇧ のようにワイルドカードが使用できるようだ。
統一されていないと、
⇧ 上記サイト様のコメント欄にあるように、カンマ区切りで指定していく必要があり、リポジトリの数が多くなるほど、大変になってくる。
命名ルールを決めておけば、リポジトリを追加した場合でも、有効化するコマンドは変更せずに済むことになるので、命名ルールは決めておけば良いような気はする。
ファイル名を指定して有効化できれば良かったんですがね...
ちなみに、「RHEL（Red Hat Enterprise Linux）」系のYumコマンドについては、
⇧「cheat sheet」が公開されていた。
毎度モヤモヤ感が半端ない…
今回はこのへんで。
