(CloudBees Plugins guide の Template plugin の情報 を元に翻訳・改変)
さまざまな Jenkins プラグインは、ユーザーがカスタムスクリプトを定義することを要求します。最も一般的なのは Groovy 言語で、Jenkins の動作をカスタマイズするために使用されます。これらのスクリプトを書く全員が Jenkins 管理者である場合、具体的には Script Console リンクなどで使用される Overall/RunScripts 権限を持っている場合は、好きなスクリプトを書くことができます。これらのスクリプトは、プラグインに提供されているものと同じ API を使用して、Jenkins の内部オブジェクトを直接参照することができます。このようなユーザーは、Jenkins に対して何でもできる(セキュリティ設定の変更やサーバーでのシェルコマンド実行も含む)ため、完全に信頼できる必要があります。
しかし、スクリプト作成者の中に、Job/Configure のような限られた権限しか持たない「一般ユーザー」がいる場合、彼らに任意のスクリプトを実行させるのは適切ではありません。このような役割分担を支援するために、Script Security ライブラリプラグインはさまざまな機能プラグインに統合できます。これは、スクリプト承認 (script approval) と Groovy サンドボックス (Groovy sandboxing) という2つの関連システムをサポートしています。
最初の、より単純なセキュリティシステムは、任意の種類のスクリプトの実行を許可しますが、管理者の承認が必要です。悪意のあるアクションを実行しないと判断された承認済みスクリプトのリストがグローバルに維持されています。
管理者が何らかの設定(たとえばジョブ)を保存すると、管理者が編集したスクリプトは自動的に承認され、その後の操作なしで実行できる状態になります。権限の低いユーザーが送信したスクリプトについては、承認が必要であることを示す適切な警告が表示されます。管理者は、Script Approval 設定ページを使用するか、スクリプトを編集して保存することで、これらのスクリプトを承認できます。以前のバージョンの Script Security Plugin では、管理者は権限のないユーザーが送信したスクリプトを変更せずに保存することで自動的に承認できましたが、この機能はソーシャルエンジニアリングベースの攻撃を防ぐために無効化されました。(「保存」は通常 Web UI からの操作を意味しますが、REST や CLI を介して新しい XML 設定をアップロードすることも含みます。)
非管理者がテンプレート設定を保存すると、含まれるスクリプトが承認済みテキストから編集されていないかどうかのチェックが行われます。(より正確には、要求されたコンテンツが以前に承認されたことがあるかどうかがチェックされます。) 承認されていない場合は、このスクリプトの承認要求がキューに追加されます。(また、スクリプトの現在のテキストが承認されていない場合、設定画面 UI に警告が表示されます。)
管理者は Manage Jenkins » In-process Script Approval に移動すると、承認待ちのスクリプトのリストが表示されます。危険そうなものが要求されていなければ、[Approve] をクリックするだけで、以降そのスクリプトを実行できるようになります。
未承認のスクリプトを実行しようとすると、単に失敗し、通常は承認待ちであることを説明するメッセージが表示されます。スクリプトが承認されたら、再試行できます。この動作の詳細は、このライブラリを統合している機能プラグインによって異なる場合があります。
どんなに些細な変更でもスクリプトの変更ごとに管理者の承認を待つことは、タイムゾーンをまたぐチームや納期が厳しい状況では受け入れられないかもしれません。代替オプションとして、Script Security システムでは、Groovy スクリプトが本質的に安全と見なされる操作のみに限定されている限り、承認なしで実行できます。この制限された実行環境はサンドボックスと呼ばれます。(現在、他の言語で利用可能なサンドボックス実装はないため、そのようなスクリプトはすべて、非管理者によって設定された場合、承認される必要があります。)
このモードに切り替えるには、Groovy スクリプトの入力フィールドの下にある "Use Groovy Sandbox" チェックボックスをオンにするだけです。サンドボックス化されたスクリプトは、誰でもすぐに実行できます。(管理者であっても、スクリプトは誰が書いたかに関係なく同じ制限を受けます。) スクリプトが実行されると、すべてのメソッド呼び出し、オブジェクト構築、フィールドアクセスが承認済み操作のホワイトリストに対してチェックされます。未承認の操作が試行されると、スクリプトは強制終了され、対応する Jenkins 機能は使用できなくなります。
Script Security プラグインには小さなデフォルトのホワイトリストが同梱されており、統合プラグインはそのリストに操作を追加できます(通常はそのプラグイン固有のメソッド)。
ただし、デフォルトのホワイトリストに限定されるわけではありません。スクリプトがまだホワイトリストに登録されていない操作を実行する前に失敗するたびに、その操作は自動的に別の承認キューに追加されます。管理者は、スクリプト全体の承認について前述したのと同じページに移動して、保留中の操作承認のリストを表示できます。操作のシグネチャの横にある [Approve] をクリックすると、その操作はすぐにホワイトリストに追加され、サンドボックス化されたスクリプトで使用できるようになります。
ほとんどのシグネチャは method class.Name methodName arg1Type arg2Type… の形式で、特定の「レシーバー」クラス (this)、メソッド名、引数(またはパラメーター)型のリストを持つ Java メソッド呼び出しを示します。(試行されたメソッド呼び出しの最も一般的なシグネチャが承認のために提供されます。実際に呼び出し対象となったオブジェクトが、そのメソッドをオーバーライドするより具体的な型であった場合でも同様です。) また、静的(クラス)メソッドについては staticMethod、コンストラクターについては new、フィールドアクセス(取得または設定)については field も表示される場合があります。
セキュリティに配慮した環境の管理者は、どの操作をホワイトリストに登録するかを慎重に検討する必要があります。永続化されたオブジェクト(Jenkins ジョブなど)の状態を変更する操作は、一般的に拒否されるべきです。ほとんどの getSomething メソッドは無害です。
ただし、一部の「getter」メソッドでさえ、特定の権限を(ACL: アクセス制御リストを使用して)チェックするように設計されていることに注意してください。スクリプトは多くの場合、すべての権限が付与されているシステム疑似ユーザーによって実行されます。したがって、たとえば method hudson.model.AbstractItem getParent(ジョブを含むフォルダーまたは Jenkins ルートを取得する)はそれ自体は無害ですが、その後の呼び出しの可能性がある method hudson.model.ItemGroup getItems(フォルダー内のジョブを名前で一覧表示する)は Job/Read をチェックします。この2番目の呼び出しを無条件にホワイトリストに登録することは危険です。なぜなら、フォルダーで Job/Create を付与されたユーザーが、プロジェクトベースの認可戦略に従って非表示にされるはずのジョブを含め、そのフォルダー内の任意のジョブから少なくとも一部の情報を読み取れるようになるからです。フォルダー内に、次のような Groovy スクリプトを含むジョブを作成すれば十分です(詳細は統合プラグインによって異なります):
println("I sniffed ${thisjob.getParent().getItems()}!");
実行すると、スクリプトの出力には、秘密にされているはずのプロジェクトの名前が少なくとも表示されます。管理者は代わりに、getItems の権限チェックを想定して [Approve] をクリックすることもできます。これにより、実際のユーザーとして実行された場合(統合プラグインがそのように実行する場合)は呼び出しが許可されますが、システムユーザーとして実行された場合(より一般的)は禁止されます。この場合、getItems は現在のユーザーがアクセスできるジョブのみを返すように実装されているため、前者のケース(特定のユーザーとして)で実行された場合、説明にはそのユーザーがそもそも見ることができたジョブだけが表示されます。このより高度なボタンはメソッド呼び出し(およびコンストラクター)に対してのみ表示され、Jenkins が権限チェックを行っていることがわかっている場合にのみ使用する必要があります。
一般的な Groovy 統合では、ユーザーにスクリプト承認とサンドボックスのどちらを使用するかのオプションを提供します。その場合は、describable の String 値のスクリプトフィールドを SecureGroovyScript フィールドに変更します。コンストラクターで、値を保存する前に、configuringWithKeyItem(トップレベルアイテムごとにそのようなスクリプトが1つだけの可能性がある場合)または configuringWithNonKeyItem(複数ある可能性がある場合)を呼び出します。設定フォームでは <f:property field="…"/> を使用して、スクリプトとサンドボックス設定を取得する必要があります。スクリプトを実行するときは、evaluate を呼び出すだけです。
(古いデータとの互換性のために、別のフィールド名を選択し、元のフィールドを非推奨にします。次に、サンドボックスをオフにした SecureGroovyScript に新しいフィールドを設定し、configuring(ApprovalContext.create()) を呼び出して未承認スクリプトがロードされたことをシステムに通知し、古いフィールドを未設定にする readResolve メソッドを定義できます。)
SecureGroovyScript が提供する以上の制御が必要な場合に使用します:
設定にブール値の sandbox フィールドを導入します。
未設定の場合、@DataBoundConstructor で ScriptApproval.configuring を呼び出す必要があります。ApprovalContext.withCurrentUser を使用し、該当する場合は withItemAsKey(ジョブごとにスクリプトが1つだけの場合)、それ以外の場合は少なくとも該当する場合に withItem、および/またはコンテキストからこの使用法を一意に識別できる場合に withKey(StaplerRequest.findAncestorObject がここで役立ちます)を使用します。これにより、システムは、特定の人物によって(おそらく新しい)スクリプトが設定されたことを認識できます。また、設定者が不明な状態でスクリプトを含む設定可能オブジェクトがディスクからロードされたときに、システムに通知するために configuring を呼び出す readResolve も必要です。スクリプトが実行されるときに ScriptApproval.using を呼び出し、必要に応じて UnapprovedUsageException をキャッチします。descriptor はスクリプトフィールドでフォーム検証を使用し、ScriptApproval.checking を呼び出す必要があります(通常、descriptor はこのフィールドで少なくとも構文チェックを既に行っているはずです)。
sandbox フィールドが設定されている場合、GroovySandbox.createSecureCompilerConfiguration で Groovy シェルをセットアップし、GroovySandbox.run を呼び出すだけで済みます。RejectedAccessException をキャッチし、ScriptApproval.accessRejected を呼び出す準備をしてください。
特定のメソッド呼び出しを事前に承認するには、プラグイン内にある場合は単に @Whitelisted で注釈を付けます。それ以外の場合は、StaticWhitelist.from に委譲し、ホワイトリストに登録されたメソッドを列挙したテキストファイルをロードする ProxyWhitelist を(@Extension を使用して)登録できます。
スクリプトを評価するために GroovyShell を構築する場合、または ecureGroovyScript.evaluate を呼び出す場合は、スクリプトの有効なクラスパスを表す ClassLoader を渡す必要があります。Jenkins コアのローダー、自分のプラグインのローダー、または Jenkins.getInstance().getPluginManager().uberClassLoader を使用できます。
どれを選ぶにしても、URLClassLoader を作成して権限のないユーザーが任意のクラスパスエントリを追加できるようにしてはなりません! これにより、サンドボックスを使用する場合にすべてのセキュリティを簡単にバイパスできるようになります。(ユーザーは、@Whitelisted とマークされた静的メソッドを持ち、好きなことを行うクラスを含む JAR を、このジョブまたは別のジョブにアーカイブさせ、そのメソッドを自分のスクリプトから呼び出すだけで済みます。) スクリプト全体の承認を使用する場合、攻撃はまだ実証されていません(通常の親優先委譲を持つ URLClassLoader は、侵害されたバージョンによる無害な外見の API の簡単なマスキングを許可しないでしょう)が、META-INF/services/org.codehaus.groovy.transform.ASTTransformation などの巧妙な使用法によって、他の方法では安全なスクリプトが予期しない不正な方法で動作する可能性があります。JENKINS-22834 は安全な標準的な代替案を提案しています。
Script Security Plugin を使用するプラグインのテストを書くとき、テストでいくつかのエラーが発生する可能性があります。
テストが ScriptApproval.get() メソッドを直接的または間接的に呼び出す場合、ユニットテストは JenkinsRule を使用して、Jenkins.getInstance() が null を返さないようにする必要があります。サンドボックスを使用していない場合、これまで動作していたテストが失敗し始める可能性があります。これは、承認のためにキューに入れられるためです。承認に関係なくスクリプトを実行する必要がある場合は、ScriptApproval.get().preapprove(script, GroovyLanguage.get()) を使用すると、設定されたすべてのスクリプトが承認されます。あるいは、サンドボックスを使用してスクリプトを実行するようにテストを設定することもできます。この場合、テストで使用するメソッドをホワイトリストに登録する必要があるかもしれません。実ユーザー向けに一般的に登録するか、@TestExtension を使用してテスト専用のホワイトリストを持つことができます。
changelog を参照してください。
