Posts for: #Auth

yubikey bio を購入してみた

0時に寝て7時に起きた。午前中は洗濯して、昨日届いたお肉を焼いて朝ご飯にしながらドラクエタクトやってた。

yubikey bio の購入

デスクトップマシンが不調だった1-2ヶ月ほど m2 macbook air でお仕事をしていた。デスクトップマシンと比べて明らかに便利だったことがある。1password にログインするときに os のシステムアカウントも利用できて、具体的には指紋認証によりパスワード入力を必要としなかった。デフォルトでは2週間ごとにパスワード入力を必要とする設定になっているが、これも無効にすることもできる。パスワードを忘れないように1ヶ月に1回ぐらいは手入力してもよいかもしれない。生体認証はその精度にまだ懸念はあるそうだけど、こういった日常的な認証における用途ならそれほど高い精度を要求しないことに気付いた。私は個人でお仕事しているから日常でオフィスに保管している物理的なデバイスを盗むのは難しい。他にも linux で使える指紋認証のデバイスを探してみた。しかし、現時点では usb の指紋認証デバイスは windows 一択になっていて linux はサポートされていない。YubiKey ぐらいしか、私はみつけることができなかった。

YubiKey Bio - FIDO Edition をオンラインストアで購入した。船便で購入したので届くまで1ヶ月ほどかかる。急ぐものではないので気長に待つ。

YubiKey Bio - FIDO Edition
$90

Shipping & handling
Economy - 10-20 Working Days - No tracking available
$5

Duties, taxes and/or carrier subcharges
$14.68 USD

日本にお店がないので輸入扱いで関税がかかるのかな?また会計システムに登録するときに税金の計上方法を調べる必要がありそう。

自分たちでやろうとしないことを他人は助けられない

他社のプロジェクト開発のお手伝いでプロジェクトマネージャーとしてこの半年をマネジメントしてきて分かるようになったことが1つある。米軍がアフガニスタンから撤退するときの方便のようにみかけ、ロシアのウクライナ侵攻のときにウクライナ軍が善戦して西側諸国の支持を得たことでその正しさを再確認できた言葉がある。

バイデン大統領は演説で「当事国の軍隊が戦う意思がないのにアメリカが戦うわけにはいかない」という趣旨を繰り返した。

アフガニスタン崩壊と日本への教訓

2月からプロジェクトの開発遅れがみえていてスケジュール調整している。プロジェクトの開発がうまくいかないことの全責任は私にあることは間違いない。その点には一切の懸念も疑問もない。昨今の働き方改革で有休取得が大事なことも理解していて、平均して取得するなら毎月1-2日休むことになる。それは理解できるが、開発が遅延していても有休で休み、その遅延をマネージャである私が休出して開発を肩代わりするという調整を1ヶ月以上続けてきて、この歪みは開発やプロジェクトにとってよくないということもわかってきた。

私個人のモチベーション管理にも多少の影響はあるが、私は指示されて休出しているわけではなく、自分の目的のためにやっているのでこの影響はそれほど重要ではない。

なにが問題かというとプロダクトオーナーシップを開発者がもたないという点にある。私はお手伝いであるから、いずれいなくなる。周りからどうみえようと最終的にプロダクトオーナーシップは契約形態としてもてない。そして、お手伝い先の開発メンバーがもつようになるのが望ましい。しかし、そういう雰囲気はみえない。これまで他社の人間がマネージャーをやっているようなプロジェクトに私が参加したことがなかったためにそういった視点がなかった。そして、私は自分がイニシアティブをもって開発するプロダクトはすべてプロダクトオーナーシップをもって臨んできた。そのため、開発者に裁量を与えることで必然的にプロダクトオーナーシップをもつようになると信じてきたが、いまのやり方だとそうならない気がしている。なぜならば、放っておいても問題になる前に私が勝手に対応してしまうために開発者のインセンティブやモチベーションを阻害してしまうからだ。

プロジェクトにおけるスケジュールや品質を担保するためにはマネージャーである私が一定の尽力をするのは合理的ではある。一方でそれをやり過ぎることで開発メンバーのプロダクトオーナーシップを遠ざけてしまう。プロダクトオーナーシップをもっていない開発者が休出してまで開発に尽力する意味など普通にはない。仮に私が開発メンバーでもそう思うだろう。昔の上長 がやっていたことをみて私が学んだことを、外部の人間として開発メンバーに教えることはとても難しいことを理解できた。

rabbitmq 再び

0時に寝て3時に起きて6時半に起きた。前日あまり寝てなかったから普段よりよく眠れた。

rabbitmq の認証

たまたまなのだけど、前のお仕事でも rabbitmq を使っていて、いまのお仕事でも rabbitmq を使っている。私の中では kafka のエコシステムに感銘を受けたので私が技術選定してよいなら kafka を使っていきたいところだけど、rabbitmq も人気があってすごいなと思う。インフラを触っていて rabbitmq の認証をしていないことに気付いた。rabbitmq の docker image を使うとデフォルトで guest/guest のユーザーが作られる。

If you wish to change the default username and password of guest / guest, you can do so with the RABBITMQ_DEFAULT_USER and RABBITMQ_DEFAULT_PASS environmental variables. These variables were available previously in the docker-specific entrypoint shell script but are now available in RabbitMQ directly.

おそらくメッセージのやり取りを通信するときも何も指定しなかったら guest ユーザーとして扱っているのかな?通信するときの RabbitMQ URI Specification によると、amqp://user:pass@host:10000/vhost のような、昔ながらの uri にユーザー/パスワードを埋め込むような認証になる。このやり方だと uri 自体が credentials になってしまって運用の使い勝手が悪くなってしまうものの、アプリケーションの変更は必要ないというメリットもある。おそらく歴史的に認証は後付けで追加されたのかな?ともかく実際の運用だとユーザー/パスワードでアクセス制御を行うだろうと想定されるので気付いたタイミングで開発環境の docker image の設定と uri の変更を行った。

時事ネタの気軽な雑談会

【おはなし会】CEXだって安全にできるもん に参加した。ちょうさんは fin-py のイベントで何度か発表を聞いたことがある。データサイエンス系のお仕事をされているのかな?ftx 事件 をうけて ethereum の創始者である vitalik buterin 氏がブログに投稿したアルゴリズムの解説をされていた。

取引所の不正を防ぐための仕組みとして、それぞれの口座の残高を公開しなくても merkle tree とハッシュ関数をうまく使って、取引所が実際に管理している残高とユーザーの残高が一致しているかをチェックできるような、そんなアルゴリズムだったと思う。ちゃんとブログの記事を読んでないけど、ちょうさんの解説を聞く分にはアルゴリズムはそう難しくないように思えた。そんなすごい仕組みじゃなくて、簡易的に大きな計算コストもなく全体の残高があっていることのおおよそのチェックはできますよといったもの。

イベントが始まる前にちょうさんが大学の研究室にいた頃、研究室へ行くと同僚がいて気軽に新しい技術の話しができたけど、社会人になるとそういう機会が減ってしまったという。時事ネタを気軽に雑談できるイベントがあればという話しをされていて私も共感できた。

backlog の認可の仕組み

0時に寝て6時に起きた。

backlog の oauth 2.0 の仕組み

ユーザー単位の API キーの他、oauth 2.0 の認可の仕組みもある。OAuth Grant Types は Authorization Code と Refresh Token の2つをサポートしている。

手順はざっくりこんな感じ。

開発者向けのサイトからアプリケーションを作成して認可コードのリクエストを送る。

https://YOUR-SPACE.backlog.com/OAuth2AccessRequest.action?response_type=code&client_id=xxx&redirect_uri=http://localhost:18080/callback

リダイレクト先に query='code=zzz' な認可コードが届く。それを使ってアクセストークンを取得する。

{'access_token': 'xxx',
 'expires_in': 3599,
 'refresh_token': 'xxx',
 'token_type': 'Bearer'}

有効期限が1時間のアクセストークンを取得できる。次のようにして認証をパスできる。

$ curl -s -H "Authorization: Bearer xxx" 'https://YOUR-SPACE.backlog.com/api/v2/space' 

基本的にはユーザー単位の認証しかなくてアプリケーションアカウントの運用はできないみたい。backlog の課金プランをみると、基本的にはユーザー無制限っぽいのでアプリケーションアカウントを一般ユーザーで作成すれば、運用上問題にならないからアプリケーションアカウントを設けていないのではないかと思う。お手伝い先の管理者にインテグレーション向けの専用ユーザーを作成して API キーを github の secrets に登録してほしいという依頼を出した。

github apps を調べた

23時に寝て5時半に起きた。何度か夜中にも起きた。起きてからドラクエタクトやってた。

oauth apps と github apps

いまお仕事で ci/cd の改善をやっていて、その一環としてリポジトリをまたがったパイプライン処理を検討している。 ci/cd で使うような認可の仕組みとして github には oauth apps と github apps の2種類がある。

私はどちらも全く関わったことがなかったので、仕組みがイメージできる oauth apps を使えばよいのだろうと調べ始めた。しかし、一通り調べてみて会社の開発における ci/cd に使うなら github apps の方が適していることがわかった。両者がどう違うのかもドキュメントに記載されている。最初にこのドキュメントを読めば oauth apps を調査する必要はなかった。

具体的には、oauth apps は user の権限を認可する仕組みで、github apps は organization の権限を認可する仕組みと言える。github apps も oauth によるユーザー認証もできる上にアプリ自身の認証もできる。さらにアクセスできるリポジトリも制限できることから github actions などで、特定のリポジトリに対してのみアクセス可能なトークンを取得するには github apps の方が向くというわけだ。oauth でユーザーが認可するときに scope を指定するが、その scope を organization が設定できるといったところが github apps と oauth との違いにみえる。取得できる token の有効期限にもその考え方の違いが出ている。

  • oauth apps
    • ユーザー/デバイス認証
      • 認可コード: 15分
      • アクセストークン: 無期限
  • github apps
    • installation 認証
      • 認可jwt: 10分
      • installation トークン: 1時間
    • ユーザー/デバイス認証
      • 認可コード: 15分
      • アクセストークン: 8時間