TOP>コラム一覧>Well-Architected コンテナセキュリティの柱を作る試み -①基礎編-

Well-Architected コンテナセキュリティの柱を作る試み -①基礎編-

はじめに

こんにちは。山下です。
AWSでは数多くのマネージドサービスが提供されています。マネージドサービスを用いてなるべくユーザが管理する部分をAWSに委任する事で運用負担の軽減、責任共有モデルの責任部分を減らす事が可能です。また、それによる運用のための人件費削減や自動スケールアウトによる信頼性と性能の向上まで見込めます。
そんなマネージドサービスの中でもアプリケーションを提供する上で大変強力なのがコンテナ関連サービス群です。今までの開発と運用手法から変更が必要なものですが、これらを上手く扱う事ができれば、上記のメリットを享受できるだけでなくハイブリッドクラウド・マルチクラウドにも対応でき信頼性のさらなる向上やセキュリティ、運用面でも大きなメリットとなります。

コンテナを扱えるAWSサービス

AWSでコンテナを扱う事ができるサービスとしては以下があります。コンテナと聞くとECS/EKSだけが範疇に見えますが、EC2上に自分でコンテナランタイムを構成する事でコンテナを扱う事もできますし、BeanstalkやLambdaでも一部制約があるもののコンテナイメージを展開する事ができます。

ただし、それぞれユースケースに応じて得意とするものと合わないものがあります。例えば、Lambdaが図を見ると一番ユーザ管理部分が少なく優れているように見えますが、実行時間が限られるため常時動かす、または処理に時間を要するようなサービスには向きません。また、BeanstalkについてもWebサーバ,APサーバなど用途が限られており全てのワークロードに対応はしていません。とはいえ、EC2でユーザが管理する箇所が増えてしまうのも避けたい。この中間に位置しマネージドサービスのように構成できるのがコンテナであり、AWSではECSとEKSが利用できます。後述のGitOpsやマルチクラウドという観点では特にEKSが有用です。
また、ECS/EKSでコンテナを扱う上で補助となるのが、AWSのマネージドサービス群です。EC2と同様に監視にCloudWatch、セキュリティ対策にGuardDutyが利用できます。また、ロードバランサーにELB、ストレージにEBS/EFSを利用できますが、これらを手動で作成していくのではなくKubernetes経由で自動作成できる機能が提供されています。EC2よりもマネージドでありながらBeanstalkやLambdaよりも自由度が高いのはこうした点からも伺えます。

IngressController:https://github.com/kubernetes-sigs/aws-load-balancer-controller#readme

StorageClass:https://kubernetes.io/ja/docs/concepts/storage/storage-classes/#aws-ebs

GitOps

コンテナアプリケーションをKubernetes(以降K8s)と扱っていく上で非常に強力なのがGitOpsという運用思想とその実装です。AWSではCIツール、監視サービス、オートスケール機能、IaCによるインフラ管理が提供されております。これにコンテナを組み合わせてさらにGitOpsに特化したデプロイツールを組み込むことでさらに強力な基盤となります。

GitOpsとは?

GitOpsとはWeaveWorks社により2017年ごろから提唱された新しいDevOpsの形です。Git上にソースコード、CIに必要なビルドファイル、CI設定ファイル、DockerFileなどを置くだけでなく、コンテナのデプロイに必要なyamlファイルも全てGit上に置きGitで全てを一元管理するという思想です。これにより開発者はGitに対してのみ操作を行うため、全ての操作がCommitに記録され追う事が出来ます。また、ロールバックについてもMerge前の状態に戻すことで簡単に実現可能です。宣言的デプロイメントを思想にしたK8sと相性が非常によいです。

https://www.weave.works/technologies/gitops/

また、このGitOpsを実現する上で欠かせないのがArgoCDやFluxCDといったCDツール群です。これらはGit上のyamlファイルを監視しつづけます。これによりコンテナイメージのバージョンが変更されればアップデート、ロールバック、Ingressと組み合わせてBlue/Greenデプロイメントを行う事が自動で可能です。ArgoCDやFluxCDが自動でK8sに対してデプロイを行うためです。また、K8sもデプロイされたyamlを基にリソースを作成/変更/削除を自動で行います。
いずれにせよGitOpsの大事な点は人の手を介しているのがソースコードからコンテナを作成するCommitとそれを承認するMerge、コンテナをどのようにK8s上に展開するかを定めたyamlファイルのCommitと承認のMergeです。厳密にはCIを行うための定義やその他連携ツールの操作定義や操作もありますが、人が手動で作業を行う要素はその程度です。人為的な事故を防ぐだけでなく、K8sに対する操作も制限されるためセキュリティ面でも有用です。

また、GitOpsを構成したK8sを軸とすることはマルチクラウドという観点でも有用です。AWSではマルチAZ、マルチリージョンで信頼性を向上させる事がベストですが、さらにMicrosoft Azure(Azure)やGoogle Cloud(GCP)など別クラウドプロバイダー、オンプレミスとのハイブリッドで構成する事ができます。ECSの場合だと、デプロイを行う定義及びオーケストレータはAWSに限定されたものになりAzureやGCPでは流用ができず、オンプレミスもECSでないと利用ができません。一方、K8sであればAzureとGCPでも利用でき、オンプレミスでもEKS Anywhereだけでなく様々なK8s製品へ適用する事も出来ます。
AWS全体に影響が及ぶ問題が発生してもユーザは別のクラウドに展開し直す事でサービスを継続できますし、逆にAzureやGCPを主とするユーザがAWSに退避する事も可能です。なぜそれが出来るかというと全てのファイルはGitに存在し、K8sはベンダーニュートラルに利用できるためです。

コンテナベースのアプリケーションを扱う危険性

ここまで見てきた通り、AWSのマネージドサービスとコンテナ関連ツール群を扱うことはEC2上でミドルウェアやソフトウェアをデプロイする以上のメリットがありつつも、BeanstalkやLambdaよりも自由度が高くあらゆるワークロードに対応できます。
これによりWellArchitectedFrameworkで柱とされる運用性、信頼性、性能、人件費を減らすという意味ではコスト最適化もさらに担保する事が出来ます。

https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/welcome.html

しかし、導入によってセキュリティも満たせているのでしょうか?ここまで見てお気づきの方もいるかもしれませんが、ユーザが管理しないといけないものはゼロではありません。さらにGitOps、K8sだから解消できた課題もあれば、GitOps、K8sだからこそ考えないといけない課題もあるのです。
ユーザはコンテナを扱う上で責任を負わなければいけないものと観点についてリスクと対策を理解する必要があります。WellArchitectedFrameworkのレンズとなるものを考える必要がありますが、具体的にAWSとして俯瞰的に提言されているものはなく、自分たちで考えていく必要があります。
そのヒントとなるのがNISTにより提供されているSP800-190『コンテナアプリケーションガイドライン』です。このガイドラインではコンテナアプリケーションと基盤を扱う上でのリスクと対策が定義されています。

SP800-190について

NISTは米国の標準技術研究所で様々なITセキュリティのガイドラインを提示しています。国際的な標準ガイドとなっています。そのガイドはさらにIPA:情報処理推進機構によって翻訳・監修され、日本国内でも展開されています。

https://www.ipa.go.jp/security/reports/oversea/nist/ug65p90000019cp4-att/000085279.pdf

NIST SP800-190の図でも示されている通り、インフラを抽象的に表すとコンテナイメージを格納するレジストリ、コンテナをデプロイし管理するためのオーケストレータ、コンテナが実際に稼働するホストマシンとなります。
また、アプリとしては開発工程によりコンテナイメージが作成された後にレジストリに格納。オーケストレータを通じてレジストリからコンテナイメージがPullされ、ホストマシン上でコンテナが稼働という流れになります。

これら要素に対してNISTがあげているリスク観点は下記の5つになります。下記の通りユーザ責任の箇所が実は多く存在しています。また、AWS責でもユーザ責でもある箇所もあります。

観点 対象 責任範囲
イメージ アプリケーション本体
(ソースコード,CIプロセス,コンテナイメージなど)
ユーザ
レジストリ コンテナイメージを格納するレジストリ
(DockerHub,Quayなどの外部レジストリ,ECRなどプライベートレジストリ)
ECR利用ならAWSとユーザ
コンテナ 稼働中のコンテナおよびそれを動かすランタイム
(cri-o,containerd,dockerなど)
ユーザ
オーケストレータ コンテナ基盤およびコンテナを管理するソフト
(Kubernetes,Openshift,ECSなど)
EKS利用ならAWSとユーザ
ホストOS コンテナが実行されるマシン及びそのOS
(EC2インスタンス,Linux/Windowsなど)
EC2利用ならAWSとユーザ
Fargate利用ならAWS

このガイドラインを基にAWSが提供するサービスや機能と組み合わせてセキュリティの柱に当たるものを次回の記事から考えていきます。

CTCは、AWSのビジネス利活用に向けて、お客様のステージに合わせた幅広い構築・運用支援サービスを提供しています。
経験豊富なエンジニアが、ワンストップかつ柔軟にご支援します。
ぜひ、お気軽にお問い合わせください。

お問い合わせ



【著者プロフィール】

山下 大貴(やました だいき)

伊藤忠テクノソリューションズ株式会社 ITアーキテクト

インフラエンジニアとしてテレコム,Webサービス事業者様向けにプリセールス/導入に従事。
AWS/Azure/GCP Professional,Expertアーキテクト資格保有。近年はDevOps/K8s関連で設計/導入支援に注力。

山下 大貴(やました だいき)

TOP>コラム一覧>Well-Architected コンテナセキュリティの柱を作る試み -①基礎編-

pagetop