go」カテゴリーアーカイブ

snmptrapもwakerで自動エスカレしたいのでラッパーを書いた

最近ネットワーク機器やストレージの面倒を見ることが増えてきて、そのあたりのアプライアンス使ってると監視のトリガーにsnmptrapを利用することがあります。現在ペパボでは自動エスカレーションにwakerを採用していることもあり、snmptrapからwakerにインシデント登録できるvolleyというラッパーを書きました。

サーバに配置して、snmptrapd.confに下記のように定義するだけで、wakerに通知してくれます。

traphandle default /usr/local/bin/volley -w https://waker.example.com/topics/XXXXX/alertmanager.json

WEB業界でsnmptrapかつwaker使っているところはそんなに多くないとは思いますが、使ってみて何かあればご連絡ください。

カテゴリー: go

パッケージの脆弱性管理サービスVeetaをリリースしました

以前より個人で開発していたパッケージ脆弱性管理サービスVeetaをリリースしました。

現状はAWSで個人資金にて運用しているため、1オーガニゼーション5台までの制限がありますが、無料で利用できます

Veetaのアーキテクチャは下記の通りです。

利用方法は、ドキュメントにも記載がありますが、以下の手順ですぐに始めることができます。

  1. オーガニゼーションを登録する
  2. 認証トークンを発行する
  3. クライアントをインストールし、認証トークンを設定する

この作業を行うだけで、クライアントであるVazがサーバ内のパッケージ情報を取得し、Veetaにアップロードし、自動的にスキャンしてくれます。

スキャンした結果はVeetaのコンソール上で確認することができ、脆弱性の詳細を確認したり、無視することができます。また、脆弱性の有無はレポート機能でメールやSlackに指定した時間に通知することが可能です。

解決したかった課題

以前よりペパボでは一部でVulsを利用して脆弱性の管理を行っておったのですが、Vulsには以下の課題がありました。

  1. スキャンユーザーでのSSHログイン設定が必要、もしくはローカルスキャンの環境作成が必要、ディープスキャンを行うには特権が必要
  2. Vulsはパッケージのドキュメント(changelog)をパースして、 CVE-xxxxxxxの文字列を拾っているだけで、必ずしも脆弱性の有無をチェックしているわけではない

追記
vulsはv4.0でバージョンでの比較にも対応しているようです!@kotakanbeさん有難うございます!

メール画像
引用元: https://github.com/future-architect/vuls/blob/master/README.ja.md#fast-scan

特に、複数サービスを運用するペパボではサーバの権限管理の観点から共有ユーザーに特権を与えるような運用は厳しい現状がありました。それを解消すべく、今回はクライアントサーバ方式を採用しています。

またVeetaのスキャン方式は取得したパッケージのバージョンとCVEデータベースの情報を全件チェックしているため、Vulsと比べて脆弱性の検知の精度が高い設計です。まだサービス導入期なのでサーバ台数は比較的少ない状態ですが、今後の利用者増加に合わせてスケールアウト可能な構成にしています。

追記
VulsはOVALの対応も行われていたため、いま時点ではVulsのほうが検出精度が高い場合が多いです。この機能はVeetaでも実装したいと思います。

余談的には極めて個人的な話ではあるのですが、ペパボではかねてより広報している通り、社内のサーバはOpenStackで構築された、プライベートクラウドNyahで運用しています。この場合、OpenStackに触れ合うことでクラウドサービスが何たるかを学ぶことはできるのですが、AWSが提供しているマネージドサービスや、アーキテクチャに対する知見を得にくい環境であるということが言えます。その点においてペパボのホスティング事業部の技術責任者の立場として非常に危機感を感じておったため、自己学習のために自分でサービスを立ち上げるという選択をしました。そして、そのバックエンドにAWSを利用することで学習機会を強制的に作ったという経緯です。

やっていきたいこと

パッケージ情報が集まり、どの脆弱性を人々が対応し、対応しないのかということが見えてくると思うので、そこにマシーンラーニングや、統計のロジックを入れて脆弱性の対応可否をある程度自動的に判別できるようにすることや、人々が脆弱性対応で疲弊しないような何かを考えていけたらよいなとボヤっと考えていますが、まだまだ足りない機能もたくさんあるので、息を切らさずやっていきたいなと思っています。内部の実装などは11/08に自社イベント、11/11にOFFTOKYOで話しますのでぜひ会場に足を運んでいただければと思います。

最後に

正直どれくらい世間のユーザーに利用されるか見えていないところではありますが、今後もサービスを育てながら運用してみたいなという気持ちがあります。運用資金など全く考えていないので、そのあたりはこれからというところではありますが、ぜひ皆さん利用していただいてフィードバックいただけたら嬉しいです!

カテゴリー: go

Muninなどのグラフデータを簡単に解析する方法

ペパボのホスティング事業部では主にnagiosで監視を行い、Muninを利用してシステムリソースの可視化を行っています。
先日ある改善を行った際に、各サーバの過去1日のロードアベレージにおける最高値、最低値、平均値を取得する必要があり、その際にそれらしいAPIがMuninになかったので、.rrdファイルをRRDToolを利用して解析し、jsonで結果を返却するprdというコマンドを開発しました。

使い方

$ prd example.jp-cpu-user-d.rrd | jq
[{
 "name": "example.jp-cpu-user-d.rrd",
  "max": 2010,
  "min": 1566,
  "avg": 1790
}]

このようなに引数にファイル名を指定すると、そのファイルを解析した結果をjsonで返却します。複数ファイルを渡した場合はこのように、複数の結果が返却されます。

$ prd example.jp-cpu-user-d.rrd example.jp-cpu-system-d.rrd  | jq
[{
 "name": "example.jp-cpu-user-d.rrd",
  "max": 2010,
  "min": 1566,
  "avg": 1790
},
{
 "name": "example.jp-cpu-system-d.rrd",
  "max": 1020,
  "min": 1136,
  "avg": 890
}]

僕自身の利用においてはSSH越しにMuninサーバに対して直接実行して、Rubyで解析してよしなに活用しています。もし既存の監視データを活かしつつ、何かをやる際の選択肢としてご検討いただければ幸いです。

カテゴリー: go

SSHのログイン先でも最適化されたvimが使いたい

サーバでオペレーションするときに、ちょっとトラブルシュートしたりするくらいならよいのですが、定期的にログインして作業するサーバがそれなりにあって、その生産性があまり無視できなくなったのでSTNSにstns-setupという機能を設けました。

STNS導入済みのクライアントでstns-setupコマンドを実行すると、事前に定義しておいたコマンドを実行することが出来ます。

$ stns-setup

アトリビュートはこんな感じです。

[users.example]
id = 1000
name = "example"
setup_commands = [
  "git clone https://github.com/pyama86/dotfiles.git /home/example/dotfiles",
  "/bin/sh /home/example/dotfiles/setup.sh"
]

もうアトリビュートを見るだけで何が出来るかお分かりですね?次にみなさんが求める記事を紹介します。

この機能を使えば自分のvimrctmux.confをログイン先のサーバでも簡単にセットアップすることが出来るので、使えたらラッキーくらいな感じで登録しておくと良いのではないでしょうか?

サーバ、クライアントともに0.3-3から利用可能で、エンドポイントは/v3を利用してください。不明な点やバグ等あれば@pyama86まで!

STNSが単体でのTLS暗号化&クライアント認証に対応しました

先日STNS,libnss-stnsともに0.2.2をリリースしました。主な変更内容は下記のとおりです。

  1. TLS暗号化に対応
  2. TLSを利用したクライアント認証に対応
  3. retry_requestパラメーターでクライントのリトライ回数を指定可能にした
  4. ubuntu14.04における再起動が完了しない不具合を修正

TLS関連

これまではnginxなどと組み合わせてTLS/SSL暗号化を提供していましたが、@naoto_gohkoさんからissueを頂いたのと、昨今みんな出来るだけサーバ立てたくないんだろうなぁというフォースを感じたので、単体でTLS暗号化に対応し、サーバ、クライアント共にパラメータを追加しています。
STNS.jp Configuration

tls_ca   = "keys/ca.pem"      # using only client authentication
tls_cert = "keys/server.crt"
tls_key  = "keys/server.key"

クライアント、サーバいずれもパラメーターの内容は一緒ですが、サーバのtls_ca及び、クライアントのTLS関連のパラメーターについてはクライアント認証を行うときだけ指定してください。

TLS暗号化だけを利用する場合

  • stns.conf
tls_cert = "keys/server.crt"
tls_key  = "keys/server.key"
  • libnss_stns.conf
api_end_point = ["https://example.jp:1104/v2"]

TLSクライアント認証を利用する場合

  • stns.conf
tls_ca   = "keys/ca.pem"
tls_cert = "keys/server.crt"
tls_key  = "keys/server.key"
  • libnss_stns.conf
api_end_point = ["https://example.jp:1104/v2"]
tls_ca   = "keys/ca.pem"
tls_cert = "keys/client.crt"
tls_key  = "keys/client.key"

クライアント認証を利用することでベーシック認証よりも堅牢になるので、グローバルな環境でより安心してSTNSを運用することが可能になります。

retry_requestパラメーターの追加

minneの踏み台サーバにログインできなくなった〜」という声を@hsbtさんから頂いたので調べてみると、STNSサーバに何らかの理由で疎通できなかったときに、nscdがネガティブキャッシュしてしまい、名前解決ができなくなっていました。NWの状況等に応じてはそれなりに起きることなので、クライアント側でリクエストをリトライできるようにしています。request_timeoutと合わせて利用することにより、問い合わせのミスを減らせると思うのでご活用ください。

ubuntu14.04における再起動が完了しない不具合を修正

@manabusakaiさんからフィードバックを頂いて、調査したところ、OS起動時にdbus-daemonが起動した際に、libnss-stnsがロードされて、コマンド実行を行う場合、またOS起動時にinitramfsで起動し、/usr/local/binなどが見えていない状態のときにコマンドを実行しようとすると、プロセスの起動、停止などが正常に動作しない状態になる不具合がありました。
straceで追いかけるとlibc.soに対してdbus-sendが失敗する挙動であったため、OS起動時にlibnss-stnsに対して、動的呼び出しが行われたとしても、以降の処理を行わず無視することで収束しています。普段自分が運用していないOSでの利用実績や、そのフィードバックを頂けて本当に助かりました。

実は本件、原因がわからず、30時間位ハマっていたのですが、I have matsumotoryなので、相談したら5分くらいでヒント情報もらえたのでホント便利。

その他

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-09-22-22-54-23

先日Qiitaに投稿されたLinuxユーザ管理の決定版? 〜STNSとサーバレスで夢が広がる〜【cloudpack大阪ブログ】の記事がバズっており、嬉しすぎてその日は3人位に缶コーヒーを奢ってしまいました。STNSを活用いただき、ただただ感謝です!こういった事例をみてhttp://stns.jpのドキュメントも拡充しておりますので、どんどんハックしてもらえれば幸いです。

STNS 0.2.0 Release!

STNS,libnss-stns,libpam-stnsの0.2.0をリリースしました。大きな変更点としてはパスワードの形式を/etc/shadow形式に統一し、より既存の環境から移行しやすいように変更しています。

主な変更点

  1. パスワードの形式を/etc/shadow形式へ移行
  2. wrapperコマンドで任意のHTTPヘッダを付与してアクセス可能になりました。#31
  3. debianでエラーが発生するためkey-wrapperコマンドの配置場所を変更しました#33

またフィードバックを頂いた@sawanobolyさん、@reiki4040さん、@fujiwaraさん有難うございました。

@sawanobolyさんに至ってはドキュメントがない中バックエンドの実装例まで記事にしていただき、感無量です。

記事を読んでいただけると、非常にシンプルなコードでバックエンドが実装できることがわかると思います。(いいつつも、エスパーしながらここまでしっかり実装出来るのすごいと思いました)

バックエンドの独自実装の未来を切り開いて頂いたので、私はドキュメントを整備しつつ、今後もフィードバックに答えられるよう開発していきます。

カテゴリー: go

~/.ssh/configを分割管理できるpincというコマンドを世に産んだ

初夏が猛暑!皆様いかがお過ごしでしょうか?
昨今、サーバインフラのクラウド化により一人のエンジニアが複数のサービスのサーバに対してSSH接続することも多くなってきました。また多くのサーバでグローバルIPを保つ必要がなくなり、リバースプロキシを置いて管理する構成が増えてきたように思います。そこで悩まされるのが~/.ssh/configの管理じゃないでしょうか?

ファイルが500行くらいになったり、新しいエンジニアが入るたびに

「xxxに接続したいんですけど、繋がらないんですよぉ~」

「なっぁぁぁにぃぃぃ~~~~!?この内容を~/.ssh/configに黙って書いてくれ!!!1」

なんてやり取り多いですよね。。そういったやり取りをなるべく少なく出来るようにGolangでpincというコマンドを開発しました。

インストール

OS Xで利用することが多いかと思いますのでhomebrewを準備しています。

$ brew tap pyama86/pinc
$ brew install pinc

使い方

$ pinc init

initコマンドにより~/.ssh配下にconf.dディレクトリ、pinc.ymlbase_configファイルが作成されます。

  • conf.d

配下に作成されたディレクトリ、ファイルを再帰的に読み込みます。

  • pinc.yml

includeディレクティブ配下に配列でファイル、ディレクトリを定義すると再帰的に読み込みます。

  • base_config

~/.ssh/configをコピーしたファイルです

$ pinc gen

initファイルで作成、定義されたファイルをマージし、~/.ssh/configファイルを作成します。

便利な使い方

複数サービスを提供している会社の場合、~/.ssh/pinc.ymlに下記のように定義することで、複数サービスの~/.ssh/configを一元管理できるようになります。

include:
  - /path/to/ServiceA_File
  - /path/to/ServiceB_Directory

このように定義しておくとServiceA、ServiceBの設定ファイルをマージして利用することが出来るので、都度都度定義する必要がなくなります。

最後に

Shellスクリプトでワンライナー管理しているような運用もあるとは思うのですが、シンプル、手軽に初められるのでpincぜひご活用下さい。

カテゴリー: go

パスワード暗号化について学びを得た

今日はパスワードの暗号化について書いてみたいと思います。
きっかけはSTNSにSudoパスワードを追加した際に@matuuさんよりご指摘をいただいたのがきっかけです。

スクリーンショット 2016-05-29 11.03.17

これまでパスワード暗号化に対する知見が全く無く、「とりあえずSHA256あたりでハッシュ化しとけば漏洩してもダイジョウV!!!」なんて思ってたものですから、これを機に調べてみました。

パスワードの暗号化が有効に働く機会として最も可能性が高いのは、サーバに何らかの手段で侵入され、データベース、ソースコードが参照された状態だと思います。要するに侵入者にすべてを見られた状態でもパスワードを知られ得ないことを目的として暗号化するわけです。

パスワードの暗号化時によく用いられる強固にする手法としてはSalt、Stretchingの2種類があります。今回はこの2点についてまとめてみました。

Saltを利用しパスワード暗号化を強化する

Saltというのは御存知の通り塩です。パスワードに塩を足して、いい塩梅にするわけです。前提となる話として、パスワードクラックの手法の一つにレインボーテーブルを用いた手法があります。
レインボーテーブルとは予め一定量の文字列をハッシュ化したものを辞書化しておき、辞書と突合することにより瞬時に元のパスワードがわかるというものです。たとえば、下記のようなコマンドの結果をひたすら作りこんでおけば、passwordp@sswordのようなパスワードは瞬時に破られてしまいます。

% echo -n 'password' | shasum -a 256
5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8  -
% echo -n 'p@ssword' | shasum -a 256
0fd205965ce169b5c023282bb5fa2e239b6716726db5defaa8ceff225be805dc  -

これに対する有効な対策として、パスワードの文字列を長くすることにより、辞書に登録され得ない値を設定することが挙げられますが、我々人類の多くは怠惰であり、パスワードマネージャーを使うのもニュータイプに限られるため、システム側でなんとかしてやる必要があります。
それに対する一つの手段がSaltです。具体的にはユーザーに入力されたパスワードに何らかの文字列を追加してからハッシュ化し、保存してあげることにより、ユーザーに意識させることなく、パスワード暗号化を強固にすることが出来ます。

手軽にやるのであればユーザー名をハッシュ化したものをSaltとして利用してあげるのが良さそうです。

% echo -n 'pyama' | shasum -a 256
6b513449d1d9f85a652dc54f440603ec19761708c801eb8cd12fc96ee6cedbc9  -
% echo -n '6b513449d1d9f85a652dc54f440603ec19761708c801eb8cd12fc96ee6cedbc9password'  | shasum -a 256    
6ae3462c59be78ddf4f8071694a6c090d89da90220a12e8b5e912d17440e3fcd  -

こうすることにより、レインボーテーブルの作成元となる文字列が6b513449d1d9f85a652dc54f440603ec19761708c801eb8cd12fc96ee6cedbc9passwordの72文字となり、事前にレインボーテーブルを作成することが困難な状態を作ることが出来ます。

Stretchingを利用し、総当り攻撃にかかる時間を稼ぐ

Saltを利用することにより、事前にハッシュの計算結果を用意しておくことは困難になりますが、総当りで全ての文字列のハッシュ値を計算する場合、いつか必ずパスワードは破られてしまいます。この場合、総当りにかかる時間を増加させることしか有効な対策がないため、Steretchingを利用します。
Stretchingとはハッシュの計算を多重化することにより、単純に計算にかかる時間を増加させることを目的とします。

簡単なShellスクリプトを書いて検証してみましょう。test.shは文字列passwordを引数で指定された回数+1回sha256ハッシュを計算します。

% cat test.sh
hash=`echo -n "password" | shasum -a 256`
for i in `seq 0 $1`
do
  hash=`echo -n $hash | shasum -a 256`
done
echo $hash
  • 1回 0.1秒
% time sh test.sh 1
7a55c84bff6647c28bd5367a810a6bfaf2320c95869474061bd9c7bc4e5c5012 -
sh test.sh 1  0.10s user 0.03s system 88% cpu 0.148 total
  • 100回 3秒
% time sh test.sh 100
52fdf2c067d2c39367f35319377ada40c835115f0dc928de922e59ec5305b02c -
sh test.sh 100  2.97s user 0.89s system 92% cpu 4.163 total
  • 1000回 30秒
% time sh test.sh 1000
5bbdcc1e453f6c315e577e941a6f34039e2821486002baec2b831f2d0e0d1f65 -
sh test.sh 1000  31.27s user 9.20s system 90% cpu 44.758 total

当たり前ですがこのようにStrethingを利用することで確実にハッシュの計算にかかる時間を増加させることができるので、総当り攻撃が成功するまでの時間を延長することが出来ます。今回は結果をわかりやすくするためにshasumコマンドを利用しましたが、もっと高速に計算できるコマンドもあるため、Stretchingについてはシステムの負荷が許す限り回数を増やすことが良いでしょう。

STNS v0.1.0で対応しました

ここまでの話を踏まえ、STNS v0.1.0でSaltとStretching対応しております。

salt_enablestretching_numberのパラメーターでそれぞれの機能を有効化することが出来ます。さらにパスワード生成用のコマンドも準備しています。

こちらはOS Xで利用できるようにhomebrewを準備しています。

% brew tap stns/stns_passwd
% brew isntall stns_passwd

手元でSaltの有無、Streching回数を指定してパスワードハッシュを作成することが出来ます。

% stns-passwd --help
Usage of stns-passwd:
  -c int
        The number of times to stretching
  -m string
        Specifies the hash function(sha256/sha512) (default "sha256")
  -s string
        String used to salt. The SNS is the user name
  -version
        Print version information and quit.
% stns-passwd -s pyama -c 1000000 p@ssword 
a3b20fc634ac4bad5be8a40566acb00adcd2e5bf2fb9be4750150553d529b799

まとめ

パスワードのDBへの保存の仕様は、新しく何かを作る時しか意外と調べることがなく、既存システム運用やってると全く触ることがない部分なので盲点で、自身はOSSを通じて学び直す機会があったの非常に良かったなと思いました。作ってるだけでフィードバック、学びがあるOSS最高だからみんなもっと作ったほうがいい。

カテゴリー: go

STNSでSudoパスワードをサポートした

STNS 0.0.4、libnss-stns 0.0.6リリースしました。今回の主な機能追加は下記のとおりです。

  1. sudoersアトリビュートでsudo用パスワードを指定可能にした
  2. STNSがダウンしている時にロックファイルを作成し、一定時間通信を抑制する

sudoersアトリビュートの追加

これまでSTNSを利用する場合、sudoersに下記のような設定を追加し、パスワード未利用での運用が必要でした。

  • /etc/sudoers

example ALL=(ALL) NOPASSWD:ALL

今回のアップデートにより、NOPASSWD:ALLを指定せずとも、Linuxの認証基盤であるPAMと連携することにより、sudo時のパスワードが指定可能となりました。

PAMについては@ITのSambaユーザーのパスワード管理 PAMを利用して認証を行うの記事がイメージをつかみやすいと思います。

まずSTNSに下記のような設定を追加します。

  • /etc/stns/stns.conf

[sudoers.example] password = "f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2" hash_type = "sha256" # $ echo "test" | sha256sum # f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2

これはsudoersの設定としてexampleを定義し、パスワードにtestという文字列のSHA256ハッシュを指定します。
このようにパスワードはハッシュ値で指定し、現状はSHA256とSHA512に対応しています。

次にsudoを実行するサーバのPAMの設定を行います。

  • /etc/pam.d/sudo

#%PAM-1.0 auth sufficient libpam_stns.so sudo example # この行を追加 auth include system-auth account include system-auth password include system-auth session optional pam_keyinit.so revoke session required pam_limits.so

lib_pam_stns.soの後にsudoと記載し、その後に、STNSに定義したsudoersの定義名を書いてください。この例ではexampleですが、実際にはSTNSのsudoers.<name>の定義と一致してれば任意の値で問題ありません。

例えば下記のようにも定義することが出来ます。

  • /etc/stns/stns.conf

[sudoers.ten_snapon] password = "946e235d658414a6dd1c3f8c3f2bf9aef06210e81a190911a307a5d2026e4b8e" # echo "portrait" | sha256sum # 946e235d658414a6dd1c3f8c3f2bf9aef06210e81a190911a307a5d2026e4b8e
  • /etc/pam.d/sudo

#%PAM-1.0 auth sufficient libpam_stns.so sudo ten_snapon …

先ほどexampleで定義した箇所をten_snaponとしております。
この状態で、sudoersで許可されたユーザがsudoコマンドを実行し、パスワードをportraitと入力するとsudoを用いてコマンドを実行することがきるようになります。

この使い方をする場合、実際の運用時にはサービス単位などで管理することが多いかと思います。加えて今回のアップデートではユーザー単位でもパスワードを指定可能としています。

ユーザー単位でsudoパスワードを指定する

従来のLinuxでの運用通り、ユーザー単位でsudoパスワードを指定することも出来ます。STNSのユーザーのアトリビュートにパスワードを追加してください。

  • /etc/stns/stns.conf

[users.example] id = 1000 group_id = 1000 directory = "/home/example" password = "f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2" # password = test

次に同じくPAMの設定を行います。

  • /etc/pam.d/sudo

#%PAM-1.0 auth sufficient libpam_stns.so # この行を追加

こちらは先ほどと異なり、libpam_stns.soの後に何も指定する必要ありません。これだけの定義でexampleユーザーがsudo可能な状態であれば、パスワード文字列testを入力することでsudoすることが出来るようになります。

また、PAMの定義をCentOSであれば/etc/pam.d/system-auth、debianであれば/etc/pam.d/common-authに下記のように定義を行えば、sudoのみならず、PAMを利用するSSHなどもパスワード認証することが可能になります。

  • /etc/pam.d/system-auth or /etc/pam.d/common-auth

#%PAM-1.0 auth sufficient libpam_stns.so

現状はパスワード用データストアを持っていないのでpasswdコマンドなどでクライアント側からパスワードを変更することは出来ませんが、公開鍵認証に対応していない古いOSでもSTNSを利用することができるので移行パスとして利用してみてはいかがでしょうか?

ロックファイルを作成し、タイムアウト時は一定時間問い合わせしない

libnss-stnsは問い合わせ先のSTNSサーバを複数定義することが出来ます。


api_end_point = ["http://aaa.com:1104", "http://bbb.com:1104"]

上記のように定義した場合、aaa.combbb.comに対してランダムな優先順位で問い合わせを行い、応答が得られ次第その値を採用し、問い合わせを終了します。

これまではaaa.comが何らかの障害でダウンしていた場合に、aaa.comに問い合わせた際、タイムアウトまで応答待ちしてしまう問題がありました。(その後bbb.comに問い合わせ結果を取得)

この場合にpsコマンドなど複数回の名前解決が必要なコマンドが異常終了してしまうケースがあったため、STNSサーバがタイムアウト、もしくは何らかのエラーが発生した場合はロックファイルを作成し、6秒間同一のサーバへの問い合わせを抑制するように修正を入れています。
これによって一度のコマンドで複数回名前解決を行うコマンドが異常終了されることが緩和されます。

最後に

今回のバージョンアップによって当初入れる予定ではななかったパスワードも管理対象となりました。現状はsha256,sha512の不可逆暗号のみ対応しておりますが、将来的にはvaultなどと組み合わせて使えるようになるとよいなぁと考えています。

またペパボ社内でも少しづつ導入が進んでおり、特にサービスに恐れることなく導入してくれた@udzuraさんや、僕が知見の薄いpuppet周りを整えてくれた@hfmさん、そして積極的に対外に情報発信してくださった@matsumotoryさんには感謝しかありません。

なにより一番使っている僕が導入楽だし、便利に使えているのでこのまま改善を続けてもっといろいろな人の選択肢になれば良いなぁと思っています。

それでは、また次回のアップデートまで。

カテゴリー: go

STNSに組織体系を管理するLinkGroup機能を追加しi386に対応しました

STNSとは

SSH公開鍵ログイン時の時の公開鍵の取得及びLinux上のユーザー、グループの名前解決を行う仕組みです。
設定ファイルにTomlを用いており、下記のワークフローでユーザー管理ができるようになります。

1.Pullリクエスト
2.レビュー
3.デプロイ

更新内容一覧

  • LinkGroup機能で部署体系を表現可能になった
  • i386に対応
  • Go 1.6対応
  • APIレスポンス修正
  • バグフィックス

LinkGroup機能で部署体系を表現可能になった

グループを定義する際に、グループに所属するユーザーをリンク可能となったことで、部署表現が可能となりました。

[groups.department]
id = 2000
users = ["example1"]
link_groups = ["division"]

[groups.division]
id = 2001
users = ["example2","example3"]

このような定義を行った時に、departmentにはexample1-3が所属し、divisionにはexample2-3が所属するというような表現出来ます。


$ id example1 uid=1001(example1) gid=2000(department) groups=2000(department) $ id example2 uid=1002(example2) gid=2001(division) groups=2001(division),2000(department)

APIレスポンス修正

これまではユーザーとグループのレスポンスが同じ形式でしたが、そのレスポンス形式を必要な情報のみ記載する形式としました。

  • before

$ /usr/local/bin/stns-query-wrapper /user/name/pyama { "pyama": { "id": 1001, "group_id": 1001, "directory": "/home/pyama", "shell": "/bin/bash", "gecos": "", "users": [""], ←グループでのみ使用する項目のため削除 "keys": [ "ssh-rsa xxxx" ] } }
  • after

/usr/local/bin/stns-query-wrapper /user/name/example1 { "example1": { "id": 1001, "group_id": 2000, "directory": "", "shell": "", "gecos": "", "keys": null, "link_users": null } }

バグフィックス

  • link_usersを利用した際に、リンク先のユーザーが存在しない場合に応答出来ない不具合を修正
  • stns-key-wrapperでchan_ssh_wrapperを利用した際に、正常に公開鍵を取得できない不具合を修正

まとめ

今回のバージョンアップで細かいバグも修正されているので是非バージョンアップして、最新版をご利用いただければと存じます。
インストール方法はGitHubのREADMEに記載しております。

カテゴリー: go