はてなブックマーク

はじめに 本記事では、CodeCommitで管理する単一リポジトリ(モノレポ)において、 変更されたディレクトリに応じて、実行するCodePipelineを振り分けるCIパイプラインをTerraformで構築する方法について記載しています。 Terraform で構築する全体構成図 構成の概要 Systems Managerの Parameter Storeには、リポジトリ内のディレクトリ名と実行する CodePipeline名がJSON形式で格納されています。 開発者がCodeCommit のリポジトリにコードをプッシュすると EventBridgeがリポジトリの変更イベントを検知してLambda関数をトリガー実行します。 Lambda関数は、Systems Managerのパラメータを読み取って、変更があったディレクトリに応じたCodePipeline を実行します。 変更があったディ

$ terraform version Terraform v1.1.9 $ helm version --short v3.9.0+g7ceeda6 $ aws --version aws-cli/2.7.18 Python/3.10.5 Darwin/21.6.0 source/arm64 prompt/off $ eksctl version 0.100.0 $ kubectl version --short Client Version: v1.24.3 $ ab -V This is ApacheBench, Version 2.3 <$Revision: 1879490 $> $ k9s version Version: 0.26.3 Commit: 0893f13b3ca6b563dd0c38fdebaefdb8be594825 Date: n/a # VPC は省略 mod

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

はじめに コンテナセキュリティのガイドライン NIST SP800-190(アプリケーションコンテナセキュリティガイド) では、イメージのリスクの1つとして 「イメージの設定の不備」 について言及されています。 さらに、NIST SP800-190 では、このリスクへの対策として、 「セキュアな設定のベストプラクティスへの準拠を検証および実施するためのツールとプロセスを採用すること」 を推奨しています。 本記事では、この 「イメージの設定の不備」 へのリスク対策ツールとして、Dockle とgit-secrets を採用し、このツール群を組み込んだCI パイプライン(ビルドのプロセス)をTerraform でAWS 環境に構築する方法を記載しています。 コンテナイメージのセキュリティ対策の一例として参考になれば幸いです。 Terraform で構築する全体構成図 構成の概要 Dockerf

はじめに 本記事では、Trivy によるコンテナイメージの脆弱性スキャンとSecurity Hub を統合したCI(Continuous Integration)環境を構築するTerraform のコードをサンプルとして共有しています。コンテナイメージのセキュリティ対策の一例として参考になればと思います。 また、補足として、CodeBuild のビルド内のTrivy に関する処理について、簡単に説明をしています。 Terraform で構築する全体構成図 構成の概要 アーキテクチャは上記のAWS Security Blog を元にしています。 Dockerfile を含むコードをCodeCommit にプッシュするとCodePipeline が実行され、CodeBuild でビルドしたコンテナイメージを、Trivy で脆弱性スキャンをしています。 その結果、深刻度が CRITICAL な脆

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

はじめに 本記事では、Terraform で ECS の Fargate の環境とBlue/Green デプロイのパイプライン (CodeCommit + CodeBuild + CodeDeploy +CodePipeline)をお試しで構築する手順を記載しています。 Terraform で構築する全体構成図 Terraform で構築するAWSリソースのBlackBeltの資料 VPC ALB ECS CodeCommit CodeBuild CodeDeploy CodePipeline CloudWatchEvents IAM Terraform のコードと構成 $ tree aws-tf-fargate-blue-green-deploy aws-tf-fargate-blue-green-deploy ├── modules │ ├── ecs │ │ ├── al

はじめに 本記事では、ECS Exec の機能を使って、稼働中の Fargate のコンテナにアクセスする時の簡易な手順について、記載しています。 アクセスする Fargate のコンテナ周りの環境は、下図になります。 ECS Execは、SSM エージェントのバイナリを、下図のようにコンテナにバインドマウントして、Systems Manager (SSM) の Session Manager 経由で、アクセスできるようにしているようです。 引用:Github での Proposal 前提条件 Fargate のコンテナサイド ECS サービスを実行するプラットフォームのバージョンが1.4.0 以降であること。 Fargate のコンテナが Systems Manager (SSM) のエンドポイントに接続できること。 アクセスするクライアントサイド ECS Exec コマンドを実行するた

AWSのデータ分析サービスの全体像を把握する 各分野の各サービスの機能を、どのように学習していけば良いか把握するために、もう一度、データ分析サービスの全体像を把握します。 下記の資料を確認して、一般的なデータ蓄積・分析環境の論理的な構成を理解し、その構成の中で発生する課題をAWSの分析サービス使ってどのように解決するのかを理解して、AWSのデータ分析サービスの全体を把握します。 参考: [AWS のデータ分析入門] (https://d0.awsstatic.com/events/jp/2017/summit/slide/D4T3-2.pdf) ※(注記)上記資料より 抜粋 サービス単体の機能を理解する AWSのデータ分析サービスの全体像が確認できたら、上記の表にある各分野ごとのサービスのBlackbelt を一通り読んでサービス単体の機能を理解します。 (初読の段階では、完全に理解しようとする必

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

AWSTemplateFormatVersion: "2010年09月09日" Description: VPC and Subnet Create Metadata: "AWS::CloudFormation::Interface": ParameterGroups: - Label: default: "Project Name Prefix" Parameters: - PJPrefix - Label: default: "Network Configuration" Parameters: - VPCCIDR - PublicSubnetACIDR - PublicSubnetCCIDR - PrivateSubnetACIDR - PrivateSubnetCCIDR ParameterLabels: VPCCIDR: default: "VPC CIDR" PublicSubn