AWS関連のことを調べてみた

【AWS】LDAP認証とIAMとの間でIDフェデレーションを行うには？

# はじめに
本記事はAWS SAA（ソリューションアーキテクト）の学習過程で自身で調べまとめた内容を備忘録として投稿したものです。

今回は、「LDAP認証とIAMとの間でIDフェデレーションを行う方法」というテーマに焦点を当て、LDAPの基礎から始め、IAMを介したIDフェデレーションの基本概念について説明しています。

LDAP認証についてはセキュリティなどの実践でもよく使われるもののため、内容理解の一助になれば幸いです。

# TL;DR
LDAP認証とIAMの間でIDフェデレーションを実現するには、SAML2.0をサポートし、IdP（Identity Provider）として機能するソフトウェアを使用します。

# LDAPとは?
LDAPとはディレクトリサービスへアクセスするためのプロトコルです。
そのためまずは、ディレクトリサービスについて説明していきたいと思います。

### ディレクトリサービスとは？
ディレクトリ（directory）は「登録簿」や「住所録」といった意味です。
ディレクトリサービスは、管理したい情報をまとめた登録簿（ディレクトリ）を作り、それに対する

AWS_Lambdaを用いた集計_前編

## 【はじめに】
本記事は、AWS LamdaおよびQuickSightを用いた、Qiita投稿記事投稿状況の可視化例をご紹介します。
記事内容に関しては前編と後編に分けてご紹介予定です。
※投稿状況の集計対象となるQiita投稿者アカウントのトークンを知っていることが前提となります。
※投稿状況の集計は、Qiitaが公開しているAPIを用います。

## 【実装内容】
今回の記事においては
・Lambda
・S3
・EventBridge
・QuickSight
・Glue
・Athena
上記AWSサービスを用いる。

最終的な実装イメージ図は以下の通り、

## 【前編での実装の流れ】
①S3バケットの作成
②Lambda関数の作成
③ETL確認作業
④EventBridgeの設定
前編の実装イメージ図は以下の通り、
![image

要MFA認証AWSアカウントからスイッチロールして手動実行・actions自動実行出来るようになるまで

AWSアカウントをセキュリティのためMFA認証設定すると開発が苦しくなると思うのは私だけか。

MFA設定したアカウントをスイッチロールさせるのを試すにはまずsts asumeroleが通るか試験したい。

“`
aws sts assume-role –role-arn “arn:aws:iam::[アカウントID]:role/[ロール名]” –role-session-name AWSCLI-Session –serial-number arn:aws:iam::[あなたのアカウントID]:mfa/[あなたのデバイス名] –token-code [MFAコード]
“`

上のコマンドで現時点のAWSACCESSKEY、SECRET、SESSIONをJSON形式で受け取れる。
これだとスイッチしたロールの権限が使えるか解らないので以下のコマンドを用意。

“`
#
STS=$(aws sts assume-role –role-arn “arn:aws:iam::[アカウントID]:role/[ロール名]” –role-session-name AWSCLI-S

WARNING: UNPROTECTED PRIVATE KEY FILE! のエラー対処方法

# 概要
`capistrano`でデプロイを行う際に、下記のエラーが発生したので、その対処方法について記載します。

# エラー文
– `capistrano`のエラー内容
“`sh
bundle exec cap デプロイ先の環境を指定 deploy

# 入力例
# Rails環境のconfig/deploy内にあるファイル名を記載する
bundle exec cap test deploy

#　　出力例
Permission denied (publickey).関連のエラーが表示される
“`
– `ssh-add`のエラー内容
“`sh
# 入力コマンド
ssh-add ＊＊＊＊＊＊＊＊＊＊＊＊＊＊.pem

# 出力結果
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Amazon DataZone に IAM Identity Center で SSO ログインを設定してみる

先日 GA となった Amazon DataZone ですが、本番運用していく上で、IAM Identity Center でユーザ管理してデータポータルにログインさせるのが推奨のようだったので、ログイン設定をやってみました。

# Amazon DataZoneとは

Amazon DataZoneは、AWS、オンプレミス、サードパーティのソースに保存されたデータをカタログ化、検索、共有、管理するためのデータ管理サービスです。

Amazon DataZoneを使用して、組織間のデータアクセスを管理できます。

データのパブリッシュとサブスクライブのワークフローを提供しているので、これにより、データプロデューサーはアセットを、ドメイン内にデータカタログとして公開できます。
そして、データコンシューマーは、サブスクライプフローを通したアクセス制御メカニズムによって、カタログにあるデータにアクセスできるようになります。
Amazon DataZone では、さまざまなデータへのアクセス制御を一元化できるため、誰がどのデータをどのような目的で使用しているかを容易に確認することができます。

LINE友だちとのコミュニケーションツールを！非エンジニアが編集可能なアンケートアプリをNuxtとmicroCMSで開発した話

# はじめに
この記事は[エムスリーキャリア Advent Calendar 2023](https://qiita.com/advent-calendar/2023/m3c)の15日目の記事です。

弊社では、医師や薬剤師のための人材紹介事業を展開しており、その一環としてLINE公式アカウントを活用しています。

求職者の転職意欲や希望条件を正確に把握することで、よりパーソナライズされたサービスを提供することができます。そこでLINE上でアンケートフォームを配信することにしました。
しかしこのアンケート、時期や転職市場の状況によって設問内容を変える必要があるため、エンジニアでなくても容易に編集可能なシステムが求められました。

この問題を解決するために**NuxtとmicroCMSを用いたJamstackなアンケートフォーム**の開発に取り組みました。

![adventcalendar2023-image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2986436/9175d294-8d93-2a

AWS DocumentDBのバージョンアップ

## はじめに
エアークローゼット　アドベントカレンダー15日目の記事です。

https://qiita.com/advent-calendar/2023/air-closet

## DocumentDBのバージョンアップ (V3.6 -> V5.0)
AWSの公式ではDocumentDBのバージョンアップは[AWS DMS](https://docs.aws.amazon.com/documentdb/latest/developerguide/docdb-migration.versions.html)を使用する方法を掲載しています。
しかし、今回は以下の理由のため、mongoDBのdumpとrestoreを用いた方法でバージョンアップを行いましたので、参考になれば幸いです。

#### mongodumpを使用した理由
– 本番環境を運用したままの移行のため、障害を発生させたくない
– 移行前後のデータ整合性を保つため

### mongodump
以下のコマンドでリストア用のbsonファイルを生成します。
“`
mongodump –host –port

cdk-serverless-clamscanを使って既存S3バケットへウイルススキャンを設定してみた

この記事は デジタルキューブ ＆ ヘプタゴン Advent Calendar 2023 の 12月15日分の記事です。

https://qiita.com/advent-calendar/2023/digitalcube-heptagon

S3バケットへアップロードしたファイルへのウイルススキャンの方法として、[AWS Developer Tools Blog](https://aws.amazon.com/jp/blogs/developer/virus-scan-s3-buckets-with-a-serverless-clamav-based-cdk-construct/)で[cdk-serverless-clamscan](https://github.com/awslabs/cdk-serverless-clamscan)が紹介されています。

ブログではCDKで新規にS3バケットを作り、作成S3バケットへのウイルススキャン設定方法が紹介されていますが、本記事では既存バケットに対してcdk-serverless-clamscanを動かすまでについてを紹介します。

# は

Amplify と React で FaceLiveness 顔認証なりすまし検知デモアプリを開発・精度検証

# なりすまし検知とは

### 顔認証システム
例えばAWSのRekognitionを使えば画像認識で人のかを分析することができ、さらに顔コレクションからの顔検索を使うと顔認証システムを構築することができる。
顔認証では、これまで個人を識別するための何かしらの物体（カードとか紙の証明書とか）を持たずして人を識別することができるというシンプルかつ画期的な技術であり、駅の改札やチケット販売などに徐々に導入されつつある。

しかし顔認証にも考慮しないといけない重大な問題がある。
それは画像や動画などを使った「なりすまし」の可能性である。
現在公の場で導入されている顔認証システムには基本的にこの問題は考慮されている。
例えば3D検知ができる専用デバイスを使って実際にそこに人がいるかを確認したり、使用される場所が限られているのであれば運用でカバーしたりなどである。
ただこれだと専用デバイスや運用にコストがかかり、セキュアな顔認証の導入はハードルが高くなる。

### FaceLiveness（フェイスライブネス）

そこで！！
AWSが2023年の４月ころに発表したサービス「Face Live

AWSCLIv1でクロスアカウントアクセスができなかった時の話

# 初めに
AWSでクロスアカウントアクセス設定をしていて詰まった話になります。
CLIv1を使用している方には参考になるかと思います。

# 前提
アカウントA
* クロスアカウント元
* EC2からアカウントBのS3へアクセスしたい
* awscliのバージョンは1.18.58
* アカウントBへのassume-role権限を持つポリシーを持ったIAMロールがEC2へアタッチされている
* credentialsとconfigの設定は以下

“`:credentials
[profile名]
role_arn = “[クロスアカウント先のarn]”
credential_source=Ec2InstanceMetadata
“`
“`:config
[default]
region = ap-northeast-1
“`

アカウントB
* クロスアカウント先
* アカウントAの信頼性ポリシーとS3アクセスを許可したポリシーを持つIAMロールがある

# 何が起こったか
アカウントAからアカウントBへS3のクロスアカウントアクセス設定をして、テストをしている際に

【AWS Lambda関数作成】Python（local環境）の開発

## はじめに
Python（local環境）の開発に関しての備忘録です。
初心者です😅
間違えてる部分が多々あると思います。
もし見つけた場合、ツッコミいただけると助かります🙇

## 🦁**結論**🦁
まずは全体図を作成していくこと

:::note info
押さえておくべき点
* APIGateway は最大30秒でタイムアウトしてしまうため対策が必要。「Lambda発火API」と「Lambda状態取得API」のAPIが必要になる。（このサイトに全てが書かれてる）
* 「Lambda発火API」は30秒タイムアウトを回避するためにリクエストする
* 「Lambda状態取得API」に実際の処理をリクエストする
* リクエスト、レスポンスは基本json形式
* インターバルの設定により、実際の処理経過を確認してる。
* インターバルにて’status’を確認してる（RUNNINGが読み込み中、SUCCEEDEDが成功）
* ArnはAWSの各機能のアドレス
* Local環境に必要なのは「各APIのロールにあるURL」
:::
***

::

TerraformでAWSサービスの情報をコード化する方法

# できること

– AWSサービスの情報をコード化（文書ファイル）にすることができる
– terraformerでコード化できないものに対応できる
– Lambda、S3が該当する

# 前提条件

– VSCodeが使えること
– AWS CLIが使えること
– Windows端末であること

# Terraformのインストール方法

1. 下記URL内から「Windows」を押下し、「AMD64」の方をダウンロードする。
– https://developer.hashicorp.com/terraform/downloads
2. ダウンロードしたzipファイルを解凍する。その中の「terraform」アプリを、コード化したファイルを置きたいディレクトリにコピーする。
3. コード化したファイルを置くディレクトリで、「main.tf」ファイルを用意する。ファイルの中身は以下の入力をする。awsに対応するversionは下記URLから抽出する。
– https://registry.terraform.io/providers/hashicorp/aws

Cognito idTokenをAPIGW＆Lambdaで受け取ってデコードする

Cognito idTokenをAPI GW＆Lambdaで受け取ってデコードする手順についてのメモ書きです。

# やりたいこと
1. Cognitoでログインし、idToken(jwt)を払い出す。
1. 手順１のidTokenを利用し、APIGWで作成された認証必要なAPIを呼び出す。
1. Cognito Authorizerでユーザー認証を行い、バックエンドのLambdaを起動する。
1. Lambdaで手順１のidTokenを受け取り、デコードする（emailなどのユーザー情報を取得する）。


# Cognito Userpool
– Userpoolの作成手順は割愛します。
– idTokenの払い出しについて、SDKなどを使うことも可能ですが、今回はホストされたUIを使います。（コールバックURLはいったんlocalhostと

lambdaからRDS(PostgreSQL)に接続

# LambdaからRDSへの接続設定が簡単になったのでやってみる

## 前提
言語（バージョン）：Python3.8
RDS：PostgreSQL
※RDSは作成済みとする
ライブラリ：psycopg2

## 全体の流れ
・ Lambda関数の作成
・ コードの作成
・ 環境変数の設定
・ レイヤーの追加
・ RDS接続設定

## 関数作成
・　一から作成を選択
・　任意の関数名を入力
・　ランタイムはpython3.8を選択
※理由は後述
・ アーキテクチャはx86_64を選択

関数の作成を押下

## コードを作成しDeploy

“`
import psycopg2
import os

# 環境変数から接続情報を取得
db_endpoint = os.environ[‘DB_ENDPOINT’]
db_username = os.environ[‘DB_USERNAME’]
db_password = os.environ[‘DB_PASSWORD’]
db_name = os.environ[‘DB_NAME’]

def lambda_handler(ev

AWS Configを使って本気でAWSアカウントを守る

# はじめに
この記事はDevOps on AWS大全の一部です。
DevOps on AWS大全の一覧は[こちら](https://qiita.com/tech4anyone/items/b06f88035d27c6ef13b2)。

この記事ではAWS Configに関連する内容を超詳細にまとめています。

具体的には以下流れで説明します。

– AWS Configとは
– AWS Configの仕組み
– AWS Configの活用
– AWS Configのベストプラクティス

AWSの区分でいう「Level 200：トピックの入門知識を持っていることを前提に、ベストプラクティス、サービス機能を解説するレベル」の内容です。

# この記事を読んでほしい人
– AWS Configがどういうサービスか説明できるようになりたい人
– AWS Configを採用するときのベストプラクティスを説明できるようになりたい人
– AWS Certified DevOps Engineer Professionalを目指している人

# AWS Configとは
AWS Configは、AW

会社のデータ分析環境をAWSで整えた話

この記事は[Wano Group Advent Calendar 2023](https://qiita.com/advent-calendar/2023/wano-group)の15日目の記事となります。

## 経緯

私は2023年2月に[TuneCore Japan](https://www.tunecore.co.jp/features)1人目のData Analyticsチームメンバーとして株式会社WANOに入社しました。

当時は、開発チームがMySQLのテーブルデータをS3へ格納したものを見たいメンバーがTableauで見るという状態で、適切な分析の為のテーブル環境が整っていませんでした。

そこで、みんながデータ活用できるような環境をAWSで作っています。
現時点でまだ足らない箇所もありますが、現時点の内容を紹介したいと思います。

### 構成図

#### 旧

![Tableau利用環境(旧).drawio (4).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/635079/

【AWS】S3

# S3(Amazon Simple Strage Service)とは
オブジェクトストレージを提供するサービス。耐障害性・可用性・コスト面に優れる。
バケット内にキーとオブジェクトのペアがあり，それぞれにメタデータが付随しているイメージ。
新しいオブジェクトの書き込みや既存のオブジェクトの上書きリクエスト成功後，読み込みリクエストはオブジェクトの最新版を受け取る(**強力な整合性**)

:::note info
**バケット**
オブジェクトを保存する場所。バケット名はAWSアカウントの中で一意である必要がある。**プレフィックス**と呼ばれるS3上のディレクトリを追加できる。また1アカウントで最大100個まで作成可能で，増加リクエストができる。
:::

:::note info
**キー**
オブジェクトに割り当てる名前(ファイル名)。キーはバケット内で一意である必要がある。
:::

:::note info
**メタデータ**
アップロードしたオブジェクトの属性を記載したデータ。アップロード時のみメタデータの設定ができる。
:::

:::note info
**オブジェ

AWS ECS Fargate で keycloak をクラスタ構成で動かしてみる

Keycloak が ver17 より WildFly から Quarkus へ移行しているが、
Quarkus ベースのバージョンでクラスタ構成を検証している情報が少ないため、
今回 Keycloak を AWS のコンテナ環境でクラスタ構成で動作させてみる。
※本記事は、Keycloakのバージョンアップに伴い、「[Keycloakを冗長構成で動かしてみる](https://qiita.com/yoonis/items/4f4a9df0f6f8e858bd4a)」と「[インフラ管理不要なコンテナ環境のAWS FargateでKeycloakを動かしてみる](https://qiita.com/wadahiro/items/0837729e7c57becbfd06)」の記事を最新化したものです。

# 本記事でやること

1. Keycloak の AWS 向けカスタム Docker イメージを ECR にプッシュする。

1. AWS 向けに S3_PING を用いたクラスタ構成設定を追加
2. コンテナビルド
3. ECR でプライベートリポジトリを作成

motoを用いてCognitoアクセストークンをMockして検証処理をテストするメモ

## 概要
Cognitoアクセストークン検証を行う処理についてローカルのテスト環境内でpytestの実行ができるよう、motoを用いてCognitoアクセストークンの発行処理をモックとして構築しました。

## 環境
Python 3.11.1

“`requirements.txt
boto3==1.28.33
botocore==1.31.37
moto==4.2.0
pytest==7.4.0
pytest-mock==3.12.0
requests==2.28.2
“`

## motoについて
motoはAWSの各種サービスに基づいてテストを簡単に行えるよう、AWSのサービスをモックできるPythonライブラリになります。AWSのサービスをモック化することで、実際のAWS環境には接続せずにテストを行うことができます。とても便利。

## モックしたリソース

### Cognitoユーザープールのモック
以下のコードにより、Cognitoユーザープール、アプリケーションクライアント、ユーザー、Cognitoアクセストークンの取得をモックしています。また、テストコード上

AWS CodeDeploy EC2 appspec.ymlを簡単に解説してみる

## 概要

CodeDeployのデプロイで使うappspec.ymlの項目をちょっとだけ簡単に解説してみる。

## 対象のファイル

“`appspec.yml
version: 0.0
os: linux
files:
– source: ./
destination: /var/www/html/test
file_exists_behavior: OVERWRITE
hooks:
ApplicationStop:
– location: scripts/application_stop.sh
timeout: 60
runas: root
BeforeInstall:
– location: scripts/before_install.sh
timeout: 60
runas: root
AfterInstall:
– location: scripts/after_install.sh
timeout: 60
runas: root
Applic