KEMPエンジニアブログでは、
弊社エンジニアから業界の最新技術情報やロードバランサー製品に関するさまざまなノウハウなどをお届けします。

2021年2月15日月曜日

Ansibleで行うKemp LoadMasterの設定自動化


 

今回はAnsibleで行うKemp LoadMaster設定方法の一部を紹介します。

具体的にはVSの負荷分散設定の追加を行います。

※環境設定に関する説明は含みません



1. Ansibleによる設定の自動化

ADCなどのNW機器を正確に運用するための作業として、作業手順書の作成、それに従った作業の実施という流れがあります。これには多くの時間とエンジニアリングリソースを消費することになります。また、こういった作業では人為的な操作ミスや手順書記載漏れなどの問題が伴うため、サービスの可用性といった面では大きな弊害となります。

そこでAnsibleという構成管理ツールの利用が広まっています。

Ansibleで設定の自動化を行うことは上記の問題を解決するだけでなく、不足するエンジニアリソースを幅広い業務に振り分けることも可能になり、運用管理コストを軽減することにもなります。


2. Ansibleの導入ポイント

Ansibleでは、作業手順書の代わりに構成機器の設定を定義するPlaybookというファイルを記述することになります。このファイルはyaml形式で書かれるため可読性が高く記述や修正が容易であるため、運用とメンテナンスにおいて多くのメリットをもたらします。

KempのサイトではAnsibleで使用されるAnsible module およびPlaybookが提供されています。これをAnsibleコントロールノードに配置し、適宜編集することにより、Ansibleでの運用を可能にします。

Kemp LoadMasterの設定では、Ansibleを使って以下の構成を自動化できます。


・VSの作成、RSの登録

・HTTPヘッダ修正(挿入, 削除)ルールの追加、適用

・URLマッチングルールの追加、適用

・サーバ証明書などのアップロード

・外部認証サーバとの連携

など


3. AnsibleによるLoadMasterの設定

今回はAnsibleを用いてLoadMaster上にバーチャルサービス(VS)を作成し、10台のリアルサーバ(RS)で負荷分散を行う設定をします。設定にあたって、システムを構成する機器とネットワーク環境を以下のように定義します。

Ansibleコントロールノード: PlaybookをもとにPythonを実行しKemp 360 Centralへ命令を行う
Kemp 360 Central: 複数台のLoadMasterを一元管理し、認証情報などの管理を効率化する
VLM-MAX(仮想LoadMaster): 10台のRSに対して効果的な負荷分散を行う


※Kemp 360 Centralのデプロイ方法に関してはご連絡いただければ別途ご紹介いたします。
以下でも紹介しております。
https://support.kemptechnologies.com/hc/en-us/articles/360005562311-KEMP-360-Central
※本ブログではコントロールノード上でのPython, Ansibleなど事前環境が準備されていることを前提とさせていただきます。

4 設定手順
■ 必要なファイルをダウンロード
以下からダウンロード可能なKemp社提供のAnsibleモジュール及びPlaybook等をダウンロードします。
 https://kemptechnologies.com/kemp360/ansible-module/
※KempIDを事前に取得いただく必要がございます。

■ 設定ファイルを配置
Zipファイル解凍後に得られる以下のディレクトリをAnsibleコントロールノード任意の場所に配置します。
・ansiblepoc-master

■ ansible.cnfの書換え
Ansibleコントロールノード作業ディレクトリにansible.cnfを配置した後、以下を追記しモジュールなどの配置場所を認識させます。(あるいは/etc/ansible配下にあるansible.cnfを編集)

library = /”上記で指定したディレクトリ”/ansiblepoc-master/kemp_ansible/library
module_utils = /”上記で指定したディレクトリ”/ansiblepoc-master/kemp_ansible/module_utils

■ 管理パスワードの設定
Kemp 360 Centralのapi keyを入手します。このapi keyはKemp 360 CentralのRest APIを使用するうえでのパスワードのような役割を果たします。
以下Passwordの箇所にKemp360 Centralの管理ユーザパスワードを入れた以下コマンドを任意のサーバなどから実行するとapi keyが出力されます。このapi keyを控えます。

curl -k -X POST -d '{"username":"admin","password":"Password"}' https://Kemp360Centralの管理IPアドレス/api/v1/user/authenticate/

なお、今回は1台のADCに設定を加えますが、設定を行うADCが増えるにつれて把握すべきログイン用情報も増えることになります。そこで、これら情報も一元管理しているCentralを介して設定変更することによりこれを解消することができます。Centralのapi keyを取得する必要があるのはそのためであり、以降でPlaybook内に明記されます。






■ Playbookの修正
Playbookはansiblepoc-masterの下にあるexampleディレクトリにありこちらから編集可能ですが便宜上、以下の内容をPlaybookに記載します。こちらもAnsibleコントロールノードexampleディレクトリに配置します。

なお繰り返しになりますが、LMに10.2.2.13:443のVSを作成しバックエンドのRSには10台のRS 10.2.2.21~10.2.2.30:80を指定する設定となります。

※Ansible Playbookの構文自体に関しては以下などを参照願います。
https://docs.ansible.com/ansible/2.9_ja/user_guide/playbooks_intro.html#playbooks-intro

====================================================================================================
- name: Create a small configuration for LoadMaster
  hosts: localhost #Playbook上の作業対象はローカル(Ansibleコントロールノード)

  vars:
    central_address: ' ' #Kemp360centralの管理IPを指定します
    central_username: 'admin'
    central_api_key: ' ' #先ほど取得したapikeyを指定します
    lm_address: ' ' #作業対象LMの管理IPアドレスを指定します、X.X.X.X:443のようにポート番号も同時に指定します
    ip: ' ' #作成したいVSのIPアドレスを指定します
    port: 443  #作成したいVSのポート番号を指定します
    prot: 'tcp' #上記がtcpかudpかを指定します
    rs_ipstart: '10.2.2.' #今回は各RSのIPアドレスが21~30のように連続するため共通な3オクテット目までを指定します
    rs_port: '80' #RSのポート番号を指定します

  tasks:
    - name: Create Virtual Service Pathos on LM
      virtual_service:
        central_address: '{{ central_address }}'
        central_username: '{{ central_username }}'
        central_api_key: '{{ central_api_key }}'
        lm_address: '{{ lm_address }}'
        enable: 'Y'
        nickname: 'Pathos'
        ip: '{{ ip }}'
        port: '{{ port }}'
        protocol: '{{ prot }}'
        vs_type: 'http'
        ssl_acceleration: 1
        check_type: 'icmp'
        qos: 'Maximize-Reliability'
        transparent: 1
    - name: Create 10 real servers in sequence
      real_server:
        central_address: '{{ central_address }}'
        username: '{{ central_username  }}'
        lm_address: '{{ lm_address }}'
        api_key: '{{ central_api_key }}'
        vs_ip: '{{ ip }}'
        vs_port: '{{ port }}'
        vs_prot: '{{ prot }}'
        rs_ip: '{{ rs_ipstart }}{{ item }}'
        rs_port: '{{ rs_port }}'
      with_sequence: start=21 end=30 format='%d' #
====================================================================================================


■ ansible-playbookの実行
実行前のLoadMasterにはVSの設定はありません


Ansibleコントロールノード作業ディレクトリからansible-playbookを(今回作ったPlaybookを指定して)実行します。


成功したようですが、念のため実行後のVSの設定状態をLMのWUIから確認します


WUIからも設定変更が確認できました。

このようにAnsibleの活用は作業ミスによるリスク排除や作業時間の軽減に大きな効果があります。LoadMasterの保守やメンテナンスを実施する上でも充分な効果が期待できます。
次回以降の記事ではAnsibleでのサーバ証明書のインポート方法紹介も予定しています。

Kemp製品に関するお問いあわせに関しては、以下メールアドレスまでご連絡いただければ幸いです。

メールアドレス: kempmarket@fxc.jp







2021年1月14日木曜日

マイクロサービスとコンテンツルール

 

FXC Kempチームでございます。

このブログはKemp Technologies社のADC製品シリーズであるLoadMasterの国内普及を目的として、対応する機能や設定に関する技術情報などを主に配信します。今回はマイクロサービスを題材に、Kemp LoadMasterが提供するアプローチを紹介したいと思います。


マイクロサービスとは

クラウドコンピューティングやインターネットサービスに於けるアプリケー ション開発では近年、マイクロサービス アーキテクチャがクローズアップされています。
これはサービスの構成要素を小さなサービスに分割することで、
アプリケーション開発の効率化とDevOpsの概念で語られる開発と運用の最適化のアプローチ手法といえます。
この結果、開発速度と運用の質を高いレベルで調和しサービスの拡張性を実現することを可能にする手法であるといえます。


現状のサービススタイル

では、マイクロサービス アーキテクチャによるソフトウェア開発は、新規にスクラッチで行う必要があるのでしょうか。
従来のウォータフォール開発手法では、コンポーネント化されたモジュールでサービスが構成されているケースが多くあります。また、httpではURLで個別にコンポーネント(CGI) を呼び出す手法が一般的です。つまり、サービスの構成要素としてコンポーネントが既に存在しているわけです。
しかし、このコンポーネントは一つのサーバ機の中で構成されており、サービス提供時に発生する多くのトランザクションはサーバ内の各コンポーネントがCPUタイムを時分割して応答しています。
この状況でより多くのトラフィックを処理するためにはロードバランサーによるサーバクラスタリングが必要になります。


マイクロサービスへのアプローチ

個別のサービスを提供するコンポーネントは、サービス内容によって処理時間やアクセスの集中が異なります。しかし、現状のスタイルでは一つのサーバ(クラスタリングを含む)がすべてのサービスを実行するようにサーバ内で構成されます。
本来、サービスの効率化のためには、コンポーネントの処理時間や利用頻度で提供するサーバを分けた方がメンテナンス性や応答性の向上が期待できます。
つまり、処理時間のかかるサービスではCPU性能や多くのコアを持つサーバを割り当て、
アクセスの集中するサービスではクラスタリングでサーバ数を増やすという形でユーザエクスペリエンスを最適化できる可能性が広がります。
つまり、コンポーネント化された既存のサービスは、各コンポーネントを特性に応じたサーバで実行することで多くの効果をもたらすと考えられます。


マイクロサービスの第一歩

マイクロサービス アーキテクチャーではコンポーネント間のインターフェース設計などで、独立性の高いコンポーネントの集合体でサービスを構成するものと考えられます。
しかし、この環境にたどり着くには設計の見直しなどの多くの工数を必要とします。 
既にある資源を活用して運用性と拡張性の高いシステムを構築する上では、コンポーネントの機能に応じたサーバの分割がその第一歩となるのではないでしょうか。
つまり、URLのメソッドが示すCGIで処理すべきサーバを切り分けてサービスコンポーネントを実行し、ストレスのない応答性能を実現していくことが、マイクロサービスを実現する第一歩になるのではないでしょうか。 


マイクロサービス実現の手法

LoadMasterのコンテンツルールとSubVS機能を使うと、既存のインターネット サービスをユーザエクスペリエンスの最適化と運用性の効率化を可能にするシステムに構成することが可能になります。

HTTPリクエストはLoadMaster内のL7コンテンツスイッチにより各コンポーネントに配信します。

それぞれのコンポーネントは、処理の負荷状況や想定されるトランザクション数に応じてサーバを割当てて、最適な応答性能を確保します。

 

<例>

コンポーネントA: 負荷が大きくトランザクションも多いため、複数台の高性能サーバでクラスタリングします

コンポーネントB: 負荷が大きい処理のため、2台の高性能サーバで可用性を確保します

コンポーネントC: 標準的な処理であり、標準的な性能のサーバで可用性を確保します

httpURLリクエストの内容をチェックし、サービスコンポーネント(CGI)に応じてリクエストを目的のサーバに振り分けます。アクセスの多いリクエストはサーバをクラスタリングしてトラフィックに対応します。リクエスト内容をチェックしてサーバに振り分ける手法はURLストリングのマッチングで行います。マッチングストリングは正規表現(PCRE)の記述で行います。特別なスクリプトを記述する必要はありません。

コンテンツルールの設定は以下のサイトを参照してください。




 

2021年1月7日木曜日

NSAが古いTLS設定排除の指針を発表

 NSA(アメリカ国家安全保障局)は古いTLS設定を排除すべき旨の発表を行いました。

この発表には、排除すべき古いサイファースイートや鍵交換方式が明記されている他

、推奨設定、そして上記TLS設定が行われている組織のための対応策などが含まれます。


CISA(アメリカサイバーセキュリティインフラセキュリティ庁)は

管理者やユーザに向けてこの発表を参照するよう求めています。

※原文及び詳細は下記参照ください※

--以下より引用翻訳--

NSA Releases Guidance on Eliminating Obsolete TLS Protocol Configurations

 Eliminating Obsolete Transport Layer Security (TLS)Protocol Configurations



2020年11月25日水曜日

TLS1.3で安全なWebサイト構築/運用


 

FXC Kempチームでございます。

このブログはKemp Technologies社のADC製品シリーズであるLoadMasterの国内普及を目的として、対応する機能や設定に関する技術情報などを主に配信します。今回はTLS1.3を題材に、Kemp LoadMasterが安全性の高いWebサイト運用に貢献できる旨を紹介したいと思います。


【TLS1.3とは】

2018年8月、IETF(The Internet Engineering Task Force)がRFCとして公開したSSL/TLSプロトコルの最新版となります。

Kemp LoadMasterは比較的新しいこのプロトコルに、いち早く対応しております。


【Kemp LoadMasterでの設定】


上記のようにWUI画面から設定が可能です。

※SSLオフロード設定の有効化やサーバ証明書などのインストールが事前に行われていることを前提としています。
上記設定に関しては以下リンクを参照いただくか、弊社までお問い合わせください。
https://support.kemptechnologies.com/hc/en-us/articles/213906303-Web-User-Interface-WUI-#MadCap_TOC_17_2
※Rest APIを用い設定変更を行うことも可能です。


加えて、SSL/TLS関連の設定で重要になる暗号スイート(Cipher Suite)の設定に関しては、Kemp社から提供されるテンプレート(Cipher Setと呼ばれます)を活用することができます。今回はKemp社推奨設定である"Best Practice"というテンプレートを使用しています。

この場合、TLS1.3での表記で言えば以下の暗号スイートが選択されていることになります。

  • AES256-GCM-SHA384
  • AES256-SHA384
  • AES128-GCM-SHA256
  • AES256-SHA
  • AES256-SHA256

上記のように推奨設定を即座に反映することが可能です。
もちろんユーザ自身が選択した暗号スイートのみを設定することも可能です。


【SSL LABでの確認】

サイトのSSL/TLS脆弱性診断方法としてSSL Labsというサイトで確認する方法があります。

https://www.ssllabs.com/

このサイトでの診断を用いて、Kemp LoadMaster & TLS1.3有効化によりどのような効果があるか確認したいと思います。

--主な前提条件

  •  LoadMaster FWバージョン: 7.2.50
  • TLS 1.2, 1.3: 有効
  • 暗号スイート: 前述
  • サーバ証明書 署名アルゴリズム: sha256RSA
  • その他設定: OCSP Stapling無効、HSTP(HTTP Strict Transport Security)有効、など

ここでSSL Labsにおいて評価ポイントになっている要素を紹介します。


  1. TLS 1.3

    以下の緑で表示される要素は、SSL Labsにて推奨される設定がなされていることを示しますが、赤枠のようにTLS1.3が問題なく設定できていることがわかります。
    なお、評価は最高のA+となっています。



  2. Forward Secrecy(前方秘匿性)
    これは安全な鍵交換アルゴリズムが使用されていることを意味します。

    つまり鍵が漏洩しても攻撃者は過去にさかのぼり暗号文を復号化することはできません。

    TLS1.3はこの性質をもったアルゴリズムのみを使用するため、
    TLS1.3設定により、Forward Secrecyの項目は自動的に担保されます。



【まとめ】

このようにKemp LoadMasterでTLS1.3を設定することにより、サイトを安全にすることができます。

またTLS1.3にはほかにもメリットがございます。

興味のある方はIPAが発表しているTLS暗号設定ガイドライン等もご覧の上、

Kemp LoadMasterご利用を検討いただければ幸いです。


参考:独立行政法人情報処理推進機構

TLS暗号設定ガイドライン~安全なウェブサイトのために(暗号設定対策編)

https://www.ipa.go.jp/security/vuln/ssl_crypt_config.html


FXC Kempチーム

エンジニア