APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。

株式会社 エーピーコミュニケーションズの技術ブログです。

API Gatewayでスタブを作るPart 2! API キーを付与しよう!

はじめに

こんにちは!

クラウド事業部の升谷です。

前回、API GatewayにてスタブAPIを作成する方法を記事にしました!

API Gateway初心者でも簡単にAPIが作成できます!

techblog.ap-com.co.jp

今回は!

前回作ったスタブをよりセキュアーに!

ということでAPIキーを付与していく流れを記事にします!

APIにAPIキーを付与しよう

1. APIキーの作成

左帯からAPIキーへ移動。

APIキーを作成 を進めましょう!

これだけで簡単にできてしまいました!

2. 使用量プランの作成と紐付け

左帯から使用量プランへ移動。

使用量プランを作成を進めます。

レートバーストリクエストにはそれぞれ数値を入れる必要があります。

出来立てほやほやの使用量プランを選択し、関連付けられたAPIキータブからAPIキーを追加をクリックし、

使用量プランとステップ2で作ったAPIキーを紐付けます。

続きまして、関連付けられたステージタブからステージを追加をクリックし、

使用量プランとAPIのステージを紐付けます。

ステージの作成手順は前回の記事の後半にあります!

3. メソッドリクエストの設定

最後に、忘れる前にAPIを付与したいメソッドのメソッドリクエストの設定を編集します。

APIキーは必須ですにチェックをいれ、保存します。

True に変わったことが確認できます。

APIをデプロイ でデプロイを忘れずに。

これで役者は揃いました!

いざ、実践!

まず、APIキーがないとGETに失敗することを確認するため、curl {URL} で試してみましょう。

URLは以下から確認しましょう。前回同様、忘れずにGETまで辿った先にあるURLを選択してください。

APIキー付与前までGETに成功してたAPIが、APIキー指定なしでは却下されることが確認できます。

curl URL
{"message":"Forbidden"} 

では、お待たせしました、APIキーを指定してGETしてみましょう!

curl URL --header 'x-api-key:APIキー'
{
    "name": "masuya",
    "job": "engineer",
    "catOrDog": "cat",
    "petName": "Simba"
}

成功しました!

おわりに

簡単に、APIを一段セキュアーに設定することができました!

さらにセキュリティに考慮する際はIAMの設定も可能です!

ではでは、まだまだAPI Gateway編は続きます!

次は、リクエストによって応答を変えるスタブAPIの作成について紹介します!

お知らせ

APCはAWS Advanced Tier Services(アドバンストティアサービスパートナー)認定を受けております。


その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。
www.ap-com.co.jp

https://www.ap-com.co.jp/service/utilize-aws/

また、一緒に働いていただける仲間も募集中です!
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp

本記事の投稿者: <升谷>
AWSをメインにインフラ系のご支援を担当しています。

【CloudTrail to Slack】Webhooksの設定

はじめに

こんにちは、クラウド事業部の清水です。

プロダクト開発の中でCloudTrailのイベントをSlackに通知する仕組みを作りました。
今回はイベントは「AWSアカウント作成通知」受け取り先は「Slack」をベースにしてますが
トリガーを置き換えることで、汎用的に使えると思ったので記事に残させていただきます

目次

どんなひとに読んで欲しい

  • CloudTrailイベント通知を受け取りたい人
  • Webhooksの設定に困っている人

関連記事

※プロダクト紹介記事
techblog.ap-com.co.jp

※EventBrdigeの設定
techblog.ap-com.co.jp

※プロダクト構築手順の1例
techblog.ap-com.co.jp

AWSアカウント作成通知ツール: 環境構築手順

前提条件

以下の前提を満たす必要があります。

  • AWSアカウントを所有している
  • AWS Organizationを作成している
  • Slackを利用している

環境構成図

環境構築手順

0. 環境構築準備

  • AWSマネジメントコンソールにログインしてください。
  • 画面左下の CloudShell を選択し、AWS Cloud Shellを起動してください。
  • AWS Cloud Shell画面右上の Actions を選択し、 Upload files を選択してください。
  • slack-account-notification-create.zip を選択し、ファイルをアップロードしてください。
  • アップロード完了後、以下のコマンドを実行し、Zipファイルを解凍してください。
$ unzip slack-account-notification-create.zip

1. Slackの設定

  • Basic Information 画面が表示されたら、画面左メニュー Incoming Webhooks を選択してください。

  • Activate Incoming Webhooks 画面が表示されたら、off をクリックしてください。

  • offon に切り替わり下に表示が追加されます。Add New Webhook to Workspace をクリックしてください。

  • 権限リクエスト 画面が表示されたら、通知先のチャンネルを選択し、許可する をクリックしてください。

  • Activate Incoming Webhooks 画面が表示されたら、最下部に Webhook URL にある Copy をクリックしてURLをメモしておいてください。

2. Lambda関数の作成

AWS Cloud Shell環境にアクセスし、以下のコマンドを実行してください。

  • 手順に記載している各種テンプレートやソースは以下アンケートにお答え頂けるとダウンロードできる仕様となります。
    よろしかったらお試しください。

www.ap-com.co.jp

# 作業ディレクトリに移動
$ cd <解凍したフォルダ名>

# lambdaの編集(項番1でコピーしたURLを入力してください)
$ WEB_HOOK="コピーしたURL"

# 入力したURLが表示されることを確認してください
$ echo $WEB_HOOK

# 取得したURLに置換します
$ sed -ie "s#Edit_Web_Hook_Url#$WEB_HOOK#" source/slack-account-notification-create-excute-handler.py

# 置換されていることを確認します
$ grep $WEB_HOOK source/slack-account-notification-create-excute-handler.py
    url = "<置換したURL>"
$ 

# 一時的に使用するAmazon S3バケットを作成します
$ BUCKET_NAME_1=`date "+%Y%m%d-%H%M%S"`
$ aws s3api create-bucket --region us-east-1 --bucket ${BUCKET_NAME_1}

# 1つ目のLambda関数を作成します
$ STACK_NAME_1=account-notification-create-request-lambda-01
$ aws cloudformation package --region us-east-1 --s3-bucket ${BUCKET_NAME_1} \
    --template-file template/slack-account-notification-create-excute-handler.yaml \
    --output-template-file template/slack-account-notification-create-excute-handler-packaged.yaml
$ aws cloudformation deploy --region us-east-1 --stack-name ${STACK_NAME_1} \
    --template-file template/slack-account-notification-create-excute-handler-packaged.yaml \
    --capabilities CAPABILITY_IAM

# 次の工程で利用するため、以下のコマンドを実行し、Lambda関数のARNをシェル変数に設定してください。

$ Lambda_ARN=$(aws lambda get-function --region us-east-1\
    --function-name slack-account-notification-create-excute-handler \
    --query "Configuration.FunctionArn" \
    --output text)
$ echo $Lambda_ARN

3. EventBrigeルールの作成

# EventBrigeルールを作成します。出力されるARNをコピーしてください
$ aws events put-rule --region us-east-1 --name "slack-notification-account-create-event" --state ENABLED --event-pattern file://slack-notification-account-create-event.json

# EventBrigeルールとSNSトピックを関連付けます。
$ aws events put-targets --region us-east-1 --rule "slack-notification-account-create-event" --targets '[{"Id":"1","Arn":"'"$Lambda_ARN"'"}]'

# Lambda側からもターゲット登録します。
$ aws lambda add-permission  --region us-east-1 --function-name $Lambda_ARN --statement-id event-enable --action 'lambda:InvokeFunction' --principal events.amazonaws.com --source-arn <EventBrigeルールのARNを入力してください>

5. 動作確認

  • slackのチャンネルに作成が完了したアカウントの情報が通知される事を確認してください。

おわりに

Webhooksアイデア次第では色々できそうですね!
今後も通知の手段として考えてみようと思いました!

お知らせ

APCはAWS Advanced Tier Services(アドバンストティアサービスパートナー)認定を受けております。


その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。
www.ap-com.co.jp

https://www.ap-com.co.jp/service/utilize-aws/

また、一緒に働いていただける仲間も募集中です!
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp

本記事の投稿者: y-shimizu
AWSをメインにインフラ系のご支援を担当しています。 https://www.credly.com/users/giiiiiyu777/badges

JAWS DAYS 2024 に (初) 参加してきました!

はじめに

こんにちは、エーピーコミュニケーションズ クラウド事業部の坂口です。

去る3月2日に、JAWS-UGによる「JAWS DAYS 2024 - LEAP BEYOND -」が開催され、私も一般参加をしてきましたので感想をそれとなく書いていければと思います。

JAWS DAYS 2024のホームページはコチラ!

jawsdays2024.jaws-ug.jp

目次

JAWS DAYS とは

note がありましたのでそちらから引用。

JAWS DAYSはJAWS-UG最大のイベントです。全国のJAWS-UGメンバーが中心となってボランティアベースでイベントの企画、準備を行い、最新技術からビジネス、ライフスタイルなどAWSに関わる幅広いテーマの様々なセッションを開催します。

とのことです。

今回の「JAWS DAYS 2024 - LEAP BEYOND -」では、5年ぶりに東京で1つの会場に集まっての開催となったようです。

全体の所感

今回の会場は『池袋サンシャインシティ 展示ホールA』。

道中のサンシャイン通りでは旗も掲げられていました。

(案の定) 迷いはしたものの、オープニング開始までに無事到着。

入場時には折り畳みのクッションをもらえました。

# 画像は、クッションとスポンサー関連でもらったオリジナルTシャツ


セッションは時間ごとに複数用意されており、気になるセッションの場所へ移動し自由に聴講する形式。

(ただし、一部のセッションは事前の申し込みが必要でした)

また特定セッションの音声のみを聴くためのレシーバー(こちらは要返却)の配布や、Keynoteでは通訳もありました。


その他セッション以外にはスポンサー企業のブースもあり、全体的にサイズを小さくしたAWS Summitという雰囲気でお祭り感もあって楽しかったです。

ただイベント参加者の人数も多く、会場は天井が低いかつ換気しづらい構造だっただめか、最後の方は空気がよどんでいるように感じてはしまいました。

とはいえJAWS-UGとして久々に開催されたイベントということもあり、コミュニティへの関わりを持ち始めて日が浅い自分としては良い経験になりました。

参加した (一部) セッションの概要

私が参加したセッション等についても一部をピックアップして簡単に記載します。

# 全セッションを含むタイムテーブル は コチラ
# タイムテーブルでは、多くのセッションで資料も公開されています

なぜAWS向けのFrameworkに携わり続けるのか? ~クラウド時代のOSS活動~

  • NTTテクノクロス 渡邉さんによるセッション
  • ご自身の関わっているOSS活動について、関わった理由や携わり続けている理由ついて紹介いただきました
  • 活動の中で気になってくる要素や、それらを踏まえてアウトプットを続ける「軸」について、共感や学びが多かったです

クラウドネイティブなデータ連携の最新動向: AWSサービスアップデートで何が変わった?

  • セゾン情報システムズ 小林さんによるセッション
  • API連携、データ同期、ファイル転送におけるアップデートの紹介をいただきました
  • AWS のアップデートは様々なサービスに関して散発的にリリースされる印象ため、カテゴリとしてまとまったものを解説いただくのは分かりやすくて良かったです

海外イベントのためのコミュニケーションワークショップ ーPollyは友達ー

  • AWS 松本さんと、助手?の方によるセッション
  • "Polly" と題されているが、AWS Blog から Polly の読み上げが無くなっていたため急遽 Polly に関してはナシに (悲しい)
  • 内容としては、海外カンファレンスに行く予定がある方に向けて、考え方やアドバイス、Tips や体験談などを紹介いただきました

Serverlessを高速化しよう!試して感じるパフォーマンスチューニング

  • JAWS-UG でよくお見掛けする (気がする) 清家さん、岡本さん、三浦さんによるハンズオンセッション
  • 事前の登録とPCが必要だったが、せっかくなのでと申し込んで参加
  • Lambda を用いたサンプルアプリケーションのパフォーマンスの向上を試す内容
  • セッションで使用した手順も公開されているので、興味ある方はよろしければ:https://github.com/seike460/serverless-performance-handson

おわりに

昨年度の JAWS FESTA 2023 にて開催されることを知り、その時から行きたいと思っていた JAWS DAYS 2024 に参加することができました。

参加するまで実感は無かったのですが、やはり普段の JAWS-UG イベントに比べると規模が大きく、

開催に至るまでの様々な方の苦労とともに JAWS-UG としてのコミュニティ活動の力を感じられました。

来年度以降の開催はまだ未定かとは思いますが、今後も関りを持っていければ嬉しく思います!

お知らせ

APCはAWS Advanced Tier Services(アドバンストティアサービスパートナー)認定を受けております。


その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。

www.ap-com.co.jp

https://www.ap-com.co.jp/service/utilize-aws/

また、一緒に働いていただける仲間も募集中です!
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp

本記事の投稿者: さかぐち
AWSをメインにインフラ系のご支援を担当しています。最近 AWS 全冠しました。
Takumi Sakaguchi - Credly

Amazon EKSのアクセス管理をAccess Entryでシンプルにする

こんにちは、クラウド事業部の山路です。

昨年12月のアップデートにより、Amazon EKSへのアクセス制御方法を Access Entry というリソース/APIで実現できるようになりました。今回はこの新機能を簡単に検証してみます。

aws.amazon.com

背景

Amazon EKSへのアクセスを制御する場合、これまではAWS、KubernetesのそれぞれのAPIに対するアクセス制御を設定する必要がありました。

※参考:

repost.aws

これによる課題はいくつかあります。

まず、アクセス制御を実現するための手順が複雑になります。クラスター管理者はAWS APIとKubernetes APIを行き来しながら設定変更を行うため、作業ミスの可能性も高くなります。例えば誤って aws-auth ConfigMapを削除してしまうと、最悪の場合そのクラスターには誰もアクセスできなくなってしまいます。

また、クラスター作成者に付与される cluster-admin 権限が残り続けることも課題でした。たとえクラスター作成者がその後そのクラスターを操作しないとしてもroot権限が付与され続けることになり、強力な権限が関係のないアカウントに付与され続ける状態は、セキュリティ的にも大きな問題となりえます。

これを改善するため、Amazon EKS APIがAmazon EKSとKubernetesオブジェクトに対しAWS IAM principalを直接付与できるようになりました。これはつまりAWS側のリソースだけでEKSに対するアクセス制御を完結できるようになったことを意味します。

この仕組みを実現するため、Access Policy Access Entry という2つのリソースを利用します。Access Policy は特定のクラスターアクションを実行するための権限を、 Access Entry は Access Policy とそのポリシーを利用するIAMロール・ユーザーとの紐づけを管理します。

https://d2908q01vomqb2.cloudfront.net/fe2ef495a1152561572949784c16bf23abb28057/2023/11/16/Workflow.png

※画像: AWSブログより引用

Access Policy Access Entry を利用することで、EKSへのアクセス制御をAWS APIで完結できるようになります。これにより、例えばAWS CloudFormation / Terraform / AWS CDKといったIaCツールを使用して、クラスターのアクセス管理を実現できました。また、クラスター作成者に付与された cluster-admin 権限も取り除けるので、不必要に強い権限の付与を避けることができます。さらに設定ミスでクラスターへのアクセス権限を削除してしまった場合も、新しいAPIから権限を付与しなおすことで復旧できます。

なお、新しいAPI追加後も、従来通り aws-auth ConfigMapによる権限管理は可能です。現在EKSへのアクセスには以下の3つの認証モードを利用できます。

  • CONFIG_MAP: 従来通り aws-auth ConfigMapによる認証
  • API_AND_CONFIG_MAP: 新しいAPIと従来のConfigMapによる認証をどちらも利用できる
  • API: 新しいAPIによる認証

2つ目の認証モードは新旧の認証モードを利用できるので、利用者は既存のConfigMapベースの認証からAPIベースの認証への移行がやりやすくなります。認証モードの切り替えは既存のクラスターに対する設定変更で実現可能であり、従来のConfigMapベースの認証とAPI認証を並行して利用することで、従来の権限を損なうことなくAPI認証モードへの移行を進めることができます。

なお、新しいAPIを利用する際はいくつか注意事項があります。

  • 認証モードの切り替えは一方向です。切り替えは CONFIG_MAPAPI_AND_CONFIG_MAPAPI の方向に切り替え可能で、切り替え後は元のモードに戻すことはできません。
  • API認証を利用するには、 ver 1.23以降のクラスターが必要です。また、指定のバージョン以上のPlatform versionを利用している必要もあります。

利用時の条件などは AWS公式ドキュメント もご確認ください。

検証

ここから実際に新しいアクセスコントロールを試します。以降の作業ではAWS CLIを利用するため、必要に応じてAWS CLIのバージョンを更新し、 list-access-policies などの新しいコマンドを実行可能にします。

AWS CLIを更新後に list-access-policies コマンドを実行すると、利用できるAccess Policyが出力されます。

$ aws eks list-access-policies
{
    "accessPolicies": [
        {
            "name": "AmazonEKSAdminPolicy",
            "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy"
        },
        {
            "name": "AmazonEKSClusterAdminPolicy",
            "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy"
        },
        {
            "name": "AmazonEKSEditPolicy",
            "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSEditPolicy"
        },
        {
            "name": "AmazonEKSViewPolicy",
            "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy"
        }
    ]
}

なお、ここで出力されるポリシーの権限は、Kubernetesに用意されたユーザー向けのロールに対応しています。

  • AmazonEKSClusterAdminPolicy: cluster-admin
  • AmazonEKSAdminPolicy: admin
  • AmazonEKSEditPolicy: edit
  • AmazonEKSViewPolicy: view

kubernetes.io

またAmazon EKSを作成済みの場合、 describe-cluster コマンドを実行すると authenticationMode というパラメータも確認できます。

$ aws eks describe-cluster --name eks-cluster --query 'cluster.accessConfig'
{
    "authenticationMode": "CONFIG_MAP"
}

認証モードの変更

API認証を利用するため、まずは authenticationMode の変更を行います。クラスターを新規に作成する場合、AWS CLIでは以下のようなコマンドで指定できます。

$ aws eks create-cluster \
      --name <CLUSTER_NAME> \
      --role-arn <CLUSTER_ROLE_ARN> \
      --resources-vpc-config subnetIds=<value>,endpointPublicAccess=true,endpointPrivateAccess=true \
      --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}' \
      --access-config authenticationMode=API

またAWS CloudFormationを利用する場合、 AWS::EKS::ClusterAccessConfig というパラメータで指定します。

Type: AWS::EKS::Cluster
Properties:
  AccessConfig: 
    AuthenticationMode: String
    BootstrapClusterCreatorAdminPermissions: Boolean

docs.aws.amazon.com

既存のクラスターの設定を変更する場合、AWS CLIでは update-cluster-config コマンドを使用します。

$ aws eks update-cluster-config \
      --name <CLUSTER_NAME> \
      --access-config authenticationMode=<Select auth mode>

今回はAWS CloudFormationでクラスターを作成していたので、ファイルに AccessConfig を設定し、更新しました。

更新後、修正されていることを確認します。

$ aws cloudformation deploy --template-file eks-cluster.yaml \
      --stack-name eks-cluster \
      --capabilities CAPABILITY_IAM

$ aws eks describe-cluster --name eks-cluster --query 'cluster.accessConfig'
{
    "authenticationMode": "API_AND_CONFIG_MAP"
}

なお、今回は BootstrapClusterCreatorAdminPermissions というパラメータは特に指定しなかったため、作成したユーザーに対するアクセス権限が付与されています。CloudFormationで指定する場合はリソースのReplaceを必要とするのでご注意ください。

$ aws eks list-access-entries --cluster-name eks-cluster
{
    "accessEntries": [
        "arn:aws:iam::<AWS Account ID>:user/yamaji"
    ]
}

EKSへのアクセスユーザーを追加

ここで、別のユーザーに対してクラスターへのアクセス権を付与します。

AWS CLIの場合、アクセス権を付与するため、まずは新しいアクセスエントリーを作成します。

$ aws eks create-access-entry \
      --cluster-name <CLUSTER_NAME> \
      --principal-arn <IAM_PRINCIPAL_ARN>

その後、作成したアクセスエントリーとアクセスポリシーを紐づけることで、権限付与は完了します。

$ aws eks associate-access-policy \
      --cluster-name <CLUSTER_NAME> \
      --principal-arn <IAM_PRINCIPAL_ARN> \
      --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy
      --access-scope type=cluster

今回はCloudFormationで以下のようなテンプレートを使用します。

AWSTemplateFormatVersion: 2010-09-09
Description: 'Access entries for EKS cluster'
Parameters:
  ClusterName:
    Type: String
  
Resources:
  AccessEntry:
    Type: 'AWS::EKS::AccessEntry'
    Properties:
      AccessPolicies: 
        - AccessScope:
            Type: 'cluster'
          PolicyArn: 'arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy'
      ClusterName: !Ref ClusterName
      PrincipalArn: !Sub 'arn:aws:iam::${AWS::AccountId}:user/test-user'

上記テンプレートファイルを使用してアクセス権の付与を行います。

$ aws cloudformation deploy --stack-name eks-accessentry \
      --template-file eks-accessentry.yaml \
      --parameter-overrides ClusterName=eks-cluster 

$ aws eks list-access-entries --cluster-name eks-cluster
{
    "accessEntries": [
        "arn:aws:iam::<AWS Account ID>:user/test-user",
        "arn:aws:iam::<AWS Account ID>:user/yamaji"
    ]
}

あとは追加したユーザーでアクセスできるようkubeconfigを更新すれば、EKSにアクセスし、クラスター上のリソースも見れるようになります。

$ aws eks update-kubeconfig --name eks-cluster

# kubectlは定期的にアップデートしておきましょう
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.0", GitCommit:"c2b5237ccd9c0f1d600d3072634ca66cefdf272f", GitTreeState:"clean", BuildDate:"2021-08-04T18:03:20Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"27+", GitVersion:"v1.27.8-eks-8cb36c9", GitCommit:"fca3a8722c88c4dba573a903712a6feaf3c40a51", GitTreeState:"clean", BuildDate:"2023-11-22T21:52:13Z", GoVersion:"go1.20.11", Compiler:"gc", Platform:"linux/amd64"}
WARNING: version difference between client (1.22) and server (1.27) exceeds the supported minor version skew of +/-1

# 今回はクラスターだけ作成しておりNodeがないためPodは作れない状態です
$ kubectl get pods -A
NAMESPACE     NAME                       READY   STATUS    RESTARTS   AGE
kube-system   coredns-8496bbc677-2hkgr   0/1     Pending   0          35m
kube-system   coredns-8496bbc677-zmwvh   0/1     Pending   0          35m

Namespaceレベルの権限コントロール

新しいアクセス管理を利用すると、Kubernetes Namespaceレベルの権限コントロールも可能となります。先ほど使用したCloudFormationには AccessScope というパラメーターがありましたが、ここで namespace を指定することも可能です。

AWSTemplateFormatVersion: 2010-09-09
Description: 'Access entries for EKS cluster'
Parameters:
  ClusterName:
    Type: String
  
Resources:
  AccessEntry:
    Type: 'AWS::EKS::AccessEntry'
    Properties:
      AccessPolicies: 
        - AccessScope:
            Type: 'namespace'
            Namespaces: # 対象のNamespaceを指定
              - 'default'
          PolicyArn: 'arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy'
      ClusterName: !Ref ClusterName
      PrincipalArn: !Sub 'arn:aws:iam::${AWS::AccountId}:user/test-user'

このファイルを使用してAccess Entryを更新すると、 test-user からは default Namespaceにしかアクセスできず、それ以外 (ここでは kube-system ) にはアクセスできません。

$ kubectl get all
NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service/kubernetes   ClusterIP   10.100.0.1   <none>        443/TCP   46m


$ kubectl get all -n kube-system
Error from server (Forbidden): pods is forbidden: User "arn:aws:iam::<AWS Account ID>:user/test-user" cannot list resource "pods" in API group "" in the namespace "kube-system"
Error from server (Forbidden): replicationcontrollers is forbidden: User "arn:aws:iam::<AWS Account ID>:user/test-user" cannot list resource "replicationcontrollers" in API group "" in the namespace "kube-system"
Error from server (Forbidden): services is forbidden: User "arn:aws:iam::<AWS Account ID>:user/test-user" cannot list resource "services" in API group "" in the namespace "kube-system"

(以降割愛)

なお、Access EntryはKubernetes RBACと組み合わせることも可能です。例えばAccess EntryはKubernetes Groupを指定することもできるので、Cluster Role BindingでKubernetes GroupとCluster Roleを紐づければ、Kubernetes RBACベースでの制御を実現できます。

さいごに

Amazon EKSへの新しいアクセス制御方法の紹介でした。従来のConfigMapベースの認証にこだわりがない場合は、基本的にAPI認証のほうが使いやすそうな印象です。

設定変更も簡単にできるので、EKSへのアクセス管理に苦労している人は検討してみるのはいかがでしょうか。

弊社はAWSアドバンスドティアサービスパートナー認定を受けております。また以下のようにAWSの活用を支援するサービスも行っているので、何かご相談したいことがあればお気軽にご連絡ください。

www.ap-com.co.jp

AWS アカウントに Google Workspace ユーザーでシングルサインオンしてみた。(part3)

目次

はじめに

こんにちは。エーピーコミュニケーションズ クラウド事業部の髙野です。
本記事ではGoogle Workspace ユーザーを IAM Identity Center ユーザーとしてAWS 環境に同期するための手順を紹介します。
なお、今回の内容は少しボリュームがあるので本記事を含め3つの記事に分けて投稿しており、本記事が3つ目の記事です。

1つ目および2つ目の記事は以下を参照してください。

techblog.ap-com.co.jp

techblog.ap-com.co.jp

前提条件

手順概要

  1. AWS のカスタムユーザー属性を作成する
  2. ID プロバイダーのメタデータをダウンロードする
  3. Google Workspace で Amazon Web Services アプリをセットアップする
  4. IAM Identity Center の ID ソースを変更し、Google Workspace を SAML ID プロバイダーとして設定する
  5. Google Workspace でアプリを有効にする
  6. IAM Identity Center の自動プロビジョニングを設定する
  7. Google Workspace で自動プロビジョニングを設定する
  8. IAM Identity Center グループを作成する★
  9. Google Workspace ユーザーをIAM Identity Center グループに追加する★
  10. IAM Identity Center グループにAWSアカウントへのアクセス権を付与する★
  11. Google Workspace ユーザーの AWS リソースへのアクセスを確認する★

※本記事では手順8から手順11を取り扱います。

手順

8.IAM Identity Center グループを作成する

8-1.IAM Identity Center コンソールの [設定] → [アイデンティティソース] で [IDストアID] を確認します。

8-2.AWS CLI を使用できる環境にアクセスします。

※IAM Identity Center の自動プロビジョニングを有効化すると、AWSの仕様でコンソールからIAM Identity Center グループに関する操作ができなくなるので AWS CLI を使用します。本記事では CloudShell で AWS CLI を実行します。

IAM Identity Center が有効化されているリージョンで CloudShell アイコンを選択します。

8-3.以下のコマンドを実行して、IAM Identity Center グループを作成します。

※今回は「google-test-administrator」という名前で作成します。

$ aws identitystore create-group --identity-store-id <手順8-1で確認したIDストアID> --display-name google-test-administrator

# 実行結果
{
    ""GroupId"": ""×××××××-××××-××××-××××-××××××××××××"",
    ""IdentityStoreId"": ""<手順8-1で確認したIDストアID>""
}

8-4.実行結果として出力された [GroupId] を確認します。

9.Google Workspace ユーザーをIAM Identity Center グループに追加する

9-1.IAM Identity Center コンソールの [ユーザー] でIAM Identity Center グループに追加するユーザーのユーザー名を選択します。

9-2.[一般的な情報] の [ユーザーID] を確認します。

9-3.以下のコマンドを実行して、IAM Identity Center グループにユーザーを追加します。

$ aws identitystore create-group-membership \
   --identity-store-id <手順8-1で確認したIDストアID> \
   --group-id <手順8-4で確認したGroupId> \
   --member-id UserId=<手順9-2で確認したユーザーID>

# 実行結果
{
    ""MembershipId"": ""×××××××-××××-××××-××××-××××××××××××"",
    ""IdentityStoreId"": ""<8-1の手順で確認したIDストアID>""
}

10.IAM Identity Center グループにAWSアカウントへのアクセス権を付与する

10-1.IAM Identity Center コンソールの [AWSアカウント] を選択します。

10-2.ユーザーにアクセス権限を与える AWSアカウント にチェックを入れて、画面上部の [ユーザーまたはグループを割り当て] を選択します。

10-3.[グループ] タブで先ほど作成した「google-test-administrator」にチェックを入れて、[次へ] を選択します。

10-4.割り当てる許可セットにチェックを入れて、[次へ] を選択します。

10-5.設定内容に誤りがないことを確認して、[送信] を選択します。

11.Google Workspace ユーザーの AWS リソースへのアクセスを確認する

11-1.アクセス許可の設定をしたGoogle Workspace ユーザーで AWS アクセスポータルアプリを開きます。

11-2.IAM Identity Center グループでアクセス許可した AWS アカウントが表示されることを確認します。

11-3.表示された AWS アカウントを選択し、手順10-4で選択した許可セット名が表示されることを確認します。

11-4.[Management console] を選択し、AWS コンソールにアクセスできることを確認します。

まとめ

これで、Google Workspace ユーザーを IAM Identity Center ユーザーとしてAWS 環境に同期し、AWSコンソールにアクセスできました。
今回は3つの記事にわたる長いチュートリアルでしたが、最後まで読んでいただきありがとうございました!

本記事で紹介している手順は以下を参考に記載しております。

docs.aws.amazon.com

お知らせ

APCはAWS Advanced Tier Services(アドバンストティアサービスパートナー)認定を受けております。


その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。
www.ap-com.co.jp

https://www.ap-com.co.jp/service/utilize-aws/

また、一緒に働いていただける仲間も募集中です!
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp

本記事の投稿者: sk07103
AWSをメインにインフラ系のご支援を担当しています。

【Amazon Connect】画面遷移を含んだステップバイステップガイドを作成する

目次

はじめに

こんにちは、クラウド事業部の菅家です。
Amazon Connectのステップバイステップガイド続きです。

前回はノーコードUIビルダーの使用を目的に1画面だけ作成しましたが、
どうせなら複数画面を作って画面遷移も試してみたく、本検証を実施しました。
いずれは短いデモシナリオを立て、シナリオに沿ったステップバイステップガイドを作成出来たらいいなと思います。
今回はその準備検証となります。

前回: techblog.ap-com.co.jp


どんなひとに読んで欲しい

複数画面を使って、Amazon Connectのステップバイステップガイドを作成したい方、
本記事の検証を通して、一緒に学んでいけますと幸いです。

目標

やりたいこと

メニュー画面、フォーム画面の2画面を使ったステップバイステップガイドを作成する。
各画面にはボタンを使って遷移する。

検証ステップ

  1. 画面作成2画面(メニュー、フォーム)
  2. 画面で押したボタンによって分岐をする設定を行う
  3. 2画面を行き来できるフローの作成

検証

①画面作成2画面(メニュー、フォーム)

Amazon Coonnectのインスタンスにログインし、ビューを作成します。
フロー>ビュー>ビューを作成

メニュー画面
 フォームに移動するボタンのみ配置します。
 部品として、Form>Submit Buttonを選択し、配置します。
 プロパティ>Actionに「transition Form」を設定します。Actionについては次の②にて説明。


フォーム画面
 テキストボックスとボタンを用意、ボタンはCancel、Submitの2つ作成します。
 部品として、
  Container>Sectionを選択し、配置します。
  Container>Button Groupを選択し、Sectionの中に配置します。
  Form>Form Inputを選択し、Sectionの中に配置します。


②画面で押したボタンによって分岐をする設定を行う

ビュー(画面作成)にて設定します。
作成したボタンに対してActionを設定することでフローで分岐をさせることができます。

docs.aws.amazon.com

今回はフォーム画面に設定します。
フォームのビューを開き、②にて配置した「Button Group」を選択します。
右のプロパティから、Itemsをクリック。

「Button Group」に所属する部品一覧が表示されます。
items-1がCancelボタン、items-2がSubmitボタンとなっています。



items-1、items-2をクリックし、各々のボタンのプロパティを展開します。
Actionにitems-1は「cancel」items-2は「submit」を入力。


コンタクトフローにて「ビューを表示」ブロックを配置してみます。
Actionにて設定した、cancelとsubmitが分岐として用意されていることがわかります。

③2画面を行き来できるフローの作成

フローは電話がかかって来たものと、ビュー表示用と2つ用意しています。
前回のものを流用しておりますので、作り方は前回の記事をご参照ください。
techblog.ap-com.co.jp

ビュー用のフローに「ビューを表示」ブロックを配置し、作成した2つのビューをそれぞれ設定します。
ボタンクリックの挙動として、単純にメニューとフォームを行き来するよう設定します。

ビューのタイムアウトは60秒設定とします。
短いと画面操作が無い場合にステップバイステップガイドが閉じてしまうためです。
タイムアウトのベストプラクティスについては要調査です。

動かしてみる

Amazon Connectインスタンスより、「エージェント Workspace」を開き、ステータスをAvailableとします。
電話をかけて確認します。

メニューから「フォームへ移動」ボタンを押し、フォームに移動します。

今度はフォーム側から「Cancel」を押し、メニューに戻ります。



フォームの「Submit」ボタンの方はビュー側のプロパティを色々いじってはみたのですが、残念ながら反応せず。
ただし、Cancelボタンとは別のボタンだとは認識されているようです。
こちらについては使用部品やフローの修正含めて次回以降にFormの値を送る際に解決していこうと思います。

おわりに

記事のはじめでも述べましたが、最終的に短いデモシナリオを立て、シナリオに沿ったステップバイステップガイドを作ることを目標としております。
次は準備その2として、フォームに入るデータや送られるデータの扱いについて検証していきたく、今回の課題解決含めて

  • 顧客情報などの動的データをフォーム画面を表示した際にあらかじめ入力しておく

  • フォームの内容をラムダに送信する

の検証ができればと思います。

お知らせ

APCはAWS Advanced Tier Services(アドバンストティアサービスパートナー)認定を受けております。


その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。
www.ap-com.co.jp

https://www.ap-com.co.jp/service/utilize-aws/

また、一緒に働いていただける仲間も募集中です!
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp

本記事の投稿者: s-sugaya
AWSをメインにインフラ系のご支援を担当しています。 https://www.credly.com/users/giiiiiyu777/badges

AWS全冠の振り返り

こんにちは、株式会社エーピーコミュニケーションズ、クラウド事業部の松尾です。


約10か月かけてAWS認定試験の12試験取得(=全冠)達成しました!学習方法や反省点をお伝え出来ればと思います。これから全冠を目指す、または検討している方の力になれば。

CredlyのBadges


大まかな受験スケジュール

時系列にしてみました。学習期間の目安は、Associateは2,3週間、Professionalは2か月、専門知識は1か月、くらい。Professionalは別として1か月あると対策が出来た感覚でした。セオリーではないですがAssociateを受けたのは最後でした。

合格日 試験名称 学習期間
2022/10/29 AWS Certified Solutions Architect – Professional 2か月
2023/7/2 AWS Certified Security – Specialty 1か月
2023/8/5 AWS Certified Database – Specialty 1か月
2023/8/26 AWS Certified Advanced Networking – Specialty 3週間
2023/10/6 AWS Certified Data Analytics – Specialty 1か月
2023/12/2 AWS Certified Machine Learning – Specialty 2か月
2023/12/16 AWS Certified: SAP on AWS – Specialty 2週間
2024/2/4 AWS Certified DevOps Engineer – Professional 1か月半
2024/2/23 AWS Certified Developer – Associate 2週間
2024/2/25 AWS Certified Cloud Practitioner 1週間
2024/3/2 AWS Certified Solutions Architect – Associate 1週間
2024/3/16 AWS Certified SysOps Administrator – Associate 2週間


簡単な経歴

・元ネットワークエンジニア

・AWS経験は期間を空けつつ合計3年程度

・設計、構築を経験

・2017年にSAAだけは取得していたが2020年には失効済み


取得のきっかけ

会社が資格取得を後押ししてくれていたことと、携わっていた業務でAWSの使ったことのないサービスを扱い始めたことがきっかけでした。

2022年にSAPは取得していたのですがその時点では全冠は全く考えておらず、そこから半年ほどは何も取得していませんでした。

その後2023年にAWSの業務に携わる機会があり、SAPの範囲外の知識が必要になったため、せっかく学習するなら資格取得も目標にしていこうか、と考えて学習を始めた形です。

専門知識の試験を3つほど取得したあたりで、もしかしたら全冠いけるかも、ぐらいに考え始めていた気がします。

AWS All Certifications Engineersの申請に間に合わせるために2024年3月末までの全取得に標準を合わせていきました。


苦労した試験

基本的には全部難しいと思っていますが、中でも記憶に残っている3つがこちら。

難易度:★★★★★

AWS Certified Solutions Architect - Professional (SAP-C01)

最も難易度が高かった印象。内容もさることながら、問題と選択肢が長文で、読んでいるだけで時間が溶けていきました。これを合格出来たら他も取得する実力はあると思います。

難易度:★★★★

AWS Certified Advanced Networking - Specialty(ANS-C01)

元ネットワークエンジニアでも油断出来ない(私)。AWSのサービスは基本的にはアカウントがあれば動作確認が出来ることが多いが、本試験はオンプレとの接続やマルチアカウントの条件も登場するので、簡単には環境を作れない点で学習のしにくさがあった。

ネットワークの知識も前提として必要なので、非ネットワークエンジニアなら他の試験よりも学習時間を長めにした方が良さそう。 試験も難しく、スコアが合格ラインぎりぎり(759点)だった試験。

難易度:★★★

AWS Certified Solutions Architect - Associate(SAA-C03)

最初に取得した試験、という意味で苦労した試験でした。

0から1にすることはエネルギーを大きく使うと思うので。受験して実際そう思いました。SAAは不合格も経験。

1つの試験に対して学習期間は約2週間~1か月でしたが、最初のSAA(表には入れてないが2017年に初めて取得したAWS認定)は2,3か月だった記憶があります。AWS用語や試験に出ないようなマネコンの操作感など、基本的なことに時間がかかってました。


学習方法

問題集(CloudLicenseなど)を基本に学習しました。試験対策という面では効果的だったと思います。有償でも解説があるものが使いやすかったです。

問題を解いても全く意味が理解出来ていない場合、問題集を進めるには早いので、基本の理解深めるために、書籍(要点整理から攻略する〇〇シリーズ)、AWSサービス別資料、ハンズオン(JP Contents Hub)で学習していました。要点整理から攻略する〇〇シリーズは説明が分かりやすい。

問題集が8割程度正答するようになったら受験する流れでした。

自分の学習のしかた

問題を解くことを基本に、不足している知識は書籍や公式ドキュメントで補足していく形で進めていました。簡単には1~4の流れです。

  1. 公式サンプル問題を解く
  2. 手応えあるなら問題集を解く
  3. なければ書籍、Udemy、サービス別資料をみたり、ハンズオンやって基礎知識を補充
  4. 問題集解いて8割正答を目安に受験


学習方法で良かった点

気が乗らない日も何か一つやる

学習する気が全く乗らない日もよくありましたが、そんな日でも何か一つだけでも前進するようにしていました。書籍を1ページだけ読むとか、問題を1問だけ解くとか。学習効果というよりは習慣を変えないためにそうしていました。

受験申込をしてしまう

背水の陣戦法。予約をしてしまい、受験日から逆算して学習ペースを決めていきました。後で受験日を決めるよりも日々の学習が出来ていた気がします。どうしても学習が追い付かない場合はスケジュールを組みなおすこともありましたが面倒なので何とか当初の予定で進めるようにしていました。


学習方法で良くなかった点

1つの試験の学習期間は少なくとも1か月はとるべきでした。業務をしながらだと繁忙期と重複した場合につらいことになります(なりました)


どんな人が全冠できるか

継続して学習出来る人、これに尽きます。

業務でAWSに触れる環境にあるとか、計画性があるとか、有った方が良い要素はいくつもありますが、結果として継続して学習することが出来る方法を見つけられるなら到達できると思います。

自分のモチベーションをうまく維持することも大事ですね。


取得する順番のおすすめ

全冠する前提で効率が良さそうな順番を書いてみましたが、Associateを最初に取る以外は興味がある順でも良いと思います。

最初はAssociate

ゼロからのスタートなら最初はAssociate(試験はどれでも良い)と思います。1つ目の試験は難しく感じると思いますが、0から1にする踏ん張りどころ。

次は専門知識

専門知識は自身の得意なジャンルがあればそこから始めると良いです。私はネットワークがバックグラウンドとしてあったのでANSを前半で着手しました。

SCSやANS、DBSはSAPに含まれる部分もあるので、SAPより先に専門知識を取ってしまうのが確実と思います。

最後はProfessional

プロフェッショナルレベルの試験はSAPとDOPの2つあります。それぞれ学習時間がかかるので、1つ受けたら忘れないうちに続けて取得するのが良いと思います。分野は違いますが問題の長文に慣れているうちに受けるのが良いです。


取得して良かった点

達成感

達成感はあります。最後の2か月は受験を詰め込んでいたのでやっと終わった感もありました。

AWS知識

不明なことを調査していくうえでキーワードというかフックにできる部分が増えた感じはします。

学習習慣

日常的に学習する習慣がついたことも良いことかなと思います。

元々朝型でしたが、さぼった学習を取り戻すため1時間早く起きて学習することもあり、生活リズムが少し変わりました。


振り返ってみて

今回、試験学習を通してある程度AWSを網羅的に理解することは出来たと思っています。ただ、どこまでいっても「ある程度」であり、実践での経験には適わないという位置づけで捉えています。それでも一つと指標して全冠を達成できたことは良かったです。

AWS全冠のブログも増えてきていますが、本記事もこれから取得を目指す人の力になれば幸いです。


おわりに

私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。

www.ap-com.co.jpwww.ap-com.co.jp

また、一緒に働いていただける仲間も募集中です! 今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp

AWS Certified DevOps Engineer - Professional 試験(DOP-C02) 合格記

こんにちは、株式会社エーピーコミュニケーションズの松尾です。 2024年2月4日にDOP-C02に合格出来たので学習方法など共有したいと思います。 プロフェッショナルレベルで難易度の高い試験だったこともあり、皆さんの学習の参考になれば幸いです。

** 受験前の知識レベル - 元ネットワークエンジニアで設計、構築の経験あり。 - 開発の知見、経験は無し。lambdaの実装をなんとか行える程度。 - AWS業務からは離れている状況。

** 学習期間 - 2023年12月~2024年1月の約2か月間、平日1時間、通勤時間を使う形で学習を進めてました。

** 学習内容 - 最初にUdemyの教材で試験概要を把握してから、CloudLicenseの問題集を解き、正答率が80~90%程度になるまで繰り返してました。

|学習順|教材|コメント| |1|試験ガイド|対象範囲を理解すること。範囲外のサービス名も記載されているので認識しておく。この時点ではサービス名で概要は分かるが、内容までは分かっていない状態。| |2|AWS Certified DevOps Engineer - Professional 公式練習問題集|練習問題20問を実施して自分のレベル感を理解。| |3|AWS サービス別資料 | 理解出来ていないところを重点的に。私はCodeシリーズを特に見ていきました。 | |4|Udemy講座|英語コンテンツだが日本語訳に対応。開発の知見が皆無なため基礎から学習。試験にフォーカスしたコンテンツなので効率的に学習が出来る。が、ボリュームがあるため全ては見れていない。進めたのは8割程度。| |5|CLoudLicense|旧TechStock。有償ではあるものの、解説が分かりやすくおすすめ。|

** 試験当日 - 会場で受験。パソコントラブルがあったとかで5分程度開始が遅れましたが、それ以外は特に問題無し。10回は会場で受験してますが初のトラブルでした。 - 試験制限時間190分(アンケート10分含む))のうち、回答には120分、見直しに20分と、同じくプロフェッショナルレベルのSAPと比べると多少時間に余裕はありました。 - 感覚的にもSAPはやたら問題と選択肢が長文で、読解に時間を要した印象でしたが、DOPはそれよりは短かった印象でした。

良かったこと(+)、悪かったこと(-) * + - CloudLicense 解説が分かりやすく、スマホでも使いやすいのでおすすめ。 - 試験会場はオフラインで 思いつきで耳栓を使ってみたら結構集中出来た感じがします。30分程度の切りのいいタイミングで一旦休憩することも実行出来たので気が楽でした。(オンライン受験だと目線外すことにも厳しいような情報も見受けられたので二の足を踏んでいます。。)

*** - - 学習期間が思ったよりかかってしまったこと。 当初は1か月半くらいで受験するつもりでしたが、解説を読んでも一回では理解出来ない部分も多く、時間がかかってしまいました。

** 振り返ってみて - 開発のバックグラウンドがあると学習しやすそうな感じがありました。私はCodeシリーズがなかなか覚えられず苦戦しました。 - 回答で迷ったら問題文をよく読むことがやはり大事かなと思いました。質問されているのが、”通知”だけなのか、”設定の是正も含む”のか、など、それだけでも選択肢を多少狭められると思います。

** おわりに

私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。

www.ap-com.co.jp

また、一緒に働いていただける仲間も募集中です! 今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp

AWS Step Functions で Task の出力を保持しておき後の Task で参照する

こんにちは。クラウド事業部の野本です。

AWS 上でバッチ処理を実装する際、複数の Lambda 関数を順番に呼び出すために Step Functions を使う機会がありました。単純なものなら Workflow Studio でステートを並べるだけで視覚的に組み立てられるのですが、 Lambda の入出力を複雑に受け渡すには Step Functions の入出力を理解する必要があり苦労しました。

本記事では Step Functions の離れたステート間で入出力を受け渡す設定方法について纏めます。特に Task ステートにおける入出力処理を、ステートの定義をプログラムに翻訳して理解してみます。

したいこと

4つの Lambda 関数を順番に実行させたいです。 Step Functions を用いれば下図のように Task ステートを並べたステートマシンとなります。

Lambda 関数の入出力には追加の要件があり、3番目の Lambda の入力には1番目の Lambda の出力を、4番目の Lambda の入力には2番目の Lambda の出力を必要とします。しかし Workflow Studio でただステートを並べただけでは、 Lambda に渡せるデータは直前の Lambda の結果だけとなり、2つ前の出力は消えてしまいます

最初はステートマシンに合うように各 Lambda の入出力仕様を変えないといけないのかと思いましたが、調べていくとステートの入出力の設定をきちんと書けば対応できることがわかりました。

設定方法

例えば Task01 の結果を Task03 で使うには、以下のような5つの設定を入れておきます。(デフォルト値であっても明記しています)

"Task01": {
  ...,
  "ResultSelector": {
    "StatusCode.$": "$.StatusCode",
    "Payload.$": "$.Payload"
  },
  "ResultPath": "$.Result01",
  "OutputPath": "$"
},
...
"Task03": {
  "InputPath": "$.Result01.Payload",
  "Parameters": {
    "FunctionName": "...",
    "Payload.$": "$"
  },
  ...
}
  • 出力時
    • ResultPath で適当なパスを指定して保存し、 OutputPath はデフォルト値(全て出力)にします
      • 保存したデータを途中で捨てないよう、以降の各ステートでも同様の対応が必要です
    • ResultSelector では保存したい項目を抽出・整形できます
  • 入力時
    • InputPath では入力の一部を抽出でき、保存した特定のステートの結果を参照しやすくなります
    • Parameters では普通にパラメータを構築します

ResultPathOutputPath が重要で、 ResultSelectorInputPath は指定しなくても Parameters で調整できます。

(個人的には "ResultSelector.$": "$.Payload" のような整形をしたいのですが、その良い方法はまだわかっていません)

入出力の設定の仕組み

5つの設定項目がどう働くのかは、公式ドキュメントの「Step Functions の入出力処理 - AWS Step Functions」に書いてあります。今回はそれをもっとコンパクトに纏めるため、ステートマシンの定義に近いコードの形で整理してみました。

ある定義の Task ステートをプログラミング言語での関数に翻訳すると、入力(引数)を与えてから出力(戻り値)が返るまでの処理は概ね以下のようになります。(コメント部が翻訳元の設定です)

function executeMyTask(message) {

    // "InputPath": "$.foo"
    const input = message.foo;

    // "Parameters": {
    //   "FunctionName": "...",
    //   "Payload": { "hoge.$": "$.fuga" }
    // }
    const parameters = {
        FunctionName: "...",
        Payload: { hoge: input.fuga }
    } || input;

    const response = callAPI(parameters);

    // "ResultSelector": {
    //   "StatusCode.$": "$.StatusCode",
    //   "Payload.$": "$.Payload"
    // }
    const result = {
        StatusCode: response.StatusCode,
        Payload: response.Payload
    } || response;

    // "ResultPath": "$.bar"
    message.bar = result;

    // "OutputPath": "$.baz"
    return message.baz;
}

$ は状況によって異なる変数を表し、また ResultPath の表すものだけは = の左に置かれているなど、設定ごとに異なる振る舞いがあります。とはいえ各設定の翻訳は単純で、全体の処理も追いやすい形な印象です。


さて、入力したオブジェクト(message)が出力されれば元のデータを保持できるのですが、それを妨げうる設定が2つあることがわかります。

  • OutputPath$ 以外のパスを指定すると message の一部のみを抽出して出力します
  • ResultPath$ を指定すると message 全体を result に置き換えます

この2つを適切に設定することが、ステートマシン実行中にデータを保持し続ける際に重要になります。

Workflow Studio 初期設定のままの場合

Workflow Studio で Lambda 実行を繋げただけの定義を読み解いてみます。

"Task02": {
  "Type": "Task",
  "Resource": "arn:aws:states:::lambda:invoke",
  "OutputPath": "$.Payload",
  "Parameters": {
    "Payload.$": "$",
    "FunctionName": "..."
  },
  "Retry": [...],
  "Next": "Task03"
},
"Task03": {
  "Type": "Task",
  "Resource": "arn:aws:states:::lambda:invoke",
  "OutputPath": "$.Payload",
  "Parameters": {
    "Payload.$": "$",
    "FunctionName": "..."
  },
  "Retry": [...],
  "Next": "Task04"
},

どちらも同じ形をしていて、関数に翻訳すると以下のようになります。

function executeTaskN(message) {

    // "InputPath": "$"  /* default */
    const input = message;

    // "Parameters": {
    //   "Payload.$": "$",
    //   "FunctionName": "..."
    // }
    const parameters = {
        Payload: input,
        FunctionName: "..."
    } || input;

    const response = callAPI(parameters);

    // "ResultSelector": null  /* default */
    const result = null || response;

    // "ResultPath": "$"  /* default */
    message = result;

    // "OutputPath": "$.Payload"
    return message.Payload;
}
  • Task02 出力時
    • ResultSelector 無指定(null)なので、レスポンス全体が result に入ります(Lambda なら PayloadSdkHttpMetadata などが含まれています)
    • ResultPath 無指定($)なので、 resultmessage そのものに保存(上書き)します
    • OutputPath$.Payload なので、 message (= result (= response)) の一部を抽出します
    • 結果的に response.Payload の部分のみがステートの出力となり、次のステートの入力へ渡されます
  • Task03 入力時
    • InputPath 無指定($)なので、入力全体を使ってパラメータを作ります
    • Parameters 内で $ と指定すると input (= message (= response.Payload)) を参照します
    • → したがって "Payload.$": "$" は前回の Lambda の戻り値をそのままイベントとして渡すことになります

このように、ResultPathOutputPath によって元の message は完全に消えています。直前の結果のみでいい場合は非常にコンパクトな方法です。

不要なデータの整理

全ての出力を保存していると、 Step Functions の制限である 256 KB を超えてしまう可能性があります。ある程度大きなステートマシンになると、出力の仕組みを利用して不要なデータを消すことも必要です。

それには例えば以下のような方法が考えられます。

  • ResultSelector で、必要なデータだけ抽出します(これは本記事の例でも扱いました)
  • ResultPath で、もう使わないデータのパスに上書きします
    • 特に "ResultSelector": {}, "ResultPath": "$" とすると、ステートの出力を空にできます
    • 一方で Task 内の結果が完全に不要なら、 ResultPathnull を指定して捨てられます
  • コンテキストオブジェクトにはステートマシン開始時の入力が含まれるため、 "OutputPath": "$$.Execution.Input" を指定するとデータをリセットできます
  • Pass ステートを用いて入力を整形し、後続に必要なデータだけ抽出します(※状態遷移が増えるため料金に影響します)

まとめ

Step Functions のステートの入出力の設定方法について整理しました。 Workflow Studio の初期設定のままだと直前のステートの結果しか残りませんが、出力(特に ResultPathOutputPath)をきちんと設定すればあるステートでの出力を保持してしばらく後のステートでも参照できることがわかりました。

実案件では、 Map でもっと複雑なデータ受け渡しが必要になったり、 Lambda の入出力仕様が途中で変更になったりもしました。これらも Step Functions の入出力がわかってからは、かなり思い通りに設定できるようになりました。

【Tips!】EventBrdige のdetail-typeの罠

目次

はじめに

こんにちは、クラウド事業部の清水(雄)です。

AWS ChatOPSサービス開発時にEventBrdige のdetail-typeの設定で悪戦苦闘したので
備忘録として記載させていただきます。
まさか発行元が違うなんて、、、

どんなひとに読んで欲しい

  • 「EventBrdige」の設定で意図した通知をしたい人
  • 「EventBrdige」の設定したの検知出来ずに困っている人

関連記事

※AWSの定型作業を楽にする ~チャットツールを活用した例の紹介~↓
techblog.ap-com.co.jp

※さらば、コンソール作業、、~AWS運用自動化ツール:IAMユーザ作成編~↓
techblog.ap-com.co.jp

※さらば、コンソール作業、、~AWS運用自動化ツール:IAMユーザ削除編~↓
techblog.ap-com.co.jp

事象

AWS アカウントの作成をSlack上でできるツールを開発したのですが
AWSアカウントは即時で作られるものではないので
作成通知用にCloudTrailでAPIの履歴を見に行くEventBrdigeの設定をしました。

{
  "source": ["aws.organizations"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventName": ["CreateAccountResult"],
   }
}

原因

「CreateAccountResult」の発行元は「AWS API Call via CloudTrail」ではなく
「AWS Service Event via CloudTrail」である為

解決策

detail-typeを「AWS API Call via CloudTrail」から「AWS Service Event via CloudTrail」に変える。

{
  "source": ["aws.organizations"],
  "detail-type": ["AWS Service Event via CloudTrail"],
  "detail": {
    "eventName": ["CreateAccountResult"],
   }
}

どうやら以下5つの区分があってそれぞれの用途があるようです。

* 「AWS API Call :API が呼び出された時の検知に用いる」

* 「AwsServiceEvent :リソースが呼び出された時の検知に用いる」

* 「AwsConsoleAction:API 呼び出しではないアクションがコンソールで実行された時の検知に用いる」

* 「AwsConsoleSignIn:コンソールサインインした時の検知に用いる」

* 「AwsCloudTrailInsight :異常検知をした時の検知に用いる」

↓公式ドキュメント
docs.aws.amazon.com

おわりに

EventBrdigeの検知で違いがあったとは勉強になりました。
それぞれの違いを組んでまた開発に取り組もうと思います。

お知らせ

APCはAWS Advanced Tier Services(アドバンストティアサービスパートナー)認定を受けております。


その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。
www.ap-com.co.jp

https://www.ap-com.co.jp/service/utilize-aws/

また、一緒に働いていただける仲間も募集中です!
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp

本記事の投稿者: y-shimizu
AWSをメインにインフラ系のご支援を担当しています。 https://www.credly.com/users/giiiiiyu777/badges

Amazon Connect ノーコードのUIビルダーでステップバイステップガイドを作成してみる

はじめに

こんにちは。エーピーコミュニケーションズクラウド事業部の菅家です。
Amazon ConnectのステップバイステップガイドをノーコードのUIビルダーで試したところをまとめます。

ステップバイステップガイドとはエージェント(電話を受け取るオペレーター)に対して、顧客とのやり取りの際に動的にオペレーションのガイド画面を提供する機能となります。
作成・設定されたステップバイステップガイドはAmazon Connect Agent Workspaceにて表示されます。
aws.amazon.com
ステップバイステップガイドを使用するには、ガイドの画面作成が必要になってきますが、
2023年のre:Inventでの発表でその画面(ビュー)の編集に対して、画面部品をドラッグアンドドロップして作成できるようになったそうです。
.NET系の言語を学んだ方ならフォームの作成であったり、Web画面について部品をぺたぺた貼りながら作成していくようなイメージを持つと良いかもしれません。

以下参考にさせていただきました。 www.cloudbuilders.jp aws.amazon.com

ノーコードのUIビルダーでステップバイステップガイドを作成してみる

画面を作っていきたいと思います。

ビューの新規作成

Amazon Connectにログインし、左のメニューから「フロー」をクリック。

「ビュー」タブを選択し、右上の「ビューを作成」をクリック。

ビューの編集画面に移動します。
ビューに対して適当な名前を付けておきます。今回は「test-step-by-step-nocode」としました。

ビューの編集

ビューを編集していきます。

画面部品の選択を左側のメニューで行います。
「ライブラリ」に画面部品が、「テンプレート」に画面のテンプレートが用意されています。
右側には「プロパティ」「スタイル」といった各部品のレイアウトや値の設定が用意されています。


ライブラリ、画面部品の一覧
・General
・Form
・Container
・Media

今回は簡単なフォーム画面を作成したく、ライブラリの「Form」からフォームの入力関連の部品をドラッグアンドドロップして、配置していきます。
配置した各部品の位置の入れ替えもドラッグアンドドロップで対応可能であり、直観的に操作することができました。

続いてプロパティ、スタイルの2つを設定していきます。
ボタンやラジオボタンの値を変更してみました。

レイアウト指定もできます。


作成が完了したら右上の「公開」をクリックしてビューを公開します。

作成したステップバイステップガイドの画面を映してみる

手順

ステップバイステップガイドの画面を表示する手順は大まかに以下となります。

①ステップバイステップガイドのデザインを考える(ビュー作成、ノーコードUIビルダーが使えます!)
②ステップバイステップガイドのビュー表示用のフローを作成します(部品としてビューの表示を選択)
③ビュー表示用フローの内容を考える
④着信フローを作成し、電話番号と紐づけ
⑤着信フローにステップビュー表示フローを組み込む
⑥Amazon Connectにてエージェントワークスペースを開いておく
⑦電話
⑧エージェントワークスペースにて電話を受け取った際にステップバイステップガイドが表示される


サンプル

試しに私が作成したフローが以下になります。
着信フロー

・「イベントフローの設定」にて、ビュー表示用のフローを呼び出しています。

ビュー表示用フロー


・「ビューを表示」にて、作成した「test-step-by-step-nocode」ビューを指定。
・試しに1画面だけ表示したかったため、ループをすることで対応しています。

参考 dev.classmethod.jp

フローができたら公開し、「電話番号」から番号とフローの紐づけをします。
次に画面上の「エージェント Workspace」をクリックして、Amazon Connect側でエージェントワークスペースを立ち上げたます。

画面左上のプルダウンにて「Offline」⇒「Avaliable」とします。


電話してみます。


作成したビューが表示されました。

今回の検証で、ステップバイステップガイドそのものに興味が出たので、
動的な値を次回は使ってみたり、ある程度シナリオを考えて複数画面で構成してみたりとやってみたいです。

おわりに

弊社はAWSアドバンスドティアサービスパートナー認定を受けております。
また以下のようにAWSの活用を支援するサービスも行っているので、何かご相談したいことがあればお気軽にご連絡ください。

www.ap-com.co.jp

また、一緒に働いていただける仲間も募集中です!
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp

【AWS】AWS Certified DevOps Engineer - Professional(DOP-C02) を受けてみて

はじめに

こんにちは。クラウド事業部の早房です。
AWS Certified DevOps Engineer - Professional(DOP-C02) を受験し無事に合格しました。
受験に至ったきっかけや実際の試験の感想について綴ります。

出題範囲と割合について

出題範囲と割合は以下です。

• 第 1 分野: SDLC のオートメーション (採点対象コンテンツの 22%)
• 第 2 分野: 設定管理と IaC (採点対象コンテンツの 17%)
• 第 3 分野: 耐障害性の高いクラウドソリューション (採点対象コンテンツの 15%)
• 第 4 分野: モニタリングとロギング (採点対象コンテンツの 15%)
• 第 5 分野: インシデントとイベントへの対応 (採点対象コンテンツの 14%)
• 第 6 分野: セキュリティとコンプライアンス (採点対象コンテンツの 17%)

参考 : https://d1.awsstatic.com/ja_JP/training-and-certification/docs-devops-pro/AWS-Certified-DevOps-Engineer-Professional_Exam-Guide.pdf

受験に至ったきっかけ

  • AWS 認定資格をコンプリートしたい
  • 業務で Code シリーズを扱っており試験内容とマッチしており、業務で学んだことを試験に活かしたい & 試験勉強で学んだことを業務に持ち帰りたい

参考にしたサイトなど

  • AWS CI/CD workshop

catalog.us-east-1.prod.workshops.aws

  • AWS Certified DevOps Engineer - Professional 公式練習問題集

explore.skillbuilder.aws

  • 参考記事など

zenn.dev

qiita.com

zenn.dev

結果

合格 (880点)

まとめ・感想など

業務で扱っているサービス中心の出題であり、なおかつ SAP や Security/DataBase の知識が前提としてあったため皆目見当がつかない問題は数問程度でした。
参考になるブログ記事も沢山あったので効率よく学習できたかなと思います。 実際に試験については、SAP よりも文章量は少なめ、難易度も易しく感じました。それでも 75 問ぶっ通しで解くのは疲れます。

試験勉強を始めるまでは Code シリーズの区別すら付かなかったものの、試験が終わった今ではそれぞれの役割をはっきりと区別できるようになりました。
出題範囲に含まれるサービスの中では「Amazon CodeGuru Reviewer」が面白そうだなと思いました。機会があったら使ってみたいですね。

zenn.dev

毎度のことですが無事に合格できてホッとしました。これでAWS認定資格は合計 6 つ取得することができました。(SAA,SAP,SCS,SOA,DBS,DOP)
次は MLS 辺りの受験を視野に入れて引き続き学習を進めたいです。
料金改定の前に可能な限り合格しておきたい。。。

techblog.ap-com.co.jp

おまけ

今後 DAS,PAS,DBS が廃止になり、ベータ版として提供されていた AWS Certified Data Engineer – Associate (DEA) が正式リリースになるとのこと。
リリース時期についてはまだ発表されていないようです。

aws.amazon.com

※修正
正式リリースは 2024 年 4 月。試験登録は 2024 年 3 月から可能とのこと。
aws.amazon.com

ベータバージョン後の標準バージョンの試験の登録は 2024 年 3 月に開始され、2024 年 4 月から受験できるようになります。

おわりに

弊社はAWSアドバンスドティアサービスパートナー認定を受けております。
また以下のようにAWSの活用を支援するサービスも行っているので、何かご相談したいことがあればお気軽にご連絡ください。

www.ap-com.co.jp

また、一緒に働いていただける仲間も募集中です!
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp

本記事の投稿者: hybs_yuuuu
AWSをメインにインフラ系のご支援を担当しています。 https://www.credly.com/users/hybs_yuuuu/badges

AWS Control Tower の Account Factory で作成した AWS アカウントに Microsoft Entra ID (旧 Azure AD) ユーザーでシングルサインオンする!(AWS アカウント作成編)

はじめに

こんにちは。クラウド事業部の早房です。
前回に引き続き、AWS Control Tower の Account Factory で作成した AWS アカウントに Microsoft Entra ID (旧 Azure AD) ユーザーでシングルサインオンする!という内容で記事を書きます。
本記事では、Control Tower の機能である Account Factory を使用して AWS アカウントを作成します。

これまでの記事は以下をご参照ください。

  • ランディングゾーンセットアップ

AWS Control Tower の Account Factory で作成した AWS アカウントに Microsoft Entra ID (旧 Azure AD) ユーザーでシングルサインオンする!(ランディングゾーンセットアップ編) - APC 技術ブログ

  • ユーザー同期編

AWS Control Tower の Account Factory で作成した AWS アカウントに Microsoft Entra ID (旧 Azure AD) ユーザーでシングルサインオンする!(ユーザー同期編①) - APC 技術ブログ

AWS Control Tower の Account Factory で作成した AWS アカウントに Microsoft Entra ID (旧 Azure AD) ユーザーでシングルサインオンする!(ユーザー同期編②) - APC 技術ブログ

AWS Control Tower の Account Factory で作成した AWS アカウントに Microsoft Entra ID (旧 Azure AD) ユーザーでシングルサインオンする!(ユーザー同期編③) - APC 技術ブログ

1. 目次

  1. 目次
  2. 全体の作業フローと本記事での作業箇所の確認
  3. 前提条件
  4. 作業完了条件
  5. 作業手順
  6. 参考情報

2. 全体の作業フローと本記事での作業箇所の確認

①AWS Control Tower のランディングゾーンセットアップ (完了) ②Microsoft Entra ID → AWS へのユーザー同期 (完了) ③Account Factory での AWS アカウント作成 (本記事) ④作成したAWSアカウントへのアクセス権の設定

3. 前提条件

  • AWS IAM Identity Center - Microsoft Entra ID ユーザー同期_3 が完了していること。
  • 作成するアカウントのメールアドレスが払い出されていること。
  • ランディングゾーンをセットアップしたユーザーでの作業が可能であること。

    別のユーザーでの作業を実施する場合は以下「3-1.Service Catalog ポートフォリオの権限付与」の手順を実施し、Service Catalog ポートフォリオの権限を付与してください。

3.1 Service Catalog ポートフォリオの権限付与 (必要な場合)

  1. 管理アカウントの AWS マネジメントコンソールにログイン後、検索窓に「service catalog」と入力し、Service catalog をクリックします。

  2. ローカルポートフォリオ内の「AWS Control Tower Account Factory Portfolio」をクリックします。

  3. アクセスタブ内の「アクセス権の付与」をクリックします。

  4. IAM Principal を選択、ユーザータブ内の作業を行うユーザーにチェックを入れ、「アクセス権を付与」をクリックします。

  5. アクセス権の付与が正常に完了したことを確認します。

4. 作業完了条件

Account Factory 上で OU およびアカウントの作成ができること。

5. 作業手順

5-1. OU の作成

  1. 管理アカウントの AWS マネジメントコンソールにログイン後、検索窓に「control tower」と入力し、Control Tower をクリックします。

  2. 左ペインより「組織」をクリックします。

  3. 「リソースを作成」から「組織単位を作成」をクリックします。

  4. 任意の OU 名、親 OU を選択し「追加」をクリックします。親 OU には ルート OU もしくは 既に Control Tower に登録済みの OU を指定することが可能です。

  5. OU の作成と AWS Control Tower への OU の登録が開始されます。

  6. OU の作成と登録が完了し、状態が「登録済み」となっていることを確認します。

5-2. アカウントの作成  

  1. 管理アカウントの AWS マネジメントコンソールにログイン後、検索窓に「control tower」と入力し、AWS Control Tower のコンソール画面を表示します。

  2. 左ペインより「Account Factory」をクリックします。

  3. 「アカウント作成」をクリックします。

  4. 以下の項目を入力し、「アカウントの作成」をクリックします。
    ・アカウントの詳細
     ・アカウント E メール : 新規アカウント用の E メールアドレス
     ・表示名 : アカウントの名前・表示名
    ・アクセス設定
     ・IAM Identity Center ユーザーの E メール : 管理アカウントの E メールアドレス
     ・IAM Identity Center のユーザー名 (名) : Admin
     ・IAM Identity Center のユーザー名 (姓) : AWS Control Tower
    ・組織単位 : アカウントを所属させる OU

  5. 作成リクエストが正常に送信されることを確認し、AWS Service Catalog コンソールを開きます。

  6. アカウントのプロビジョニングが成功することを確認します。(所要時間 : 約 15 分)

  7. AWS Control Tower コンソールの組織内より、プロビジョニングしたアカウントが登録済みであることを確認します。

6. 参考情報

まとめ

今回は Account Factory で AWS アカウント を作成する様子をご紹介しました。
次回は作成した AWS アカウントへシングルサインオンするためのアクセス権限セットの作成などの設定についてご紹介します。

おわりに

弊社はAWSアドバンスドティアサービスパートナー認定を受けております。
また以下のようにAWSの活用を支援するサービスも行っているので、何かご相談したいことがあればお気軽にご連絡ください。

www.ap-com.co.jp

また、一緒に働いていただける仲間も募集中です!
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp

本記事の投稿者: hybs_yuuuu

https://www.credly.com/users/hybs_yuuuu/badges

AWS アカウントに Google Workspace ユーザーでシングルサインオンしてみた。(part2)

はじめに

こんにちは。エーピーコミュニケーションズ クラウド事業部の髙野です。

本記事ではGoogle Workspace ユーザーを IAM Identity Center ユーザーとしてAWS 環境に同期するための手順を紹介します。 なお、今回の内容は少しボリュームがあるので本記事を含め3つの記事に分けて投稿しており、本記事が2つ目の記事です。 1つ目の記事は以下を参照してください。

techblog.ap-com.co.jp

本記事で紹介している手順は以下を参考に記載しております。

docs.aws.amazon.com

前提条件

AWS アカウントに Google Workspace ユーザーでシングルサインオンしてみた。(part1) に記載の手順を実施済みであること。

目次

  1. AWS のカスタムユーザー属性を作成する
  2. ID プロバイダーのメタデータをダウンロードする
  3. Google Workspace で Amazon Web Services アプリをセットアップする
  4. IAM Identity Center の ID ソースを変更し、Google Workspace を SAML ID プロバイダーとして設定する
  5. Google Workspace でアプリを有効にする★
  6. IAM Identity Center の自動プロビジョニングを設定する★
  7. Google Workspace で自動プロビジョニングを設定する★
  8. IAM Identity Center グループを作成する
  9. Google Workspace ユーザーをIAM Identity Center グループに追加する
  10. IAM Identity Center グループ にアカウントへのアクセス権を付与する
  11. Google Workspace ユーザーの AWS リソースへのアクセスを確認する

※本記事では手順5から手順7を取り扱います。後続の手順については次回以降の記事で紹介します。

手順

5.Google Workspace でアプリを有効にする

5-1.Google管理コンソールの左側のナビゲーションパネルで、[アプリ] を展開し、[ウェブアプリとモバイルアプリ] を選択します。

5-2.アプリのリストで、Amazon Web Servicesを選択して、アプリの詳細ページを開きます。

5-3.[ユーザーアクセス]パネルで、[ユーザーアクセス] の横にある下矢印を選択して [ユーザーアクセス] を展開し、[サービスステータス] パネルを表示します。

5-4.[サービスのステータス] で [オン(すべてのユーザー)] を選択し、[保存] を選択します。

5-5.AWS access portalを選択して、アプリの詳細ページを開きます。

5-6.[ユーザーアクセス] パネルで、[ユーザーアクセス] の横にある下矢印を選択して [ユーザーアクセス] を展開し、[サービスステータス] パネルを表示します。

5-7.[サービスのステータス] で [オン(すべてのユーザー)] を選択し、[保存] を選択します。

6.IAM Identity Center 自動プロビジョニングをセットアップする

6-1.管理者権限を持つロール又はユーザーで IAM Identity Center コンソール にサインインします。

6-2.[設定] ページで、[自動プロビジョニング情報] ボックスを見つけて、[有効にする]を選択します。

これにより、IAM Identity Center での自動プロビジョニングがすぐに有効になり、必要な SCIM エンドポイントとアクセストークンの情報が表示されます。

6-3.[インバウンド自動プロビジョニング] ダイアログボックスで、次のオプションの各値をコピーします。

  • SCIM エンドポイント
  • アクセストークン

6-4.[閉じる] を選択します。

7.Google Workspace で自動プロビジョニングを構成する

7-1.Google管理コンソールの左側のナビゲーションパネルで、[アプリ] を展開し、[ウェブアプリとモバイルアプリ] を選択します。

7-2.アプリのリストで、Amazon Web Servicesを選択します。

7-3.[自動プロビジョニング] セクションで、[自動プロビジョニングを設定] を選択します。

7-4.手順6-3でコピーしたアクセストークンの値を Google Workspace の[アクセストークン] フィールドに貼り付け、[続行] を選択します。

7-5.手順6-3でコピーしたSCIMエンドポイントの値を Google Workspace の [エンドポイントURL] フィールドに貼り付け、URLの末尾にあるスラッシュを削除し、[続行] を選択します。

7-6.すべての必須の IAM Identity Center 属性が Google Cloud Directory 属性にマッピングされていることを確認し、[続行] を選択します。

マッピングされていない必須項目がある場合は、下矢印を選択して、適切な属性にマップします。

7-7.Google Workspace ディレクトリを持つグループを選択して、Amazon Web Servicesへのアクセスを提供できます。この手順をスキップして、[続行] を選択します。

7-8.プロビジョニング解除では、状況ごとにプロビジョニング解除が開始されるまでの時間を指定できます。[完了] を選択します。

Amazon Web Servicesのページに戻ります。

7-9.[自動プロビジョニング] セクションで、トグルスイッチをオンにして、[無効] から [有効] に変更します。

7-10.確認ダイアログボックスで、[有効にする] を選択します。

7-11.IAM Identity Center コンソールに戻り、 [ユーザー] を選択します。[ユーザー] ページには、SCIM によって作成された Google Workspace ディレクトリのユーザーがリストされます。ユーザーが IAM Identity Center に正常に同期されていることを確認します。

ユーザーがまだリストされていない場合は、プロビジョニングがまだ進行中である可能性があります。プロビジョニングには最大24時間かかる場合がありますが、ほとんどの場合は数分以内に完了します。数分ごとにブラウザウィンドウを更新してください。

まとめ

これで、Google Workspace と AWS 間の SAML 接続が正常に設定され、自動プロビジョニングが機能していることを確認できました。

次回はIAM Identity Center に同期されたユーザーをIAM Identity Center グループに追加してAWSアカウントへのアクセス許可を実施します。

techblog.ap-com.co.jp

お知らせ

弊社はAWSアドバンスドティアサービスパートナー認定を受けております。また以下のようにAWSの活用を支援するサービスも行っているので、何かご相談したいことがあればお気軽にご連絡ください。

www.ap-com.co.jp

一緒に働いていただける仲間も募集中です!
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp

本記事の投稿者: sk07103
AWSをメインにインフラ系のご支援を担当しています。

AWS Control Tower の Account Factory で作成した AWS アカウントに Microsoft Entra ID (旧 Azure AD) ユーザーでシングルサインオンする!(ユーザー同期編③)

はじめに

こんにちは。クラウド事業部の早房です。
本記事では、Microsoft Entra ID 上のユーザーを IAM Identity Center ユーザーとして AWS 環境に同期するための方法をご紹介します。

IAM Identity Center ユーザーとは?

【AWS】【初心者】IAM Identity Center とは?IAM Identity Center ユーザーって何者? - APC 技術ブログ

なおユーザー同期編はボリュームがあるので本記事も含め 3 つの記事に分けて投稿しており、本記事が3つ目の記事です。
これまでの記事は以下を参照ください。

前々回
techblog.ap-com.co.jp

前回
techblog.ap-com.co.jp

1. 目次

  1. 目次
  2. 全体の作業フローと本記事での作業箇所の確認
  3. 前提条件
  4. 作業完了条件
  5. 作業手順
  6. 参考情報

2. 全体の作業フローと本記事での作業箇所の確認

①AWS Control Tower のランディングゾーンセットアップ
②Microsoft Entra ID → AWS へのユーザー同期
③Account Factory での AWS アカウント作成
④作成したAWSアカウントへのアクセス権の設定
といったフローで作業を進めていきます。

本投稿の作業範囲は「Microsoft Entra ID → AWS へのユーザー同期 」です。

3. 前提条件

AWS Control Tower の Account Factory で作成した AWS アカウントに Microsoft Entra ID (旧 Azure AD) ユーザーでシングルサインオンする!(ユーザー同期編②) に記載の手順を実施済みであること。

4. 作業完了条件

Microsoft Entra ID 内のユーザーが IAM Identity Center ユーザーとして同期されること。

5. 作業手順

5-1. エンタープライズアプリケーションの設定 (Azure)

  1. Microsoft Entra ID 内のエンタープライズアプリケーションページの左ペインより「プロビジョニング」をクリックします。

  2. 「作業の開始」をクリックします。

  3. AWS IAM Identity Center で控えた SCIM エンドポイント、アクセストークンを用意します。テナントの URL にSCIM エンドポイントを、シークレットトークンにアクセストークンを入力し、「接続テスト」をクリックします。

  4. 接続テストが正常に完了したことを確認します。

  5. 「保存」をクリックします。

  6. マッピング内の「Provision Azure Active Directory Users」をクリックします。

  7. 属性マッピング内より、「givenName」をクリックします。

  8. null の場合の規定値 (オプション) に「givenName」と入力し、「OK」をクリックします。

  9. 属性マッピング内より、「surname」をクリックします。

  10. null の場合の規定値 (オプション) に「surname」と入力し、「OK」をクリックします。

  11. 「保存」をクリックし、確認画面で「はい」をクリックします。

  12. 設定の保存が正常に完了したことを確認します。

  13. 左ペインより「ユーザーとグループ」をクリックします。

  14. 「ユーザーまたはグループの追加」をクリックします。

  15. AWS アカウントへの SSO に使用したいユーザーやグループにチェックを入れ「選択」をクリックします。

  16. 「割り当て」をクリックします。

  17. 割り当てが正常に完了したことを確認します。

5-2. ユーザーの同期

  1. 左ペインより「概要」をクリックします。

  2. 「プロビジョニングの開始」をクリックします。

  3. 「更新」をクリックし、初期サイクルが完了したことを確認します。(処理が完了するまで時間を要する場合があるため、何度か更新をします。)

  4. AWS マネジメントコンソールを開き、IAM Identity Center 内左ペインより「ユーザー」をクリックします。

  5. エンタープライズアプリケーションに割り当てたユーザーが同期されていることを確認します。
    ※「表示名 : AWS Control tower Admin」 として管理アカウントのアドレスが追加されますが、正常な動作であるため問題ありません。

6. 参考情報

  • チュートリアル: Microsoft Entra SSO と AWS IAM Identity Center の統合

learn.microsoft.com

  • 外部 ID プロバイダーConnect する

docs.aws.amazon.com

まとめ

これで Microsoft Entra ID 上のユーザーを IAM Identity Center 上に同期することができました。
ハマりポイントは属性マッピングで、givenName と surName (苗字と名前) が null の場合に既定の値を指定するところでした。
Azure 側では任意の値であるものの AWS 側では必須の項目なので、値が入っていないと正常に同期できないので注意です。

次回は AWS Control Tower 内の機能である Account Factory を使用して、シングルサインオン先の AWS アカウントを作成する様子をご紹介します。

おわりに

弊社はAWSアドバンスドティアサービスパートナー認定を受けております。
また以下のようにAWSの活用を支援するサービスも行っているので、何かご相談したいことがあればお気軽にご連絡ください。

www.ap-com.co.jp

また、一緒に働いていただける仲間も募集中です!
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp

本記事の投稿者: hybs_yuuuu

https://www.credly.com/users/hybs_yuuuu/badges