Teleport：SSHキーを一切使わずに50以上のサーバーとKubernetesを管理する方法 – ITFROMZERO

Table of Contents

5台から50台以上のサーバーへスケールする際の不安

スタートアップでよく見かける光景です。最初はUbuntuサーバーが5台ほどで、すべてが非常にスムーズでした。新しいエンジニアが入社するたびに、公開鍵をコピーしてAnsibleでauthorized_keysに流し込むだけで、わずか2分で終わっていました。しかし、システムが50台以上のサーバーに急増し、数十のKubernetes（K8s）クラスターやデータベースが加わると、この「職人芸」のような手動プロセスは脆弱性を露呈し始めました。

本当の悪夢は、メンバーが退職したときにやってきました。以前、一人のメンバーの鍵を数十台의 サーバーから特定して削除するためだけに、午後を丸一日潰したことがあります。たった一台でも削除し忘れば、それはリスクの高いバックドアになってしまいます。また、メンバー間でrootアカウントを共有していたため、責任の所在を追跡することはほぼ不可能でした。もし誰かが午前2時にうっかりrm -rfを実行してしまっても、SSHの監査ログが貧弱すぎて、誰が犯人なのかさえ分かりませんでした。

なぜ従来のSSHキーはリスクになりやすいのか？

根本的な問題は、静的な認証情報（Static Credentials）にあります. SSHキーのペアは、手動で削除されるまで通常は永久に有効です。企業環境において、これは以下のような潜在的なリスクとなります：

アイデンティティの紐付けが弱い： SSHキーはコンピュータに紐付いており、個人に紐付いているわけではありません。開発者のノートPCが盗まれたり、マルウェアに感染したりすれば、悪意のある攻撃者は何の防御層も通らずにサーバーに侵入できてしまいます。
権限管理（RBAC）の困難さ： AさんはWebサーバーのみ、BさんはDBサーバーのみ、といった権限設定を従来のSSHで行うのは、運用管理上の大きな挑戦です。
Kubeconfigの流出： 長期間有効な証明書を含むKubernetesの設定ファイルが、SlackやGoogleドライブに安易に保存され、管理不能になりがちです。

あまり効果的ではなかった「その場しのぎ」の対策

Teleportを知る前は、踏み台サーバー（Bastion Host）を試しました。これによりサーバーをインターネットから隠せますが、依然として静的な鍵を使用していました。また、毎週鍵をローテーション（rotate）させるスクリプトも書きました。しかし、スクリプトを実行するたびにエラーが発生し、ある時はスクリプトのバグでDevOpsチーム全員が2時間もシステムから締め出されるという事態も起きました。

WireGuardやOpenVPNのようなVPNを利用している組織もあります。これはネットワークレイヤーでは優れた解決策ですが、アイデンティティレイヤーが疎かになります。VPNは「家に入る」ことまでは許可しますが、部屋（サーバー）の中で何をしたかまでは関与せず、記録も残りません。

Teleport：私が最も気に入っている集中アクセス管理ソリューション

本番環境で6ヶ月間運用した結果、Teleportはこのセキュリティの課題を根本的に解決してくれたと感じています。静的な鍵の代わりに、Teleportは短命な証明書（Short-lived Certificates）を使用します。ログインすると、数時間（通常は勤務時間の8時間に設定しています）だけ有効な証明書が発行されます。時間が過ぎれば証明書は自動的に無効化され、すべてのアクセス権限が閉じられます。

ぐっすり眠れるようになった3つの機能：

SSO（シングルサインオン）連携： Google WorkspaceやGitHubと直接連携できます。ユーザーは会社のMFA（多要素認証）を通過しなければSSH権限を取得できません。
セッション録画： ターミナルでの操作全体をビデオのように録画します。メンバーがどのようにデバッグしたかを後から見直すことができ、教育や障害調査において非常に役立ちます。
ワンストップ管理： SSHからKubernetes、データベース（Postgres、MySQLなど）まで、単一のインターフェースで集中管理できます。

Teleportのクイック導入ガイド

Teleport Proxy & Authとして機能するサーバーが1台必要です。ドメインとSSL証明書（Certbotが定番の選択肢です）を準備しておきましょう。

1. Ubuntuへのインストール

以下のコマンドを実行して、最新の安定版を取得します：

curl https://apt.releases.teleport.dev/gpg -o /usr/share/keyrings/teleport-archive-keyring.asc
echo "deb [signed-by=/usr/share/keyrings/teleport-archive-keyring.asc] https://apt.releases.teleport.dev/ubuntu $(lsb_release -cs) stable main" | sudo tee /etc/apt/sources.list.d/teleport.list
sudo apt update && sudo apt install teleport

2. 自動設定

ドメインが teleport.example.com であると仮定します。このコマンドは標準的な設定ファイルを自動生成します：

sudo teleport configure --acme [email protected] --cluster-name=teleport.example.com -o /etc/teleport.yaml
sudo systemctl enable --now teleport

3. 管理者の初期化

Web管理画面にアクセスするための初期管理者ユーザーを作成します：

sudo tctl users add admin --roles=editor,access --logins=root,ubuntu

表示されたリンクをブラウザにコピーしてパスワードを設定し、OTPコードをスキャンしてください。

実体験：古びたsshコマンドとの別れ

現在、私たちのチームはもう ssh user@ip と入力することはありません。代わりに強力な tsh ツールを使用しています：

# 朝に一度だけログイン
tsh login --proxy=teleport.example.com

# アクセス権のあるサーバー一覧を表示
tsh ls

# 分かりやすい名前でサーバーにアクセス
tsh ssh root@web-server-01

大きなメリットは、tsh が kubeconfig を自動的に設定してくれることです。tsh kube login コマンドを実行するだけで、証明書ファイルを持ち歩くことなく、すぐに kubectl を使用できます。

半年間の運用で得た教訓

Teleportを本番環境に導入する場合は、以下の点に注意してください：

Authサーバーの保護： このサーバーがダウンすると、チーム全員がどこにもアクセスできなくなります。設定データの定期的なバックアップを優先してください。
最小権限の原則： 全員に root 権限を与えないでください。開発チームにはStaging環境のみのロールを与え、Production環境に触れるのはDevOpsチームのみにすべきです。
監査ログの監視： TeleportのログをELKやSplunkに転送しましょう。何か問題が発生した場合、これがわずか数分で根本原因を突き止めるための決定的な証拠となります。

SSHからTeleportへの移行は、物理的な鍵からスマートな指紋認証錠に変えるようなものです。最初は設置に手間がかかるかもしれませんが、それによって得られる安心感とプロフェッショナルなサーバーのハードニングは、費やした労力に十分見合う価値があります。