Basic Jenkins Information
アクセス
ユーザー名 + パスワード
Jenkinsにログインする最も一般的な方法は、ユーザー名またはパスワードです。
クッキー
認証されたクッキーが盗まれた場合、ユーザーのセッションにアクセスするために使用される可能性があります。クッキーは通常JSESSIONID.*と呼ばれます。（ユーザーはすべてのセッションを終了できますが、最初にクッキーが盗まれたことを確認する必要があります）。
SSO/プラグイン
Jenkinsは、プラグインを使用してサードパーティのSSO経由でアクセス可能に構成できます。
トークン
ユーザーはトークンを生成して、CLIまたはREST APIを介してアプリケーションに自分を偽装させることができます。
SSHキー
このコンポーネントは、Jenkins用の組み込みSSHサーバーを提供します。これは、Jenkins CLIの代替インターフェースであり、任意のSSHクライアントを使用してこの方法でコマンドを呼び出すことができます。（ドキュメントから）
認可
/configureSecurityでは、Jenkinsの認可方法を構成することができます。いくつかのオプションがあります：
誰でも何でもできる：匿名アクセスでもサーバーを管理できます。
レガシーモード：Jenkins <1.164と同じです。「admin」ロールを持っている場合、システムに対して完全な制御が与えられ、それ以外（匿名ユーザーを含む）は読み取りアクセスのみが与えられます。
ログインしたユーザーは何でもできる：このモードでは、すべてのログインしたユーザーがJenkinsの完全な制御を得ます。完全な制御を持たない唯一のユーザーは匿名ユーザーで、読み取りアクセスのみが与えられます。
マトリックスベースのセキュリティ：誰が何をできるかを表で構成できます。各列は権限を表し、各行はユーザーまたはグループ/ロールを表します。これには、未認証ユーザーを表す特別なユーザー「anonymous」や、すべての認証されたユーザーを表す「authenticated」が含まれます。
プロジェクトベースのマトリックス認可戦略：このモードは、各プロジェクトごとに追加のACLマトリックスを定義できる「マトリックスベースのセキュリティ」の拡張です。
ロールベースの戦略：ロールベースの戦略を使用して認可を定義できます。
/role-strategyでロールを管理します。
セキュリティレルム
/configureSecurityでは、セキュリティレルムを構成することができます。デフォルトでは、Jenkinsはいくつかの異なるセキュリティレルムをサポートしています：
サーブレットコンテナに委任：Jenkinsコントローラーを実行しているサーブレットコンテナに認証を委任します。例えば、Jettyなどです。
Jenkins自身のユーザーデータベース：外部システムに委任するのではなく、Jenkins自身の組み込みユーザーデータストアを使用して認証します。これはデフォルトで有効です。
LDAP：ユーザーとグループの両方を含む、構成されたLDAPサーバーにすべての認証を委任します。
Unixユーザー/グループデータベース：Jenkinsコントローラー上の基盤となるUnix OSレベルのユーザーデータベースに認証を委任します。このモードでは、認可のためにUnixグループを再利用することも可能です。
プラグインは、Jenkinsを既存のアイデンティティシステムに組み込むのに役立つ追加のセキュリティレルムを提供できます。例えば：
Jenkinsノード、エージェント＆エグゼキュータ
ドキュメントからの定義：
ノードは、ビルドエージェントが実行されるマシンです。Jenkinsは、ディスクスペース、空き一時スペース、空きスワップ、時計の時間/同期、応答時間のために各接続ノードを監視します。これらの値のいずれかが設定された閾値を超えると、ノードはオフラインになります。
エージェントは、エグゼキュータを使用してJenkinsコントローラーの代理としてタスク実行を管理します。エージェントはJavaをサポートする任意のオペレーティングシステムを使用できます。ビルドやテストに必要なツールは、エージェントが実行されるノードにインストールされます。これらは直接インストールするか、コンテナ（DockerまたはKubernetes）内にインストールできます。各エージェントは、ホストマシン上で独自のPIDを持つプロセスです。
エグゼキュータは、タスクの実行スロットです。実際には、エージェント内のスレッドです。ノード上のエグゼキュータの数は、そのノードで同時に実行できる同時タスクの数を定義します。言い換えれば、これはそのノードで同時に実行できる同時パイプラインステージの数を決定します。
Jenkinsシークレット
シークレットと資格情報の暗号化
ドキュメントからの定義：JenkinsはAESを使用してシークレット、資格情報、およびそれらの暗号化キーを保護します。これらの暗号化キーは、マスターキーと共に$JENKINS_HOME/secrets/に保存されます。このディレクトリは、Jenkinsコントローラーが実行されているオペレーティングシステムユーザーのみが読み取りおよび書き込みアクセスを持つように構成する必要があります（つまり、chmod値が0700であるか、適切なファイル属性を使用します）。マスターキー（暗号用語で「キー暗号化キー」と呼ばれることもあります）は、Jenkinsコントローラーのファイルシステムに_暗号化されていない_状態で保存され、**$JENKINS_HOME/secrets/master.key**にあります。これは、そのファイルに直接アクセスできる攻撃者に対して保護されていません。ほとんどのユーザーと開発者は、一般的なシークレットデータを暗号化するためのSecret APIや資格情報APIを介して、これらの暗号化キーを間接的に使用します。暗号に興味がある方のために、JenkinsはAESを暗号ブロックチェーン（CBC）モードでPKCS#5パディングとランダムIVを使用して、$JENKINS_HOME/secrets/に保存されるCryptoConfidentialKeyのインスタンスを暗号化します。これらはそのCryptoConfidentialKey IDに対応するファイル名で保存されます。一般的なキーIDには以下が含まれます：
hudson.util.Secret：一般的なシークレットに使用されます；com.cloudbees.plugins.credentials.SecretBytes.KEY：一部の資格情報タイプに使用されます；jenkins.model.Jenkins.crumbSalt： CSRF保護メカニズムによって使用されます；
資格情報アクセス
資格情報は、任意の構成されたプロジェクトからアクセスできるグローバルプロバイダー（/credentials/）にスコープを設定することができるか、特定のプロジェクト（/job/<project-name>/configure）にスコープを設定することができ、そのため特定のプロジェクトからのみアクセス可能です。
ドキュメントによると：スコープ内の資格情報は、制限なくパイプラインに利用可能です。ビルドログでの偶発的な露出を防ぐために、資格情報は通常の出力からマスクされているため、env（Linux）やset（Windows）を呼び出したり、環境やパラメータを印刷するプログラムは、資格情報にアクセスできないユーザーに対してビルドログにそれらを表示しません。
そのため、資格情報を外部に持ち出すには、攻撃者は例えばそれらをbase64エンコードする必要があります。
参考文献
Last updated
