【CloudBees CI奮闘記】第7章：セキュリティ・運用を考える

Jenkinsは世界中で人気があるフリーでオープンソースの自動化サーバーです。そのため気軽に運用を開始することができ、Jenkinsの豊富な機能やプラグインを用いることで環境を発展させていくことが可能です。その一方でJenkinsの運用を進めていくうちに課題も発生してくることがあります。
CloudBees CI奮闘記として、Jenkinsを利用していると発生し得る課題の紹介をしながら、それらを解消するエンタープライズ機能を強化した有償版JenkinsであるCloudBees CIの紹介を行っていきます。

そもそも「CloudBees CIとは？」といったことや、Jenkinsの利用上の課題についてはこちらのブログより確認ください。

はじめに

登場人物

吉田：転職したてのエンジニア。前職では積極的にCIやCDに取り組みながら開発をしていた。CI奮闘記ではJenkinsの導入にあたり、服部に色々アドバイスを行った。

服部：元々CIやJenkinsについては言葉は聞いたことがある程度であったが、吉田からのサポートをうけつつCI環境の導入担当として日々奮闘している。CI奮闘記では自部署にJenkinsを導入した。

溝口：吉田、服部の上司。

用語

CloudBees CIの主な構成要素としてClient ControllerとOperations Centerがあります。

Client ControllerはJenkins(コントローラー)に該当します。起動したClient Controllerに対してJenkinsの様にジョブを作成していきます。
Operations CenterはJenkinsにはない、Client Controllerを束ねるための要素となります。Client ControllerをOperations Centerに接続することで、Client Controllerの集中管理が可能になります。

本ブログでは、CloudBees CIと区別するためにhttps://www.jenkins.io/のJenkinsをOSS Jenkinsと記載します。区別する必要がない場合、Jenkinsと記載します。

セキュリティ・運用

あ、そうだ服部さん。前回のバックアップの時も思ったんだけど、これだけClient Controllerが増えたら認証とか認可の設定とかも結構大変じゃない？

丁度いいところに！そうなんですよ。認証周りの設定もそうなんですが、先日溝口さんに……

セキュリティリスクを下げるため、認証や認可についてもしっかりしていこうと思う。
Client Controllerはメインで利用している開発チームからしかアクセスできないように設定しておいてくれ。ただ、評価チームは成果物を取得しにアクセスするから評価チームは全部のClient Controllerにアクセスできた方がいいな。

……と言われたところでして。

なるほど。確かに誰でもすべてのClient Controllerの成果物にアクセスできる状況というのは好ましくないものね。
それに、セキュリティ周りの設定は服部さんが引き続き管理していくとして、それ以外の設定については少しずつ各プロジェクトのリーダーが設定できるように移譲していってもいいかもしれないわね。

そうですね。僕の変更がボトルネックになっても問題ですし、そういったことができるのであれば実施していきたいです。

それ以外にもノードのセキュリティや管理について便利なプラグインがありそうよ。今回はこのあたりを確認していきましょう。

OSS Jenkinsにもロールベースのアクセス制御など優れたセキュリティ制御の方法がありますが、第7章ではCloudBees CIならではの大規模運用に関連した認証・認可について紹介します。

ユーザーの認証／認可

Operations CenterでのSSOの使用

シングルサインオン（SSO）を利用すると、ユーザーは一度のログインですべてのClient Controllerにアクセスできます。

Operations CenterのJenkinsの管理 > Security > Security Setting Enforcement

設定した場合、Client Controller側の設定はグレーアウトになり、設定できなくなります。

また、特定のClient Controllerにて、Operations Centerと異なる方法で認証を管理する必要がある場合、[Allow controllers to opt-out] チェックボックスをオンにすることでClient Controller個別での設定も可能になります。

Operations CenterでのSSOの使用の詳細な内容については【こちら】を参照ください。

Role-Based Access Controlの集中管理

代表的なJenkinsの認可の方法としてRole-Based Access Controlプラグインが挙げられます。
Role-Based Access Controlプラグインを用いることで、例えば管理者やジョブ作成者、匿名ユーザーなどのロールを作成し、ロールごとに全体的なアクセス、エージェント、ジョブ、実行、表示、SCMの権限を設定できます。また、アイテム固有のロールを作成して、ジョブ、パイプライン、フォルダーに特定の権限（例えば、ジョブの閲覧、実行、認証情報の管理など）を設定することも可能です。

CloudBees CIでは複数のClient Controllerを跨っての制御が可能です。開発者チームは影響のあるClient Controllerにのみアクセスを許可し、評価チームには成果物取得のため、すべてのClient Controllerへのアクセスを許可したいと考えています。

開発チームAはClient Controller1へのアクセスのみ
開発チームBはClient Controller2へのアクセスのみ
評価チームはClient Controller1、Client Controller2へのアクセスが可能

こういったClient Controllerを跨っての制御についても可能になります。具体的なグループとロールの設定については【こちら】を参照ください。

CloudBees CIでのRole-Based Access Controlの集中管理の詳細な内容については【こちら】を参照ください。

管理の委任

CloudBees CIではOverall/Administrator権限を付与することなく、管理の一部をユーザーに委任することが可能です。

Overall/Manage: ユーザーにCloudBees CI設定オプションの一部を管理する権限を安全に付与します。例えば、プロジェクトの命名変更、システムメッセージの更新、CasCバンドルの更新、ノード/クラウドの管理など、セキュリティ関連でない設定の変更が可能です。スクリプトコンソールの変更、セキュリティレルムの変更、プラグインの管理と言ったセキュリティ関連の設定にはアクセスできません。

Overall/Read: ユーザーにCloudBees CIインスタンスの設定を閲覧する権限を付与します。プラグインに利用可能な設定オプションを非管理者ユーザーが確認したり、ログや監視情報の参照も可能なため、ビルドの問題を確認する際に活用できます。

管理の委任の詳細な内容については【こちら】を参照ください。

特定のエージェントで実行できるジョブを制限する

Folders Plusプラグインを使用すると、特定のエージェントで実行できるジョブを制限することが可能です。
デフォルト設定では、ジョブはラベルを持つエージェントに割り当てられます。しかし、特定のエージェントが機密情報を持つ場合や、タスクが特定のエージェントに限定されるべき場合、これは問題となり得ます。
例えば、本番環境へのデプロイに必要な認証情報やツールを特定のエージェントに設定したとします。Folders Plusプラグインの制御が無い場合、設定済みのエージェント上で任意のジョブを実行し、認証情報やツールをコピーすることが可能になってしまいます。
Folders Plusプラグインでエージェントで実行可能なジョブを制限することで、運用グループはより安全にエージェントを管理することができるようになります。

チェックを付けた時点で、権限を持たないジョブが該当のノードを利用しようとすると「No valid security token.」となり実行ができなくなります。

実行できるようにするためにはFolder > Controlled Agentsからリクエストを発行し、エージェントを構成する権限を持つ人がリクエストを承認する必要があります。

Folders Plusプラグインの詳細な内容については【こちら】を参照ください。

Nodes Plus プラグイン

Jenkinsを運用するにあたり、ビルドエージェントは特定の個人が特定のビルドエージェントを管理することがよく見られます。
ビルドエージェントが何らかの原因でオフラインになりオンラインに戻らない場合、そのエージェントに割り当てられたビルドがビルドキューで滞留することになります。
OSS Jenkinsにはビルドエージェントがオフラインになった際に通知する仕組みが無いため、ジョブの成功/失敗のメール通知が届かないことで気づいたり、特定のプロジェクトのビルドがキューに滞留していても、WebブラウザでJenkinsインスタンスを確認するまで誰も気づかないことがあります。
Nodes Plusプラグインで利用可能になる「Node Owners」プロパティを設定することで、設定可能なトリガーに基づいて指定された所有者にメール通知を送ることが可能になります。指定可能なトリガーについては以下になります。

Folders Plusプラグインの詳細な内容については【こちら】を参照ください。

まとめ

溝口さんが言っていた「Client Controllerはメインで利用している開発チームからしかアクセスできないように設定しておいてくれ。ただ、評価チームは成果物を取得しにアクセスするから評価チームは全部のClient Controllerにアクセスできた方がいい」というのはRole-Based Access Controlの集中管理で実現できそうね。

Folders Plusプラグインで実現できる、エージェント上で実行できるジョブの制限についても、特に本番環境にデプロイするためのエージェントには制限をかけておいた方がよさそうですね。

これ以外にもいろいろ安全性を担保するための機能がドキュメントにいろいろ書かれているから、もう少し内容を確認していきましょう。

今回はセキュリティに関わる機能を5つ紹介しました。