Compute Engine SSH: OS Login機能は、GCEは、SSHの何を変えて、何を変えないのか。

はじめに: Cloud Nativeにとってのブラックボックス: SSHサービス

• 亀梨です。数ヶ月ぶりですかね。
• さて、「IaaSしか触ったことない(オンプレミス？何それ)です」という「cloud native」が増えています。喜ばしいことではあります。
• しかし、コンテナ開発が(知らないおじさんによって)叫ばれている昨今、「素のOSとは？素のミドルウェアとは？」という根本的な、根源的な知識の重要性はむしろ高まっています。
  • IaaSのゆりかごの上で、地表のオンプレネットワーク、オンプレ装置、物理ディスク、手動でのOSインストール、BIOS セットアップ(今はEFIですか)といった荒ぶる神々の洗礼を受けずにいること、「分かったつもりでコンテナに手を出す」ことは、地図なしに荒海に漕ぎ出すような蛮勇であるといえるでしょう。
• IaaSは、たしかに便利です。各daemonが何をして、どこでlistenして、どの設定ファイルを読むのか。そういう「最初の設定」が済ませてあることでしょう。「考えなければならない変数」を減らすことができることでしょう。
• しかしながら、それはオンプレ経験者にとっての話。
  • 初めてのサーバーが「お金を払うと期間貸しで使うことのできる、root権限のないVPS」であったり、それこそAmazon EC2、Google Compute Engineのような「出来てるので、使うだけ、sudoし放題で実質single user OSにでき、複数人で運用することがない」といった「吊るしで使えるサーバー」の人が今後はずっと増えていくでしょう。
• そういう「本当のサーバーを知らない人達」にとって、IaaSが提供する「managedで、IAMで制御でき、勝手にクラウドサービスが設定してくれるSSHサービス」は、ブラックボックスになりがちです。
  • 「素のOSと、それに付属するサービスは、何をして、何をしないのか」。
  • 「IaaSサービスは、そのOSをmanagedで提供するために、何をして、何をしないのか」。
• あくまでも検証に基く仮説に過ぎませんが、そこからサービス提供事業者の設計思想、哲学を推測することはできます。そして、事実を調査することはできます。その時点の仕様に過ぎませんが。

仮説1: Googleはsshdに手を加えるか？

• 私の持論はNoです。手を加えるくらいなら、sshd相当を再実装するでしょう。丸ごと。
• なぜなら、sshd(OpenSSH)はただでさえ複雑なソフトウェアであり、かつ、認証という最重要機構を担当するモジュールです。これに手を加えてmanaged機能を実装する場合、エンバグする可能性が非常に高く、かつ、sshdのためだけにモジュール単位のsecurity patchに追随する必要性 が発生します。
• 運用負荷が高過ぎるので、そんなことはしないでしょう。

仮説2: Googleはカーネルに手を加えるか？

• 半分Yes、半分Noです。根本的な新機能を搭載するためにカーネルを修正することはないでしょう。それをやってしまうと、compute engine自体に機能を追加する妨げになる可能性が考えられます。
• ハイパーバイザーを経由した、仮想化基盤との通信に関する機能については、当然導入していると考えられます。
• ただ、sshdの認証機構にカーネルの細かい機能が関わってくるとは考えにくいです。また、その機能を実現するために、仮説1の「sshd自体のソースコードをメンテナンスする必要性」が発生するでしょう。故にNoです。

仮説3: Googleは既存機構をそのまま活用したagentを導入することで、既存OS distributionの機能を保ったまま、機能拡張をおこなうのではないか？

• これが本命です。
• というか、答えは公式documentに書かれています。「Linux guest environmentのinstall」に、「google-accounts-daemon」に関する情報が掲載されています。

Google Compute Engine Accounts Daemon とは？

• トップページのreadme.mdで直接言及されているわけではないのですが、Compute Engine Linux Instance向けのpackageがGCP公式によってホストされており、このリポジトリのIssueを参照することで、「google-accounts-daemon」の存在を確認することができます。
• このdaemonが何をするのか。その名の通り、/etc/shadowや/etc/gshadow、/etc/passwdにオレオレUNIXユーザー(gcloud compute sshを実行したclientのOSユーザーと同じ名前の)を追加したり、~/.ssh/authorized_keysを生成したりといった、「システム管理者がこれまでやっていたこと」と同じことを代行しています。
• 実際に見てみましょう。

gcloud compute ssh [instance-name] --zone [zone-name]

• はい。いますね。これはdebianのGCE instance上で実行した ps axuwwf の結果の一部です。
• そして、頼んでもいないのに、わたしの手元のMacOSに設定しているユーザー名、「y.kmns」さんがOSユーザーとして勝手に追加され、その ~/.ssh/authorized_keys に、GoogleアカウントやProject Metadataで登録したSSH公開鍵が追加されます。
• これによって、謎の「gcloud compute ssh によるユーザ自動追加、かつ、SSH鍵配置の自動化による、スムーズなlogin」が実現されています。

では、既存の運用は不可能になり、gcloud compute sshを使わなければならなくなるのか？

• 否です。
• sshには様々な用途があります。完全な無人運転の遠隔バッチ実行といったことを、公開鍵認証機能を使うことで実現したりできます。
• そのために、関連する全てのホストにGoogle Cloud SDK(gcloudコマンド)を入れて周る必要があるか？いいえ、そんな馬鹿げたことはありません。手間を増やすツールなんて、無いほうがマシです。
• google-accounts-daemonは、gcloud compute ssh によってGCE APIに対するリクエストを送ってきたユーザの情報に応じて、『インスタンスにUNIXユーザを追加し、公開鍵を置いているだけ』のようです。
• これは、実際にOSユーザをGCE上に手オペレーションで追加作成し、公開鍵を置いてみれば確認できます。
  • GCPには1年間有効な、結構な額の無償枠があるため、是非一度、お手元でお試しいただければと思います。

では、「OS login機能」で、プロジェクトの公開鍵をブロックする構成にした場合、手動で追加したユーザーはブロックされるのか？されないのか？

• されません。
  • 引き続き、手で追加したOSユーザーにはSSH loginが可能です。
• 「google-accounts-daemonが自動生成したユーザー」と、「手で作成したユーザー」は、google-accounts-daemonからの扱いが異なるため、この実装に依存した機能を作成する場合は、十分にお手元で検証の上、運用してくださいますようお願いいたします。

おわりに

• たかがSSH、されどSSH。OpenSSH client/serverだけで本が一冊書け、それでも足りない程度には複雑なのがSSHです。
• シェル芸もいいのですが、たまにはお仕事の経路を支えているsshdについて深く調べてみてはいかがでしょうか。
• それではまた、次の記事でお会いいたしましょう。