BIG-IP Forward Proxyでは標準機能による実装には限界があるため、iRulesによるコード拡張を用いざるを得ないケースがあります。 そのため、PoC (Proof of Concept)としてiRulesによるFirewall Policyライクな実装例をGitHubで公開しました。
実装例の特長
PoC (Proof of Concept)と強調しているように、本番環境での実用に耐えうるレベルの実装にはなっておりません。 あくまでもコンセプトの実証のために公開しました。
BIG-IP Forward Proxyでは開発者自らが定義した設定データの保持先として、KVS (Key-Value Store)のData Groupしか実質的な選択肢がない実情があります。 そして、Data Groupに設定データを保持すると、Forward Proxy構成の実装方法によってはData Group数が肥大化していく問題がありました。 そのため、管理対象であるData Group数を少なくして、少しでも運用面が楽になる方法がないかと思案したのが筆者の実装方法です。
Data GroupのKeyを処理順序が一意になるような制御に用い、Valueを複数のフィールドに分けてFirewall Policyのような複数要素を参照できる実装にしました。
なお、Data Groupに設定データを保持する問題に関しては、下記の記事にて詳しく記載しております。
実際のコードを見て頂くと分かりやすいですが、Forward Proxyが担うアクセス制御の主要機能の多くをコード拡張によって実現しているため、皮肉にもSoftware Defined Forward Proxy (SDFP)とでも表現すべき実装者依存の状態になっています。 アプライアンス製品であるのにも関わらず、その実装方法の多くがコード拡張を用いているとなると品質の維持が難しくなります。 また、業界トップレベルの多機能さを誇るProxySGからの移行だと、大半がiRulesによる実装になります。
3つのスパゲッティ (スパゲッティ コード, スパゲッティ ロジック, スパゲッティ データ)
BIG-IP Forward Proxyでのコード拡張の実装を複雑化している要素として、スパゲッティ コード , スパゲッティ ロジック , スパゲッティ データの3つのスパゲッティがあります。
- スパゲッティ コードは、複雑なロジックを実装したiRulesの実装コードを指します。
- スパゲッティ ロジックは、機能アクセスの制約故に複雑化したロジックを指します。
- スパゲッティ データは、設定データの保持構造を無理やりにData Groupで実装して複雑化したものを指します。
まず前提としてセキュリティ上の理由により、実装時の肝となるiRulesコマンドからのOSに紐付く機能アクセスは限定されます。そして、機能アクセスの範囲に制約がかかると実装可能なロジックの案が限定されます。 ロジックの案が限定されるとコードでの実装方法も限定されてループしているかのように相互影響して、スパゲッティ コードとスパゲッティ ロジックが生み出されるキッカケとなります。
補足ですが実装時に利用可能なiRulesコマンドは Master list of iRule Commands のリストにあるものとなります。
更に、BIG-IP Forward Proxyで設定データの格納に採用可能な機能が、KVS (Key-Value Store)のData Groupしか実質的にないため、データの保持構造が複雑化してスパゲッティ データが生み出されます。 例えば、KVSのData Groupで疑似的なRDB (Relational DB)のデータ構造を無理やりに再現する複雑なやり方があります。 そして、データの保持構造が複雑化が、データ処理のロジックとコードからデータへのアクセスを複雑化してしまい悪影響のスパイラルに陥ります。
このように、3つのスパゲッティがお互いに調和して、熟練のエンジニアさえ手につけようのない巨大なスパゲッティに変貌を遂げます。
なお、リファクタリングはスパゲッティ コードに対しては効果を期待できますが、コード化の元になっているロジックとデータがスパゲッティとなっているので根本的な解決にはなり得ません。 ちなみに、筆者の実装案はスパゲッティ データの複雑性の低減に注力したものです。
理想案と妥協案
注記しますが、筆者の実装案は妥協案であり、理想的な実装案ではありません。 いくつもの実装案を考案しては機能制約のため実現性がなく廃案となり、その中で妥協案として生き残ったものをPoCレベルで実装しました。 裏を返せば、それだけBIG-IP Forward ProxyでiRulesによる実装を行うのが難しいと言えます。
筆者の意図しては、BIG-IP Forward Proxyへの移行や、案件の請負検討にあたり、参考例とするために公開しております。 繰り返しますが、本番環境にそのまま導入しようと考えないでください。筆者はコードに対してサポートを提供しませんし、何ならサポートを求めるスキル レベルであれば導入すべきではありません。
筆者はBIG-IP Forward Proxyの導入がより良いものになるように試行錯誤を繰り返しましたが、3つのスパゲッティが実装の難易度を異様なほど高くしているため、無理な導入が行われないように問題点を理論的に解説するために本記事を書きました。
