ローカルアカウント
Semaphore のユーザー名とパスワードでサインインします。
プロジェクトの RBAC、テンプレート単位の詳細な権限、ID プロバイダーによるサインインを組み合わせます。グループをロールにマッピングし、ローカルアカウントには二要素認証を追加します。
権限
チームでプロジェクトロールを割り当てます。エンジニアの責務に応じて、ジョブの実行、結果の確認、設定の管理を許可できます。
特定の責務向けにロールを作成します。アクセスを選択したジョブに限定する場合は、プロジェクト全体の権限を無効にしてください。
タスクテンプレートにロールを追加し、設定の編集を許可せずに実行を許可します。
Enterprise で ID プロバイダーのグループをプロジェクトロールにマッピングします。Semaphore は、次回サインイン時にマッピングによるアクセスを更新します。
アカウント → セキュリティを開き、ローカルサインイン用の認証アプリを設定します。同じ画面で外部 ID も関連付けられます。
既存の ID システムをサインインに接続します。各ユーザーがアクセスできるリソースと操作は、Semaphore のプロジェクトロールで決まります。
Semaphore のユーザー名とパスワードでサインインします。
既存のディレクトリ認証情報でサインインできます。
Keycloak、Okta、Microsoft Entra ID、Authentik、その他の OIDC プロバイダーを接続します。
信頼する認証プロキシからの署名済み ID トークンを受け入れます。
ローカルアカウントに認証アプリのコードを有効にし、復旧方法とセッションの有効期間を設定します。ユーザーが自分の第 2 要素を登録します。
認証アプリのコードで、サインインに第 2 の認証要素を追加します。
認証アプリを利用できないときの復旧を可能にします。
設定された最大有効期間の経過後、新たなサインインを要求します。
権限を一から設定せず、組み込みロールをプロジェクトメンバーに割り当てられます。1 人に複数のロールを付与でき、それらの権限は合算されます。


Enterprise では、チームの責務に合わせてカスタムロールを定義します。全員に同じ広いアクセスを与えず、許可する操作を選べます。
プロジェクト内の全ジョブではなく、特定のタスクテンプレートへのアクセスをカスタムロールに付与します。テンプレートの編集と分けて、タスクの実行を許可できます。
ワークフローにも同じ方式を適用でき、実行、編集、承認の権限を分けられます。

委任するジョブには、リポジトリ、インベントリ、認証情報への参照を保存したタスクテンプレートを使います。まず作成してテストし、その後で実行を許可するロールを作成してください。対象者と同等のアカウントでサインインし、意図したタスクは開始でき、別のタスクは利用できないことの両方を確認します。
ワークフローの権限は、閲覧、実行、編集、承認を対象とします。承認は実行とは別なので、操作を開始する人と、待機中のステージを進める人を同じにするか選べます。2 つの権限を当然のようにまとめず、意識して割り当ててください。
Enterprise のグループマッピングは、プロバイダーが送信する groups クレームを使い、OIDC グループと Semaphore プロジェクトのロールを関連付けます。マッピングされたロールはサインイン時に更新されます。ディレクトリのグループから削除しても、すでに保持しているセッションは終了しないため、このタイミングを踏まえて失効を計画してください。
日常のサインインを外部プロバイダーに依存する場合も、テスト済みのローカル管理者アカウントを 1 つ併設してください。管理責任者と認証情報の保管場所を記録し、障害前にアクセス経路を試します。復旧後は、その際に付与したアクセスを見直し、一時的な変更が恒久化しないようにしてください。
選択オブジェクトの権限は、その 2 種類のオブジェクトに適用されます。個別のインベントリ、リポジトリ、変数グループ、Key Store エントリーは、この方法では制御されません。それらはプロジェクト全体の権限とプロジェクト自体の境界に従います。より細かなリソース制御に依存する要件は、その上にプロセスを構築する前に検証してください。
メンバーは、組み込みロールとカスタムロール、グローバルロールとプロジェクトロールを同時に複数持つことができます。有効なアクセス権はそれらすべての和集合です。そのため、別の場所で割り当てた広い権限が、慎重に絞り込んだ権限を打ち消す場合があります。制限に頼る前に、割り当てられたロール全体を確認してください。
認証は、ローカルアカウントまたは対応する外部 ID システムを通じて、誰がサインインするかを確定します。認可は、その Semaphore ユーザーがアクセスできるプロジェクトと操作を決めます。SSO を有効にするだけでは、適切な運用ロールは割り当てられません。両者を一緒に設計してください。ID の関連付けを確認し、意図するプロジェクトメンバーシップを追加して、運用タスクを委任する前に、対象者と同等のアカウントが実際に利用できる操作をテストします。
組み込みの Task Runner ロールは、そのプロジェクトのすべてのテンプレートを実行できます。選択したジョブだけを委任するには、対象のタスクテンプレートとワークフローへの権限を持ち、プロジェクト全体の実行権限を持たない Enterprise カスタムロールを使います。割り当て済みのすべてのロールの権限が合算されるため、同時に広いロールを持っていると、ほかのテンプレートも実行できる場合があります。
はい。Enterprise のカスタムロールは、プロジェクト全体の権限と個別オブジェクトへの権限付与を組み合わせます。プロジェクト全体の権限を無効にし、対象のタスクテンプレートとワークフローだけを追加して、それぞれ閲覧、実行、編集を選び、ワークフローには承認も選べます。グローバルロールは一度定義して複数プロジェクトで再利用し、プロジェクトロールは作成元のプロジェクト内にとどまります。ユーザーは複数ロールを持て、権限は加算されるため、機密性の高い自動化へのアクセスを制限する際は全体を確認してください。
オブジェクト単位の制御は、タスクテンプレートとワークフローに適用されます。インベントリ、リポジトリ、変数グループ、Key Store エントリーのプロジェクト全体の管理権限を、個別オブジェクト 1 つに絞れると考えないでください。運用責任を分ける際は、プロジェクトの境界と利用可能なロールモデルを意識して使います。ほかの種類のリソース単位の制限に依存するアクセス設計では、本番で頼る前に、その要件が満たされるか正確に確認してください。
文書化された認証方式は、ローカルアカウント、LDAP と Active Directory、OpenID Connect、信頼するリバースプロキシから渡される JWT です。利用できるプランは現在の比較表に示されています。外部認証されたユーザーにも Semaphore のユーザーレコードがあり、意図したプロジェクトアクセスが必要です。既存設定を変更する前に、プロバイダー識別子とアカウント関連付けの動作を確認してください。ID プロバイダーを有効にするだけで、すべてのディレクトリグループが認可設計に必要なロールへ自動マッピングされるとは考えないでください。
外部認証の設定と並行して、テスト済みのローカル管理者用復旧経路を維持してください。管理責任者、必要な認証情報の保管場所、障害時のアクセス手順を文書化します。すべての管理者が同じ利用不能なプロバイダーに依存していることをインシデント時に知るのではなく、事前に手順をテストしてください。復旧後は、関連するアカウントとプロジェクトアクセスを確認し、一時的な運用変更が意図しない恒久権限にならないようにします。
はい。組み込みの Task Runner ロールは、ほかのリソースを読み取り専用にしながら、プロジェクトのテンプレートを実行できます。選択したジョブへのアクセスには、該当するタスクテンプレートとワークフローへの権限を持つ Enterprise カスタムロールを使います。権限は加算されるため、メンバーに割り当てられたすべてのロールを確認してください。準備済みのタスクテンプレートは、チームが使える実行設定を保持します。
Guest ロールは、プロジェクトへの読み取り専用アクセスを付与します。ゲストは、タスクの実行や設定変更をせずに、プロジェクト情報とタスク結果を確認できます。適切なプロジェクトチームにユーザーを追加し、ほかのロールも確認してください。Guest と併せて広いロールが割り当てられていると、追加の権限が付与される場合があります。
Enterprise のグループマッピングは、OIDC プロバイダーのグループと Semaphore プロジェクトのロールを関連付けます。プロバイダーで groups クレームを設定し、対象のプロジェクトとロールへのマッピングを追加します。Semaphore は、そのプロバイダーからサインインしたときに割り当てを更新するため、変更は既存セッションへ直ちに反映されるのではなく、次回のサインイン時に適用されます。
はい。サーバー設定で TOTP を有効にすると、ユーザーはローカルアカウントに認証アプリを登録し、パスワードの後に時間ベースのコードを入力できます。登録時には、認証アプリを使えないときのサインイン用に復旧コードが生成されます。有効化してもすべてのアカウントに登録が強制されるわけではないため、導入はプロセスとして扱ってください。同じ設定領域では、利用状況にかかわらず一定時間でセッションを終了する絶対有効期間も設定できます。