Building a secure software factory on AWS using Amazon EKS

Pulisher : Cloud Technology Center イ・ギョンソン
Description : Amazon EKSを使用しながら、CNCF secure software factoryを使って最初からセキュリティを強化した方法でデプロイするWorkShopセッション。

はじめに

日々急速に発展している昨今、セキュリティは常に最初から私たちと一緒にいたと思います。 DevOpsという言葉が出たばかりですが、今は単純なDevOpsではなく、Securityまで考慮してDevSecOpsについてもっと深く勉強してみたいと思い、直接参加するWorkshopセッションを申し込みました。

セッションの概略紹介

本セッションは、グローバルに規制された環境内でセキュリティを最優先するソフトウェアを開発することを目指し、安全かつ弾力的に高速に提供するために、Amazon EKSを使用してCNCF secure software factoryを通じて、最初からセキュリティを強化した方法で配布するWorkShopを行うセッションです。

Amazondmsクラウドの構築を開始したとき、トラフィックを持続させ、パフォーマンス、安定性、またはデータがセキュリティの危険性にさらされることを気にする必要がないようにしたいと考えていました。
世界中を航行する船や、AWSがデータを運ぶ海底のダークファイバーケーブルを通じて、ネットワークはコラボレーションとアイデアのやり取りを可能にします。 そしてそれは地域を超えたコミュニティを生み出します。

ワークショップ開始前

SSF(Secure Software Factory)を説明する前に、ソフトウェアサプライチェーンとソフトウェア工場という用語を定義してくれました。

ソフトウェアサプライチェーン(software supply chain)は、最終消費者にアプリケーションを作成、テスト、パッケージ、および配布するために必要なツール、ライブラリ、およびプロセスで構成されています。

ソフトウェアファクトリー(Software Factory)は、ソフトウェアサプライチェーン内でソフトウェア配信を容易にする論理的な構造です。

Cloud Native Computing Foundation (CNCF) が発行した ‘Software Supply Chain Best Practices’のうち、下記の4つの原則を使用して、ソフトウェアファクトリー(Software Factory)の3つのBuild(=5つの要素)に適用することができます。

・Verification
・Automation
・Authorization in Controlled Environments
・Secure Authentication

つまり、SSF(Secure Software Factory)は、上記のプロセス段階(Pre-build、Build、Post-build)で発生する攻撃または悪用に対して保護することです。

この時、下記の3つの原則を考慮してソフトウェアパターンに適用すると、適切な認証システムを通じてアーティファクトが生成され、検証して保護することができます。

・Provenance verification : アーティファクトの出所とメタデータが改ざんされていないか。
・Trustworthiness : 適切なコードが安全に実行し、リスクに対して十分な情報を基に信頼があるかどうか。
・Dependencies : アーティファクトの依存関係と信頼性の確認

ワークショップ開催

今回のワークショップで進行する最終的なアーキテクチャは上記の図の通りで、4つのモジュールについての内容は下記の通りです。

---

モジュール1 ：

SSFを構成するのに必要な最も基本的なリソースであらかじめプロビジョニングされていました。

・AWS CodeCommit : EKSアプリケーションを実行するためのK8s設定ファイル
・Amazon Inspector : Amazon ECRにアップロードされたコンテナにソフトウェアの脆弱性を継続的に検査します
・AWS KMS : アーティファクト署名、保存されている間SBOMを暗号化するためのキー
・AWS Signer : 作成されたSigningプロファイルを通じて、コンテナイメージに署名し、コードの信頼と整合性を保証するための用途
・AWS CodePipeline
・Amazon EKS : アプリケーションの配布、Kyvernoを通じたポリシーの施行

---

モジュール2 ：

git-secretsを通じて、リポジトリの全てのファイルを検査して特定のpasswordがcommitされないように防止した後、Dockerを通じてコンテナイメージを生成してECRにpushしてビルド、生成したイメージをInspectorを通じてイメージのSBOMを生成する段階を経て、Commitにpushしてパイプラインをトリガーする過程を経ます。

git-secretsを使って全てのファイルとディレクトリ内部ファイル検査を行い、Inspectorを使ってSBOMを生成してS3にアップロードして、CI/CDパイプラインの初期コンポーネントを完成します。

(時間の関係でキャプチャの代わりに録画してキャプチャしましたが、画質が悪いのでご了承ください。)

---

モジュール3

アプリケーションのデプロイメントを管理し、ポリシーの施行を確認するために、EKSを通じてWebアプリケーションとポリシー施行ツールをホストし、ELBを通じて負荷分散し、ArgoCDを通じたCD、Kyvernoを通じてリソースの検証、変更、生成を行い、継続的なデプロイメントを試みます。

この時、EKSクラスターにポリシー適用を有効にして、構成したように必要な署名されたアーティファクトがないため、アプリケーションが正常にデプロイされていないことが確認できます。 (502 Bad Gateway)

---

モジュール4 : SSF実行

AWS Signerサービスを通じて、Notationというものと統合され、ECDSA暗号化アルゴリズムを使用して画像に署名してアップロードします。

その後、AWS SDKを通じてInspectorを呼び出してCosignで整合性と信頼を提供するためにSBOMを証明して署名します。

再ビルド後、Pipelineを実行すると、署名されたイメージでArgoCDを通じて正常にWebアプリケーションをデプロイすることができます。

最終的に該当アプリケーションのURLを貼り付けると、下記のような画面が確認できました。

セッションを終えて

このテーマについては、以前から絶えず言及されてきました。Elastic Beanstalkベースから現在のEKSベースまで、また、毎回追加されるAWS NativeサービスやAWS以外の様々なソリューション、様々な方法を通じて常に着実に追加され、発展している部分を見ると、今後も多くのツールと技術を通じてその概念を拡張し、セキュリティを向上させることができると思いました。