便利な使い方
必要なときだけ管理権限を付与する

必要なときだけ管理権限を付与する

アクションやデータソースを設定できる強い権限を、特定の担当者へ常時付与している運用はよくあります。実際にその権限を使うのは月に数回でも、アカウントを乗っ取られたときの被害はその数回とは関係なく大きくなります。

普段は誰も強い権限を持たず、必要になったときだけ付与する構成を組めます。付け外しは公開APIから呼び出すので、社内の承認フローを通ったときだけ権限が付き、作業が終われば剥がれる、という形にできます。

ここでは、その構成の作り方を説明します。

全体の形

グループを役割で2つに分けます。

作業者が普段所属するグループには、日常業務に必要なアクションの実行権限を設定します。ロールをどこまで持たせるかは運用によりますが、昇格してはじめて使えるようにしたい管理権限は、ここには含めません。

昇格用のグループには「開発者」や「アクション運用責任者」など、必要になったときだけ使うロールを設定し、平常時はメンバーを空にしておきます。ロールと管理権限の対応はグループを参照してください。

権限を付け外しする主体として、サービスアカウントを1つ用意します。このサービスアカウントを「プロジェクトユーザー管理者」のロールを持つグループに入れ、OIDC信頼ポリシーで、トークンを交換できる呼び出し元を社内の承認基盤に限定します。

プロジェクトユーザー管理者はユーザー・サービスアカウント・グループ・環境・ナビゲーションの設定ができる一方、アクションとデータソースを扱う権限はありません。

この構成では、平常時にプロジェクト管理者が0人でも構いません。権限を管理できる主体としてサービスアカウントが常時残るためです。

昇格する

承認が下りたら、承認基盤がサービスアカウントとして公開APIを呼び出し、対象ユーザーを昇格用のグループに追加します。

トークンの取得方法は認証して呼び出すを参照してください。

# ID Token をアクセストークンに交換する
ACCESS_TOKEN=$(curl -s -X POST \
  "https://platform.basemachina.com/public/v1/token" \
  -H "Content-Type: application/json" \
  -d '{
    "grant_type": "urn:ietf:params:oauth:grant-type:token-exchange",
    "subject_token": "'"$ID_TOKEN"'",
    "subject_token_type": "urn:ietf:params:oauth:token-type:jwt"
  }' | jq -r .access_token)
 
# 対象ユーザーを昇格用のグループに追加する
curl -X PUT \
  "https://platform.basemachina.com/public/v1/projects/csi2hcc0iaejrqgivkfg/users/email:taro@example.com/groups/cq8m3f6ubcj4k2p1s7a0" \
  -H "Authorization: Bearer $ACCESS_TOKEN"

対象ユーザーの指定には2つの形式があります。プレフィックスなしで書くとベースマキナの内部ID、email:をつけて書くとメールアドレスとして扱います。どちらで指定しても結果は変わりません。

承認基盤がベースマキナの内部IDを保持していれば、そのまま内部IDで指定できます。保持していない場合は、email:の形式でメールアドレスをそのまま渡せます。内部IDで揃えたい場合は、GET /projects/{project_id}/usersでプロジェクトユーザーの一覧を取得し、メールアドレスから内部IDを引いてください。

付与した管理権限は、対象ユーザーが画面を再読み込みすれば反映されます。再ログインは必要ありません。

降格する

作業が終わったら、同じ経路で所属を外します。

curl -X DELETE \
  "https://platform.basemachina.com/public/v1/projects/csi2hcc0iaejrqgivkfg/users/email:taro@example.com/groups/cq8m3f6ubcj4k2p1s7a0" \
  -H "Authorization: Bearer $ACCESS_TOKEN"

作業者の申告を待つのではなく、承認の期限切れを検知したバッチから呼び出す形にすると、剥がし忘れが起きません。

PUTとDELETEはどちらも冪等です。すでに所属しているユーザーへのPUTも、所属していないユーザーへのDELETEも成功として200を返します。リトライしても状態は壊れません。

棚卸しする

昇格用のグループに誰も残っていないことを、定期的に確かめられます。

curl -s \
  "https://platform.basemachina.com/public/v1/projects/csi2hcc0iaejrqgivkfg/users" \
  -H "Authorization: Bearer $ACCESS_TOKEN"

レスポンスには各ユーザーの所属グループが含まれます。昇格用のグループのIDで絞り込めば、剥がし忘れを検出できます。グループの一覧とIDは/projects/{project_id}/groupsで取得できます。

気をつけること

対象ユーザーはあらかじめプロジェクトに追加しておきます。 公開APIで付け外しできるのはグループへの所属だけです。プロジェクトへのユーザー追加は管理画面から操作してください。そのプロジェクトに所属していないユーザーを指定すると404 not_foundを返します。

メールアドレスは登録済みのものと完全に一致する必要があります。 大文字と小文字も区別します。一致しない場合は404 not_foundを返します。

ユーザー管理権限の持ち主がいなくなる変更はできません。 プロジェクトのユーザー管理権限を持つユーザーとサービスアカウントがどちらもいなくなる所属変更は409 state_conflictで拒否されます。この構成では上記のサービスアカウントが常に残るため、通常この制約には当たりません。

所属が実際に変わったときだけ監査ログに残ります。 すでに所属しているユーザーへのPUTは成功しますが、所属は変わらないため記録されません。

関連情報

環境別のIPアドレス制限SQLのアクションで前のクエリの結果を使用する