allow_ips = ["10.1.1.1/24"]上記のようなシンタックスがコンフィグにかけるようになりました。
用途としてはこれまで僕自身はクラウドサービスのSGでアクセス制限をしていたのですが、STNSをマルチクラウドで動かすにあたり、DNSフェイルオーバーを利用したいと考えました。その際にヘルスチェックをRoute53から行いたかったので、IPフィルターをサーバサイドで実装して、 /status はすべてのIPからアクセスを可能にして、それ以外のエンドポイントはIP制限を行うようにしました。
STNS自体がアクセスできなくなると、困るケースが多いと思うのでマルチクラウド化を進めていく際に活用していただければと思います。
僕は現在GMOペパボの技術基盤チームに所属しており、多くの開発基盤を運用開発していることに加えて、個人で開発しているOSSを数多くペパボ内で活用しているので、日に数回程度は社内のメンバーから問い合わせを受けることがあります。
その際に、Slackで
「ほいー、調べます〜」
とかで対応してしまう事が多いのですが、Slackの情報の流れは早く、検索のUXもさほど高くないことから、情報をストックするという観点ではあまり向いていないと僕は思っています。
そこで考えたのが Issuer-bot です。社内の大和田チャンネルで、:oowada: をつけるとowadaリポジトリにissueが作成されます。
こんな感じで、Slackからいい感じに本文を拾って、自動で登録してしてくれます。
登録のUIはスラッシュコマンドを用いており、
/register-reaction :oowada: tech/owada labelのように登録すると、登録したチャンネルとリアクション、リポジトリを紐付けることができます。 list や deregister もエンドポイントとして備えているので、一覧、削除も可能です。
ほかに想定しているユースケースは、MackerelやPrometheusからのアラートが来たときにピッとリアクションをつけてissueを作っておくと便利とかそういうのがあると思います。
Slackが主流になり、なかなかストック情報化が進まないという課題がある職場でご利用いかがでしょうか！
Twitterで @angel_p_57 さんからご指摘頂いて実装を追加した。
もともとパスワードより危ういというツイートを見て、色々聞いていると、おっしゃっている内容としては署名が流出した場合に、それを悪意を持って利用すると認証が突破できてしまうという問題提起を頂いているようだった。
一方で、僕自身は今回実装した認証はパスワード認証と比較すると危ういかというとそうとは思わない。理由としては下記がある。
加えて僕自信のユースケースとしては多要素認証の一要素としてこの認証を用いていたたため、署名の流出というかなり高い攻撃難易度を考えると妥当な実装であると考えている。
しかし、セキュリティ上安全であるに越したことはないので、利用者の意図を持って署名の再利用が困難になるようなチャレンジコードによる認証を追加した。実装としては認証前にクライアントからサーバにチャレンジコードを要求し、それに対する署名を作成して、サーバサイドでチャレンジコードと署名の検証を行うようにした。なおこのチャレンジコードは一回しか利用できない。これによって署名そのものが流出したとしても、その署名を利用したなりすましは原理的に困難になる。
考えられる攻撃ケースとしては悪意を持ったサーバが正規サーバにチャレンジコード要求を行い、払い出された値を、たまたま悪意を持ったサーバにチャレンジ要求を投げてきたクライアントに、正規サーバから払い出されたチャレンジコードを払って署名させるみたいなケースだが、これを防ぐならば何かしらのサーバ、クライアントを認証する仕組みのTLSクライアント認証なり、何かしらのシークレットキーを互いに持ち合うなどを追加すると良さそう。
最後に、今回Twitterでお話させてもらって思ったのだが、セキュリティの評価をするときにユースケースや背景にある技術をすり合わせずに話すと、原理的な話だけしかできなくて、攻撃容易性や危険度について正しい評価がされないなぁと感じたので、議論のベースをすり合わせてから話すのちゃんとやらないとなぁと思った。
ざっくりSTNSを利用するとこれまでLDAPなどで管理されてきたLinuxのユーザーをTOMLフォーマットの設定ファイルやDynamoDB、S3で管理できるようになります。またSSHログインの公開鍵認証などをかんたんに実現できるのがSTNSの優位性でした。
今回そのSTNSを利用して、下記のライブラリを活用するとあらゆるWEBサービスやCLIツールで公開鍵認証が可能になります。
サンプルコードとしては下記のようなものになります。
package main
import (
"fmt"
"github.com/STNS/libstns-go/libstns"
"github.com/k0kubun/pp"
)
func main() {
stns, err := libstns.NewSTNS("https://stns.lolipop.io/v1/", nil)
if err != nil {
panic(err)
}
user, err := stns.GetUserByName("pyama")
if err != nil {
panic(err)
}
pp.Println(user)
// id_rsaキーで署名する
signature, err := stns.Sign([]byte("secret test"))
if err != nil {
panic(err)
}
// pyamaの公開鍵で署名検証できた
fmt.Println(stns.VerifyWithUser("pyama", []byte("secret test"), signature))
// 文字列が異なるので署名検証できない
fmt.Println(stns.VerifyWithUser("pyama", []byte("make error"), signature))
}実装としては任意の値を ~/.ssh/id_rsa などの秘密鍵で署名し、その署名をSTNSで公開されている公開鍵で検証し、検証成功すればそれはSTNSに登録されたユーザーであると認証することができます。
勘の良い方は気づいたかと思いますが、SSHのログイン時に利用されている公開鍵認証相当のことをあらゆるシステムで可能にしたというのが今回の実装です。
まず公開鍵認証を利用することで一般的なID/Password認証よりも比較的暗号強度が高い認証を行うことができます。さらには多要素認証の一つとして活用いただくのも良いと思います。
あとは社内で利用するツールを開発するときに、OAuth認証は容易に利用できるので僕も重宝しているのですが、CLIツールから利用するとなると非常に手間がかかります。そういった場合に、この仕組を利用するとCLIで完結するかつ、強力な認証を利用できます。
今回実装してみて思ったのですが世の中意外とそんなに公開鍵認証って実装されてるものって少ないなぁと思ったりもしました。今回の実装の追加でSTNSを利用したおもしろ隙間ソフトウェアとかもできるようになると思うので、是非活用いただいて、ブログなど書いていただけると大変に嬉しく思います。
ちょっとかんたんに試してみたいのだけど！という方がいらっしゃいましたら、STNS as a Serviceもあるのでお試しください。
ペパボでは新型コロナウィルスをきっかけに、全社でのリモートワークを前提とした勤務体制を取っています。それにあたり、いろいろな工夫をしているわけですが、開発者が利用するイントラAPIなどを安全に利用するために、VPNを利用するケースは非常に多いと思います。しかし、VPNについてはネットワークによる認可の細かい制御が難しく、基本的にVPNのエンドポイントにつなげると何でもできてしまうという状態になってしまいがちです。そういった課題を解決するために、僕が社内に提供するサービスはなるべくTLSクライアント認証を利用して、ネットワークの認証を行ったあとに、更にアプリケーションで認証・認可を行うようにしています。
またTLSクライアント認証に利用するクライアント証明書、鍵のセットはHashicorp VaultのPKI基盤を利用して払い出しており、こちらもGHEのOrganization/Repository/Teamの情報とリンクする形式で認可を行っています。
一方でHashicorp VaultはAPIを実行したり、クライアントCLIを利用したり、または管理者向けのWEBUIはあれど、この手のミドルウェアを利用したことがないエンジニアに、ここから認証後に鍵取得して、あとはよろーというには少々厳しい現実があります。
それらを解決するために開発したのがKagianaです。
Kagiana自体はGitHub(厳密にはGitHub Enterpriseを利用しています) の提供するOAuth認証を行ったあとに、Kagianaで指定したPKIエンドポイントから証明書と鍵のダウンロードを行います。イメージとしては下記のとおりです。要するにKagianaの設定ファイルで指定してある証明書、鍵をWEBUIで認証し、払い出すことができる仕組みです。
ペパボではKagianaで認証後に、Vaultに接続が可能な証明書、鍵をダウンロードすることで、利用者をVaultに接続可能にします。その後、Vaultで認証・認可を行うことで、そのユーザーが利用可能な証明書と鍵がダウンロードできるようになります。
更に、上記図の5にあたる証明書の管理については consul-template を手元の端末で起動できるスクリプトをLinux、MacOSの環境それぞれ準備しており、インターナルなKagianaの管理リポジトリで、 make install と実行するだけで、利用者の手元で consul-template が起動し、自動で証明書の取得、更新管理を行ってくれます。配布している consul-temlate の設定は下記のようなものです。
max_stale = "10m"
log_level = "info"
pid_file = "/tmp/consul-template.pid"
vault {
address = "https://vault.example.com"
renew_token = true
ssl {
enabled = true
verify = true
ca_path = "~/.kagiana/vault.example.com.ca"
cert = "~/.kagiana/vault.example.com.cert"
key = "~/.kagiana/vault.example.com.key"
}
}
template {
contents = "{{ with secret "example.com/issue/example.com" "common_name=vault.example.com" }}{{ .Data.issuing_ca }}{{ end }}"
destination = "~/.kagiana/vault.example.com.ca"
}
template {
contents = "{{ with secret "example.com/issue/example.com" "common_name=vault.example.com" }}{{ .Data.certificate }}{{ end }}"
destination = "~/.kagiana/vault.example.com.cert"
}
template {
contents = "{{ with secret "example.com/issue/example.com" "common_name=vault.example.com" }}{{ .Data.private_key }}{{ end }}"
destination = "~/.kagiana/vault.example.com.key"
}
このような設定ファイルを定義して起動すると、Vaultから取得した証明書の有効期限を consul-template が監視し、自動で証明書を失効前に更新してくれます。さらには必要に応じて、更新したタイミングで何かしらのコマンドを実行することができます。例えばWEBサーバであれば証明書を更新したあとにWEBサーバをリロードするというような定義をすることはよくあります。
ちなみに、なぜ consul-template を利用するのかというと、これらの仕組みで提供する証明書の有効期限を1日程度と非常に短い値にすることで、主に退職時などにおける鍵の失効管理をなくしたいという狙いがあるためです。実態としてはVaultでアカウントが認証できなくなることで鍵の更新ができなくなり、自動的に失効するような運用を行っています。一方であまりに短い期間で証明書を手動で更新するのは非常に手間なので、 consul-template で更新を自動化しているということです。更にこの仕組を利用すればリポジトリにおいてある、 consul-template の設定ファイルを更新、配布するだけで全開発者に利用を許可する証明書を一括で配布することができるので管理者としても非常に運用が楽です。
ここで一つ与太話なのですが、Linux、MacOSの各環境の consul-template の起動スクリプト生成に Foreman を利用しています。僕も今回知ったのですが、 Foreman には export というサブコマンドがあり、下記のようなProcfileをまず定義します。
consul-template: /usr/bin/env PATH=$PATH:/usr/local/bin consul-template -config=./consul-template/my-config.hcl
そして foreman export systemd <dest> <option> -f myProcfile と実行するとsystemd の起動スクリプトを出力してくれます。そしてこれが launchd などにも対応しているので、各環境の起動スクリプトのグルー技術として非常に便利でした。下記のリンクにある通り、いろいろな出力が可能なので知っておくと、今後Linuxデスクトップも増えてくると思うので便利だと思います。
今回はTLSクライアント認証に利用する証明書、鍵を何かしらの認証後に取得し、その証明書を利用して必要な認証、認可をしていくというようなまさに鍵穴となるようなソフトウェアを開発しました。おそらくこの仕組はしばらくペパボ内でレバレッジを効かせながら使われていくソフトウェアになると思うので継続開発していく予定です。同じような課題をお持ちの方、認証方法の追加のご希望などあればIssueを書いていただければ諸々検討するので、ぜひお気軽にご連絡ください。
先日ペパボのあるサービスでKubernetes1.12系から1.17系に更新した際にflannelに起因したパフォーマンス問題が発生したので紹介します。
なお、本事象はGitHubのIssue上に情報がありますが、日本語話者の情報はあまりないので記事に書くことにしました。
余談を最後に書くと、1.12系から、1.17系のウルトラジャンプがなせたのは、AWSとオンプレミスOpenStackなハイブリッドクラウド環境なので、クラウドをまたいだBG運用ができるからこそなせる技だと思います。それでは本題になります。
事象として、1.17にバージョンを上げた直後から、WEBサーバのレスポンスが全体的に1.5～2倍程度遅くなったという事象が発生しました。
その際に調査として下記のようにcurlの出力を変更して調査したところ、接続処理が遅いということがわかりました。
# cat time-format.txt
time_namelookup: %{time_namelookup}s\n
time_connect: %{time_connect}s\n
time_appconnect: %{time_appconnect}s\n
time_pretransfer: %{time_pretransfer}s\n
time_redirect: %{time_redirect}s\n
time_starttransfer: %{time_starttransfer}s\n
----------\n
time_total: %{time_total}s\n
curl -I -w @time-format.txt -s 10.240.0.125:xxxx/example -H "Host:api.example.com"
...
time_namelookup: 0.000s
time_connect: 3.002s
time_appconnect: 0.000s
time_pretransfer: 3.002s
time_redirect: 0.000s
time_starttransfer: 3.349s
----------
time_total: 3.349s
3.349秒のうち、time_connectが3.002秒なので、接続処理が支配的というのがわかります。
次にKubernetesでflannelを利用している場合、NATを利用して通信されるため、接続にあたりを付けるために、conntrack tableを覗いていきます。
# conntrack -L -n|grep 31576 |&grep -v TIME_WAIT conntrack v1.4.3 (conntrack-tools): 2922 flow entries have been shown. tcp 6 118 SYN_SENT src=10.240.0.125 dst=10.240.0.125 sport=40112 dport=31576 [UNREPLIED] src=10.233.86.51 dst=10.233.79.0 sport=80 dport=15474 mark=0 use=1
このとき、何度かコマンドを実行していると SYN_SENT でしばらく表示されるレコードがあることに気づきました。ここまで絞れると、お得意の古代兵器である程度原因を特定することができます。
~# tcpdump -i flannel.1 dst port 80 and src host 10.233.79.0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on flannel.1, link-type EN10MB (Ethernet), capture size 262144 bytes 17:01:03.483430 IP 10.233.79.0.10024 > 10.233.71.50.http: Flags [S], seq 2340116947, win 43690, options [mss 65495,sackOK,TS val 151530136 ecr 0,nop,wscale 7], length 0 17:01:04.481397 IP 10.233.79.0.10024 > 10.233.71.50.http: Flags [S], seq 2340116947, win 43690, options [mss 65495,sackOK,TS val 151530386 ecr 0,nop,wscale 7], length 0 17:01:06.485388 IP 10.233.79.0.10024 > 10.233.71.50.http: Flags [S], seq 2340116947, win 43690, options [mss 65495,sackOK,TS val 151530887 ecr 0,nop,wscale 7], length 0
flannelのインターフェースを覗いていると、Synパケットを再送している処理を確認することができました。これで何かしらの問題が発生して、Synパケットが到達できていないという事象が特定できたのであとはおもむろに「Kubernetes 1.17 flannel syn」とかでGitHubのIssueを探してみます。
Issueではflannelを利用しているかつ、処理が低速である場合にSynパケットが再送され、かつ、その2パケット目がiptablesでマークされないことからこの事象が発生すると述べられており、対応方法としてはnicのTCP Offloadを無効にすることが挙げられていました。要はnicでのパケット分割をやめてカーネルでやるということです。
この事象以外でもTCP Offloadは度々踏み抜くことがあり、またお前か・・・という気持ちになりましたが、下記で無事解決。
# ethtool --offload flannel.1 rx off tx off
前述の問題を解決してめでたしめでたしと思っておったところ、次はサービスのピークタイムにおいて、レスポンスタイムが律速になるという問題が発生しました。ピークタイムということからアクセス数もしくはコネクション数に起因する問題というのはすぐに経験から想定できたので、contrack周りを調べましたが、特にコネクション数がシステム上限を超えているような状況ではありませんでした。しかし、ワークアラウンドとしてサービスの受け口となるKubernetesのIngressを増やしたところ症状が良化したたため、なにかネットワーク周りの問題であることは間違いなさそうということだけがわかっていました。
何か類似の事象があるはずと思い、GitHubのIssueを探していると下記のIssueを見つけました。
また上記から参照されているIssueは下記です。
これらは端的にはLinuxにおいてiptablesがポート採番でレースコンディションになり、パフォーマンスが低下するのを避けるために、iptablesのオプションとして --random-fully を採用するというものです。
このフラグについては下記ページが詳しいです。
対応としては我々が利用していたKernelではiptablesのバージョンが低く、上記のフラグを利用できなかったため、Kernelとディストリビューションを変更することで根本的な対応を行いました。
今回起きたものは割とKubernetesというよりかはLinuxのレイヤーに関連するもので、やはりKubernetesが導入されて楽になった部分はあれど、パフォーマンスの問題が起きたときに解決するためには古代兵器を活用できることや、Linuxカーネルに対する理解などが必要になるなぁと思いました。一方で、Kubernetesに対する理解がないと解決できないのも事実なので、自分の得意な領域で慢心することなく、どんどん知識を増やしていかねばなぁとおもたので、Pythonと機械学習の本を買ったのが今です。それでは、皆様良い週末をお過ごしください。
最近仕事でElasticAPMを導入しているのだけど、その際にelasticapmのgemがtmpディレクトリを利用する。kubernetesで動作させるアプリは可能な限りreadOnlyRootFilesystemということもあり、試していると下記のエラーに出くわした。
usr/local/lib/ruby/2.6.0/tmpdir.rb:35:in `tmpdir': could not find a temporary directory (ArgumentError)理由は下記のブログが詳しい。
先のブログだと、Rubyにモンキーパッチを当ててるのだけど、うーむという感じで考えてみたら、普通にinit containerでsticky bit与えればええやんということに気づいた。
volumes:
- name: tmp
emptyDir: {}
initContainers:
- name: setup-tmpdir
command: ["sh", "-c", "chmod 1777 /tmp && ls -lda /tmp"]
image: busybox:latest
imagePullPolicy: IfNotPresent
volumeMounts:
- mountPath: /tmp
name: tmp
こんな感じでmanifestを書くと、モンキーパッチを入れる必要がない。
個人的な思想信条なのだけど、アプリケーションのコードに環境に依存するようなコードを入れるのはこれからのインフラの局面を考えるとあまりベターではないように思う。アプリケーションレイヤーは分離して、アプリケーションはどのような環境でも動くという状態で記述するのがいいと思うので、モンキーパッチをせずに、アプリケーションとインフラの中間にk8sという環境があるわけだからそこで吸収するとシンプルに構成管理できるんじゃなかろうかと思う。
こんにちは!!1
awk、してますか？？？
はい、というわけで僕は普段OpenStackを触っているときによく下記のようなコマンドを打ちます。
$ openstack server list | grep example |awk '{print $2}' | xargs -o -n1 openstack server showこの中の、 awk '{print $2}' これで2カラム目のサーバのID列を抽出するのですが、やりたいことに対してタイプ数が多すぎる。
一時はtrとか覚えようと思ったが毎回オプションを忘れてしまう。
そんな悩みがあるのは僕だけじゃないはずです。そして、僕が考え出した神がかった関数がこちらです。
function t() {
cat - | awk "{ print \$$1 }"
}
これをzshrcなりに定義しておくと、
command | t 1とか打つだけで、1カラム目が取得できます。awk使うとき、大体スペース区切りだしこれでいいやろ的なアプローチですが、よくやる作業ならこのタイプ数、馬鹿にできないので、ぜひおすすめです！
GMOペパボではPuppetをサーバのミドルウェアインストールやセットアップに利用しているサービスが多くあり、ユースケースとしてはサーバ・クライアント構成でサーバにPuppetの資産をCapistranoなどでデプロイして、クライアント側で puppet apply コマンドを利用して開発しています。
一方で、僕が開発しているサーバは基本的にはChefないし、Itamae(mitamae)を利用して開発しており、特にいま一緒に仕事させていただいる @sawanoboly さんが開発しているKnife Zeroを1日に549858回くらい実行しています。
そんな僕がPuppetを利用する場合に非常に手間に感じるのが、開発サーバなどでレシピを開発しているときに、変更のたびにマニフェストをPuppetサーバにデプロイしないといけなくて、それが非常に手間に感じており、僕はあまりやらないのですが本番サーバに直接手で変更を加えて、Puppetに書き戻すというようなオペレーションも散見されていました。これはスノーフレークサーバを作ってしまう習慣となり得るので、システムを開発運用する上で望ましいこととは思えませんでした。
これらの課題を解決するために、開発においていちいち資産をデプロイしなくてもPuppetをApply出来る、Peroというgemを開発しました。この名前はあんちぽさんがのりでPeroとどっかに書いたのをそのまま採用したのですが、ソフトウェア自体が前述のKnife Zeroに影響をうけているので、Puppet Zeroの略なのかもしれません。
作りとしては非常にシンプルです。
localhost:8140 を laptopのPuppet Serverプロセスにポート転送。localhost:8140 をPuppetサーバとしてApply.まずpuppetをクライアントにインストールするとともに、Peroが利用する構成情報を作成します。
$ pero install --agent-version 6.17.0 example.comあとはこれらの情報を基に、マニフェストをApplyすることが出来ます。
$ pero apply --noop example.com
$ pero apply example.com手元からデプロイ無しでマニフェストをApply出来るだけでもハチャメチャ便利なのですが、いくつか便利な使い方があります。
puppet apply -C5 example.* のように登録されたノードを正規表現で指定できるようにしてあり、合致したノードに並列してマニフェストをApplyすることが出来ます。
またinstallコマンドも複数の引数を受け付けることが出来るので、下記のように一気にインストールすることが出来ます。
$ pero install --agent-version 6.17.0 10.1.1.1 20.1.1.1これが最大のメリットだと思うのですが、サーバ・クライアント構成をとっている場合に、双方を一気にあげてしまうか、何かしらの環境を作り込まないとバージョンアップしづらいのがPuppetのサーバ・クライアント構成運用の大変なところだと思います。しかし、PeroはPuppetサーバをDockerで起動するので、例えばPuppet5ブランチと、Puppet6ブランチを共存して運用することが用意になります。これまですべてのロールを一気にバージョンアップするのが辛くて、バージョンアップが進んでいないようなリポジトリやサービスも、Peroを利用すると既存の環境に影響を与えることなく、安心してバージョンアップすることが出来ます。
もともとは最近色々な商材のPuppetを触る機会があって、ぼくがふわっと立てたIssueがきっかけだった。
ちょうど一ヶ月くらい前だったんだけど、そこからなんとなく頭の片隅にありながらも証明書の扱いどうすっかなぁと考えていたりして、最初はsshfsでmasterの証明書ディレクトリをマウントしてしまうかとかも考えたのだけど、何かの拍子にunshareが振ってきて、今の実装を思いついて、合計3〜4日くらいで出来たと思う。
僕は仕事でたまたまコンテナの基礎技術を @udzura の影響で扱うことがあったから着想出来たけど、まあこれも普段からLinuxプログラミングインターフェースを読んだり、そういうコミュニティで活躍してたから思いつけたなぁと思っていて、こういう発想を得て、課題を解決出来うるためには日々精進だなぁと改めて思った。
先日リリースしたcache-stnsdを利用していれば、オリジンサーバがダウンしている場合はキャッシュから応答するようにしました。
課題感としては僕が所属しているペパボにおいて、クライアントサーバのNW系のトラブルなどでSTNSサーバに接続できない場合に、調査しようとしてSSHログインしようとするのだが、そもそもSTNSに接続できないので名前解決ができずにSSHログイン出来ないという問題がありました。それらを解決するためにSTNSサーバに接続できない場合は、キャッシュから応答出来るようなパッチを入れたので、ぜひcache-stnsdをご活用ください。cache-stnsdの利用はcache-stnsdをインストールして、 /etc/stns/client/stns.conf に use_cached = true と記述すれば有効になります。
お盆休み明けに是非お試し下さい！！１