注意
この記事は2019年8月24日に更新されたもので、内容が古い可能性がありますのでご注意ください。
目次
- はじめに: Cloud Nativeにとってのブラックボックス: SSHサービス
- 仮説1: Googleはsshdに手を加えるか?
- 仮説2: Googleはカーネルに手を加えるか?
- 仮説3: Googleは既存機構をそのまま活用したagentを導入することで、既存OS distributionの機能を保ったまま、機能拡張をおこなうのではないか?
- Google Compute Engine Accounts Daemon とは?
- では、既存の運用は不可能になり、gcloud compute sshを使わなければならなくなるのか?
- では、「OS login機能」で、プロジェクトの公開鍵をブロックする構成にした場合、手動で追加したユーザーはブロックされるのか?されないのか?
- おわりに
はじめに: Cloud Nativeにとってのブラックボックス: SSHサービス
- 亀梨です。数ヶ月ぶりですかね。
- さて、「IaaSしか触ったことない(オンプレミス?何それ)です」という「cloud native」が増えています。喜ばしいことではあります。
- しかし、コンテナ開発が(知らないおじさんによって)叫ばれている昨今、
「素のOSとは?素のミドルウェアとは?」という根本的な、根源的な知識の重要性
はむしろ高まっています。- IaaSのゆりかごの上で、地表のオンプレネットワーク、オンプレ装置、物理ディスク、手動でのOSインストール、BIOS セットアップ(今はEFIですか)といった荒ぶる神々の洗礼を受けずにいること、「
分かったつもりでコンテナに手を出す
」ことは、地図なしに荒海に漕ぎ出すような蛮勇であるといえるでしょう。
- 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について深く調べてみてはいかがでしょうか。
- それではまた、次の記事でお会いいたしましょう。