Amazon Web Services ブログ

Category: Amazon Elastic Kubernetes Service

Amazon ECRのネイティブなコンテナイメージスキャン機能について

本投稿は Richard Nguyen と Michael Hausenblas による寄稿を翻訳したものです。 コンテナセキュリティは、開発者、セキュリティ運用エンジニア、およびインフラ管理者を含む、さまざまなアクティビティとツールで構成されます。クラウドネイティブサプライチェーンの重要な要素の 1 つは、コンテナイメージをスキャンして脆弱性を検出し、そこから行動に移せる洞察を得ることです。 私たちはコンテナロードマップのIssue 17で、AWSネイティブソリューションを提供することがいかにお客様にとって重要であるかを学び、そして、ECRイメージスキャン機能を一般公開いたしました。この投稿では、ECR ネイティブのソリューションについて説明し、ユースケースの一つである「定期スキャン」の実装戦略を説明します。 Scanning 101 最初にコンテナスキャンに関する用語を解説し、前提知識を合わせましょう。 コンテナスキャンに精通している場合は、このセクションをスキップいただいても大丈夫です。 概念的には、コンテナセキュリティの一部としてのスキャンは次のようになります。 コンテナ化されたアプリケーションを見てみると、開発者(developer)がContinuous Integration(CI)パイプラインでコンテナイメージをbuildし、これらのアーティファクトをECRにプッシュしています。一方、セキュリティ運用エンジニア(secops)は、1つもしくは複数のECRリポジトリと、ECSやEKSなどのコンテナオーケストレーターを管理しています。この文脈でいうと、コンテナセキュリティは共同の責任であるということに着目することが重要で、developerと secops の役割は、クラウドネイティブのサプライチェーン全体のセキュリティに対処するために連携しています。たとえば、developerは、コンテナのUSER を定義し、イメージ内の不要なビルドツールを削除して攻撃対象領域を最小限に抑えるといった、セキュアなコンテナイメージをbuildするための推奨プラクティスに従います。同様に、secops も、runtimeポリシーを検証して適用するといったことを行ないます。 さらに、2種類のスキャンに分類することができます。 Static scanning (静的スキャン) :デプロイ前のフェーズで実行されるため、developers (もしくは secops) はコンテナが実行される前に脆弱性に気づくことができます。ECR イメージスキャン機能は、このカテゴリに分類され、コンテナイメージ内の OS パッケージをスキャンして、既知のセキュリティ上の脅威公開リストである共通脆弱性識別子 (CVE) を検出します。ECR イメージスキャン機能を利用すれば、独自のスキャンインフラを設定したり、サードパーティのスキャンライセンスを購入したりする必要はありません。 Dynamic scanning (動的スキャン):ランタイム環境で実行されるスキャンのことです。テスト環境、QA 環境、または本番環境で、すでに実行されているコンテナの脆弱性を特定することが可能であり、ビルド時点でインストール済みのソフトウェアに脆弱性が含まれていることが後日発覚した際や、ゼロデイの脆弱性なども検出可能です。動的(またはランタイム)コンテナセキュリティについては、CNCF Falcoなどのオープンソースソリューションから、Aqua Security、Trend Micro、Twistlock など、AWS コンテナコンピテンシーパートナーが提供するサービスまで、サードパーティ製のさまざまなオプションが利用可能です。 みなさまからお寄せいただいたフィードバックとさまざまな選択肢の評価結果に基づき、我々は人気のあるオープンソースプロジェクトであるCoreOS ClairをECRイメージスキャン機能で利用して脆弱性の静的解析を実行することに決定しました。イメージスキャン機能を備えるように ECR API、AWS CLI、SDK の拡張を行い、CI パイプラインやコマンドラインで使用しやすい形で、スケーラブルで信頼性の高いマネージドサービスを実装しました。 具体的な現実世界のユースケースから始めましょう。ECRでのコンテナイメージの定期スキャンです。 […]

Read More

Amazon EKS Windows Container が一般利用可能になりました

今年 3 月に、当社は Amazon Elastic Kubernetes Service で Windows Container サポートのプレビューを発表し、カスタマーをベータテストにお招きし、フィードバックを提供していただきました。そのフィードバックに基づいて数か月間改修を重ね、Windows Container が一般利用可能になりました。 多くの開発チームは Windows Server で実行されるように設計されたアプリケーションを構築し、継続的にサポートしています。また、この発表により、 Linux アプリケーションと共に Kubernetes で展開が可能となりました。この機能は、システムロギング、パフォーマンス監視、コードデプロイパイプラインでより一貫性を実現します。 Amazon Elastic Kubernetes Service は、Kubernetes の構築、保護、運用、および維持のプロセスを簡素化し、組織が Kubernetes の代わりに、アプリケーションの構築に焦点をあてることができるようにします。AWS は、Kubernetes で Windows Container を一般的に利用可能にした最初のクラウド プロバイダーであることに誇りを思っています。そして、Windows と Linux ワークロードの両方で、Kubernetes のビジネス上の利点をお客様に解放していくことを楽しみにしています。 この機能の動作の方法を示すためには、Amazon Elastic Kubernetes サービスクラスタが必要になります。新しいものを作成しますが、これは Kubernetes バージョン 1.14 以上を使用するクラスタで機能します。クラスタが構成されたら、いくつかの新しい Windows ノードを追加し、Windows アプリケーションをデプロイします。最後に、アプリケーションが期待通りに動作することをテストします。 クラスタのセットアップを行う最も簡単な方法は、EKS の正式な CLI ツールである eksctl […]

Read More

Amazon EKS クラスターエンドポイントへのプライベート接続とワーカノードVPC外からのDNS解決方法

本投稿は AWS のシニアコンテナスペシャリストソリューションアーキテクトである Jeremy Cowan による寄稿です。 Amazon EKS クラスターを作成した時点では、標準ではKubernetes クラスターのエンドポイントはパブリックな設定になっています。エンドポイントにはインターネット経由でアクセスし、Identity and Access Management (IAM) とKubernetes role-based access control (RBCA) のポリシーによるアクセス制御を行います。 ゆくゆくはあなたも Kubernetes クラスターのプライベートエンドポイントを設定する必要が出てくるかもしれません。Kubernetes クラスターのエンドポイントをパブリックからプラベートに変更すると、インターネットをはじめとしたパブリックな経路からのアクセスは完全に無効になります。 実際に、プライベートなアクセスのみを許可するように設定されたクラスタは、以下のネットワークからのみアクセスできます。 ワーカーノードが存在する VPC その VPC とピアリングしているネットワーク AWS Direct Connect (DX) または Virtual Private Network (VPN) を介して AWS に接続されているネットワーク ただし、Kubernetes クラスターエンドポイントは、以下の理由からワーカーノードが存在する VPC からしか名前解決することができません。 エンドポイント用に作成された Amazon Route 53 プライベートホストゾーンは、ワーカーノード用 VPC にのみ関連付けられています。 プライベートホストゾーンは AWSが管理しているアカウントとは分けて作成されており、変更できません。 詳細については、プライベートホストゾーンの使用を参照してください。 […]

Read More

Kubernetes サービスアカウントに対するきめ細やかな IAM ロール割り当ての紹介

本投稿は Micah Hausler と Michael Hausenblas による記事を翻訳したものです AWS ではお客様のニーズに最優先にフォーカスしています。Amazon EKS におけるアクセス権制御に関して、みなさまは「パブリックコンテナロードマップ」の Issue #23 にて EKS でのきめ細かい IAM ロールの利用方法 を求められていました。このニーズに応えるため、コミュニティでは kube2iam、kiam や Zalando’s IAM controller といったいくつかのオープンソースソリューションが登場しました。これらのソリューションは素晴らしいプロダクトであるだけでなく、それぞれのアプローチの要件及び制約は何なのかについて多くの方の理解を促すことを可能にしました。 そして今、柔軟かつ簡単に利用可能なソリューションがやってきました。私たちの重要なゴールとして、粒度の高いロールを Node レベルではなくPod レベルでの提供がありました。私たちが今回考え出したソリューションもオープンソースとして公開されているため、eksctl での Amazon EKS クラスター作成時にも利用できますし、DIY アプローチでの Kubernetes クラスターとしてポピュラーな kops によって作成されたようなクラスタにおいてもご利用いただくことが可能です。 アクセスコントロール: IAM と RBAC Kubernetes on AWS では、補完しあう2つのアクセスコントロール手法が動作します。AWS Identity and Access Management (IAM) は AWS サービスへのアクセス許可、例えばあるアプリケーションが S3 […]

Read More

Fluent Bit による集中コンテナロギング

本投稿は Wesley Pettit と Michael Hausenblas による寄稿を翻訳したものです AWS はビルダーのために作られています。ビルダーは常に最適化の方法を模索し、それはアプリケーションのロギングにも当てはまります。全てのログの重要性が同等ということはありません。あるログはリアルタイムの分析を必要とし、他のログは必要となった時に分析が行えるよう単に長期間保管しておくことを必要としたります。それ故に AWS とパートナーが提供する様々なストレージや分析のツールに容易にログをルーティングできることが重要です。 そこで私たちは Fluent Bit をサポートし、コンテナ化されたアプリケーションから AWS やパートナーのログ保存ソリューション、ログ分析ソリューションへのログストリーム向けに、容易に利用可能な拡張ポイントを作成できるようにします。新しくリリースしたAWSコンテナイメージ向けの Fluent Bit プラグインを用いて、ログを Amazon CloudWatch と Amazon Kinesis Data Firehose の送信先 (Amazon S3、Amazon Elasticsearch Service、Amazon Redshift を含みます)へルーティングすることが可能です。 本投稿では、Fluent Bit プラグインのECS、EKS 両クラスタでの動作をご紹介いたします。ツール自体に慣れていない場合は、こちらの記事(basics of Fluentd and the Kinesis Firehose)にあるチュートリアルを確認いただくと参考になるかもしれません。よろしければ AWS containers roadmap の関連するイシュー #10 と #66 もご参照ください。

Read More

Amazon EKS バージョンライフライクルの更新

本投稿は Nathan Taber と Michael Hausenblas による寄稿を翻訳したものです re:Invent 2017で、私たちは Amazon Elastic Container Service for Kubernetes(Amazon EKS) を紹介しました。当時発表した次の tenets(信条) は、現在に至るまで引き続き確かなものであると考えています。

Read More

Docker on AWS: AWSのコンテナ関連サービスの選定例の紹介

本記事ではこれからAWS上でDockerコンテナを活用される方向けに、AWSのコンテナ関連サービスのどれを選択すると良いかの一例を紹介します。前提としては、example.com社の技術者Aさんが、自社のWebサービスをAWS上で構築するにあたって構成を決めるために、AWSのソリューションアーキテクト(SA)に相談するという流れの記事になります。AWSのどのサービスを使うかのご参考に是非ご覧ください。※こちらの選定はあくまで一例です。要件によっては選択すべきAWSのサービスが異なる点、予めご了承ください。

Read More

Amazon EKS が 東京リージョンに対応しました。

みなさん、こんにちは。アマゾン ウェブ サービス ジャパン、プロダクトマーケティング エバンジェリストの亀田です。 Kubernetes のマネージドサービスである、Amazon Elastic Container Service for Kubernetes (Amazon EKS)  が東京リージョンに対応しましたのでお知らせいたします。 Amazon EKS では Kubernetes 管理インフラストラクチャ(コントロールプレーン)が複数の AWS アベイラビリティーゾーンで運用されるため、単一障害点をデータセンター単位で排除することができ、高い可用性を実現します。アップストリームの Kubernetes が実行され、Kubernetes への準拠が認証されているため、Amazon EKS で管理されるアプリケーションには、あらゆる標準的な Kubernetes 環境で管理されるアプリケーションとの完全な互換性があります。 また、Amazon EKS は AWS Cloud Mapと統合されています。AWS Cloud Map は動的に変化するインフラストラクチャーが抱える課題である、サービスの自動検出機能を提供します。アプリケーションリソースのカスタム名を定義し、これらの動的に変化するリソースの更新された場所を管理できます。これにより、Webサービスが常にリソースの最新の場所を検出するため、アプリケーションの可用性が向上します。 また、Application Load Balancer とも  AWS ALB Ingress controller を介して連携することが可能です。Application Load Balancer は先日 Lambda対応も発表され、アプリケーション内部において、それぞれの目的に合致したパスベースルーティングを可能とします。 料金はこちらにまとまっています。 – プロダクトマーケティング エバンジェリスト 亀田 […]

Read More

AWS Cloud Map:アプリケーションのカスタムマップの簡単な作成と維持

アプリケーションをマイクロサービス(多数の別れたサービスがそれぞれ1つのジョブを実行する)として構成するお客様が増えています。マイクロサービスによりお客様は、多くの場合で反復的かつ、より素早いデプロイを可能になります。これらのマイクロサービスをベースとしたモダンなアプリケーションの多くは、様々な種類のクラウドリソースを利用して構成され、動的に変更されるインフラストラクチャ上にデプロイされます。これまでは、アプリケーションリソースの場所を管理するために設定ファイルを利用する必要がありました。しかし、マイクロサービスをベースとしたアプリケーションにおける依存関係は簡単に管理するには、複雑すぎる様になります。加えて、多数のアプリケーションは動的にスケールし、トラフィックにあわせて変更されるコンテナを利用して構成されていています。その様な構成はアプリケーションの応答性を向上させますが、新しい問題をもたらします。- 現在、アプリケーションのコンポーネントはその動作時にアップストリームサービスを検出し、接続する必要があります。この動的に変更されるインフラストラクチャーおよびマイクロサービスにおける接続性に関する問題は、共通してサービスディスカバリーによって解決されます。

Read More