0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

ROKSで考えるコンテナのサプライチェーンセキュリティ対策

0
Posted at

はじめに

Red Hat OpenShift on IBM Cloud(以下、ROKS)を利用する際、コンテナイメージの信頼性をどう担保するかは重要な課題です。本記事では、ROKS におけるサプライチェーンセキュリティ対策として、コンテナイメージの署名検証を中心に整理します。

特に Portieris を使った実装手順を紹介し、署名方式によって利用するツールが異なる点を説明します。

サプライチェーンセキュリティとは?

サプライチェーンセキュリティとは、アプリケーションが開発されてから本番環境で実行されるまでの流れにおいて、ソースコード、依存ライブラリ、CI/CD、コンテナイメージ、レジストリ、デプロイ、ランタイムを保護する考え方です。

具体的には、以下のようなリスクを防ぐために必要です。

  • 改ざんされたコンテナイメージの実行を防ぐ
  • 未許可イメージの混入を防ぐ
  • 信頼できないレジストリやイメージの利用を制御する
  • 本番環境に到達する前にポリシー違反を止める

サプライチェーンリスクについては米国のNISTがガイドラインをだしていることもあり、グローバルで注目されています。

サプライチェーンセキュリティの主な要素

サプライチェーンセキュリティを構成する主な要素は以下の通りです。

  • ソースコード管理
  • 依存ライブラリ管理
  • CI/CD パイプライン保護
  • コンテナイメージビルド
  • SBOM(Software Bill of Materials)
  • 脆弱性スキャン
  • イメージ署名検証
  • レジストリ保護
  • Admission Control
  • ランタイム検知
  • 監査ログ

なぜデプロイ前の署名検証が重要か

従来コンテナイメージのハッシュ値(digest)を発行元の値と突合することで信頼性を確認してきました。この方法では「改ざんの有無を確認」できますが、「そのイメージが正規の手段で作成されたものか」、「信頼できるフローを経て承認されたものか」、「誰が署名したか」を判断することはできません。

CI/CDパイプラインや認証認可の仕組みなど一度構築したコンテナイメージのサプライチェーンは「安全なもの」と思い込みがちですが、実際には開発途中のイメージが狙われることもあり、一度攻撃されるとユーザーも知らないまま改ざんされたイメージや設定を利用する可能性があります。

そのためビルドからデプロイまでの全工程を継続的に監視し、サプライチェーンのどこが攻撃されても、それを確認できる仕組みを作ることが重要です。これを実現するためサプライチェーンセキュリティには「入り口で防ぐ」、「途中工程で検出する」、「出口で拒否する」など複数の対策を組み合わせて多層防御の構えをとることが推奨されています。

この一環としてイメージの署名検証で、改ざんの有無だけではなく、責任の所在や信頼性を確認することが重要です。

ROKS 上で署名検証することの重要性

ROKS では、Pod 作成時に Admission Control の段階でイメージの信頼性を確認できます。署名検証を行うことで、未署名または信頼できないイメージを実行前にブロックできます。

これにより、クラスタ上で実行されるワークロードの信頼性を高め、セキュリティリスクを低減できます。

ROKS でサプライチェーンセキュリティ対策としてできること

コンテナイメージの署名方式によってツールが異なる

コンテナイメージの署名方式には複数の方式があり、ROKS で利用できるツールも署名方式によって異なります。

主な署名方式とツールの対応は以下の通りです。

署名方式 ツール 説明
Red Hat signatures Portieris GPG系の署名検証に対応
Cosign / Sigstore IBM Cloud Security and Compliance Center Workload Protection (Sysdig) Cosign / Sigstore 系の署名検証に対応

どちらが優れているかではなく、署名方式や運用モデルが異なるため、要件に応じて選択する必要があります。

※OpenShiftにネイティブな署名検証機能(Image Policy)がありますが、検証時は動作しませんでした。ROKSはマネージドであり、Machine Config Operatorへの設定変更が制限されているためと思われます。

Portieris

Portieris は、ROKS で利用できる Image Security Enforcement の仕組みです。GPG鍵を利用したRed Hat signatures 方式の署名検証を実現します。

Pod作成前のAdmission Control のタイミングで対象のコンテナイメージの署名検証を行い、ポリシーに違反するイメージの実行を拒否します。

構成図.jpg

IBM Cloud Security and Compliance Center Workload Protection / Sysdig

Sysdig ベースのワークロード保護サービスで、Cosign / Sigstore 系の署名検証に対応しています。こちらもPod作成前のAdmission Control のタイミングで署名検証できる選択肢として利用できます。

本記事では Portieris を中心に説明しますが、Cosign / Sigstore を利用する場合は Workload Protection / Sysdig の利用を検討してください。

Portieris の実装方法

ここからは、Portieris を使った署名検証の実装手順を見ていきましょう。

前提条件

本検証での前提条件は下記の通りです。

  • ROKS クラスタが作成済みであること
  • IBM Cloud Container Registry(ICR)が利用可能であること
  • ICR認証用API Key
  • ibmcloud CLI、oc CLI がインストール済みであること
  • 署名付与作業用の Linux サーバまたは環境があること

検証環境

  • OpenShift on IBM Cloud: ver 1.20
  • 作業用 Linux サーバ(署名付与用)
    • 必要なバイナリ: ibmcloud, oc, gpg, skopeo, pinentry, pinentry-tty

全体の流れ

  1. ROKS で Image Security Enforcement を有効化
  2. ICRの namespace を追加
  3. GPG 鍵の生成
  4. 署名付与対象のコンテナイメージを作成
  5. skopeo コマンドで署名を付与して ICR にプッシュ
  6. ROKS 上で ICR からイメージをプルするための Secret を作成
  7. ROKS 上で GPG 公開鍵の Secret を作成
  8. ROKS 上で Portieris の ImagePolicy を作成
  9. 署名検証を実施して Pod を起動

1. ROKS で Image Security Enforcement を有効化

まず、ROKS クラスタで Image Security Enforcement(Portieris)を有効化します。

※有効化時にcontrol planeの設定を更新するため完了に時間がかかる場合があります

# 機能有効化
ibmcloud oc cluster image-security enable --cluster <クラスタ名>

2. ICRの namespace を追加

作業用サーバで ICR の namespace を追加します。

# 今回利用する ICR のあるリージョンを設定
ibmcloud cr region-set jp-tok

# ICR の namespace を追加
ibmcloud cr namespace-add <namespace名>

# 設定の確認
ibmcloud cr namespace-list

3. GPG 鍵の生成

署名に使用する GPG 鍵を生成します。

gpg --generate-key

対話形式で以下の情報を入力します。

  • Real name: 任意の名前(例: portieris test
  • Email address: 任意のメールアドレス(例: portieris-test@example.com
  • Passphrase: 任意のパスフレーズ(例: portieris test

生成後、フィンガープリントを取得します。

gpg --list-secret-keys --with-colons "portieris test" | awk -F: '/fpr:/{print $10; exit}'

GPG 公開鍵をエクスポートします。

gpg --export --armor <フィンガープリント> > my.pubkey

4. 署名付与対象のコンテナイメージを作成

テスト用のコンテナイメージを作成します。

Dockerfile の例:

FROM registry.access.redhat.com/ubi9/ubi-minimal:latest
CMD ["sh","-c","echo signed image test && sleep 3600"]

イメージをビルドします。

# コンテナイメージをビルド
podman build -t portieris-test:v1 .

# イメージの確認
podman image list

5. skopeo で署名を付与して ICR にプッシュ

skopeo コマンドを使って、署名を付与しながらイメージを ICR にプッシュします。

skopeo --insecure-policy copy \
  --sign-by <フィンガープリント> \
  --dest-creds "iamapikey:<ICR APIkey>" \
  containers-storage:localhost/portieris-test:v1 \
  docker://jp.icr.io/<ICRのnamespace名>/portieris-test:v1

プッシュ時にパスフレーズが求められるため、先ほど設定したパスフレーズを入力します。

プッシュ後、イメージを確認します。

ibmcloud cr image-list

6. ROKS 上で ICR からイメージをプルするための Secret を作成

ROKS 上で ICR にアクセスするための Secret を作成します。

oc create secret docker-registry icr-secret \
  --docker-server=jp.icr.io \
  --docker-username=iamapikey \
  --docker-password=<ICR APIkey> \
  --docker-email=iamapikey

ServiceAccount を作成します。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: icr-puller
  namespace: <任意のnamespace名>
imagePullSecrets:
  - name: icr-secret
oc apply -f <yamlファイル名>

7. ROKS 上で GPG 公開鍵の Secret を作成

署名検証に利用する GPG 公開鍵の Secret を作成します。

# Secret を作成
oc create secret generic my-pubkey \
  --from-file=key=my.pubkey \
  -n <署名検証したいnamespace名>

# 作成の確認
oc get secret -n <署名検証したいnamespace名>

8. ROKS 上で Portieris の ImagePolicy を作成

ImagePolicy を作成します。

apiVersion: portieris.cloud.ibm.com/v1
kind: ImagePolicy
metadata:
  name: <任意の名前>
  namespace: <任意のnamespace名>
spec:
  repositories:
  - name: "jp.icr.io/<ICRのnamespace名>/*"
    policy:
      simple:
        requirements:
        - type: "signedBy"
          keySecret: my-pubkey

YAML を適用します。

oc apply -f <yamlファイル名>

動作確認

署名済みイメージの起動

署名済みイメージを使って Pod を起動します。

oc run portieris-test \
  --image=jp.icr.io/<ICRのnamespace名>/portieris-test:v1 \
  --restart=Never \
  --overrides='{"spec": {"serviceAccountName":"icr-puller"}}'

正しく署名されていれば、Pod が正常に作成されます。

未署名イメージの起動(失敗例)

未署名のイメージを使って Pod を起動しようとすると、以下のようなエラーが表示されます。

Error from server: admission webhook "trust.hooks.securityenforcement.admission.cloud.ibm.com" denied the request:
simple: policy denied the request: A signature was required, but no signature exists

このように、Portieris が Admission Control の段階で未署名イメージの実行を拒否します。

まとめ

本記事では、ROKS におけるサプライチェーンセキュリティ対策として、Portieris を使ったコンテナイメージの署名検証についてみていきました。

  • サプライチェーンセキュリティは、開発から本番実行までの流れ全体を保護する考え方
  • ROKS では Admission Control の段階で署名検証を行い、未署名イメージの実行を防げる
  • コンテナイメージの署名方式によって利用するツールが異なる(Red Hat signatures → Portieris、Cosign/Sigstore → Sysdig)
  • Portieris を使うことで、IBM Cloud Container Registry と連携した署名検証を実現できる

ROKS だけでサプライチェーンセキュリティが完全に解決するわけではありませんが、Admission Control での署名検証は重要な対策の一つです。要件に応じて適切なツールを選択し、セキュリティ対策を強化していきましょう。

参考文献 / 参考URL

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?