Ksocket の Azure 上で動作を改善しました。

Ksocket に以下の内容を含むアップデートを行いました。

  • ksocket-20200220
    • ksocket-core: 1.9.2
    • ksocket-networks: 1.9.1

アップデート内容

  • 全体的なパフォーマンス向上
  • 新規インストール時のデフォルトの loglevel を INFO に変更
  • Azure 上にて ksocket が動作しないバグを修正
  • スキャン対象に大量のアドレスを指定した際に発生するメモリリークバグを修正
  • インストーラーが一部環境で動作しなかった問題の修正
  • アンインストーラーが付属していなかった問題の修正

最新の Ksocket はこちらよりダウンロードすることができます。



Kompira cloud 製品紹介ページはこちら
Kompira cloud 資料ダウンロードはこちら

新しい画面デザインを正式にリリースしました

Kompira cloudについて、下記の機能を含むアップデートを行いました

新しい画面デザインを正式にリリースしました

これまでβ機能としていた、新しい画面デザインを正式リリースいたしました。

f:id:honda_fixpoint:20191204184448p:plain:w720
新しい画面デザイン

見た目・使い勝手が向上しているのはもちろん、スマートフォン等の画面サイズの小さい端末での表示に関する考慮や、英語表示への切り替え機能が追加されております。

f:id:honda_fixpoint:20191204184710p:plain:w200
スマートフォンサイズでの表示

f:id:honda_fixpoint:20191204184738p:plain:w720
英語での表示

なお、旧デザインについては今後廃止を予定しておりますが、当面の間は上部メニューより切り替えて使用することが可能です。

f:id:honda_fixpoint:20191204185640p:plain:w200
旧デザインに戻す

[Pigeon] 連絡実行・中止を行う新しいAPI機能をリリースしました

連絡実行・中止を行うためのAPIとして、これまでのAPIよりも高機能な新しいAPIを追加しました。
旧APIに関しては引き続きご利用いただけますが、今後は新APIを推奨する形となります。

詳しくは下記の記事をご覧ください。
Pigeonの新しい連絡APIの機能と使いかたについて

Pigeonの新しい連絡APIの機能と使いかたについて

Pigeonの連絡に使用するAPIについて、新しいAPIをリリースしました。

  • 連絡実行API
    • 旧:POST /api/tasks
    • 新:POST /api/apps/chain/invoke
  • 連絡中断API
    • 旧:POST /api/tasks/{taskId}/abort
    • 新:POST /api/apps/chain/abort

新しいAPIはこれまでより高機能かつ使いやすいものとなっており、本記事ではこのAPIの使用方法についてご説明いたします。 (コマンド例にて使用するデータは Pigeon チュートリアルのものに準じます)

連絡の実行:POST /api/apps/pigeon/chain/invoke

定義済みのコールフロー・ガイダンスを用いて連絡を実行する

事前定義したコールフロー・ガイダンスを用いて連絡を行うには、それぞれのID値を用いて例えば下記のデータをリクエストボディに指定してPOSTリクエストを行います。

{
  "params": {
    "callflowId": "049de6fc-c1a7-4963-af43-616cce2492c6",
    "guidanceId": "570e6f71-5459-43fe-a745-aa7d115ce20d",
    "parameters": {
      "server": "テスト用サーバー",
      "incident": "軽度の障害"
    }
  }
}

curlコマンドでのリクエスト例を下記に示します。

$ curl -X POST -H "X-Authorization: Token aAbBcCdDeEfFgGhHiIjJkKlLmMnNoO0123456789" \
https://yourspace.cloud.kompira.jp/api/apps/pigeon/chain/invoke \
-d '{"params":{"callflowId":"049de6fc-c1a7-4963-af43-616cce2492c6","guidanceId":"570e6f71-5459-43fe-a745-aa7d115ce20d","parameters":{"server":"テスト用サーバー","incident":"軽度の障害"}}}'

リクエストを行うと、例えば下記のように「リクエストに使用したパラメータ」「連絡結果ID(成功時のみ)」「連絡の成否(requested であれば成功)」を含むレスポンスを返します。

{
  "params": {
    "callflowId": "049de6fc-c1a7-4963-af43-616cce2492c6",
    "guidanceId": "570e6f71-5459-43fe-a745-aa7d115ce20d",
    "parameters": {
      "server": "テスト用サーバー",
      "incident": "軽度の障害"
    }
  },
  "resultId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "status": "requested"
}

レスポンス中に含まれる連絡結果IDを用いて、後述する「連絡の中止」や、
既存のAPI GET /api/apps/pigeon/results/{resultId} を通した連絡結果情報の取得を行うことができます。

コールフロー・ガイダンスの内容をその場で指定して連絡を実行する(新機能)

リクエスト時に callflowId guidanceId の代わりに、使用するデータの内容を callflow guidance として指定して連絡することができます。

{
  "params": {
    "callflow": {
      "loopLimit": 3,
      "contacts": [
        {
          "displayName": "田中さん",
          "phones": [ { "phoneNumber": "0999001122" } ]
        },
        {
          "displayName": "山田さん",
          "phones": [ { "phoneNumber": "0999334455" } ]
        },
        {
          "displayName": "斎藤さん",
          "phones": [ { "phoneNumber": "0999778899" } ]
        }
      ]
    },
    "guidance": {
      "messageTemplate": "テスト用サーバーにて軽微な障害が発生しました。 対応される場合は1を、次の担当者に連絡する場合は2を、以降この電話への連絡をスキップする場合は3を押してください。",
      "reactions": {
        "1": {
          "behavior": "terminate",
          "messageTemplate": "1が押されました。対応をよろしくお願いいたします。"
        },
        "2": {
          "behavior": "continue",
          "messageTemplate": "2が押されました。次の担当者に連絡します。"
        },
        "3": {
          "behavior": "leave",
          "messageTemplate": "3が押されました。以降この電話への連絡をスキップします。"
        }
      }
    }
  }
}

上記の例ではコールフロー・ガイダンスの内容を双方とも直接指定していますが、片方はID指定にて事前登録済みのデータを使用し、もう片方は内容をその場で指定するといった形でのリクエストも可能です。

本機能により、例えば電話番号を含む名簿データを自前で管理しているシステムとの連携時に、呼び出し側でコールフローのデータ内容を生成する形をとることでPigeonへ電話番号を二重登録することを防ぐ、といった使い方が可能となります。

連絡の中止:POST /api/apps/pigeon/chain/abort

連絡の中止を行うには、連絡結果IDを用いて例えば下記のリクエストボディにてPOSTリクエストを行います。

{
  "resultId": "3fa85f64-5717-4562-b3fc-2c963f66afa6"
}

curlコマンドでのリクエスト例を下記に示します。

$ curl -X POST -H "X-Authorization: Token aAbBcCdDeEfFgGhHiIjJkKlLmMnNoO0123456789" \
https://yourspace.cloud.kompira.jp/api/apps/pigeon/chain/abort \
-d '{"resultId":"3fa85f64-5717-4562-b3fc-2c963f66afa6"}'

旧APIの今後の取り扱いについて

今後は新しいAPIを使用することを推奨し、旧APIは 非推奨 となります。
ただし、旧APIの既存機能については今後も引き続きご利用いただけますので、既にご活用いただいているものをただちに置き換えていただく必要はございません。

なお今後連絡APIへの機能追加を行う場合、その対象は原則として新APIのみになりますのでご承知おきください。

EC2上にインストールしたksocket用のIAM Userを作成する

この記事では、AWS EC2上にインストールしたksocketに対して、AWS上のサーバをスキャンするために必要な権限を持ったIAMユーザを作成する方法を説明します。

1. AWSコンソールからIAMユーザ一覧画面を開き、IAMユーザの追加へ進む

f:id:e-sekito:20190904180411p:plain

2. IAMユーザの名前を入力し、クレデンシャルの発行を行うよう指定する

今回の例では、IAMユーザ名は ksocket としましたが、お好きな名前で構いません。 また、EC2上に配置するためのクレデンシャルファイルを発行するために、 Programmatic Access のチェックボックスをオンにします。

f:id:e-sekito:20190904180246p:plain

3. AWSのManaged Policyから、ReadOnlyAccessを付与する

ksocketはスキャンのために、ReadOnlyAccess相当の権限を必要とします。 AWSのManaged Policyには、ReadOnlyAccessというものがあるため、それを付与します。

f:id:e-sekito:20190904181502p:plain

4. タグの指定はスキップする

ksocketは特にIAMユーザに対するタグを必要としません。

f:id:e-sekito:20190904181600p:plain

5. 内容を確認し、IAMユーザの追加を実行する

ここまで設定した内容を確認し、実際にIAMユーザを追加します。

f:id:e-sekito:20190904181613p:plain

6. クレデンシャルファイルをダウンロードし、画面を閉じる

作成されたIAMユーザ用のクレデンシャルファイルは、忘れずにダウンロードをお願いします。

f:id:e-sekito:20190904181627p:plain

新しい UI デザインをベータ公開しました

f:id:lambdalisue:20190904123446p:plain
新デザインでノード詳細を表示した様子

スマートホン等の小さなデバイスでの閲覧性向上やインターフェースの英語対応を行うために、かねてより開発を進めていた Kompira cloud の新しい UI デザイン(新デザイン)をベータ公開しました。 独自デザインから Google Material Design ベースのデザインへ切り替えることで、初めてでも使いやすいデザインとなっています。 いち早く新デザインを試したい方は、ログイン後のアカウントメニュー(サイト右上のメニュー)より「新しいデザインを試す」をクリックしてください。

f:id:lambdalisue:20190904123925p:plain
アカウントメニュー > 新しいデザインを試す

新デザインから旧デザインに切り替えるには、同様にログイン後のアカウントメニューより「旧デザインに戻す」をクリックしてください。

f:id:lambdalisue:20190904124818p:plain
アカウントメニュー > 旧デザインに戻す

ベーター公開のため、一部未実装の機能があります。未実装機能を利用する場合は旧デザインに戻してから利用してください

以下記事執筆時点(2019/09/04)で未実装の機能

  • 構成図上での検索機能
  • 構成図上でのノード詳細表示機能
  • Ksocket クレデンシャルファイルジェネレータ

[Sonar] 詳細情報の取得のためのアカウント情報の設定

ksocketは検知した機器に対して外部に公開されている情報を取得しますが、詳細情報の取得のためには、対象機器へのアカウント情報の設定が必要になります。本記事ではアカウント情報の設定方法に関してお伝えします。

対応プロトコル

ksocketは以下の形式のアクセスに対応しています。

  • SNMP(v2c/v3)
  • SSH
  • WInRM

設定ファイル

設定はtoml形式のファイルの記載し、以下のパスに格納します。

f:id:tomiyoichi:20190823110837p:plain
アカウント設定ディレクトリの構成

1つのアカウント情報ごとに1つのtomlファイルを作成します。また.skeletonファイルは記載方法のテンプレートとして用意されていますので、.tomlにコピーして利用してください。各プロトコルごとに記載し、ファイルのソート順の早い順で認証情報を適用してアクセスを試みます。

SNMP v2cの場合

例えば、以下のように記載します。

includes = ["10.10.0.0/24",
            "10.20.0.0/24"]

port = 161

[authData]
community = "public"

ここで"includes"ではアカウント情報を適用する対象のIPアドレスです。ksocketが検知した際に、ここに含まれているアドレスであった場合は記載されているアカウント情報を利用してアクセスを試みます。ここに記載したIPアドレス全てに対してksocketからアクセスを試みるわけでは無い点にご注意ください。

SNMP v3の場合

記述例です。

includes = ["10.10.0.0/24",
            "10.20.0.0/24"]

port = 161

[authData]
username = "snmp-user"

authProtocol = "usmHMACMD5AuthProtocol"
authKey = "your-password"

privProtocol = "usmAesCfb128Protocol"
privKey = "priv-password"

"authprotocol"には以下のいずれかを記載します。

  • 認証をしない場合: "usmNoAuthProtocol"
  • MD5を使用する場合: "usmHMACMD5AuthProtocol"
  • SHAを使用する場合: "usmHMACSHAAuthProtocol"

"privProtocol"には暗号化方式を記載します。

  • 暗号化をしない場合: "usmNoAuthProtocol"
  • DESを使用する場合: "usmDESPrivProtocol"
  • AESを使用する場合: "usmAesCfb128Protocol"

SSHの場合

パスワードログインの場合の例

includes = ["10.10.0.0/24"]

port = 22

[account]
username = "john"
password = "passw0rd"

鍵認証でのログインの場合の例

includes = ["10.10.0.0/24"]

port = 22

[account]
username = "john"

[[account.clientKeys]]
filename = "../../id_rsa.common"
passphrase = "secret_credential"

WinRMの場合

接続先側のWinRM接続を有効にするためには以下の記事を参照ください。 blog.cloud.kompira.jp

includes = ["10.10.0.0/24"]

port = 5985

authMethod = "ntlm"

[account]
username = "john"
password = "passw0rd"

"authMethod"には認証形式を記載します。"basic", "ntlm", "credssp"のいずれかから選択できます。

複数のアカウント情報が存在する場合

f:id:tomiyoichi:20190823113503p:plain
複数のアカウント情報が存在する場合

上記のように複数のアカウント情報ファイル(tomlファイル)が存在する場合には、以下の順序で処理されます。

  1. 100-test1.toml のアカウントを使ってsshアクセス試行する
  2. 200-test2.toml のアカウントを使ってsshアクセス試行する
  3. 300-test3.toml のアカウントを使ってsshアクセス試行する
  4. 999-example.toml のアカウントを使ってsshアクセス試行する

あるネットワークのゾーン内のアカウント情報を共通化させたい場合には、"includes"で指定する事が出来ます。言い換えれば、各接続先ごとに認証情報が異なる場合には、各接続先ごとにアカウント情報ファイルを用意する必要があります。

設定ファイルを暗号化/復号化する

TOML形式で保存されたアカウント情報は平文で保存されていますので、必要に応じて暗号化を行います。

$sudo /opt/fixpoint/ksocket/bin/ksocket encrypt (認証情報のtomlファイル名)

例
$sudo /opt/fixpoint/ksocket/bin/ksocket encrypt 999-sample.toml

拡張子".toml"が ".toml.kscrypt" という暗号化ファイルになります。 (ksocket本体はkscryptファイルを読み取り、内部的に復号処理を行って対象の機器にアクセスを行います。)

暗号化したアカウント情報ファイルを復号する際は以下のように行います。

$sudo /opt/fixpoint/ksocket/bin/ksocket decrypt (暗号化認証情報の.kscryptファイル名)

例
$sudo /opt/fixpoint/ksocket/bin/ksocket decrypt 999-sample.toml.kscrypt

拡張子".toml.kscrypt"ファイルが平文の".toml"に復号されます。複合後はテキストエディターで編集できるようになりますので、必要に応じて再度暗号化を行ってください。

暗号化設定ファイルの保存・バックアップ

ksocket は初回起動時に RSA 鍵ペアを作成保存します。暗号化・復号化では、ここで作成した RSA 鍵が利用されます。 暗号化されたファイルを別のksocket用サーバーに移動させるなど、 元のRSA鍵にアクセスできない場合には復号化は出来ません。 このためアカウント情報ファイルのバックアップや移動を行う際には、必ず復号化してから行ってください。

特に(コールドスタンバイ用などで)ksocketサーバーを複数運用してアカウント情報ファイルを共有する場合、kscryptファイルのコピーは利用出来ませんのでご注意ください。

ksocketからWindowsサーバーの接続受け入れ設定を一括で行う手順を公開しました

Sonarを用いてWindowsサーバーからの情報収集を行う際、ksocketのクレデンシャルファイルを作成すると共に、各ノードにWinRMの設定を行う必要があります。 この設定が大変、という皆様からの多くの声を受け、設定を一括で行うためのひとつの方法を簡易ながらマニュアルとしてまとめさせていただきました。

Active Directory環境下限定の方法とはなりますが、これから大量のWindowsサーバーを管理される予定の方は是非お試しください。

ksocket接続受け入れの一括設定マニュアル

引き続き、ご愛顧のほどよろしくお願いします。