Zenn
↔

SORACOMの新機能「スイッチユーザー」をcliで試してみた

2023/08/09に公開
CLI
SORACOM
#
switchuser
tech

この記事は

2023年7月6日、7日に開催されたSORACOM Discovery 2023で発表された新機能「スイッチユーザー」をcliで試してみたので、その内容をまとめました。

スイッチユーザーとは

スイッチユーザーは、ルートユーザーまたは SAM ユーザーが SORACOM ユーザーコンソールにログインしている際、ログアウトすることなく、ほかの SAM ユーザーとしてログインし直す機能です。
以下の条件を満たせば、切り替える際に切り替え先のユーザーの認証情報は不要であり、切り替え先は同一オペレーター内に限らず、信頼関係を持つユーザ間であれば切り替えることができます。

  • 切り替え先はSAMユーザーである(ルートユーザーへの切り替えはできない)
  • 切り替え先のユーザーの「信頼ポリシー」に、切り替え元のユーザーが設定されている
  • 切り替え元のユーザーに以下の権限がある
    • Operator:generateAuthToken
    • Auth:switchUser

詳しくは、公式ドキュメントをご覧ください。

これを使うと、認証情報を共有せずに社外の保守担当者に保守用SAMユーザーの権限を渡したり、最小権限で作ったユーザーを切り替えながら必要な処理を行うといったことが簡単にできるようになり、セキュリティを向上させることができます。

使ってみる

では、早速使ってみましょう。WEBコンソールからの実施方法は公式ドキュメントにありますので、今回はcliで試してみます。

事前準備

SORACOM cli v1.0.0以降をインストールしてください。インストールの手順や初期セットアップについてはここでは省略します。

SAMユーザーの作成

切り替え先と切り替え元の2つのSAMユーザーを作成します。SAMユーザーの作成方法については公式ドキュメントをご覧ください。

以下の2つのユーザーを作成します。

  • すべての権限を持ったSAMユーザーswitch-a
  • スイッチユーザーを行う権限だけを持ったSAMユーザーswitch-b

switch-aにはログインのための認証情報は作成せず、switch-bの認証情報をcliのプロファイルswitch-bに登録します。

以下のように、switch-bのプロファイルでSIMの一覧を取得しようとしてもエラーになることを確認します。

$ soracom --profile switch-b sims list
Error: {"code":"SEM0049","message":"SAMユーザー 'switch-b' にこの操作を行うための権限 'Sim:listSims' が許可されていません。SAMユーザーの権限設定については管理者にお問い合わせください。なお、SAMユーザーは管理者が適切な権限を設定したあとで再度ログインしなおす必要があります。"}

信頼ポリシーの設定

次に、switch-aの信頼ポリシーにswitch-bを設定します。ルートユーザーで以下を実行します。

$ soracom users trust-policy update --user-name switch-a --trust-policy '{"statements": [{"effect": "allow","principal": {"soracom": ["srn:soracom:OPxxxxxxxxxx::User:switch-b"]}}]}'

powershellの場合は以下のようにダブルクオートをエスケープする必要があります。

$ soracom users trust-policy update --user-name switch-a --trust-policy '{\"statements\": [{\"effect\": \"allow\",\"principal\": {\"soracom\": [\"srn:soracom:OPxxxxxxxxxx::User:switch-b\"]}}]}'

OPxxxxxxxxxxは、switch-bのオペレーターIDに置き換えてください。

スイッチユーザーしてみる

これで準備できたので、スイッチユーザーしてみましょう。スイッチ先のオペレーターIDとユーザー名を指定します。

$ soracom --profile switchb auth switch-user --operator-id OPxxxxxxxxxx --user-name switch-a
{
        "apiKey": "api-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
        "operatorId": "OPxxxxxxxxxx",
        "token": "eyXXX...",
        "userName": "switch-a"
}

無事apiKeyとtokenが取れたので、これを使って先程のコマンドを叩いてみましょう。

$ soracom sims list --api-key "api-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx" --api-token "eyXX..."
[
        {
                "activeProfileId": "xxxxxxxxxxxxxxxxxx",
                "arcSessionStatus": {
                        "arcAllowedIPs": [
...
]

無事動いてますね！

スイッチ先のIAMユーザーswitch-aの認証に関する情報は一切触れていないことがわかります。触れていないどころか、そもそもswitch-aにはログインのための認証情報を作成していません。

configureで設定してみる

switch-userコマンドを実行することでスイッチユーザーできることはわかりました。しかし、普段cliで実行するのにいちいちapiKeyと長いtokenを貼り付けるのはやや面倒です。そこで、この情報をプロファイルに保存する方法を試してみましょう。

SORACOM cliには、cliを実行する認証情報の設定を行うconfigureというコマンドがあります。こちらにも現在はスイッチユーザーの認証情報を設定する機能があります。

先程作ったIAMユーザーswitch-bのプロファイルに基づいて、switch-aにスイッチユーザーするプロファイルを作成してみましょう。

$ soracom --profile switch-a configure
--- SORACOM CLI セットアップ ---
/home/xxxxx/.soracom ディレクトリがなければ作成し、そこにファイル 'switch-a.json' を作成します。

カバレッジタイプを選択してください。

1. Global
2. Japan

選択してください (1-2) > 2

認証方法を選択してください。

1. AuthKeyId と AuthKey を入力する（推奨）
2. オペレーターのメールアドレスとパスワードを入力する
3. SAM ユーザーの認証情報を入力する（オペレーターID、ユーザー名、パスワード）
4. スイッチユーザー

選択してください (1-4) > 4
Switch destination operator ID (OP00...): OPxxxxxxxxxx
Switch destination user name: switch-a
Source profile (switch origin)
  1: default
  2: switch-b
[1-2]: 2

出来上がったプロファイルは以下のようになっています。

$ cat ~/.soracom/switch-a.json
{"sandbox":false,"coverageType":"jp","username":"switch-a","operatorId":"OPxxxxxxxxxx","registerPaymentMethod":false,"sourceProfile":"switch-b"}

operatorIdとusernameが設定され、他のプロファイルにはなかったsourceProfileが追加されています。

では、これを使ってコマンドを実行してみよう。

$ soracom --profile switch-a sims list
[
        {
                "activeProfileId": "xxxxxxxxxxxxxxxxxx",
                "arcSessionStatus": {
                        "arcAllowedIPs": [
...
]

バッチリですね！apiKeyやtokenを引き渡さないでいいので、常用にはこちらのほうが楽だと思います。

まとめ

スイッチユーザー機能を使うと、スイッチ先のユーザーの認証情報を一切持つことなく、スイッチ先のユーザーの権限でcliを実行できるようになります。これにより、通常時のオペレーションをよりセキュアに(かつ容易に)実行したり、セキュアに権限を委任したりといったことが可能になります。

ただし、当然ながらスイッチ元のユーザーの認証情報とスイッチ先のユーザーのオペレーターIDとユーザー名が漏洩したらNGですのでその点はご注意ください(もし漏洩した場合は信頼ポリシーの設定を削除して対応することになるかと思います)。

皆さんのお役に立てば幸いです。

GitHubで編集を提案

Discussion