クラウド同上

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

Author
かめなし
Lv:7 Exp:5675

2017年12月より現職。SREエンジニア目指してIaC、Kubernetesを勉強中。好きな言語はJavascript。好きなGCPプロダクトはCloud Build。好きなOCGカードは《破壊剣士融合》。

はじめに: 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の機能を保ったまま、機能拡張をおこなうのではないか?

console-log-doc

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]

ps axuwwf

  • はい。いますね。これは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上に手オペレーションで追加作成し、公開鍵を置いてみれば確認できます。

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

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

おわりに

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