セキュリティモデル
Semaphore はあなたのインフラへの認証情報を保持し、それに対してコードを実行します。ここから 2 つの性質が導かれ、その両方がこのページの他のすべての判断を形づくります。すなわち、シークレットは決してブラウザーへ戻ってはならない こと、そして タスクを開始できる人は、そのタスクが到達するマシン上でコードを実行できる ことです。
このページではモデルを説明します。それを実現する設定については セキュリティ を参照してください。
信頼境界
| 境界 | 通過するもの | 保護手段 |
|---|---|---|
| ブラウザー ↔ サーバー | セッション、API トークン | TLS、セキュアな Cookie、リバースプロキシ |
| サーバー ↔ データベース | すべての永続的な状態 | ネットワークの制限、書き込み前に暗号化されるシークレット |
| サーバー ↔ ランナー | シークレットを含むジョブのペイロード | HTTPS とランナーごとのベアラートークン |
| タスク ↔ 管理対象ホスト | あなたの自動化処理 | テンプレートに与えたキー |
タスクはこれらすべての境界の向こう側にあります。必要なシークレットを自分の環境で受け取り、その瞬間からは、リポジトリ内のコードがそれらをどう扱うかを決めます。
アイデンティティ
ユーザーは 3 つの方法のいずれかで認証し、3 つとも同じセッションに行き着きます。
- ローカルアカウント。 パスワードは Argon2id でハッシュ化されます（2.20 より前は bcrypt で、初回ログイン時に移行されます）。TOTP による二要素認証を必須にできます。
- LDAP または Active Directory。 ディレクトリがパスワードを検証し、Semaphore はアカウントだけを保持します。
- OpenID Connect。 プロバイダーが認証を行い、Semaphore はクレームをユーザーに対応付けます。
非対話的なアクセスには、ユーザーが作成した API トークン を使い、そのユーザーの権限を引き継ぎます。ランナーはユーザーのアイデンティティをまったく使いません。登録時に発行された独自のトークンで認証します。
タスクもアイデンティティを持てます。タスク JWT を使うと、実行時にプロジェクト、テンプレート、ユーザーを示す短命の署名付きトークンを受け取れます。長期間有効な認証情報を保管する代わりに、外部のシークレットストアがこれを検証できます。
認可
2 つのレベルがあり、互いに独立しています。
サーバーレベル。 管理者はユーザー、グローバルランナー、サーバー設定を管理します。サーバー管理者であること自体は、プロジェクトのメンバーシップを与えるものではありません。
プロジェクトレベル。 各メンバーは、各プロジェクトで 1 つのロールを持ちます。
| ロール | できること |
|---|---|
| Owner | メンバー管理と削除を含む、プロジェクト内のすべて。 |
| Manager | タスクの実行と、リソースおよびテンプレートの管理。 |
| Task Runner | タスクの実行のみ。他は何もできません。 |
| Guest | 閲覧。 |
この 4 つでは粒度が粗すぎる場合に備えて、Enterprise では カスタムロール Enterprisesince 2.17 が追加されます。
セキュリティ上重要な線引きは、Task Runner と Manager のあいだにあります。Manager はテンプレートが実行する内容を変更できるため、そのプロジェクトの認証情報を使って任意のコードを実行できます。Task Runner はすでに存在するものを開始できるだけです。ただし、テンプレートがコマンドラインに到達するプロンプトやサーベイ変数を公開している場合は別で、その場合はテンプレートの作成者が意図的にその境界を広げたことになります。
シークレット
秘密の値（SSH 秘密鍵、パスワード、トークン、秘密変数）は、保存前に access_key_encryption のキーで暗号化されるため、データベースのダンプだけでは内容が漏れることはありません。API が秘密の値を返すことは決してなく、UI はシークレットが設定されていることは示しますが、その中身は示しません。
シークレットは、タスクの開始時にその環境を通じてタスクへ渡されます。だからこそタスクの出力は機微な情報として扱う価値があります。変数を表示するプレイブックは、それを他のプロジェクトメンバーが読めるログに書き出すことになるか らです。
そもそもシークレットを保持したくない場合は、外部シークレットストレージ によって、値を HashiCorp Vault、OpenBao、AWS Secrets Manager、Devolutions Server に保持し、実行ごとに取得できます。
信頼できないコードの実行
既定の構成では、タスクは Semaphore サーバー上のプロセスであり、サーバーのファイルシステムとネットワークアクセスを利用します。これは、テンプレートを編集できる全員がすでにサーバーについて信頼されている場合には適切です。
そうでない場合は、実行をサーバーから引き離してください。
- ランナー はタスクを別のマシンに置くため、タスクが侵害されても Web サービスやデータベースは侵害されません。
- Docker または Kubernetes エグゼキューターは、ジョブごとに新しいコンテナーや Pod を与えるため、ある実行が別の実行のファイルやホストのファイルを読むことはできません。
- キーを分けた別々のプロジェクトにすれば、タスクは自分のプロジェクトの認証情報が許す範囲にしか到達できません。
プロジェクトメンバーが変更できるリポジトリは、そのプロジェクトの認証情報で実行されるコードです。テンプレートがビルド元とするブランチを保護するか、レビュアーだけが書き込めるブランチをテンプレートに指定してください。
利用者に委ねられること
Semaphore はセルフホスト型のため、モデルの一部はあなたが用意する必要があります。
- サービスの前段の TLS。組み込みのものでも、リバースプロキシ によるものでも構いません。
- データベースおよびサーバーの管理面へのネットワーク制限。
- データベースと
access_key_encryptionのバックアップ。後者は前者なしでは無意味であり、前者は後者なしでは読み取れません。 - バージョンを最新に保つこと。脆弱性は
[email protected]へ報告してください。