5月4日
5月4日といえばスターウォーズの日。実はここ2年、(特に内容はスターウォーズとは関係ありませんが)この日を記念してBlog記事を投稿させて頂いていました。
2022年 techblog.ap-com.co.jp
2023年 techblog.ap-com.co.jp
2年も続けたのだから今年も頑張って記事をひねり出したいと思います。
Backstage Kubernetes Plugin
もう1年も前になりますが、以前BackstageのKubernetes Pluginをご紹介していました。
このときはBackstage上でどういった内容が表示されるのか、といったものはご紹介しましたが、実際にどうすればその内容を表示できるのかまではご紹介しませんでした。
そこで今回は1年ぶりにAKS利用時のkubernetes plugin設定方法についてご紹介します。
Kubernetes Plugin設定方法
なにはともあれ、 Kubernetes Pluginをインストールします。ここは基本的にはBackstage公式ドキュメントに従って作業を行えばOKです。
ポイントはこの作業のあとにあります。
Kubernetes PluginでAKSの情報を表示する際のポイントは2つ。アクセスする先の「Kubernetes Clusterの指定方法」とBackstageから Kubernetes Clusterへアクセスする際の「アクセス時の認証方式」の指定です。
Cluster情報の指定方法
Cluster接続先の指定方法はclusterLocatorMethodsに記載された内容にしたがい、 app-config.yaml
に記載します。
kubernetes: enabled: true serviceLocatorMethod: type: 'multiTenant' clusterLocatorMethods: - type: 'catalog' - type: 'config' clusters: - name: another-cluster-name url: https://your-cluste.hcp.region.azmk8s.io authProvider: aks skipTLSVerify: true
AKSを利用する場合、一般的にはつぎの2通りをCatalog Cluster Locator として利用することになると思います。
上記の例を見て分かる通りconfigで指定する場合、app-config.yaml
にその接続先を指定します。設定としては簡単ですが、Clusterが増加した場合、app-config.yaml
を更新してBackstageを再起動しなければなりません。
これに対して catalog の場合は app-config.yaml
には catalogを使ったCluster情報の登録を宣言するのみで、Backstageのカタログ情報としてCluster接続先を登録します。カタログ情報はBackstageのデータベースに格納するものであり、更新も比較的容易です。もし可能であればこちらの方式を採用するほうがよいのではないかと思います。
今回はcatalogのみを利用するため、config
の指定はコメントアウトしましょう。
kubernetes: enabled: true serviceLocatorMethod: type: 'multiTenant' clusterLocatorMethods: - type: 'catalog' # - type: 'config' # clusters: # - name: another-cluster-name # url: https://your-cluste.hcp.region.azmk8s.io # authProvider: aks # skipTLSVerify: true
カタログ情報としてCluster情報を登録するには Resouceというkindを利用します。
apiVersion: backstage.io/v1alpha1 kind: Resource metadata: name: <cluster name> annotations: 'kubernetes.io/api-server': 'https://<aks-cluster-fqdn>.hcp.<region>.azmk8s.io' # AKSの 「APIサーバーのアドレス」を指定します 'kubernetes.io/auth-provider': 'aks' # 以下で説明するアクセス時の認証方式の内容 'kubernetes.io/api-server-certificate-authority': '' # ここは空白文字を指定してください 'kubernetes.io/skip-tls-verify': 'true' 'kubernetes.io/skip-metrics-lookup': 'true' spec: type: kubernetes-cluster # kubernetes cluster情報のTypeである `kubernetes-cluster` を指定します。 owner: group:guests
アクセス時の認証方法
Kubernetes Clusterにアクセスする際の認証方式は使用方法に応じて複数用意されています。
- Server side : azure
Backstage BackendにEntraID の認証情報を登録しておき、そのトークンを利用してAKS Clusterにアクセスします。 - Server side : serviceAccount
Backstage BackendにKubernetes Service Account情報を登録しておき、そのトークンを利用してAKS Clusterにアクセスします。 - Client side: aks
Backstage frontendでユーザーのEntraIDでサインインし、そのトークンを利用してAKS Clusterにアクセスします。
Servier sideで認証する場合は、(ユーザーの権限とは関係なく)Backstageにアクセスできるユーザーが閲覧することができます。 それに対してClient sideで認証する場合、Entra IDでサインインし、ユーザーが保持している権限でAKSにアクセスするようになるため、閲覧権限に沿ったアクセスができるようになります。
今回はClient sideで認証する方式(aks)をご紹介します。
aks
を利用する場合は認証方式としてBackstage側に microsoft
を指定する必要があります。
bacend側に、以下のようにpluginを追加します。
backend.add(import('@backstage/plugin-kubernetes-backend/alpha'));
続いてEntra IDにアプリケーションを登録し、「email、ofline_access、openid、profile、User.Read」権限を割り当て、以下のようにBackstageのapp-config.yaml
に情報を追加します。
auth: environment: production providers: github: production: clientId: <github-client-id> clientSecret: <github-client-secret> signIn: resolvers: - resolver: usernameMatchingUserEntityName microsoft: # ここ以降を追加 production: clientId: <entra-id-app-registratoin-client-id> clientSecret: <entra-id-app-registration-client-secret> tenantId: <entra-id-tenant-id>
Azure(AKS Cluster)へのアクセスのみ行う場合はBackstage SignInPageの修正は不要です。
これでBackstage側の修正は完了です。
最後に連携したいComponentにkubernetes pluginの連携情報を埋め込みます。
apiVersion: backstage.io/v1alpha1 kind: Component metadata: namespace: default annotations: backstage.io/kubernetes-label-selector: app=your-app # Clusterでアプリケーションを検索する際のlabel selector backstage.io/kubernetes-namespace: your-nns backstage.io/kubernetes-cluster: cluster-name name: app-name spec: type: service owner: group:guests lifecycle: experimental dependsOn: - resource:your-cluster-name # Resourceで指定した名前
アプリケーションを特定する方法はいくつかありますが、ここではlabel selectorを用いています。
まとめ
Kubernetesという外部システムと連携するにあたって、単にPluginを導入するだけではなく、いくつかの選択肢の中から連携方法を選択し、その内容に基づいてコンフィグレーションやカタログ情報を登録しなければならないということで、Kubernetes Pluginは少し面倒な部分があったように思います。実際この記事に至るまでに1年の時間が必要でした。今回とあることをきっかけに再整理して、「こうすればいい感じになる」ということを掴んだように思いましたので皆さんに共有させていただきました。
こうした情報の共有が皆さんの「フォース」となれば幸いです。
ということで、最後はこの言葉で締めたいと思います。
May (the) fourth(4th) be wit you!!
それではまた来年。