Hudsonの操作権限をユーザ/グループ/ロール別に制御する
はじめに
Hudsonを標準状態のままで使用した場合、Hudsonにアクセスできる全てのユーザが、Hudsonの全ての機能を制限なく利用できてしまいます。
Hudsonの機能を熟知しているチーム内でHudsonを使用するのであれば、この標準状態の方が設定に煩わされない分、簡便に運用できるので都合が良いかもしれません。
しかし一般的には、間違った操作によってHudsonが動作しなくなることを防ぐために、「Hudsonの管理者」と「Hudsonの利用者」くらいの最低限の区別をした方が良いのではないかと思います。
そこで、この記事では、Hudsonのユーザーデータベースを使用して、Hudsonの操作権限を制御する方法について説明したいと思います。
なお、説明を簡素化するために、Hudsonの公式サイトにはない用語や分類を用いて説明していますので、その点はご了承ください。
操作権限を制御する前に
config.xmlのバックアップ
間違った設定をしてしまうと、全てのユーザがHudsonにログインできなくなったり、ログインできたとしてもHudsonのシステム設定を変更できなくなったりします。
操作権限の設定は、HUDSON_HOMEディレクトリ配下の「config.xml」に保存されるので、設定を変更する前にこのファイルをバックアップしておくと良いでしょう。
なお、バックアップを取っていなかったとしても、Disable securityの手順に従って、操作権限を制限しない状態にすることができます。
操作権限の種類
操作権限の種類は次のとおりです。
大項目 | 中項目 | 小項目 | 操作権限 |
---|---|---|---|
システムレベル | 全体 | [U] Administer | Hudsonのシステム管理 |
[R] Read | Hudsonへのアクセス | ||
スレーブ | [U] Configure | スレーブの設定 | |
[D] Delete | スレーブの削除 | ||
ビュー | [C] Create | ビューの作成 | |
[D] Delete | ビューの削除 | ||
[U] Configure | ビューの設定 | ||
SCM | [C] Tag | 構成管理のタグ付け | |
プロジェクトレベル | ジョブ | [C] Create | ジョブの作成 |
[D] Delete | ジョブの削除 | ||
[U] Configure | ジョブの設定 | ||
[R] Read | ジョブへのアクセス | ||
[U] Build | ジョブのビルド | ||
[U] Workspace | ジョブのワークスペース管理 | ||
ビルド | [D] Delete | ビルドの削除 | |
[U] Update | ビルドの保存 |
補足: 表内の[C]/[R]/[U]/[D]は、Hudsonの各権限がCRUD - Wikipediaのどの操作に該当するのかを私なりに分類したものです。
操作権限の構造
操作権限には次の2種類の権限が存在します。
- 「システムレベルの権限」
- 「プロジェクトレベルの権限」
「システムレベルの権限」は、「プロジェクトに依存しない操作」の権限になり、常にシステム全体に適用されます。
例えば、[全体 - Administer]の権限は、システム全体で「権限を与える」かどうかを決めることになります。
これに対して「プロジェクトレベルの権限」は、「プロジェクトに依存する操作」の権限になり、システム全体に(プロジェクトに共通して)適用されるケースとプロジェクト別に適用されるケースを使い分けることができます。
例えば、2つのプロジェクト(PRJ1とPRJ2)が登録されている状態で、[ジョブ - Configure]の権限は、システム全体で「権限を与える」に加えて、PRJ1またはPRJ2に対して「権限を与える」かどうかを決めることもできます。
次に操作権限の構造を示します。
権限設定の単位について
Hudsonは、標準ではユーザー単位の権限設定機能しか備えていません。設定画面の中にグループという言葉も現れますが、後述するauthenticatedグループを除いて、グループに見立ててアカウントを共有するという意味ですのでご注意ください。
アカウントを共有せずに、グループを形成するためには、Role Strategy Pluginを使用する必要があります。
Role Strategy Pluginの名称と関連URLは次のとおりです。
プラグイン名 | Wiki URL | ダウンロード URL | GitHub URL |
---|---|---|---|
Role Strategy Plugin | http://wiki.hudson-ci.org/display/HUDSON/Role+Strategy+Plugin | http://hudson-ci.org/download/plugins/role-strategy/ | https://github.com/hudson/role-strategy-plugin |
なお、グループという用語を用いると誤解を招く恐れがあるので、アカウントを共有しないグループのことを、このプラグインの用語を用いてロールと呼ぶことにします。
匿名(anonymous)ユーザーとauthenticatedグループについて
匿名ユーザーは、Hudsonに登録されていないユーザーも含む全てのユーザーを代表するユーザーになります。
authenticatedグループは、Hudsonに登録されている全てのユーザーを代表するユーザーになります。
匿名ユーザーとauthenticatedグループの扱いを考慮した場合、例えば [全体 - Read] の権限は次のOR条件で決定されます。
- 匿名ユーザーに設定されている「システム全体の[全体 - Read]」
- authenticatedグループに設定されている「システム全体の[全体 - Read]」
- ユーザー/グループ/ロールに設定されている「プロジェクト別の[全体 - Read]」
また、例えば [ジョブ - Read] の権限は次のOR条件で決定されます。
- 匿名ユーザーに設定されている「システム全体の[ジョブ - Read]」
- 匿名ユーザーに設定されている「プロジェクト別の[ジョブ - Read]」
- authenticatedグループに設定されている「システム全体の[ジョブ - Read]」
- authenticatedグループに設定されている「プロジェクト別の[ジョブ - Read]」
- ユーザー/グループ/ロールに与えられている「システム全体の[ジョブ - Read]」
- ユーザー/グループ/ロールに設定されている「プロジェクト別の[ジョブ - Read]」
つまり、ある権限を匿名ユーザーに与えると、その権限をHudsonに登録されていないユーザーも含む全てのユーザーに与えたことになります。
また、ある権限をauthenticatedグループに与えると、その権限をHudsonに登録されている全てのユーザーに与えたことになります。
セキュリティポリシーについて
セキュリティポリシーは、次の観点で検討すると良いでしょう。
- ログインしていないユーザー(匿名ユーザー)にジョブの状態を見せるかどうか。
- ユーザー/グループ/ロールのどの単位で権限を与えるのか。
- ユーザー/グループ/ロールに、CRUDのどの操作権限を与えるのか。
- 「設定を変更した人」や「ビルドを実行した人」を特定する必要があるかどうか。
- プロジェクト別に権限を与える必要があるかどうか。
これらを適切に検討しておくことで、次の問題を防ぐことができます。
- ジョブの公開範囲が必要以上に広くなってしまう。
- Hudsonの操作に不慣れな人がHudson環境を壊してしまう。
- 権限の設定が複雑になりすぎて負担になる。
操作権限の設定手順
ここから、次の3種類の権限管理手段の設定手順を説明します。
(それぞれの権限管理手段のメリット/デメリットは後述します)
- (A) : システム全体に適用される権限のみで管理する。
- (B) : プロジェクト別に適用される権限も使用して管理する。
- (C) : ロール単位で権限を管理する。
共通事項
権限設定の基本的な流れは次の通りです。
- アクセス制御を有効にする
- ユーザー/グループ/ロールを追加する
- 操作権限を設定する
- 各ユーザーがサインアップする
2つの開発プロジェクトのどちらかに対応する次の4つのジョブ(プロジェクト)が、Hudsonに登録されているものとします。
開発プロジェクト | Hudsonのジョブ名 | 概要 |
---|---|---|
開発プロジェクトPRJ1 | PRJ1-BUILD | PRJ1のビルド用ジョブ |
PRJ1-DEPLOY | PRJ1のデプロイ用ジョブ | |
開発プロジェクトPRJ2 | PRJ2-BUILD | PRJ2のビルド用ジョブ |
PRJ2-DEPLOY | PRJ2のデプロイ用ジョブ |
(A) : システム全体に適用される権限のみで管理する。
- 次のとおりに設定するものと仮定します。
ユーザー名 | 操作権限 |
---|---|
匿名ユーザー | 権限なし(ログイン画面以外は見えない) |
admin | Hudsonの全ての権限をもつ |
user1 | [全体 - Read]とプロジェクトレベルの全ての権限をもつ |
user2 | [全体 - Read]、[ジョブ - Read]、[ジョブ - Build]の権限をもつ |
user3 | [全体 - Read]、[ジョブ - Read]の権限をもつ |
user4 | [ジョブ - Read]の権限のみをもつ |
補足: user4ユーザーは、[全体 - Read]の権限の必要性を説明するためだけのユーザーです。
- 次の操作で操作権限の行列を開きます。
- Hudsonのトップ画面を開きます。
- [Hudsonの管理] - [システムの設定]を選択します。
- [セキュリティを有効化]をチェックします。
- [ユーザー情報]セクションの[Hudsonのユーザーデータベース]を選択します。
- [権限管理]セクションの[行列による権限設定]を選択します。
- 「ユーザー/グループの名前」と「操作権限」の行列が表示されます。
- 次の操作でadminユーザーを追加します。
- 匿名ユーザーの[全体 - Administer]と[全体 - Read]をチェックします。
- [追加するユーザー/グループ]に、"admin"と入力します。
- [追加]ボタンを押します。
- "admin"ユーザーが行列に追加されます。
補足: ユーザーを追加する際に、誤って[Enter]キーを押してしまった場合、[追加]ボタンが押されるのではなく、画面下部の[保存]ボタンが押されたことになります。不十分な設定のままで操作権限が保存されてしまうと復旧に一手間かかるので、Hudsonのシステム管理に必要な操作権限を一時的に匿名ユーザーに与えています。
補足: 追加されたユーザー名の左側に表示されるは、ユーザーがシステムにサインアップしていないことを表すアイコンです。
- 次の操作でユーザーに操作権限を与えます。
- "admin"ユーザーの全ての権限をチェックします。
- 匿名ユーザーの[全体 - Administer]と[全体 - Read]のチェックを外します。
補足: 誤って[Enter]キーを押してしまったとしても、全ての権限をもつadminユーザーでHudsonのシステム設定を変更することができます。
- 同様の操作でuser1〜user4ユーザーに操作権限を与えて、最後に画面下部の[保存]ボタンを押します。
- この状態でHudsonのトップ画面を開くと、ログイン画面が表示されるので、[サインアップ]を選択します。
- サインアップ画面が表示されるので、次の操作をします。
- すべての空欄に値を入力します。
- [サインアップ]ボタンを押します。
補足: [テキスト:]欄には、サインアップ画面に表示される認証用文字列を入力してください。
- サインアップに成功すると、[成功]と表示されてログイン済みの状態になります。
adminユーザーの画面例:
補足: [全体 - Administer]の権限をもっているので、[Hudsonの管理]メニューが表示されています。
user1ユーザーの画面例:
補足: [全体 - Administer]の権限をもっていないので、[Hudsonの管理]メニューが表示されません。
user4ユーザーの画面例:
補足: [全体 - Read]の権限をもっていないので、Hudsonにログインすることができません。
- 以上で(A)のケースの操作権限設定は完了です。
(B) : プロジェクト別に適用される権限も使用して管理する。
- 次のとおりに設定するものと仮定します。
ユーザー名 | 操作権限 |
---|---|
匿名ユーザー | (A)と同じ |
admin | (A)と同じ |
user1 | (A)と同じ |
user2 | (A)に加えてPRJ1-BUILDジョブのConfigure権限をもつ |
user3 | (A)に加えてPRJ1-BUILDジョブのBuild権限をもつ |
user4 | (A)に加えてPRJ1-BUILDジョブのBuild権限をもつ |
- 次の操作で操作権限の行列を開きます。
- Hudsonのトップ画面を開きます。
- [Hudsonの管理] - [システムの設定]を選択します。
- [セキュリティを有効化]をチェックします。
- [ユーザー情報]セクションの[Hudsonのユーザーデータベース]を選択します。
- [権限管理]セクションの[行列による権限設定(プロジェクト単位)]を選択します。
- 「ユーザー/グループの名前」と「操作権限」の行列が表示されます。
- (A)と同じ手順で各ユーザーに権限を与えます。
注意: この画面で設定できるのは「システム全体に適用される権限」だけです。
- 次の操作でPRJ1-BUILD特有の操作権限を設定します。
- [PRJ1-BUILD]の設定画面を表示します。
- [権限設定(プロジェクト単位)の有効化]をチェックします。
- [追加するユーザー/グループ]に、"user2"と入力します。
- [追加]ボタンを押します。
- "user2"ユーザーが行列に追加されます。
- 匿名ユーザーの[ジョブ - Read]と[ジョブ - Build]をチェックします。
- "user2"ユーザーの[ジョブ - Configure]をチェックします。
- 画面下部の[保存]ボタンを押します。
補足: 匿名ユーザーがもつ権限は、全てのユーザーに適用されるので、user2ユーザーに[ジョブ - Read]を設定する必要はありません。(ただし、user2ユーザーは、「システム全体に適用される権限」で既に[ジョブ - Read]の権限をもっています)
- 以上で(B)のケースの操作権限設定は完了です。
(C) : ロール単位で権限を管理する。
- Role Strategy Pluginがインストール済みであると仮定します。
- 次のとおりに「システム全体に適用される権限」を設定するものと仮定します。
ロール名 | 操作権限 |
---|---|
admin | (A)のadminユーザー相当 |
all-job-build-mgr | (A)のuser1ユーザー相当の権限をもつ |
all-job-build | (A)のuser2ユーザー相当の権限をもつ |
all-job-read | (A)のuser3ユーザー相当の権限をもつ |
- 次のとおりに「プロジェクト別に適用される権限」を設定するものと仮定します。
ロール名 | 操作権限 |
---|---|
PRJ1-job-build-mgr | 名前が「PRJ1-」から始まるジョブの全ての権限をもつ |
PRJ2-job-build-mgr | 名前が「PRJ2-」から始まるジョブの全ての権限をもつ |
- 次のとおりにロールとユーザーを関連付けるものと仮定します。
ロール名 | ユーザー名 |
---|---|
admin | admin |
all-job-build-mgr | user1 |
all-job-build | user2 |
all-job-read | user3 |
PRJ1-job-build-mgr | user2 |
- 次の操作でロール単位の権限設定を有効にします。
- Hudsonのトップ画面を開きます。
- [Hudsonの管理] - [システムの設定]を選択します。
- [セキュリティを有効化]をチェックします。
- [ユーザー情報]セクションの[Hudsonのユーザーデータベース]を選択します。
- [権限管理]セクションの[Role-Based Strategy]を選択します。
補足: この操作によって[システムの設定]画面に、[Manage Roles]メニューが追加されます。
- 次の操作でロール単位の権限設定の管理画面を表示します。
- [Hudsonの管理] - [システムの設定]を選択します。
- [Manage Roles]を選択します。
- [Manage Roles]を選択します。
- 次の操作で「システム全体に適用される権限」を設定します。
- [Role to add]に、"admin"と入力します。
- [Add]ボタンを押します。
- "admin"ロールの全ての権限をチェックします。
- 他のロールも同様の方法で追加し、権限を与えます。
- 次の操作で「プロジェクト別に適用される権限」を設定します。
- [Role to add]に、"PRJ1-job-build-mgr"と入力します。
- [Pattern]に、正規表現で"PRJ1-.*"と入力します。
- [Add]ボタンを押します。
- "PRJ1-job-build-mgr"ロールの権限をチェックします。
- 他のロールも同様の方法で追加し、権限を与えます。
- [Save]ボタンを押します。
補足: ロール名の接頭語をPatternにマッチさせるジョブの接頭語は、一致している必要はありません。
- 今度は[Assign Roles]を選択します。
- 次の操作で「システム全体に適用される権限」をもつロールにユーザーを割り当てます。
- [User/group to add]に、"admin"と入力します。
- [Add]ボタンを押します。
- "admin"ユーザーに、"admin"ロールのチェックを付けます。
- 他のユーザーも同様の方法で追加し、ロールを割り当てます。
補足: 分かりにくくなってしまいましたが、adminユーザーとadminロールは完全に独立のものです。
- 次の操作で「プロジェクト別に適用される権限」をもつロールにユーザーを割り当てます。
- [User/group to add]に、"user2"と入力します。
- [Add]ボタンを押します。
- "user2"ユーザーに、"PRJ1-job-build-mgr"ロールのチェックを付けます。
- 他のユーザーも同様の方法で追加し、ロールを割り当てます。
- 以上で(C)のケースの操作権限設定は完了です。
メリット/デメリット
(A) : システム全体に適用される権限のみで管理する。
- メリット
- ユーザー単位で管理するので分かりやすい。
- システム全体に適用される権限のみを管理するので分かりやすい。
- 設定画面は1画面だけなので分かりやすい。
- デメリット
- ユーザー数が増えた場合に煩雑になりやすい。
- プロジェクト別に管理担当者を割り当てるなどの柔軟な対応ができない。
(B) : プロジェクト別に適用される権限も使用して管理する。
- メリット
- ユーザー単位で管理するので分かりやすい。
- プロジェクト別に管理担当者を割り当てるなどの柔軟な対応ができる。
- デメリット
- ユーザー数が増えた場合に煩雑になりやすい。
- 設定画面がプロジェクトの数分存在するので煩雑になりやすい。
(C) : ロール単位で権限を管理する。
- メリット
- ロール(役割)で管理するので、どのユーザーがどの役割をもっているのかが分かりやすい。
- プロジェクト別に管理担当者を割り当てるなどの柔軟な対応ができる。
- 設定画面は3画面であるが、(B)よりも少ないので許容範囲である。
- (A)に比べて、ユーザー数が増えても煩雑になりにくい。
- デメリット
- ジョブ(プロジェクト)の名称を適切に決めておかないと、Patternが上手に設定できなくなるので煩雑になりやすい。
おわりに
最後に、操作権限を設定する場合のポイントをいくつかご紹介します。
- 特権ユーザー(記事内ではadminユーザー)を少なくとも1ユーザー登録しておく。
- 匿名ユーザーを利用して、設定数を少なくできないか検討する。
- authenticatedグループを利用して、設定数を少なくできないか検討する。
- 「システム全体に適用される権限」を利用して、設定数を少なくできないか検討する。
- ロール単位で操作権限を設定する場合は、ジョブ(プロジェクト)の命名規則を決めておき、Patternを活用できるようにする。
実際の動作を確認した上で記事を書き起こしていますが、誤りなどありましたら、早急に修正しますのでご指摘ください。
変更履歴
- 2011/1/13にauthenticatedグループに関する記述を追記しました。