こんにちは。X(クロス)イノベーション本部クラウドイノベーションセンターの柴田です。本記事ではTeleportを使ってKubernetesクラスタへアクセスする際の再認証方式を設定する方法を紹介します。
Teleportとは
Teleport はGravitational社が開発するソフトウェアです。OSS版、Enterprise版、Cloud版の3種類が存在します。
Teleportはざっくりいうと高機能かつ現代的な踏み台サーバです。SSHサーバ、データベース、Kubernetesクラスタなどへアクセスする際の踏み台として機能します。またシングルサインオンやセッションレコードの記録などの機能も提供します。
例えば以下の表はAmazon EKSクラスタへアクセスする際にTeleportを使う場合と使わない場合を比較したものです。AWSにも AWS Systems Manager Session Manager などの機能があります。一方でAmazon EKS上のコンテナへ kubectl exec
でログインした際のセッションレコードを記録したい場合などはTeleportが必要になります。
Teleportを使わずにAmazon EKSクラスタへアクセスする | Teleportを使ってAmazon EKSクラスタへアクセスする | |
---|---|---|
認証方法 | IAM user、IAM role | ローカルユーザー、GitHub OAuth(Enterprise版はGoogle OAuth、OIDC、SAMLにも対応) |
ノードへのログイン | AWS Systems Manager Session Managerでログインできる。セッションレコードはCloudWatch Logs、S3へ記録される。 | できる。セッションレコードはS3へ記録される。 |
コンテナへのログイン | kubectl exec でログインできる。セッションレコードは記録されない。 |
kubectl exec でログインできる。セッションレコードはS3へ記録される。 |
kube-apiserveへのアクセスログの記録 | コントロールプレーンのログ記録 を有効化することでCloudWatch Logsへ記録される | DynamoDBへ記録される |
セッションレコードの形式 | AWS Systems Manager Session Managerのセッションレコードはテキスト形式で記録される。エスケープシーケンスもテキストとして記録されており、若干見づらい。テキスト検索はできるが、動画として再生はできない。 | 独自形式で記録される。TeleportのWeb UIや tsh play コマンドで動画として再生できる。テキスト検索はできない。 |
運用の手間 | 踏み台サーバの運用は不要1 | Teleportクラスタの運用が必要 |
このように便利なTeleportですが、実際に使ってみたところ、Kubernetesクラスタへアクセスする際の再認証方式の設定に少しハマりどころがありました。本記事ではそれを紹介します。
前提条件
本記事では以下の環境を使用します。
- Amazon EKS v1.21
- Teleport v9.0.1
Teleportクラスタは 公式ドキュメント に従って既にEKSクラスタ上へ構築されているものとします。
以降では例として以下の値を使用します。実際には各自の環境に置き換えてください。
名前 | サンプル値 |
---|---|
TeleportクラスタのURL | teleport.example.com |
GitHubアカウント名 | octocat |
Teleportを使ってGitHub SSOでKubernetesクラスタへアクセスする
Teleportを使ってGitHub SSOでKubernetesクラスタへアクセスする際は、まず以下のコマンドを実行します。 tsh
はTeleportのCLIツールで Teleport Downloads からダウンロードできます。
# Teleportクラスタへログインする $ tsh login --proxy teleport.example.com --auth github --user octocat # 必要な設定をkubeconfigファイルへ書き込む $ tsh kube login teleport.example.com
kubeconfigファイルへ新しくcontextが追加されるので、これを使ってTeleport経由でKubernetesクラスタへアクセスできます。
$ kubectl config current-context teleport.example.com-teleport.example.com $ kubectl get pods No resources found in default namespace.
再認証時の認証方式を指定する
再認証時はデフォルトの認証方式が使用される
Teleportクラスタの認証情報には有効期限があります。有効期限を過ぎてからKubernetesクラスタへアクセスしようとすると、再認証を要求されます。
しかし実際にやってみると、初回認証時の認証方式(GitHub SSO)ではなく、デフォルトの認証方式(Teleportに登録されたローカルユーザーのパスワード認証)が要求されます。
$ kubectl get pods Enter password for Teleport user octocat:
これではGitHub SSOによる再認証ができずに困ってしまいます。
原因
なぜそうなるのか調べてみましょう。kubeconfigファイル(デフォルトでは $HOME/.kube/config
)の users
を見てみます。
users: - name: teleport.example.com-teleport.example.com user: exec: apiVersion: client.authentication.k8s.io/v1beta1 args: - kube - credentials - --kube-cluster=teleport.example.com - --teleport-cluster=teleport.example.com - --proxy=teleport.example.com command: /usr/local/bin/tsh interactiveMode: IfAvailable provideClusterInfo: false
kubectl
は client-goクレデンシャルプラグイン の仕組みを使って tsh kube credentials
コマンドからユーザーの認証情報を受け取ります。Teleportクラスタの認証情報の有効期限が切れている場合、このコマンドはTeleportクラスタへの再ログインを試みます。デフォルトの認証方式が要求されたのは、このコマンドに auth
などが指定されていないためです。
再認証時の認証方式を指定する
tsh kube credentials
コマンドに適切な認証方式を指定することでこの問題を解決できます。今回は環境変数経由で認証方式を設定します。なお tsh
コマンドが参照する環境変数の一覧は Teleport CLI Reference を参照してください。
以下のコマンドを実行します。
kubectl config set-credentials teleport.example.com-teleport.example.com --exec-env=TELEPORT_AUTH=github kubectl config set-credentials teleport.example.com-teleport.example.com --exec-env=TELEPORT_USER=octocat
するとkubeconfigファイルが以下のとおり更新されます。
users: - name: teleport.example.com-teleport.example.com user: exec: apiVersion: client.authentication.k8s.io/v1beta1 args: - kube - credentials - --kube-cluster=teleport.example.com - --teleport-cluster=teleport.example.com - --proxy=teleport.example.com command: /usr/local/bin/tsh env: - name: TELEPORT_AUTH value: github - name: TELEPORT_USER value: octocat interactiveMode: IfAvailable provideClusterInfo: false
これにより、Teleportクラスタの認証情報の有効期限が切れた後、GitHub SSOによる再認証が要求されるようになりました。
おわりに
本記事ではTeleportを使ってKubernetesクラスタへアクセスする際の再認証方式を設定する方法を紹介しました。この記事が皆様のお役に立てば幸いです。
参考
- Introduction to Teleport | Teleport Docs
- TeleportでKubernetesクラスタへのユーザーアクセスを管理する - Cybozu Inside Out | サイボウズエンジニアのブログ
執筆:@shibata.takao、レビュー:@higa (Shodoで執筆されました)