はじめに

はじめまして、データ推進室データテクノロジーラボ部アーキグループ（以下アーキG）所属の荒木です。アーキG では、 AI/ML アプリケーションの稼働環境を Kubernetes で構築・運用・管理しています。

今回は Webアプリケーションの認証認可、 Alibaba Cloud の認証認可、サーバへの SSH接続を Okta を利用したものに統合しました。こちらの取り組みについて紹介いたします。

背景

アーキG で運用している Kubernetes 環境では、複数のWebアプリケーションが稼働しており、ユーザー管理・認証認可について以下の課題がありました。

• 各Webアプリケーションで認証認可機能を持っており、一元管理されていない
• ユーザーが複数の ID / PASS を管理しなければならない
• LDAP サーバが複数存在し、管理が煩雑である
• 各Webアプリケーションでリクルート社内のID管理基準に則るための保守工数がかかっている

上記の課題を解決するべく、 Okta の Workforce Identity Cloud の中から Single Sign-On 、 Universal Directory 、 Advanced Server Access の3つを導入し、各種Webアプリケーションやサービスに okta 上に作成したユーザーだけでアクセス可能になりました。今回は以下の3つの事例についてご紹介します。

• Webアプリケーションの認証認可
• Alibaba Cloud の認証認可
• サーバへのSSH接続(Advanced Server Access の導入)

Webアプリケーションの認証認可

アーキG が管理しているWebアプリケーションは AWS 上にあるため、今回は ALB で利用できるユーザー認証機能の OIDC を利用し、 Okta ユーザーでログインできるように設定を行いました。
メリットとしては Okta と ALB の設定だけで認証が可能なため、Webアプリケーション上で追加の認証の仕組みを構築する必要がありません。
すでに構築されているWebアプリケーションでは独自で管理している LDAP ユーザーで認証していましたが、比較的少ない変更で導入が可能でした。

設定方法は以下の通りになります。

Okta 上の設定

管理者画面の[アプリケーション]に遷移し、[アプリ統合を作成] から新規アプリケーションを作成します。

サインイン方法は OIDC
アプリケーションタイプは Webアプリケーション
を選択し、次へを押下します。

任意のアプリ表示名を入れ、
サインインリダイレクト URIに https://${ALBのDNSレコード}/oauth2/idpresponseを記入し
アプリを作成します。
※オプション部分に関しては必要に応じて、適宜設定を行います。後からでも設定変更可能なのでまずはシンプルに作成しても良いかもしれません。

作成後に、作成したアプリの[一般]→[一般設定]から[ログイン開始時URL]をhttps://${ALBのDNSレコード}にします。

ALB 上の設定

今回は作成されている ALB があり、その設定内容を変更することを前提に進めます。

該当の ALB を押下し、変更したいリスナールール(HTTPSのもの)にチェックを入れ、[ルールの編集]を押下します。

ステップ2の[ルールアクション定義]において、
[OpenID または Amazon Cognitoを使用する]にチェックを入れ、以下のように設定を行い保存します。

参考：ALB 上で設定する際の Okta の情報はアプリケーションの[一般]から取得できます

参考：Okta のグループ情報取得方法について

作成したWebアプリケーションに Okta 上のグループ情報を渡したい場合は[高度な認証設定]の[スコープ]にgroupsを追加することで情報を渡せます。

また ALB で設定したグループ情報は作成したWebアプリケーションで以下のように取得して、ページの出しわけ等に利用できます。

import jwt

user = {}
oidc_data = request.headers.get('x-amzn-oidc-data', None)

if oidc_data:
    payload = jwt.decode(oidc_data, options={'verify_signature': False}, algorithms=['RS256'])
    user['groups'] = payload.get('groups', [])

参考：認可について

アーキG の環境では、認可について Okta のグループで管理しており、この後紹介する Alibaba Cloud や サーバへの接続制御で利用する GID など全ての管理しているサービスで Okta と同じグループ単位で管理できるように、網羅的に権限を設計しています。

複数のWebアプリケーションがあり利用できるユーザーが限られているものもあるため、Webアプリケーションの表示はグループ毎に管理しています。

設定方法は対象のアプリケーションの[割り当てタブ]から[割り当て]→[グループに割り当て]を押下し、付与したいグループを追加します。

Alibaba Cloud の認証認可

アーキG が管理している Kubernetes は Alibaba Cloud 上で動いており、Alibaba Cloud のユーザー情報も他のシステムとは独立した管理になっていました。 また開発環境や本番環境等がアカウント毎に分かれているため、複数のアカウントが存在し、1人あたり複数の ID / PASS が必要で、管理が煩雑でした。

今回は上記を解決するために、 Alibaba Cloud のユーザー管理を CloudSSO を利用したものに変更し、 Alibaba Cloud にアクセスするユーザーを一元管理できるように変更しました。
そして、CloudSSO の　IdP を Okta に設定、 SAML 認証することで既存のユーザー管理を Okta と連携したものに変更しました。アカウントへのアクセス変更のイメージは以下の通りです。

ログインフローは Okta のダッシュボードから CloudSSO にログインすると、 Management アカウント(= CloudSSO の管理アカウント)の CloudSSO ポータルにアクセス。 その後、CloudSSO ポータルから Member アカウント(=各環境のアカウント)を選択することでAlibaba Cloud のコンソール画面へアクセスすることが出来るフローになっています。

Okta から CloudSSO にユーザー設定やグループ設定を同期させられると楽だったのですが、今回は Lifecycle Management を使わない構成であるため、以下の方法を取りました。

Okta 上で CloudSSO　ポータルへのアプリケーションを設定する際に [Provisioning設定]をオフとする
↓
Management アカウントの CloudSSO ポータルにて、グループ作成し、どの Member アカウントへアクセスできるかの設定をします。
※ CloudSSO のグループの設定は Okta と同じ設計思想で作成したものとなっております。
↓
Management アカウントの CloudSSO ポータル内で　Okta と同様のユーザー作成し、グループ情報を付与します
↓
上記が作成されると、Member アカウントに RAM ユーザーが自動で作成されます。

また、 Management アカウントから Member アカウントにアクセスする際の権限設定において、対象のメンバーアカウントへ操作権限を付与する方法が 2種類 存在しますが、今回は RAM User Provisioning を採用しました。
RAM User Provisioning では CloudSSO ユーザーと同一のユーザー名となる RAMユーザーがメンバーアカウントで管理され、その RAM ユーザーでログインする認証方式となります。
採用理由としては各環境でより細かく権限制御を RAM ユーザーに対して行うためにカスタムポリシーを利用できるのが RAM User Provisioning だったためです。

サーバへのSSH接続(Advanced Server Access の導入)

アーキ G が管理している環境では、 LDAP ユーザーを使って各サーバへSSH接続する方式を取っていました。
マルチクラウド構成を取っている関係で、各パブリッククラウド内に LDAP サーバ が必要であり、設定内容やアクセスログを一元管理できず、管理が煩雑でした。
Advanced Server Access(以下 ASA)を導入したことで、各環境にある LDAP サーバ を除却し、ログ・設定等の一元管理が可能になりました。

設定手順は以下の通りです。

Projectの作成

ASA の画面から [Project] を選択し、[Create Project] を押下する。

任意の Project Name を記載し、[Enable shared primary GIDs for Users] にチェックをいれ 他の値はデフォルトのままにし、 Submit を押下する。
※ Enable shared primary GIDs for Users が表示されない場合は Okta 社に問合せてみてください。

サーバのセットアップ

次に、 Okta から接続したいサーバにセットアップを行います。
[Project] の [Enrollment] から [Enrollment Token] を任意の名前で作成し、 Token 情報を取得します。

Okta 認証を行いたいサーバに sftd をインストールします。
以下は Ubuntu での例です。

sudo apt-get update
sudo apt-get install gpg
curl -fsSL https://dist.scaleft.com/GPG-KEY-OktaPAM-2023 | gpg --dearmor | sudo tee /usr/share/keyrings/oktapam-2023-archive-keyring.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/oktapam-2023-archive-keyring.gpg] https://dist.scaleft.com/repos/deb bionic okta" | sudo tee /etc/apt/sources.list.d/oktapam-stable.list
sudo apt-get update
sudo apt-get install scaleft-server-tools
sudo vi /var/lib/sftd/enrollment.token
sudo mkdir /etc/sft
sudo vi /etc/sft/sftd.yaml
sudo systemctl restart sftd
sudo journalctl -u sftd
sudo systemctl restart sshd

[enrollment.token] に書き込むのは作成した Enrollment Token 情報です。
構成ファイルを手動で設定する場合は [sftd.yaml] に記載します。
オプション内容については こちら をご参照ください。
アーキG では AccessAddress、 Basiton や SSHDPort 等を設定しています。

設定したサーバが Servers のリスト上に表示されると、サーバが正常に登録されたことになります。

参考：サーバへのアクセス制御設定について

追加したサーバにアクセスできるようにするためには作成したプロジェクトにグループ・ユーザーを追加する必要があります。
今回はグループ毎にアクセスできるサーバを絞る方法についてご紹介します。

サーバ に対してアクセスできるグループ・ユーザーを絞りたい場合は、対象のサーバに付与した Labels をプロジェクトへのグループ・ユーザー設定時に Server Selector Tags に追加することでアクセス制御可能となります。

サーバの Labels 付与設定は、[Edit Labels] から任意の Labels を作成します。
アーキG では Okta 上で設定したグループで権限を付与しているので Okta のグループ名と合わせた Labels にしています。

プロジェクトへのグループ追加の設定は以下のように行います。

参考：踏み台サーバにおけるユーザー権限制御について

アーキG の環境下では踏み台サーバからアクセスできるサーバをユーザー毎に制限しています。また踏み台サーバでは特定ユーザーのみ sudo 可能の設定を入れています。

上記を実現するために以下の2点について設定を行いました。

• 踏み台サーバの iptables でアクセス可能先を制御
  • iptables では、ユーザーのプライマリグループのみが判定されますが、デフォルトで ASA 上ユーザーのプライマリグループはユーザー名と同一のユニークなグループ名となっています。今回は任意のグループ毎でアクセス可能先を制御したかったので、Project の設定で Enable shared Primary GIDs for users にチェックを入れることで複数のユーザーに同一の GID を設定できるようにしました。
  • GID の設定方法は、Projects の [Usersタブ]から変更したい User を選択し、[Edit Attributes] を押下し、[Unix GID] を任意のものに書き換えます。

• 踏み台サーバの /etc/sudoers を編集し、 sudo を制御
  • ASA　を設定したサーバ内で/etc/sudoers.d/95-scaleftに sudoers ファイルが作成されるのでこのファイルを読み込まないようにする かつ 特定ユーザーのみが sudo 出来るように設定を以下のように変更します

# 以下の1文を追記
%sft_対象のグループ名 ALL=(ALL:ALL) NOPASSWD:ALL
# 以下の1文を削除
#includedir /etc/sudoers.d

おわりに

Okta の3つのサービスを導入することで、各種Webアプリケーションやサービスに okta 上に作成したユーザーだけでアクセス可能になり、権限管理も一元的に行えるようになったので、運用の効率化につながりました。 また、副次的な効果ですが、認証認可を Okta に統合したことで、 Microsoft のアプリダッシュボードのようにアーキG で管理しているアプリが Okta のダッシュボードからアクセスできるようになり、利用ユーザー側の利便性も向上しました。

ASA を導入したことでサーバへの接続は便利になりましたが、購入できる台数が50台ずつ(2023/10当時時点) なので、アーキG の環境ではうまく買わないと余剰が発生してしまう状況でした。余剰コストを少しでも抑えるために、 ワークサーバをコンテナ化した話 について同じアーキG の舛谷さんが記載していますのでこちらもご確認いただければ幸いです。

クラウドエンジニア、アナリティクスエンジニア

荒木彩也華

アーキテクトからアナリティクスまで担当しています。最近ゴルフにハマっています。