クラウドインテグレーション部の千葉です。
サーバーワークスではBYOD制度が普及していて、過半数の社員がPCやスマートフォンは個人所有のものを利用しています。 参照: サーバーワークスホームページ - はたらきかた
以前に macOSのスリープ時に一時ファイルを削除しよう なんて記事を投稿して、業務時間外にOSがスリープモードに入るとローカルの ~/Downloads ディレクトリの中身は強制的に削除されるようにしました。
ちょっと困るかな…と思いつつ実施してみたのですが、まあ数日で慣れちゃいますね。
業務で利用するファイルがローカルに残らない ことに加えて、何か資料を作成する際も Boxにファイルを作成してから着手する って習慣ができたことは非常に良い副次効果でした。
さて、本投稿のタイトルにもある秘密鍵についてです。
主にコードを書く仕事をするのですが、前記したとおりローカルの macOS に業務関連のファイルを持ちたくないので Amazon Linux 2(EC2) に SSH 接続してコードを書いています。
なので、ソースコードや実行環境へのデプロイ時に利用する API Token 等の秘匿情報もローカルの macOS には存在しません。
そんなワケで、ずっとモヤモヤしてたんです。この SSH 接続 に利用している秘密鍵の存在が…
当然、ローカルディスクの暗号化 / MDMの導入 / アンチウィルス等は実施しているのですが、徹底的に ローカルに業務関連のファイルを持たない を突き詰めてきて『持たない』ことは成功したのですが、業務関連のファイルにアクセスする為の秘密鍵はローカルディスクに置いている。って気持ちわるいな。と
前置きが長くなりましたが↑こんなワケで re:Invent 2020 で発表のあった AWS CloudShell に秘密鍵を置いてソコから開発環境の Amazon Linux 2(EC2) に SSH 接続する運用にしてみました。
1. 手順
やったことは、以下のとおりです。
普段使いしているツール(zsh / tmux / Vim) CloudShell にデフォルトで入っていたので特に工夫するポイントはありませんでした。
1-1. タイムゾーンの変更
$HOME 以外のファイルは永続化されないので ~/.bashrc の最終行で毎回設定するようにしちゃいます。
※: $HOME ディレクトリも120日間 CloudShell へのアクセスがないと自動削除されてしまうので注意が必要です
$ echo "sudo ln -sf /usr/share/zoneinfo/Japan /etc/localtime" >> ~/.bashrc
1-2. Bash から Zsh への変更
ローカルの macOS で使っていたシェルが zsh なので、CloudShell でも同じものをデフォルトに設定して ~/zshrc 等のセットアップを実施しました。
デフォルトで chsh コマンドは入っていないのでチカラワザで ~/.bashrc の最終行で zsh を起動するようにしちゃいました。
$ echo "/bin/zsh" >> ~/.bashrc
1-3. tmux + tmux-powerline の設定
こちらも、ローカルの macOS で使っていたので、操作性が損なわれないようにローカル同等のセットアップを実施しました。
1-4. Vim の設定
こちらも、ローカルの macOS で使っていたので、操作性が損なわれないようにローカル同等のセットアップを実施しました。
1-5. sshクライントの設定
ここがメインです。ローカルの秘密鍵や ~/.ssh/config を CloudShell 側に移動した後にローカルからは削除しちゃいます。
2. イメージ
できあがった環境のイメージがコチラです。CloudShell の『Homeディレクトリは1GB』制限も余裕の 141MB に収まりました。
元々つかっていた iTerm2 と比較すると、画面上下にマネジメントコンソールのバーが出ていて邪魔ですが、これもスグに慣れるかな。と
まとめ
ずっとモヤモヤしていたローカルディスクの秘密鍵もなくなりました。
新しいパンツをはいたばかりの正月元旦の朝のように爽やかな気分デス。
CloudShell側に pyenv 等を導入して開発環境を作ってみたのですが、あっと言う間に1GB制限に引っかかっちゃったので断念しました。
ここまで夢中になって作り込んで、やっと気付いたんです『結局 EC2 使うなら Session Manager使うのが正解』っスね。
いったい何をしていたんだろう…
ってことで、別記事でSession Manager使う版を書こうと思います。
誰かが同じような過ちを繰り返さないことを願い記事を投稿させていただきました。
結論: CloudShell で環境を作り込む必要がある課題って多くない
