こんにちは @jedipunkz 🚀 です。 ECS 構成をもう少しセキュアに保てる構成はないものだろうかと模索しているなかで Sysdig を見つけました。まだ導入できる目処は立っていないのですがある程度ノウハウ蓄積出来てきたのでここで検証内容等を記事にしようかと思っています。 Sysdig は幾つかのサービスが存在するのですが今回検証したのは Sysdig Serverless Security と呼ばれるモノで ECS Fargate 上のコンテナランタイムセキュリティを実践することができるサービスです。 Sysdig とは AWS のサービスにも脅威検知を行うことができるサービスが揃っているのはご存知と思います 対象 目的 技術・サービス AWS リソース 驚異検知 AWS GuardDuty また予防の観点で脆弱性診断が出来るサービスもありあす 対象 目的 技術・サービス AWS リソース セキュリティ診断 AWS Trusted Advisor ECS コンテナ 脆弱性診断 ECR Image Scan EC2 上のソフトウェア 脆弱性診断 AWS Inspector ここで気がつくと思うのですがコンテナ上の驚異検知を行うサービスが AWS には無いと思っています。 (2022/09 時点) Sysdig Serverless Security は ECS Fargate コンテナ上の脅威検知を行うサービスです。ECS Fargate 利用時にコンテナ上の脅威検知を行うサービスは他にも幾つかありますが、Sysdig はシステムコールを利用したコンテナランタイムセキュリティを実践して脅威検知・通知が行えるものになります。自分も詳しくないのですがこれを CWPP (Cloud Workload Protection Platform) と言うらしいです。ワークロードというのはクラウド上の仮想マシン・稼働中のソフトウェアを指して、CWPP はマルウェア保護、脆弱性スキャン、アクセス制御、異常検知の機能を使用してそれぞれのワークロードを保護する、ということらしいです。 ...

こんにちは @jedipunkz 🚀 です。 今回は CNCF にジョインした PipeCD と Datadog を用いて ECS 環境にてプログレッシブデリバリーを実現する方法について調査したので、その内容を記したいと思います。 そもそもプログレッシブデリバリーとは アプリケーションのデリバリー方法はカナリーリリースやブルーグリーンデプロイメント等がよく知られていると思います。プログレッシブデリバリーはその一歩先を行くデリバリー方式で、Prometheus や Datadog 等のメトリクスを用いて SLO (SRE の SLO と言うよりはデプロイのための指標という意味での) を元にカナリーリリースしたアプリケーションが期待した動作をしているかを確認し (プログレッシブデリバリー的にはこのフェーズを ANALYSIS という様です)、その上でカナリーリリースを完了するというフローになります。 構成 Pipecd, Piped 共に Kubernetes (EKS) クラスタ上に起動する構成 この検証ではこちらの構成を選択しました。この構成の特徴は piped は pipecd の API エンドポイントを指し示す pipecd は UI を提供 pipecd は Filestore (S3, GCS, Minio など), Datastore (MySQL, Firestore など) を利用可 (今回は Minio, MySQL を選択) piped は Target Group, ECS タスク定義等の操作を行うため ECS API へのアクセス権限が必要 piped の pipeline 上のステージで ANALYSIS という Datadog 等のメトリクスを解析する機能を有している アプリケーションレポジトリには app.pipecd.yaml を配置しターゲットグループ・タスク定義・ECS サービスを指し示す piped は GitHub レポジトリを参照 となっています。 ...

こんにちは。jedipunkz🚀 です。 引き続き Go を学習しています。前回の記事 ECS コンテナにログインする CLI を Go 言語で作った話 のまとめにも記したのですが Go のコードを書くアイデアとして下記をぼんやり考えていました。 ECR 脆弱性スキャンのパッケージを開発 そのパッケージを利用して Datadog のカスタムメトリクスとして送信 同様にそのパッケージを利用して ECR スキャンの CLI を作成 その紹介を軽くしたいと思います。 開発した ECR 脆弱性スキャンの Go パッケージ 開発したパッケージは https://github.com/jedipunkz/ecrscan になります。 下記のように Ecr 構造体を初期化します。 e := myecr.Ecr{} e.Repositories = [][]string{ {"image-to-scan", "latest"}, } e.Resion = "ap-northeast-1" finding, vulFindings, _ := e.ListFindings() その後 ListFindings() メソッドでスキャンします。結果、finding.FindingSeverityCounts には下記の深刻度毎のイメージに含まれている脆弱性の数が入ります。 INFORMATIONAL LOW MEDIUM HIGH CRITICAL UNDEFINED また、vulFindings には含まれている脆弱性の CVE 名 深刻度レベル (INFORMATIONAL, LOW, MEDIUM, HIGH, CRITICAL, UNDEFINED) CVE URI 説明 が入ります。 ...

こんにちは @jedipunkz 🚀 です。 今回は Go 言語で ECS コンテナにログインする CLI を作った話を書きます。 開発の経緯 自分はまだ Go 言語の初学者で学習のために開発するアイデアを探していた状態でした。そこで自分の勤めている会社で ECS Execute 機能を使ったコンテナログインの機能を開発者に提供していた事を思い出し色々調べていて「もう少し手間が省けないか？」と思い立った、という経緯で開発をはじめました。 awscli を使った ECS Execute 機能によるコンテナログイン 手間が多いと書きましたが実際に awscli を使う場合どの程度の手間があるのか簡単に記します。まず下記のコマンドを実行して $ aws ecs list-tasks --cluster <クラスタ名> --service <サービス名> taskArn が得られるので Arn から task ID を拾って、その task ID を使って $ aws ecs execute --cluster <クラスタ名> \ --task <task ID> \ -- container <コンテナ名> \ --interfactive \ --command "sh" とコマンドを実行することでコンテナにログイン出来ます。が手間が少し多いのと task ID を拾い出す作業も辛いので改善したい…。 操作画面 ということで miniecs という CLI を作ったのですが、 まずは操作している様子を貼り付けます。😷 Fuzzy Finder なインクリメンタルサーチが出来る CLI になっていて、ECS クラスタ名・ECS サービス名・コンテナ名を一部入力するとログインしたい環境が選択出来るツールになっています。 ...

こんにちは。jedipunkz🚀 です。 今回も READYFOR Advent Calendar 2021 の記事として執筆します。 今回のテーマ 前回の記事 では ECS 移行後の構成について検討する内容を記しました。Progressive Delivery を実践する上でもその一歩手前の構成と言っていいカナリーリリース構成について、今回は記していきたいと思います。 デグレしてしまっていたカナリーリリース READYFOR では AWS ECS 移行を行い ECS + CodeDeploy による Blue/Green デプロイメントを導入しました。逆に移行前までに出来ていたカナリーリリースが実施できなくなりました。とは言ってもそれまで開発者がカナリーリリースに対して求めていた主な機能はロールバックだったため、ひとまずは Blue/Green デプロイメントで事足りている状況なのですが、今後大きな機能をリリースする際にはトラヒックを徐々に寄せ影響を把握した上でリリース進めるという作業は必要になってくる可能性があります。 よって、 Progressive Delivery の一歩手前の構成を実践する 大きなリリースのための環境整備 という意味でも、一回カナリーリリース構成について検討しておこうと考えました。 環境構築 今回用意した Terraform コード 検証で作成した AWS 環境をデプロイするための Terraform コードを下記の場所に置いてあります。参考にしてください。 https://github.com/jedipunkz/tf-appmesh-ecs-canary-release (今回検証で作成したコードは業務上作成したものですが、READYFOR の OSS ポリシーに則り著作権譲渡をうけており、自らのGitHubリポジトリで公開しています。) App Mesh ECS NLB Service Discovery Envoy X-Ray といった技術要素で構成されています。 Terraform コードによるデプロイ実施 上記に記した Terraform コードを使った構成のデプロイ手順を記します。 前提として Terraform バージョン 1.0.x 系以上をローカルにインストールする必要があります。 $ # AWS クレデンシャル情報を設定 $ git clone https://github.com/jedipunkz/tf-appmesh-ecs-canary-release $ cd tf-appmesh-ecs-canary-release $ terraform plan $ terraform apply 構成 検証で構築した構成(上記の Terraform コードで構築できる) は下記になります。 ...

こんにちは。jedipunkz です。 今回は READYFOR Advent Calendar 2021 の記事として執筆します。 READYFOR では 2021 年の夏に AWS ECS へプラットフォーム移行をしました。ECS は自分達の要件を全て満たしてくれ運用コストも極小化できて更に周辺の技術も AWS 公式のものが揃っているので、とても満足している状況です。 移行を終えたばかりなので「では次のアーキテクチャは？」という話にはまだなっていないのですが、今は準備期間として余裕を持ってスケジューリングできる状態にして頂いているので、SRE チームとしては色々な技術をリサーチしている段階になります。 今現在は ECS + CodeDeploy を使って Blue/Green デプロイメントを実現しているのですが、よりモダンなデプロイ方式 Progressive Delivery について去年あたりから興味を持っていました。ただ、今までは実際に技術を触るまでには至っていなかったのでこの機会に色々と触ってみたという次第です。 今までも Blue/Green デプロイメント, Canary リリースとデプロイ方式が複数ありましたが、これらを含む継続的デリバリの次のステップと言われているのが Progressive Delivery です。2020年に Hashicorp 社の Mitchell Hashimoto 氏 が来日した際に「今一番気になっているワード」としてあげていましたのが印象的でした。 ECS を使った Canary リリース Progressive Delivery の話をする前に ECS を使った Canary リリースについて少し触れておきます。 (具体的な話についても、どこかのタイミングで記事にできればと思っています) AWS App Mesh と ECS, X-Ray を使って下記のような構成を作りました。この構成中の App Mesh の Virtual Router のルーティング情報を修正する形で Canary リリースのトラヒック操作が行えます。ECS 以前は Canary リリースを実現できていて ECS 導入によってそれがデグレした状態だったので、この構成の検証は一つの成果だったと思っていますし、今回話をする Progressive Delivery のひとつ前のステップとも考えています。 ...

こんにちは @jedipunkz 🚀 です。 最近、職場では ECS/Fargate でサービスを運用しています。そこで ECS Task 上でコマンドを実行する必要に迫られて幾つか調べたのですが、複数の方法があり検証をしてみました。これには 2021/03 にリリースされたばかりの ECS 上のコンテナでコマンドを実行する機能も含まれています。 自分たちは自動化する必要があったので Go 言語 (aws-sdk-go) を中心に検証実施しましたが同時に awscli でも動作検証しましたので、その方法をこの記事に記そうかと思います。 下記の2つの ECS の機能についてそれぞれ Go 言語, awscli で動作検証実施しました。 (1) ECS Execute Command (2021/03 リリース) (2) ECS Run Task 用いるツール類 下記のツールを前提に記事を記します。 aws-sdk-go Terraform awscli 共通で必要な taskRoleArn まず Task Definition に対して executeRoleArn とは別に TaskRoleArn の付与が必要になります。 resource "aws_ecs_task_definition" "sample" { family = "sample" cpu = "256" memory = "512" network_mode = "awsvpc" requires_compatibilities = ["FARGATE"] execution_role_arn = module.ecs_task_execution_role.iam_role_arn task_role_arn = module.ecs_task__role.iam_role_arn container_definitions = data.template_file.container_definition_sample.rendered } taksRoleArn の内容については https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task-iam-roles.html に情報があり、下記が必要になります。 ...

こんにちは。jedipunkz です。 仕事ではこれから会社のサービス環境として AWS ECS の導入を始めていくところなのですが、最近の SRE/インフラ界隈のトレンドを自分たちが追うために自分たち SRE が管理しているボット環境を EKS を使って GitOps 化しようということになり色々と準備を進めています。導入までもう一歩のところまで来たので、構成や技術要素についてここに記したいと思います。 どんなボットが動いているの？ まずボット開発に用いてる言語は Go 言語です。主に aws-sdk-go を使ってボットを開発しています。私達はコミュニケーションツールとして Slack を使っているので Slack ボット化するためには slack-go を使っています。 ただまだボットの数が少なく主に利用されてるのは Ansible を実行するモノです。開発環境へアプリをデプロイするのに Ansible を使っています。もうすぐ ECS 化するので役割はそろそろ終えるのですが… 利点は開発者だけでなく非エンジニアの方が GitHub のブランチ上のアプリの動作をしたい際に Slack を使って簡単にアプリの動作ができるところです。今後は自動化目的でもっと沢山のボットを開発していきたいです。 EKS/Fargate vs EKS/EC2 EKS の利用を検討する際に Fargate タイプと EC2 タイプがあります。2020年の今年頭に評価した際には ALB Ingress Controller と HPA のための Metrics Server が正常に動作しない状態だったので、まだ EC2 タイプを選択すべきなのかな…と考えたのですが AWS 的にも Fargate を推してる気もするし再度評価実施しました。結果ドキュメントもソフトウェアもだいぶ更新されていて ALB Ingress Controller も Metrics Server もあっけなく動作し、今回のボット環境も EKS/Fargte を選択しました。 ...