こんにちは！ チームが大きくなり、プロジェクトが増えてくると、「みんなで1つのJenkinsサーバーを使っているけれど、他のチームのジョブをうっかり触ってしまわないか心配……」「新人が間違えてプロダクション用のデプロイジョブを消しそうになった……」なんてヒヤッとする場面、増えてきませんか？
今回は、そんなマルチテナント（複数チーム共用）なJenkins環境で直面する権限の悩みを鮮やかに解決する、「Folder-based Authorization Strategy」を使った権限分離の極意を、優しく丁寧にお伝えします。
これをマスターすれば、セキュリティが万全になるだけでなく、各チームが自分の庭（フォルダ）を自由かつ安全に管理できるようになり、毎日の開発体験が劇的に快適になりますよ。ぜひ最後までついてきてくださいね！
—
1. そもそも「マルチテナントJenkins」ってなに？ なぜ権限分離が必要なの？
ひと昔前のJenkinsは、「1つのチーム、1つのサーバー」が主流でした。しかし、クラウドネイティブな現代において、インフラストラクチャをチームごとに乱立させるのはコスト的にも管理工数面でもナンセンスです。
そのため、「1台のパワフルなJenkinsマスターを、フロントエンドチーム、バックエンドチーム、インフラチームなど、複数チーム（テナント）で共有する」という構成が選ばれます。これがマルチテナントJenkinsです。
ここで問題になるのが「権限の境界線」です。全員が「Admin（管理者）」権限を持っていたらどうなるでしょう？
- インフラ担当者が、フロントエンドのビルド設定を誤って書き換えて壊してしまう
- 研修中のメンバーが、本番リリース用ジョブを誤操作で実行してしまう
- セキュリティ監査で「誰でも全ジョブを操作できる状態」を厳しく指摘される
こうしたカオスを防ぐために、「自分のチームの領域（フォルダ）だけ触れて、他人の領域は見えない・触れない」という厳密な境界線を引く必要があるのです。
—
2. 権限管理の主役：Folder-based Authorization Strategy とは
Jenkinsの標準機能やデフォルトの権限管理（Role-Based Strategyなど）は、グローバル（全体）またはプロジェクト名の大雑把な正規表現ベースで制御するため、階層構造を持つ現代のジョブ管理には少し窮屈でした。
そこで登場するのが、「Folder-based Authorization Strategy（フォルダベース認可戦略）」プラグインです。
このプラグインの素晴らしいところは、名前の通り「Job DSLやUIで作成した『フォルダ』単位で、アクセス権限を完全に独立させられる」点にあります。
- Team-Aフォルダ ＝ Team-Aのメンバーだけが読取・実行・設定変更可能
- Team-Bフォルダ ＝ Team-Bのメンバーだけが読取・実行・設定変更可能
- 共通フォルダ ＝ 全員読み取り専用、実行は特定のCIbotのみ
このように、現実の組織図やプロジェクト構造とJenkinsの権限を美しく同期させることができるのです。
—
3. 基礎セットアップ：プラグインの導入と全体設定
それでは、実際に手を動かして環境を整えていきましょう。ここでは、プラグインのインストールから、安全な権限モデルの土台作りまでをステップ・バイ・ステップで解説します。
Step 1: プラグインのインストール
まずはJenkinsの管理画面から必要なプラグインを入れます。
1. Jenkinsダッシュボード ＞ [Jenkinsの管理] ＞ [プラグインの管理] を開く。
2. 「利用可能」タブを選択し、検索窓に `Folder-based Authorization Strategy` と入力。
3. チェックを入れて [インストール] （再起動は必要に応じて実施）。
Step 2: 認可戦略の切り替え
次に、Jenkins全体のセキュリティ設定を変更します。
1. [Jenkinsの管理] ＞ [セキュリティーツール（Global Security）] を開く。
2. 「Authorization（認可）」の項目で、[Folder-based Authorization Strategy] を選択します。
3. 設定を保存（Save）します。
> ⚠️ 先輩からの重要なアドバイス（ここテストに出ます）
> 認可戦略を変更した直後は、権限がリセットされて「ログインできなくなった！」とパニックになりがちです。設定を変更する前に、必ず現在の管理者アカウントにグローバルな「Administer（管理者）」権限が正しく付与されていることを二重三重に確認してください。
—
4. 実践！フォルダの作成とチーム別権限の割り当て
ここからが本番です。例として、「Backendチーム」専用のフォルダを作り、その中身の権限をそのチームだけに絞る設定を行います。
1. フォルダの作成
1. ダッシュボードから [新規ジョブ作成] をクリック。
2. アイテム名に `backend-projects` と入力し、[Folder（フォルダ）] を選択して作成。
2. グローバル設定でのロール（役割）定義
Folder-based Authorization Strategyでは、まず「どんな権限のセット（Role）があるか」を定義します。
1. [Jenkinsの管理] ＞ [Manage and Assign Roles（ロールの管理と割当）] を開く（プラグイン導入でこのメニューが追加されます）。
2. [Manage Roles] をクリック。
3. [Global roles] では、全員共通の最低限の権限（例: ログインできる権限 `Overall:Read`）を設定します。
4. 下部の [Folder roles] に移動し、新しいロールを追加します。
- Role name: `backend-team-role`
- Pattern: `^backend-projects/.` （※この正規表現により、`backend-projects` フォルダ内のすべてのアイテムにこの権限が適用されます）
- 権限のチェックボックス：`Job (Read, Discover, Build, Cancel, Workspace)` など、必要なものにチェックを入れます（Deleteは含めないのが安全です！）。
3. ユーザーやグループへのロール割り当て
1. 同じ画面の [Assign Roles] をクリック。
2. 先ほど作った `backend-team-role` に対して、Backendチームのメンバーのユーザー名、またはLDAP/Active Directoryのグループ名を追加します。
これで、Backendチームのメンバーは `backend-projects` フォルダの中だけを自由にいじれて、他のチームの領域は見ることすらできなくなりました！
—
5. 誤操作を防ぐための設計思想とハック
最後に、マルチテナント環境を「事故ゼロ」で運用するための、現場で培った設計思想とハックをいくつか授けましょう。
① 「Delete（削除）」権限は原則与えない
人間誰しもミスをします。どれほど優秀なエンジニアであっても、深夜の作業でうっかりプロダクション用のジョブを削除してしまうリスクはゼロになりません。
ジョブやフォルダの「削除（Delete）」権限は、個別のチームメンバーには絶対に与えず、インフラ/CI専任の管理者チームのみに制限するのが鉄則です。ジョブの再作成が必要になったら、コード化（Job DSLやJenkinsfile）で何度でも復活できるようにしておきましょう。
② 設定は必ずコード化する（Jenkins Configuration as Code: JCasC との組み合わせ）
UIからポチポチと権限を設定していると、「誰がいつ何の権限を変えたかわからない」という監査上のブラックボックスが生まれます。
Folder-based Authorization Strategyの設定は、JCasC（Configuration as Code）を使ってYAMLファイルでリポジトリ管理するのがベストプラクティスです。
設定ファイルのイメージ例：
unclassified:
authorizationStrategy:
folderBased:
# グローバルおよびフォルダごとのアクセス制御をコードで完全に再現
roles:
folder:
- name: “backend-team-role”
pattern: “^backend-projects/.”
permissions:
- “Job/Read”
- “Job/Build”
- “Job/Workspace”
entries:
- user: “yamada-t”
- group: “backend-engineers”
これをGitで管理し、Pull Requestレビューを通さないと権限が変更できない仕組みを作っておけば、セキュリティも透明性も完璧になります。
—
おわりに
いかがでしたでしょうか？
「Folder-based Authorization Strategy」を導入し、適切な権限分離設計を行うことで、1つのJenkinsインスタンスを安全かつ快適に複数チームでシェアできるようになります。
最初は少し難しく感じるかもしれませんが、「フォルダという物理的な境界線」と「正規表現によるスマートな権限アサイン」を組み合わせることで、あなたのJenkins環境は見違えるほどクリーンで安全な場所生まれ変わります。
「毎日のデプロイやビルドが、もっと安心で楽しいものになりますように。」
ぜひ、次のチーム共有環境の設計に取り入れてみてくださいね。それでは、また次の極限知見でお会いしましょう！