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

Kompira cloudについて、12月11日下記の機能を含むアップデートを行います。

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

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

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に関しては引き続きご利用いただけますが、今後は非推奨という扱いになります。

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

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

Pigeonの連絡に使用するAPIについて、新しいAPIを12月11日に公開します。

  • 連絡実行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": "bf72caa6-34fa-4032-aaa1-cf6136c9a9a5",
    "guidanceId": "60125ed2-4f8a-485d-8c60-d885ad76f37a",
    "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":"bf72caa6-34fa-4032-aaa1-cf6136c9a9a5","guidanceId":"60125ed2-4f8a-485d-8c60-d885ad76f37a","parameters":{"server":"テスト用サーバー","incident":"軽度の障害"}}}'

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

{
  "params": {
    "callflowId": "bf72caa6-34fa-4032-aaa1-cf6136c9a9a5",
    "guidanceId": "60125ed2-4f8a-485d-8c60-d885ad76f37a",
    "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ファイルのコピーは利用出来ませんのでご注意ください。

メール送信によりPigeonの連絡を行う機能をβ公開しました

PigeonはAPIリクエストをトリガとして、誰かに繋がるまで自動的に電話連絡を行うサービスです。 APIリクエストを行うことができるシステムとであれば何とでも連携ができ、その一例として本ブログでもZabbixとの連携について、過去に紹介いたしました。

blog.cloud.kompira.jp

一方で、連携するシステムによってはAPIリクエストを行うことができなかったり、かなりトリッキーな設定が必要になるケースがあります。 先述のZabbixとの連携例においてもサーバー上にわざわざスクリプトを配置しているなど、一手間必要になってしまっているのがわかります。

そこで、今回新たに「メール送信をトリガに連絡を行う」機能のβ版を公開いたしました。

なお、本機能はβのため、使用には個別のシステム設定が必要となります。ご利用を希望する場合は本記事末尾の記載に従い、利用希望の旨ご連絡ください。

機能の概要

特定のメールアドレスに対して書式に沿った形でコールフローID・ガイダンスIDを記載したメールを送信すると、その内容を用いて連絡を実行します。

送信先メールアドレスについて

β版ではご利用のスペースのスペースID( スペースURL https://xxxxx.cloud.kompira.jpxxxxx にあたる文字列 )に基づいてメールアドレスが決まります。 例えば スペースID xxxxx の場合は下記のアドレスを使用します。

xxxxx+5162a03d-b059-4097-a513-f150b018e47c@cloud.kompira.jp

xxxxx をご利用のスペースIDに置き換えてご使用ください。β版ではスペースIDより後ろの部分は上記のまま変更しなくて構いません。 (正式版では仕様が変わりますのでご注意ください)

送信内容について

メール本文に下記の2行を記載してメール送信を行なってください。 (IDの値は連絡に使用するコールフロー・ガイダンスのIDに置き換えてください)

callflowId: 85f0a373-8b54-4c70-85a6-71957ecf7f48
guidanceId: e689a0ea-8678-4c68-b832-8b3f8e402398

上記2行が含まれていれば、前後に別の内容を記載しても問題ございません。 また、件名は自由に設定していただいて構いません。

制約事項

β機能につき、現在下記の制約があります。

  • ガイダンスへパラメータを与えることができない
  • 平文またはBase64以外のエンコード形式を受付できない

特に後者の制約により、メール送信に使用するクライアントの種類や設定によっては連絡開始が上手くいかない可能性がありますので、ご了承ください。

連携例(Zabbix)

本機能を用いて先述の記事に記載したZabbixでの連絡アクション作成を行なってみます。

記事の内容に従ってコールフロー・ガイダンスのIDを調べた後、下記のようにアクション作成を行います。 (先述の通りガイダンスパラメータは使用できないため、パラメータを使用しない形に文面は調整しておきましょう)

f:id:honda_fixpoint:20190805140808p:plain

f:id:honda_fixpoint:20190805141249p:plain

以上の設定を行なってアクションの発火を行うと、ZabbixからPigeonへメール送信が行われ、これをトリガにPigeonの連絡が実行されます。
Zabbixはメール送信を取り扱いやすく作られているため、APIリクエストを行う方法よりも遥かにシンプルに設定が出来ていることがわかります。

ご利用希望の方へ

本機能を利用するには個別のシステム設定が必要となりますので、ご利用を希望される場合は下記の内容でメールにてご連絡ください。

項目 内容
メールアドレス devcloud@kompira.jp
件名 メールトリガ連絡ご利用希望
本文 会社名・ご担当者名・スペースIDを記載してください。
(スペースIDの調べ方は「送信先メールアドレスについて」を参照してください)

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

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

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

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

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