Skip to main content

これが存在する理由

Shanoneアカウントにエージェントを接続するチームメンバーは、デフォルトでは、Shanoneが実装している269以上の連携すべてにアクセスできてしまいます。ほとんどのチームにとって、これは範囲が広すぎます——エンジニアに請求関連のツールは必要ありませんし、誰もがエージェント経由で本番リポジトリにforce-pushできるべきではありません。ShanoneのPermission Vendorを使えば、Rootユーザー(または委任された管理者)が、2段階の粒度でアクセスを制御できます。

サービスレベル

1つの連携に属するすべてのツールを一括で有効化/無効化する(例:あるロールについて「stripe」を完全に無効化する)

ツールレベル

サービスレベルの設定を上書きして、特定の1つのツールだけを有効化/無効化する(例:github_create_issueは許可しつつgithub_delete_repoはブロックする)
ツールレベルのオーバーライドは常にサービスレベルのオーバーライドより優先され、サービスレベルのオーバーライドは常にロールのデフォルト設定より優先されます。

ロール

「SA2」はShanoneのセカンダリ管理者ロールの階層を指します——アカウントは、完全なRoot権限を与えることなく、特定のポリシーアクション(他ユーザーのツール権限の管理など)をSA2ユーザーに委任できます。SA2ユーザーの作成方法、ログイン方法、ポリシーの仕組みについてはSA2ユーザーを参照してください。

Permission Vendorのツール

委任されたSA2ユーザーは一般メンバーの権限を管理できますが、どのようなポリシーアクションを許可されていても、Rootユーザーの権限を管理することは決してできません。

よくあるワークフロー

新しいメンバーに限定的な権限セットでオンボーディングする

1

サービス名を調べる

shanone_list_servicesを呼び出して、必要な正確なservice_nameの値(例:slack、github、notion)を取得します。
2

操作のバッチを作成する

[{"type": "service", "name": "slack", "enabled": true}, {"type": "service", "name": "stripe", "enabled": false}]のようなJSON配列を構築します。
3

1回の呼び出しで適用する

新しいメンバーのtarget_user_idと操作の配列(1回あたり最大500件)を指定してshanone_batch_set_user_permissionsを呼び出します。
4

確認する

同じtarget_user_idに対してshanone_get_permission_summaryを呼び出し、意図した通りの件数になっているか確認します。

サービス全体を無効化せずに危険なツールだけをロックする

これにより、そのユーザーは他のすべてのGitHubツールを引き続き利用できる一方で、この1つのアクションだけがブロックされます。

誰が実際に何を実行できるかを確認する

そのユーザーのロール、デフォルトのアクセス設定、サービスとツール両方の有効/無効件数を返します——無効化されているサービスの明示的な一覧も含まれます。サマリーではなく生のオーバーライド一覧が必要な場合は、shanone_list_user_tool_permissionsを使用してください。

マスタデータに関する警告

Shanoneがまだ認識していないtool_nameやservice_nameに対して権限を設定した場合(たいていはタイプミス、または前回の同期以降に追加されたツール)、呼び出し自体は成功してオーバーライドは保存されますが、レスポンスにはnot found in tool permission master dataのような警告が含まれます。オーバーライドが正しく機能していないと判断する前に、shanone_list_servicesやshanone_search_toolsで正確な名前を再確認してください。

次のステップ

SA2ユーザー

RootとSA2アカウントの違い、およびSA2ユーザーの作成・管理方法

ツールリファレンス

すべてのPermission Vendorツールの完全なパラメータとリクエスト例

トラブルシューティング

「Permission Denied」および関連エラーを解決する