Sysdigを使用してOpenShiftにおけるTektonパイプラインをセキュアにする

本文の内容は、2020年4月9日にSysdigのVicente Herrera Garcíaが投稿したブログ(https://sysdig.com/blog/securing-tekton-pipelines-openshift/)を元に日本語に翻訳・再構成した内容となっております。

このブログ投稿では、TektonパイプラインとOpenshiftクラスター用の再利用可能なSysdig Secureイメージスキャンタスクを作成する方法を学びます。このタスクは、多くのパイプラインにデプロイできます。

DevOpsエンジニアとして、アプリケーションを迅速にデリバーする一方で、CIS、PCI DSS、NIST 800-190、GDPRなどのセキュリティ標準に準拠したい場合は困難な作業になる可能性があります。

CI/CDパイプラインにイメージスキャンを実装して、既知の脆弱性や不正な設定などの問題を検出して解決することができます。ただし、多くのパイプラインでは、各スクリプトを異なる方法でカスタマイズする必要がある場合があります。それは負担であり、不確実性をもたらし、エラーが発生しやすくなります。

Tektonは、パイプラインタスクの再利用に重点を置いたクラウドネイティブの継続的インテグレーションおよびデリバリー（CI/CD）ツールです。これは、多くのパイプラインでのSysdig Secureイメージスキャンなどのツールの統合を加速して、セキュリティポスチャポリシーにおけるコンプライアンスを有効にすることですばやく実現します。

この記事は、以前にMarc ChisinevskiのGitHubアカウントで優れたチュートリアル「OpenShift 4.2以降でのSysdig Secureイメージスキャンを使用したTekton Pipeline」を彼と共同執筆したものです。

Tekton パイプライン

Tektonは、継続的インテグレーションおよびデリバリー（CI/CD）システムを作成するために設計された、GoogleによるKubernetesネイティブのオープンソースフレームワークです。 Kubernetesネイティブであることは、Jenkins、Circle-CI、Gitlab CI/CD、Azure Pipelines、AWS CodePipelineおよびCodeBuild、GitHubアクションなどの他のCI/CDスタックとは異なり、Tektonはクラウドネイティブのコンセプトを基盤として構築されていることを意味します。たとえば、クラスタで直接実行され、すべてのTekton要素はKubernetesカスタムリソースです。

Tektonの優れた機能の1つは、コンポーネントの再利用に重点を置いていることです。いくつかの異なるパイプラインでインスタンス化し、異なる入力および出力リソースに接続することにより、再利用できる一般的なタスクを定義できます

Tektonパイプラインの構造

Tektonは、パイプラインの構築に使用する少数のKubernetesリソースを定義します。

TektonのCI/CDパイプラインは、いくつかのステップで構成されるタスクをインスタンス化します。パイプラインには、タスクへの入力および出力として機能するPipelineResourcesがあります。これらのタスクは、異なるPipelineResourcesを使用して、異なるパイプラインでインスタンス化できます。ServiceAccountはPipelineを実行し、PipelineRunを作成します。 詳細については、公式ドキュメントをご覧ください。

Tektonタスクは汎用的で、入力および出力リソースを取得し、コンテナイメージとしてステップを実行し、いくつかのパイプラインで再利用できます。 次に、いくつかのタスク例を示します：

• unit-test: リポジトリの単体テストを実行します。
• Input: gitリポジトリ
• build-push: Kanikoを使用してイメージをビルドし、リポジトリにプッシュします。
• Inputs: gitリポジトリ
• Output: ビルドされたコンテナイメージ
• deploy: イメージをクラスターにデプロイします。
• コンテナイメージ

たとえば、特定のGoアプリケーションリポジトリがイメージをビルドしてレジストリにプッシュし、それをクラスターにデプロイするためのパイプラインを構築するために、これらのタスクをインスタンス化して相互接続します。すべてのステップが問題なく実行された場合です。

イメージスキャンのためのTektonタスク

Sysdig Secureでのイメージスキャン用に、任意のパイプライン定義で再利用できる新しいTektonタスクを作成します：

• scan-image: Sysdig Secureを使用してイメージをスキャンし、セキュリティポリシーに準拠していない場合にパイプラインを停止します。
• Input: コンテナイメージ

scan-imageタスクの定義は次のとおりです：

apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:
  name: scan-image
spec:
  inputs:
    resources:
    - name: image
      type: image
  steps:
  - name: scan-image-step
    image: sysdiglabs/secure-image-scanning:latest
    env:
    - name: IMAGE_TO_SCAN
      value: $(inputs.resources.image.url)
    - name: SYSDIG_SECURE_TOKEN

      value: <your_sysdig_secure_token> 

ご覧のとおり、入力としてimageタイプのリソースが必要であり、単一のステップがあります。そのステップには名前とその実行をカプセル化するイメージがあります。この場合、sysdiglabs/secure-image-scanning:latestです。スキャンするイメージのURLおよびアカウントを識別するためのSysdig Secure APIトークンの環境変数としてパラメーターが渡されます。

このイメージスキャン手順ではSysdig Secureアカウントを利用しているため、アカウントですでにアクティブになっているCIS、PCI、またはNISTのすべてのデフォルトのコンプライアンスイメージスキャンポリシーと、自分で定義したカスタムポリシーが考慮されます。

イメージスキャンを使用したパイプライン定義の例

また、タスクが再利用される方法をよりよく例示する、もう少し複雑なパイプラインを構築してみます。それを行うために、リポジトリで利用可能なSkaffoldプロジェクトの一部である2つのマイクロサービスアプリケーションを使用します：

• Microservice 1: leeroy-app
• Microservice 2: leeroy-web

これらは、行をプリントし、その出力をWebサーバーで公開するいくつかの小さなgoプロジェクトです。 なので複雑すぎません。

両方のマイクロサービスが同じコードリポジトリに存在するため、両方に単一のユニットテストタスクを使用できます。ただし、ビルドとデプロイのタスクは、マイクロサービスごとに並行して実行されます。また、脆弱性が検出された場合に停止することを期待して、デプロイメント前に新しいスキャンイメージタスクを挿入します。

したがって、前に定義した一般的なタスクを使用して、作成する具体的なパイプラインは、次のようにそれらを使用します：

パイプライン内のタスクインスタンス：

• unit-test: 同じ「リポジトリ」上のAppとWebの両方のタスク「単体テスト」
• build-app: Appのタスク「build-push」は、単体テスト後に実行されます
• build-web: 単体テスト後に実行されるタスク「build-push」（Webの場合）
• scan-app: Appのタスク「scan-image」は、build-appの後に実行されます
• scan-web: Webのタスク「scan-image」は、build-webの後に実行されます
• deploy-app: Appのタスク「deploy」はscan-appの後に実行されます
• deploy-web: scan-webの後に実行されるWebのタスク「deploy」

これは、パイプラインの完全なコードです。 最初は、コンテナレジストリ資格情報、パイプラインとその役割を実行するためのサービスアカウント定義、新しいスキャンイメージを含む一般的なタスク、パイプライン定義、リソース、それを実行するためのPipelineRunが含まれています。

Openshift

この例では、Kubernetesの上に構築されたRed HatのオープンソースオーケストレーターであるOpenShiftを使用します。これは、セキュリティに焦点を当て、すぐに使用できる多くの拡張機能を組み込んでいます。

これを商用製品として使用する場合は、インフラストラクチャーにOpenShiftをインストールし、サーバーソフトウェアの開発に長い歴史を持つ組織であるRed Hatからサポートを受けることができます。

Kubernetesには、さまざまなソフトウェアをプラグインして実装できるさまざまな一般的な定義がありますが、OpenShiftには、すぐに使用できるクラスターがあり、本番環境対応のクラスターを実行するために必要なものがすべて揃っています。

役割ベースのアクセス制御（RBAC）に加えて、OpenShiftには、拡張機能を備えたセキュリティコンテキスト制約（SCC）が組み込まれています。また、一般的なKubernetesのIngressよりも成熟したHAProxyを備えたルーターと、より優れたコンテナイメージのライフサイクル管理のためのImageStreamを使用できます。ネットワーキングは、オープンソースのマルチレイヤー仮想スイッチであるOpen vSwitchの堅牢な実装を活用しています。一般に、クラスターを管理するために個別のツールや追加のプラグインをインストールする必要がないため、管理者のユーザーエクスペリエンスはよりシームレスになります。

Red Hat CodeReadyコンテナを使用してOpenShiftをローカルにインストールする

これを使用してローカルマシンでこれらの例をテストし、クラウドリソースを消費しないようにするために、Code Ready Containers（CRC）を使用してOpenShiftをローカルにインストールする方法を説明します。これは、インストールが簡単で、完全なOpenShiftインストールよりも開発マシンで消費するリソースが少なくなるように調整された、開発用の特定のインストールパッケージです。

Red HatのCode Ready Containersページにアクセスし、登録してインストールパッケージをダウンロードし、pull-secret.txtファイルをダウンロードしてデプロイします。公式ドキュメントの指示に従ってインストールします。要約すると次のようになります

1. crc.tar.xyz/crc.zip圧縮ファイルをダウンロードします。
2. 解凍して、crcをパス内のフォルダーに移動します。
3. crc setupを実行します。
4.  $HOME/.crc/binをパスに追加して、ocコマンドを使用できるようにします（OpenShiftの代わりにkubectlを使用します）。
5. crc start --pull-secret-file pull-secret.txtを実行します。
6. ログメッセージに、作成されたクラスターのkubeadminとしてログを記録する方法が示されます。次のようになります。

      oc login -u kubeadmin -p <your_password> https://api.crc.testing:6443

コンピュータのオペレーティングシステムによっては、いくつかの追加手順が含まれる場合があります。 上記のドキュメントを参照してください。

すべてが機能していることを確認するには、次のコマンドを実行して、バージョンが少なくとも次のバージョンと同じであることを確認します。

$ oc version && crc version
Client Version: v4.4.0
Server Version: 4.3.0
Kubernetes Version: v1.16.2
crc version: 1.6.0+8ef676f

OpenShift version: 4.3.0 (embedded in binary) 

Tektonをインストールする

Tektonをデプロイするには、新しいOpenShiftプロジェクトを作成し（新しいKubernetes namespaceの作成を含みます）、anyuidのtekton-pipelines-controller権限を追加し、リモートでホストされるマニフェストをapplyします。

oc new-project tekton-pipelines
oc adm policy add-scc-to-user anyuid -z tekton-pipelines-controller

oc apply --filename https://storage.googleapis.com/tekton-releases/pipeline/latest/release.notags.yaml 

anyuidは、tekton-pipelines-controllerアカウントの管理者権限を有効にする機能であり、Tekton-pipelines namespaceにTektonに必要なリソースをデプロイできます。

必要に応じて、以下こコマンドを使用して、パイプラインの状態をチェックし、ブラウザーで実行するWebダッシュボードをデプロイできます。

oc apply -f https://storage.googleapis.com/tekton-releases-nightly/dashboard/latest/openshift-tekton-dashboard-release.yaml --validate=false

oc get route tekton-dashboard -n tekton-pipelines 

最後のコマンドは、ダッシュボードへのアクセスに使用するドメインを表示します。 次のようになります。

http://tekton-dashboard-tekton-pipelines.apps-crc.testing

パイプライン定義を準備する

パイプライン定義を準備するには、ローカルにダウンロードしていくつかのファイルを編集する必要があります：

wget https://raw.githubusercontent.com/marcredhat/crcdemos/master/sysdig/sysdigpipeline.yaml

wget https://raw.githubusercontent.com/marcredhat/crcdemos/master/sysdig/sysdigpipelineblock.yaml 

sysdigpipelineblock.yamlファイルをもう一度見てみましょう。これまでに説明したSysdig Secureタスクと、その他の種類のTekton要素が表示されます。また、ビルドされたイメージをプッシュするためにDockerを認証するためのシークレットの定義もあります。

sysdigpipeline.yamlとsysdigpipelineblock.yamlを次のように編集します：

• ファイルの先頭にある<username>および<password>フィールドのdockerレジストリ資格情報を置き換えます。さまざまな認証スキームを使用するには、Tektonの公式ドキュメントで詳細を確認してください。
• leeroy-appイメージのリモートレジストリURLに置き換えます。
• gcr.io/christiewilson-catfactory/leeroy-app
• leeroy-webイメージのリモートレジストリURLに置き換えます。
• gcr.io/christiewilson-catfactory/leeroy-web
• 以下のSysdig APIキーを置き換えます。
• <REPLACE WITH YOUR TOKEN>

sysdigpipelineblock.yamlファイルはsysdigpipeline.yamlと同等ですが、以前にビルドされたイメージをスキャンする代わりに、イメージスキャンプロセスを検証しないはずの既知の脆弱なイメージ定義をスキャンするように修正されています。

パイプラインをデプロイして実行する

すべてが準備できたら、次の方法でパイプラインをデプロイできます：

oc create -f sysdigpipeline.yaml

そして、進行状況を確認してください：

oc get pods


NAME                                                      READY   STATUS    RESTARTS   AGE
demo-pipeline-run-1-skaffold-unit-tests-gxwmq-pod-k2qhk   2/2     Running   0          30s
tekton-dashboard-77f5d8994b-ckhmk                         2/2     Running   1          7h17m
tekton-pipelines-controller-8564689cff-xcp75              1/1     Running   0          7h17m

tekton-pipelines-webhook-56b4b768c5-szxlg                 1/1     Running   0          7h17m 

ポッドが実行されている間、各タスクがポッドを作成するのがわかります。その中に、各ステップのコンテナが作成されます。 すべてがうまくいった場合は「Completed」、それ以外の場合は「Error」の状態になります。

実行が正常に完了すると、すべてのパイプラインポッドが「Completed」状態にあることがわかります。

ポッドのログを確認し、その出力をすべて確認するには、次のコマンドを使用します：

oc logs demo-pipeline-run-1-scan-image-app-nwml6-pod-c6tt4


{"level":"info","ts":1583344980.0405614,"logger":"fallback-logger","caller":"logging/config.go:69","msg":"Fetch GitHub commit ID from kodata failed: \"KO_DATA_PATH\" does not exist or is empty"}
env var $TIMEOUT not defined, defaulting to 10 minutes
Adding image docker.io/vicenteherrera/leeroy-app to Anchore engine at https://secure.sysdig.com/api/scanning/v1/anchore
Image digest: sha256:cff29b270cfb0d5c37751073eb0d51165b7ec74e616b1a0e1295386350a25933
Image tag: docker.io/vicenteherrera/leeroy-app
Waiting for image sending and unpacking to complete
Image received
Waiting for scan analysis report to be ready
...
Waited 35 s
Image Digest: sha256:cff29b270cfb0d5c37751073eb0d51165b7ec74e616b1a0e1295386350a25933
Full Tag: docker.io/vicenteherrera/leeroy-app:latest
Status: pass
Last Eval: 2020-03-04T18:23:07Z

Policy ID: default 

Sysdig Secureアカウントで設定したポリシーはスキャンで考慮され、Sysdig Secureで結果を確認します。これについては、後のセクションで説明します。

Tektonダッシュボードをナビゲートしたい場合は、タスクとステップのすべてのログに簡単にアクセスすることもできます。

脆弱なイメージでパイプラインを実行する

脆弱なイメージでパイプラインを実行するには、まず、現在のパイプライン実行を削除して、混同しないようにする必要があります。また、表示されるポッドがTektonパイプラインとダッシュボード自体のものだけになるまで待ちます。

oc delete -f sysdigpipeline.yaml

次に、脆弱なイメージを使用してパイプラインsysdigpipelineblock.yamlを実行すると、結果は次のようになります；

oc get pods


NAME                                                      READY   STATUS    RESTARTS     AGE
demo-pipeline-run-1-build-skaffold-app-rt4c6-pod-5zd8r    0/4     Completed   0          19m
demo-pipeline-run-1-build-skaffold-web-dsfd5-pod-xznpk    0/4     Completed   0          19m
demo-pipeline-run-1-scan-image-app-6jnrh-pod-487p5        0/1     Error       0          17m
demo-pipeline-run-1-scan-image-web-mqnnl-pod-9h4xv        0/1     Error       0          17m
demo-pipeline-run-1-skaffold-unit-tests-gnnrh-pod-697pj   0/2     Completed   0          20m
tekton-dashboard-77f5d8994b-ckhmk                         2/2     Running     1          8h
tekton-pipelines-controller-8564689cff-xcp75              1/1     Running     0          8h

tekton-pipelines-webhook-56b4b768c5-szxlg                 1/1     Running     0          8h 

失敗したスキャンのログは次のようになります：

oc get logs demo-pipeline-run-1-scan-image-app-6jnrh-pod-487p5


{"level":"info","ts":1583347195.6537874,"logger":"fallback-logger","caller":"logging/config.go:69","msg":"Fetch GitHub commit ID from kodata failed: \"KO_DATA_PATH\" does not exist or is empty"}
env var $TIMEOUT not defined, defaulting to 10 minutes
Adding image quay.io/marcf5/mltitanic to Anchore engine at https://secure.sysdig.com/api/scanning/v1/anchore
Image digest: sha256:6ceaa66e80586fca952eaa6436ce7497a476a4556272eff6da679eb79d142a09
Image tag: quay.io/marcf5/mltitanic
Waiting for image sending and unpacking to complete
Image received
Waiting for scan analysis report to be ready
...............
Waited 625 s
Image Digest: sha256:6ceaa66e80586fca952eaa6436ce7497a476a4556272eff6da679eb79d142a09
Full Tag: quay.io/marcf5/mltitanic:latest
Status: fail
Last Eval: 2020-03-04T18:58:05Z

Policy ID: default 

Sysdig Secureでのポリシーの設定と結果の参照

パイプラインでイメージをスキャンするときは、プライベートトークンを使用してアカウントを識別しています。これにより、Sysdig Secureアカウントで独自のポリシーを作成し、いくつかのゲートを定義して特定の脆弱なパッケージまたは構成のイメージをスキャンし、最終的にCI/CDパイプラインでブロックすることができます。

パイプラインでスキャンされたイメージのイメージスキャンレポートはログに記録され、Sysdig Secureアカウントでオンラインで利用できます。それにアクセスして、詳細なレビューを行います。連続スキャンでのイメージのセキュリティベンチマークが時間とともにどのように進化してきたかに関する履歴情報も含まれます。

まとめ

Tektonは、クラウドネイティブなオープンソースの継続的インテグレーションおよびデリバリー（CI/CD）システムです。特にKubernetesに合わせて調整されており、再利用可能なタスクに重点を置いています。OpenShiftと一緒にTektonをオーケストレーターとして使用すると、完全にクラウドネイティブなパイプラインを迅速に構築できます。

すべてのパイプラインにSysdig Secureイメージスキャンタスクを追加して、既知の脆弱性を簡単に見つけ、セキュリティのベストプラクティスに対して設定を検証します。このようにして、CIS、PCI DSS、NIST 800-190、GDPRなどのセキュリティフレームワークに対する規制コンプライアンスについて簡単にレポートできます。 Sysdig Secureを今すぐお試しください！