Basic Jenkins Information
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Jenkinsにログインする最も一般的な方法は、ユーザー名またはパスワードです。
認証されたクッキーが盗まれた場合、それを使用してユーザーのセッションにアクセスできます。クッキーは通常JSESSIONID.*
と呼ばれます。(ユーザーはすべてのセッションを終了できますが、最初にクッキーが盗まれたことを確認する必要があります)。
Jenkinsはプラグインを使用してサードパーティのSSO経由でアクセス可能に構成できます。
ユーザーはトークンを生成して、CLIまたはREST APIを介してアプリケーションに自分を偽装させることができます。
このコンポーネントは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コントローラーの代わりにタスク実行を管理します。エージェントはJavaをサポートする任意のオペレーティングシステムを使用できます。ビルドやテストに必要なツールは、エージェントが実行されるノードにインストールされます。これらは直接インストールするか、コンテナ(DockerまたはKubernetes)内にインストールできます。各エージェントは、ホストマシン上で独自のPIDを持つプロセスです。
エグゼキュータはタスクの実行スロットです。実際には、エージェント内のスレッドです。ノード上のエグゼキュータの数は、そのノードで同時に実行できる同時タスクの数を定義します。言い換えれば、これはそのノードで同時に実行できる同時パイプラインステージ
の数を決定します。
ドキュメントからの定義: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のインスタンスを暗号化します。一般的なキー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エンコードする必要があります。
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)