hakolate

低スペック端末で動作するIDE
hako+chocolate

これまでの開発環境の課題 大きく分けると3つの課題がありました
課題1 コードを書き始めるまで障壁が高い 課題2 環境構築でつまずきがち
事前準備でやる気をなくしがち

PATHの通し方がわからない

手元にiPadはあるけどパソコンがない

どのランタイムを入れたら良いのかわからない

ブラウザで動かせるようにしよう！

第2回イベント

第3回イベント

ペルソナ設定技術の素振り

デモを示す

MDMなどによる規制でアプリなどインストールが難しいサーバで処理させよう！

第4回イベント

Dockerベースに戻す
CI/CDを整えた

アップデートのたびに改修

Passkey対応に取り組んだ

CI/CDを作る大切さを学んだ

遊べる環境があると便利

端末ごとに挙動が違うと授業がしにくい

12月イベント

DockerからK8sへ

本番環境だと壊すと怖いので自由に環境構築のマニュアルを作っても生徒が全員出来るわけではない

ブラウザで動くIDEは存在するが処理がもっさりしているタブレット端末でのキーボード操作問題が生まれた

どのように作品にセキュリティを落とし込むか

iPadファーストなターミナルという作品像GIGAスクール構想により、iPadなどのタブレット端末が教育現場で普及

iPadではSwift以外のランタイムを動かせない

SecHack365を通してやってきたこと
第1回イベント

さらに2022年になり情報Ⅰが共通必履修科目へ

課題3 iPadで開発がしたい

簡単に動かせて壊せる環境にしよう！

開発駆動コース 仲山ゼミ
加藤 颯

発表会

第5回イベント

バグ修正

Remixへ移行

コストへの対策

Rootless対応

コンテンツ作り

ベンチマーカー作り

入力の工夫

DockerからKubernetes(K8s)からDockerへの変遷

SSRへの移行

コストへの対策

ソフトウエアキーボード前提のツールに使用としていた

Docker単体ではオーケストレーションが不可能

低スペック端末に焦点を当てたので、それ相応のアプローチが必要

サービス安定化のため、ランタイム基盤を切り離す画面の占領率が高いため、別のアプローチを探ることに多くの使用ケースがあるK8sベースの基盤へ移行を実施

サーバサイドで処理が走るSSRを採用

ユーザがランタイム部分を提供することにより、コストが浮く

アプリ化して独自のキーボードを作ることも検討したがコスパが×使っていたライブラリの扱いが非常に難しく、開発の難易度が上昇

体感ではあるがスペックの低い端末で体験が向上

できる限りAWSへ移行することにより、詳細なデータを取れる物理キーボードのみにし、ほかの箇所でユーザの利便性を高めること

Dockerへ戻る(Docker Swarmを噛ませると運用が出来る)

SSG/SPAに比べるとデプロイが大変だが、CIを整備し楽に→ボトルネックの監視が容易に

構成図

hakolateの製作過程にて
こだわりポイント

ユーザが触る部分はAWSに、開発者が触る部分はGitHubにとAttack Surfaceを絞った
GitHubではAWS IAMのシークレットを利用せずOpenID Connectを利用した認証を採用
GitHubリポジトリにRenovate/DependaBotを常駐させる

AWS ECRにCIで構築したコンテナイメージをアップロードしている様子

得た効果

ランタイム基盤で実行

AWSはCloudTrailによるログ記録により、インシデントが起きた際に詳細調査が可能

簡単に立ち上がるシェルで課題2を解決

シークレットキー自体を発行しなくても良いので、流失リスクがゼロになった
パッケージに更新があれば、テストCIを通過すれば自動Mergeをするので、より安全に開発環境がよりセキュアに実際にできあがったもの※写真は開発中のスクリーンショットです

シェルが動いている様子

AWSで実行

ブラウザ上から編集可能で課題3を解決

シンプルなUIとパスワードが不要な認証で扱いやすくなり課題1を解決

ユーザ

ホーム画面

hakolateを支えるセキュリティ

ログイン画面

エディタが動いている様子

ユーザから見える部分 – Passkeyを認証に採用処理を動かすランタイム基盤 – セルフホストを可能に実際に実装してみて、ユーザがパスワードを忘れた際のワークフローがややこしい

自分で調達したサーバで実行できるようにすることで、自宅サーバなどを運用している人にとって刺さりやすい

はじめはGitHubやGoogleが提供しているOpenID Connectを採用しようとしていたパスワードマネージャーも全ユーザーが使えるわけではない＜参考:Passkeyについて＞
フィッシングサイトによる詐欺的認証試行が防げる•

公開鍵暗号方式を用いた認証方式•異なるサービス間でPasskeyの共有が可能

hakolateの運用コストを減らすことができ、安定的な運用へとつながる

セルフホスト先では好きなイメージをダウンロードできかつ選択できるようにする（予定）

そのためパスワードを使わないPasskey認証を採用•

自分でイメージを作成することができ、幅が広がる

Rootlessで実行可能に
ユーザーネームスペースの有無にかかわらずDockerデーモンはroot権限を必要とするので、デーモンに脆弱性があると、他人のコンテナにアクセス可能である

これら3点を踏まえ、従来のパスワード認証よりも安全かつ簡単な認証体験を享受できる

Rootlessで実行することにより、デーモンがuser空間で実行させるため、安全に動かすことができる

root

Rootless

脆弱性

セキュアでユーザーフレンドリーな世界へ

Passkey、セルフホスト、Rootlessの3機能によって、使用する側と運用する側の両方にとって、使いやすく安全な基盤を提供することに大きく貢献

技術自体をOSSにして、開発方針を示す（GitHub ActionsでCIを組んでいるので、リソースへのアクセスが容易なため要注意）

セキュアでユーザーフレンドリーな世界を構築するためには開発者が使い込み、ユーザの声を聞き、継続的に改善していくことが重要

コミュニティを構築する（Googleなどでも引っかかってほしいのでIssue等で対処）

2つのバランス（セキュリティとユーザビリティ）が重要であり、どちらかに偏るのは良くない

これまでの世界課題1 コードを書き始めるまで障壁が高い
課題2 環境構築でつまずきがち
課題3 iPadで開発をしたい

ブラウザから扱えるので授業教材として使えるhakolateがある世界

生徒に気軽に壁打ち道具として使ってもらえる
休み時間にも「ものづくり」ができる

ブラウザでhakolateにアクセスすればターミナルが立ち上がる
すべてインストール済みのコンテナイメージを用意すれば何も入れなくて良い
エディタ機能もあるので、気軽に試せる

家に帰って別端末でも再現できる

マイクラサーバ構築 → hakolateセルフホスト?

今後の展望

1年間いろいろな技術を触ってみてそれぞれの面白さや奥深さを感じることが出来た

GUI機能を実装してQEMUが動かせたりとよりhakolateの活用幅の広がる機能を実装する

AWSやGitHub ActionsでCIを構築したりとクラウドネイティブな開発が出来て、時代の流行に乗りながらそれらの問題点も議論できた
ボトルネックになる部分の特定だったり、監視の技術を身につけることができ、これからのものづくりに生かせる一生物の力を手に入れた

2024/2/20
1年間支援してくださった仲山トレーナーをはじめとするSecHack365事務局、トレーナー、アシスタント、トレーニーの皆様へ心から感謝申し上げますセキュリティ

hakolate

ツール開発可能性が広がる

教育を起点に様々なセルフホストが出来て自宅サーバでも動く

hakolateを実際に作ってみてプロダクトにセキュリティを持ち込むのは技術を知った上に設計も必要でハードルは高かったが、実践できた

ゲーム開発

インフラ

データサイエンス

一括管理が出来るような便利で使いやすいコンソール画面を実装し、安心してつかるような仕組みを整える
現状はコンテナ技術の上にランタイムが走っているが、WASMでここの技術を置き換えることも検討している認証基盤に関しては、現状は外部の基盤を組み込んでいるがPasskeyベースの認証基盤を自作することを視野に入れている（IDaaS自作）

ここから体験できますhttps://hakolate.kattyan.dev/

1