Amazon Web Services ブログ

Category: Containers

AWS Secrets Controller PoC: AWS Secrets Manager と Kubernetes の統合

  はじめに Kubernetes では、API キーや証明書などのシークレットオブジェクトを使用して、podSpec の外部に機密情報を保存して管理できます。概念的には、これにより、他のタイプの Kubernetes オブジェクトとは異なる方法でシークレットを処理できます。それにもかかわらず、多くの顧客は、最初に導入されたときにカスタマーマネージドキーによる強力な暗号化オプションが含まれていなかったため、シークレット素材の保存用に Kubernetes Secrets を使用することを避けました。これが、この PoC を作成する動機となりました。Kubernetes 動的アドミッションコントローラを使用して、外部サービス (AWS Secrets Manager) からシークレットを使用する方法を示します。 EKS の最近の進歩 最近、EKS は Kubernetes Secrets の KMS エンベロープ暗号化のサポートを追加しました。エンベロープ暗号化では、カスタマーマネージドの AWS KMS キーを使用して、Kubernetes がシークレットの暗号化に使用するデータキーを暗号化できます。これにより、Kubernetes の外部に保存されている別のキーに依存するため、全体的なセキュリティ体制を強化できます。AWS が etcd に保持されているデータを保護するために、既に使用しているフルボリューム暗号化に追加されます。Kubernetes Secrets データ暗号化の詳細については、暗号化データのドキュメントをご覧ください。 エンベロープ暗号化により、Kubernetes Secrets はシークレット素材を保存するための実行可能なオプションになりますが、これにはいくつかの欠点があります。まず、Kubernetes ポッドとシークレットのスコープは名前空間です。ポッドとシークレットが名前空間を共有している場合、ポッドはその名前空間で作成されたすべてのシークレットを読み取ることができます。次に、Kubernetes Secrets は自動的にローテーションされません。シークレットを定期的にローテーションする必要がある場合は、手動でローテーションを行う必要があります。 Kubernetes Secrets の代案 従来からお客様は、詳細な権限とシークレットの自動ローテーションの両方をサポートする Hashicorp の Vault などの外部シークレットプロバイダーを使用して、Kubernetes Secrets の欠点に対処してきました。また、Kubernetes サービスアカウントおよび変更ウェブフックを介して Kubernetes […]

Read More

Java ベースの Kubernetes オペレーターを使用した Amazon EKS での Kubernetes RBAC と IAM の統合

  はじめに Kubernetes ネイティブアプリケーションは、Kubernetes クラスターにデプロイされ、Kubernetes API と kubectl などのクライアント側ツールの両方を使用して管理されるアプリケーションです。Kubernetes オペレーターは、etcd データベースクラスターや Prometheus モニタリング/アラートシステムなど、重要な Kubernetes アプリケーションをデプロイするための抽象概念です。このようなアプリケーションに必要なドメイン固有の知識を持つカスタムリソースとコントローラを使用して Kubernetes 機能を拡張するメカニズムを提供します。 カスタムコントローラを開発するには、Kubernetes コントローラランタイムと対話するために低レベルの API が必要です。GoLang 開発者コミュニティは、豊富なフレームワークと一連の安定した SDK から得た利点を長い間使用してきました。Java は世界で最も人気のあるプログラミング言語の 1 つですが、そのようなライブラリリソースは Java 開発者コミュニティでは利用できませんでした。最近、公式の Kubernetes Java SDK プロジェクトは、カスタムコントローラの開発に役立つコントローラビルダー Java SDK を作成するために、GoLang SDK の主要機能の多くが Java に移植されたと発表しました。 このブログ記事では、Kubernetes Java SDK の新機能を活用して Kubernetes のロールベースのアクセスコントロール (RBAC) と、Amazon Elastic Kubernetes Service (Amazon EKS) を使用してプロビジョニングされた Kubernetes […]

Read More

Okta SSO で Amazon EKS を管理する

 Amazon Elastic Kubernetes Service (Amazon EKS) を使用すれば、Kubernetes を使ってコンテナ化されたアプリケーションを簡単にデプロイ、管理、スケーリングできます。Okta は、開発者がユーザーアカウントとユーザーアカウントデータを作成、編集、安全に保存し、それらを 1 つまたは複数のアプリケーションに接続できるようにする API サービスです。Okta は、スケーラブルで安全な方法で組織の AWS マネジメントコンソールまたは AWS CLI へのアクセスを提供するのに役立ちます。Okta では、Active Directory または LDAP 認証情報を使用して AWS サービスを使用できます。 Okta が提供する ID を使用して Amazon EKS クラスターを認証する方法を示します。Amazon EKS は、IAM を使用して Kubernetes クラスターに認証を提供しますが、認証はネイティブの Kubernetes ロールベースアクセスコントロール (RBAC) に依拠しています。つまり、IAM は有効な IAM エンティティの認証にのみ使用されます。Amazon EKS クラスターの Kubernetes API とやり取りするためのすべての権限は、ネイティブの Kubernetes RBAC システムを通じて管理されます。 EKS […]

Read More

Infosys が AWS Fargate を使用して、Wingspan での技術スキル評価を新しい形に

 この投稿は、Infosys のリードアーキテクトである Arpan Patro 氏と、AWS ソリューションアーキテクトの Satheesh Kumar が共同執筆しています。 Infosys は、次世代デジタルサービスおよびコンサルティングのグローバルリーダーです。同社は世界中に広がる 24 万人を超えるスタッフを抱え、ビジネスコンサルティング、情報技術、アウトソーシングサービスを提供しています。 挑戦: Infosys は 46 か国以上にまたがるクライアントに、さまざまなデジタル変革の取り組みを提供しています。クライアントに適切なサービスを提供できるよう、Infosys のスタッフは新しい技術スキルを習得して、技能を向上させることが重要です。技術スキルを習得しようとしている学習者が天才的な才能を発揮し、そうしたスキルを職場で見せたい、実験したい、クラスや動画で知ったことをやってみたいと思うことは多々あります。こう思ったときこそ学習者の熱意が高まるときで、一方で実践のための適切な環境がないためにつまずくときでもあります。 制限、インフラストラクチャへのアクセスの困難さ、ソフトウェアのインストール、バージョンの不一致は、学習者が対処しなければならない現実であり、スキルアップの経験を積もうとしても望む結果をもたらさない可能性があります。 Infosys は、学習者が学びを達成するには応用の効く実践スキルが必要であると考えています。学習者には独自のプレイグラウンドを準備し、そこではフェイルセーフな環境で実験、強化、分解できる必要があります。失敗に時間を掛けないことが、堅牢性を築く最もよい方法です。 同社は、スタッフ全員がいつでもどこでも好きな環境にアクセスできるソリューションを求めていました。この結果、実践的に学習し評価できる環境を、いつでも、どこでも、どのデバイスでも迅速に提供するという目標を立てるのに役立ったのです。Wingspan Assessments は基本的なプログラミングベースの言語だけでなく、コアテクノロジーとツールを具体化するものでした。 Infosys Wingspan は組織が人材の変革を加速し、やり方を変更するのに役立つ多目的な学習ソリューションです。学習を継続するための環境を作成することで、人材が一段階上のステップに進むのを支援します。 https://www.infosys.com/products-and-platforms/wingspan.html   ソリューション: このユースケースは独特で、一筋縄ではいきませんでしたが、AWS Fargate の Amazon Elastic Container Service (ECS) に着目することになりました。これは、ケーラブルでコスト効率の高いマネージドサーバーレスサービスで、コンテナを実行するためのものです。AWS Fargate を選択した理由は次のとおりです。 AWS Fargate はコンテナを実行するサーバーレスコンピューティングエンジンです。これのおかげで、インフラストラクチャ管理の差別化につながらない手間のかかる作業から、より多くの機能を備えた評価プラットフォームの構築に焦点を移すことができました。 AWS Fargate は「awsvpc」ネットワーキングモードをサポートしています。このモードでは、各タスクが独自の IP アドレスを取得し、タスクレベルでセキュリティグループを関連付ける機能を備えた、きめ細かなセキュリティ制御を実行できます。 コンテナをアドホックな方法で実行するこのワークロードの性質を考えると、AWS Fargate は、このソリューションを大規模に実行するためのコスト効率の高いオプションであることがわかったのです。AWS Fargate […]

Read More

AWS SAM を使用した Kubernetes のサーバーレスアドミッションウェブフックの構築

著者: Simon Woldemichael、アソシエイトソリューションアーキテクト、WWPS ソリューションアーキテクチャ Josh Jiang、アソシエイトクラウド開発者、プロフェッショナルサービス共有配信チーム 学習レベル: 300 Kubernete クラスターでリソースデプロイを制御すると、難しい課題に直面することがあります。たとえば、本番環境に変更をプッシュすると、互換性のないパッケージやサービスをクラッシュさせる脆弱な依存関係をインストールする危険性があります。 Kubernetes のカスタムアドミッションウェブフックを作成すると、規制を厳格に定義し、承認済みリソースをクラスターでのみ起動できます。 次の図は、サンプルのウェブフックのアーキテクチャを示しています。 このブログでは、Kubernetes の開発者とクラスター管理者に向けて、AWS サーバーレスアプリケーションモデル (SAM) を使用してサーバーレスアドミッションウェブフックを作成する方法を解説します。ウェブフックの有用性を示すために、Amazon Elastic Kubernetes Service (EKS) のデプロイを、Amazon Elastic Container Registry (ECR) のイメージに対して検証するようにウェブフックを設定します。 サーバーレスアドミッションウェブフックは、このユースケースに適しています。ですが、Kubernetes リソースの作成、削除、更新に機能を拡張することもできます (Pod など)。最初に、Kubernetes で作成できるウェブフックのタイプについて説明します。次に、構築済みウェブフックをデプロイします。最後に、カスタムウェブフックを作成する方法について説明します。 バックグラウンド Kubernetes クラスターの動的受付制御 Kubernetes がどのように新しいクラスターリソースを内部で調整するかを理解することは、独自のルールを構築するために重要です。Kubernetes ではいくつかのアドミッションコントローラーを使用して、クラスター内のリソースが特定の予想に一致するようにします。これらのアドミッションコントローラーは、有効な作成、更新、削除操作のみを実行できることを保証します。たとえば、存在しないクラスター名前空間に Deployment を作成しようとすると、NamespaceExists アドミッションコントローラーは作成を拒否します。 Kubernetes バージョン 1.9 以降、カスタムプラグインを作成できる 2 つのコードパッケージ (ValidatingAdmissionWebhook と MutatingAdmissionWebhook) が導入されました。これらのプラグインを使用すると、リソースの受付処理に直接統合できます。 ValidatingAdmissionWebhook で、リソースが予想基準に一致するかどうかを検証 できます。たとえば、作成中の Pod には正しいラベルがあり、制限された量の CPU […]

Read More

Amazon EKS コンソールの改善により、クラスターの作成と管理が容易に

先日、AWS は Amazon EKS コンソールにおけるクラスターの作成機能、管理機能、およびサポートドキュメントの使用感を改善したことを発表しました。このブログ記事では、どのような改善が施されたか、またお客様やクラスターの管理者が Amazon EKS コンソールを使用してクラスターを作成する際に、今回の改善がどう役立つかについて詳しく説明します。 1.複数ステップのクラスター作成フロー EKS のコンソールには、複数ステップのクラスター作成フローが追加され、ネットワーキング、ログ記録、タグやシークレットの暗号化といった追加の設定で、クラスターを簡単に作成できるようになりました。今回のアップデートでは、上図や下記のとおり、4 ステップのクラスター作成プロセスが導入されました。 クラスターの設定 ネットワーキングの指定 ログ記録の設定 レビューと作成 2.情報リンクと画面移動のない参照 クラスター作成中に画面を移動しなくてもドキュメントを参照できるよう、入力フィールドに情報リンクが追加されました。リンクをクリックすると、同じページのタブ内に情報が表示されるので、クラスター管理者は情報を参照しやすくなります。クラスター作成フロー中に表示できる新しい情報パネルの一覧を次に示します。 一般的なクラスター設定 (ステップ 1) Kubernetes のバージョン (ステップ 1) クラスターサービスロール (ステップ 1) シークレットの暗号化 (ステップ 1) タグ (ステップ 1) VPC、サブネット、セキュリティグループ (ステップ 2) クラスターエンドポイントアクセス (ステップ 2) コントロールプレーンのログ記録 (ステップ 3) 3.設定の「コンソール内」リフレッシュ クラスター作成の各ステップにおいて、ページ全体をリロードしなくても設定フィールドが動的に更新されるようになりました。また、入力フィールドの横に導入された更新ボタンにより、VPC、サブネット、セキュリティグループ、クラスターサービスロール、KMS キーなど、EKS 外で定義した設定を動的に反映させることができます。この動的更新機能により、コンソールページをリフレッシュすることなしに利用可能なリソースの最新リストをロードできます。 その他のマイナーアップデート クラスター作成後に設定を更新する際に、コンソールから更新タブに移動し、現在のステータスをモニタリングしたり、以前の更新履歴を確認したりできるようになりました。 エンドポイントアクセスを選択するためのトグルボタンがラジオボタンに変更され、クラスターに対して現在どのエンドポイントアクセスオプションが選択されているかが分かりやすくなりました。 複数ステップの設定を反映して、ステップ 4 のクラスターレビューページの編成が変更されました。 クラスター作成レビューページでは、設定情報を失うことなく、各ステップ内で動的に編集できるようになりました。 サブネット/セキュリティグループの選択が、大きなテーブルからコンパクトな複数選択リストになりました。 […]

Read More

Fluentd を使用して Amazon EKS Windows ポッドから Amazon CloudWatch Logs にログをストリーミングする

コンテナはオペレーティングシステム仮想化の方法の 1 つで、リソース隔離処理でアプリケーションとその依存関係を実行できるようにするものです。コンテナを使用することで、アプリケーションのコード、設定、依存関係を使いやすいビルディングブロックに簡単にパッケージ化でき、環境の一貫性、運用効率、開発者の生産性を高め、バージョン管理を行うことができます。 Windows コンテナを使うと、前に述べた利点をすべて享受できるだけでなく、Windows Server 2003、2008、2008 R2 などのサポートされていない運用システムで実行しているレガシーアプリ (現在では、環境全体をセキュリティの脅威にさらし、セキュリティルールのコンプライアンスに準拠していない恐れがあります) を移行することも可能です。 AWS でコンテナを実行する場合、2 つの選択肢があります。1 つ目は、サーバーを管理するかどうかです。コンテナ用のサーバーレスコンピューティングが必要な場合は AWS Fargate を選択し、コンピューティング環境のインストール、設定、管理を制御する必要がある場合は Amazon EC2 を選択します。2 つ目は、Amazon Elastic Container Service (ECS) または Amazon Elastic Kubernetes Service (EKS) のどちらかのコンテナオーケストレーターを選択して使用します。コンテナの詳細については、こちらをご参照ください。 同時に、新しいプラットフォームに移行するには、適切な作業に適切なツールが必要です。このブログ投稿では、ログを一元化する方法として、Windows ポッドで作成した IIS ログを Amazon CloudWatch Logs にストリーミングする方法について解説します。 では、これをどのように実現するかをご説明しましょう。 前提条件および仮定: Amazon EKS クラスター (1.14 以降) が実行中である。ステップバイステップの説明。 Amazon EKS Windows ワーカーノードをリリース起動している。ステップバイステップの説明。 Amazon EKS […]

Read More

AWS で実行する NVIDIA Clara Train アプリケーション開発フレームワークを使った医療画像のモデルトレーニングと AI 支援アノテーションの迅速化

2020 年 5 月、AWS は NVIDIA Clara Train アプリケーションフレームワークを使った医療画像モデルの開発環境を AWS クラウドにデプロイするために使用できる AWS クイックスタートをリリースしました。Philips および Cerner などの多数のヘルスケアおよびライフサイエンス関連のお客様が、機密性の高いヘルスケアワークロードに関して AWS を信頼しておられます。セキュアでスケーラブルなクラウドインフラストラクチャは、データサイエンティスト、アーキテクト、および医療研究者が、医療コミュニティを支援するための機械学習 (ML) のワークフローとパイプラインの構築に集中できるようにします。 FDA に認可された AI は、すでに世界中の病院で医師たちが時宜を得た高品質のケアを提供するために役立っています。商用ソリューションには AWS で本番環境の医療画像ワークロードを確立しているものがあり、これには GE ヘルスケア、Zebra、Arterys、および Heartflow によって開発されたソリューションが含まれます。これらの成功にもかかわらず、ヘルスケアにおける革命はまだ初期の段階にあり、データと ML のパイプラインが臨床医による診断、ワークフローの最適化、医療機器の強化、および臨床品質の向上を補助する機会が今後ますます増えるでしょう。 以下のセクションでは、NVIDIA Clara Train アプリケーションフレームワークを紹介してから、CT スキャンにおける脾臓のセマンティックセグメンテーションに関する実際のユースケースに対応するためのデプロイメントについて説明します。このクイックスタートは、Amazon Elastic Container Service (ECS) と、NVIDIA V100 Tensor Core GPU 搭載の Amazon EC2 p3.2xlarge インスタンスタイプを使って Clara Train SDK をデプロイします。 […]

Read More

AWS Fargate プラットフォームバージョン 1.4 での一時的なストレージにおける、AWS Fargate 管理のキーを使ったサーバー側の暗号化

この記事は Yuling Zhou、Eduardo Lopez Biagi、Paavan Mistry の執筆によります 本日は、AWS Fargate プラットフォームバージョン 1.4 での、一時的なストレージにおけるサーバー側の暗号化を紹介します。この更新版のプラットフォームバージョンでは、AWS Fargate が管理するキーと業界標準の AES-256 暗号化アルゴリズムを使って、一時的なタスクストレージが自動的に暗号化されます。お客様がプラットフォームバージョン 1.4 で新たに起動する Amazon ECS タスクやサービスは、特別な設定を必要とせずにこの機能をご利用になれます。AWS Fargate 上で起動する Amazon EKS ポッドにはプラットフォームバージョン 1.4 が使用されます。したがって本日以降に起動されるポッドでは、一時的なストレージが Fargate 管理のキーにより暗号化されるようになります。 AWS Fargate でサービスを構築しているお客様には、保存中のデータに対する暗号化の需要があります。この場合、アプリケーションやワークロードもしくは環境に対応して、特定の機密やセキュリティおよびコンプライアンス上の要件を満たす必要があります。保存データの暗号化は、ディスク上に保存された機密性のあるデータを、不正アクセスから確実に保護するための法的コンプライアンスにとって非常に重要です。PCI DSS や HIPAA など一部のコンプライアンス規制では、保存されているデータには、そのライフサイクル全体を通じての暗号化が求められます。当社では昨年、AWS Fargate の一時的ストレージに保存したデータに対する暗号化に関し、お客様からのご提案を集める目的で、AWS containers roadmap の #314 版を通じてフィードバックを求めました。 従来、タスクストレージに書き込まれたデータの暗号化において、AWS Fargate のお客様が組織上のセキュリティとコンプライアンス要件を満たすためには、データ暗号化の制御機能を設計し、それをアプリケーションアーキテクチャの中に実装する必要がありました。今回の新機能では、データ保存中の一時的なタスクストレージが Fargate 管理のキーを用い暗号化されるので、お客様は、組織内もしくは法規制上のセキュリティとコンプライアンス要件を満たすことが可能になります。この機能を使うことで、AWS Fargate のタスクやサービスにアタッチされた一時的なストレージに書き込まれるデータは、お客様が一切のアクションを起こす必要もなく、そのストレージ上で常に暗号化され保存されるようになります。これにより、AWS Fargate で実行するタスクを綿密に保護するための、新たなセキュリティ層が追加されます。 AWS Fargate […]

Read More

コンテナまで Transport Layer Security を維持: Amazon ECS および Envoy で Application Load Balancer を使用する

 この記事は、Sri Mallu、Re Alvarez-Parmar、Sahil Thapar が寄稿したものです Application Load Balancer は、高可用、スケーラブルで安全なアプリケーションを構築する際、重要な要素となっています。AWS のお客様は、ALB を利用することで、従来からアプリケーションのコードで使えた機能を実行できます。接続のセキュリティを例にとると、ALB を使用して暗号化と復号化の作業をオフロードできるため、アプリケーションのビジネスロジックに集中できます。 Application Load Balancer を使用すると、暗号化された接続 (SSL オフロードとも呼ばれる) を使用する HTTPS リスナーを作成できます。この機能により、ロードバランサーと、SSL または TLS セッションを開始するクライアント間のトラフィックの暗号化が可能になります。HTTPS リスナーを作成するときは、SSL/TLS サーバー証明書をロードバランサーにデプロイします。ロードバランサーは、このサーバー証明書を使用してフロントエンド接続を終了し、クライアントからのリクエストを復号化してからターゲットに送信します。ALB がリクエストを復号化する必要があるのはなぜでしょうか? ALB がリクエストを復号化する必要があるのは、それが Open Systems Interconnection (OSI) モデルのアプリケーション層で動作していて、リクエストをルーティングするにはリクエストを検査する必要があるためです。リクエストをルーティングするには、HTTP ヘッダー、メソッド、クエリパラメータ、ソース IP CIDR に基づいて ALB を使用できます。ALB を使用してアプリケーションの負荷を分散すると、ALB で SSL/TLS が終了するのはそのためで、通常、ALB とバックエンドアプリケーション間の接続は暗号化されません。ロードバランサーで安全な接続を終了し、バックエンドで HTTP を使用するだけで、お使いのアプリケーションにとっては十分かもしれません。AWS リソース間のネットワークトラフィックは、接続の一部であるインスタンスのみがリッスンできるからです。 ただし、厳しい外部規制に準拠する必要があるアプリケーションを開発している場合は、すべてのネットワーク接続を保護する必要があることがあります。 以下、クライアントとロードバランサーの間、およびロードバランサーから ECS クラスターで実行されているアプリケーションコンテナへの接続を暗号化する方法を示します。この記事では、Fargate の ECS […]

Read More