Quantcast
Channel: 技術 –サーバーワークスエンジニアブログ
Viewing all 1210 articles
Browse latest View live

OneLoginからWorkSpacesへログインが可能になりました

$
0
0

宮澤です。

今回は、Amazon WorkSpacesのコネクタを利用して、OneLoginからサインインする手順を紹介します。
OneLoginからWorkSpacesにログインする場合は、事前にWorkSpacesのWebアクセスが有効になっている必要があります。

OneLogin側でコネクタの作成

OneLoginに管理者でログインし”APPS > Add Apps”を選択します。

検索欄に”WorkSpaces”と入力して検索を行い、表示された”Amazon WorkSpace”を押します。

OneLogin上の表示名を設定し”SAVE”を押します。

“Parameters”タブからWorkSpacesにログインさせるための情報を、以下の内容を確認し設定します。

Configured by end-users 利用するエンドユーザー自身がID/パスワード/Registration CodeをOneLoginに設定
Configured by admin 管理者が、エンドユーザーのID/パスワード/Registration CodeをOneLoginに設定
Configured by admins and shared by all users 管理者が設定した一意のがID/パスワード/Registration CodeをOneLogin設定して、エンドユーザーが共有して利用
Password WorkSpacesへログインするためのパスワード
Registration WorkSpacesのRegistration Code
Username WorkSpacesへログインするためのログインID

最後に”Access”タブから該当ユーザーが利用している”ロール”を選択して”SAVE”を押します。

動作確認

OneLoginのユーザー画面から、作成したWorkSpacesのコネクタを選択します。

自動的にレジストレーションコードが入力されます。

設定されたID/パスワードが入力されます。

その後、WorkSpacesにログインがされます。


RDS for Oracleの初期化パラメータを確認する(sessions,processes,memory_target)

$
0
0

技術4課の渡辺です。
最近、OracleデータベースをRDS for Oracleへ移行する案件を担当することが増えてきました。
そこで「パラメータ何にしましょう?」という話になり、「RDSのデフォルト値ってどうなってるの?」となることが多くあります。

調査対象

  • DBエンジンはOracle Standard Edition Two 12.1.0.2.v12
  • db.m4ファミリー(db.m4.large、db.m4.xlarge、db.m4.2xlarge、db.m4.4xlarge)
  • パラメータグループの中のよく聞かれる3つのパラメータ(sessions、processes、memory_target)

まず結果

ParameterName db.m4.large db.m4.xlarge db.m4.2xlarge db.m4.4xlarge
sessions 1262 2548 5120 10256
processes 827 1683 3397 6823
memory_target 5840M 11904M 24000M 48256M

使用するインスタンスクラスによって、値が異なります。
結果を見れば、メモリサイズに比例して各パラメータが増えているのがわかりますね。

どう調査したか

地道に以下のようなコマンドで確認していきました。

SQL> show parameters memory_target

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
memory_target big integer 24000M

各パラメータについて

ParameterName デフォルト値  意味
sessions    
processes LEAST({DBInstanceClassMemory/9868951}, 20000) DBInstanceClassMemory/9868951と20000のうちの小さい方が使用される
memory_target IF({DBInstanceClassHugePagesDefault}, 0, {DBInstanceClassMemory*3/4}) DBInstanceClassHugePagesDefaultが無効の場合、DBInstanceClassMemoryの3/4。

パラメータグループをみて見ると、デフォルト値が空白だったり、式が入っています。

DBInstanceClassHugePagesDefault

今回確認するインスタンスクラスは、DBInstanceClassHugePagesDefaultはデフォルトで無効です。
Oracle DB インスタンスで huge pages を使用する

DBInstanceClassMemory

現在の DB インスタンスに関連付けられている DB インスタンスクラスに割り当てられたメモリから、インスタンスを管理する Amazon RDS プロセスによって使用されるメモリを引いたバイト数を返します。
DB パラメータグループを使用する

ところで、人材募集中らしい

私はオンプレではOracle経験がなく、AWSの移行案件で初めてOracleを触るようになりました。
ぜひ、Oracleが得意なエンジニアにJoinしていただき助けていただければと思っています。
オンプレでOracleやっていたけど、AWSにも興味あるという方、サーバーワークスに入れば活躍できるかもしれません。

AWS Batch のジョブ結果を SNS で通知する

$
0
0

CloudWatch Events で AWS Batch のステータス変更をキャッチできたんですね。

こんにちは、技術一課の山中です。
AWS Batch のジョブが成功したのか失敗したのかメールで受け取りたいときってありますよね?

Before

これまではジョブを実行したと同時に 1 分おきに list_jobs を呼び出す Lambda ファンクションを起動してステータスチェックを行っていました。
ステータスが成功(SUCCEEDED)または失敗(FAILED)に変わるとそれを SNS 経由でメールにて通知します。

After

今回、もっといい方法ないかなと考えていたところ、以下のページを発見しました。

チュートリアル: 失敗したジョブイベントに関する Amazon Simple Notification Service アラートを送信する

これでええやん!

ということで、以下構成にて作り直すことにしました。

実行結果確認用の Lambda を 1 分おきに起動する必要がなく、すっきりした構成ですね。

結果通知用の Lambda ファンクション作成

今回 Lambda ファンクションは Python で作成します。
CloudWatch Events から Lambda ファンクションの event パラメタには以下のような値が入ってきます。

{
    'version': '0',
    'id': '195122c5-bfae-b13b-9bca-7889ddbe73e7',
    'detail-type': 'Batch Job State Change',
    'source': 'aws.batch',
    'account': '000000000000',
    'time': '2018-09-06T09:54:17Z',
    'region': 'ap-northeast-1',
    'resources': [
        'arn:aws:batch:ap-northeast-1:000000000000:job/955c6177-3594-429c-b747-29be36936852'
    ],
    'detail': {
        'jobName': 'job_20180906185213',
        'jobId': 'xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx',
        'jobQueue': 'arn:aws:batch:ap-northeast-1:000000000000:job-queue/sample-queue',
        'status': 'SUCCEEDED',
        'attempts': [
            {
                'container': {
                    'containerInstanceArn': 'arn:aws:ecs:ap-northeast-1:000000000000:container-instance/ed94df41-6d11-4407-b41c-e5d1048b6e53',
                    'taskArn': 'arn:aws:ecs:ap-northeast-1:000000000000:task/e7a0be6d-31b6-4091-891c-119d8a7916c7',
                    'exitCode': 0,
                    'logStreamName': 'sample-job-definition/default/e7a0be6d-31b6-4091-891c-119d8a7916c7'
                },
                'startedAt': 1536227653907,
                'stoppedAt': 1536227655513,
                'statusReason': 'Essential container in task exited'
            }
        ],
        'statusReason': 'Essential container in task exited',
        'createdAt': 1536227533583,
        'retryStrategy': {
            'attempts': 1
        },
        'startedAt': 1536227653907,
        'stoppedAt': 1536227655513,
        'dependsOn': [],
        'jobDefinition': 'arn:aws:batch:ap-northeast-1:000000000000:job-definition/sample-job-definition:3',
        'parameters': {},
        'container': {
            'image': '000000000000.dkr.ecr.ap-northeast-1.amazonaws.com/sample',
            …

よって、 Lambda ファンクションで以下のように status を取得しこれを SNS に投げさえすればステータスのメール通知ができます。

def main(event, context):
    status = event['detail']['status']

イベントルールの登録

今回は FAILED だけでなく SUCCEEDED も通知したいので、以下のようにイベントパターンを登録し、チェック用の Lambda ファンクションをターゲットとして登録します。

{
  "detail-type": [
    "Batch Job State Change"
  ],
  "source": [
    "aws.batch"
  ],
  "detail": {
    "status": [
      "SUCCEEDED",
      "FAILED"
    ]
  }
}

以上で設定は完了です。
あとは、いつもどおり AWS Batch にてジョブを実行してみてください。
ステータスが SUCCEEDED または FAILED に変わった際にほぼリアルタイムで Lambda が起動するはずです!

おわり

今回はメール本文を編集するためにイベントルールのターゲットとして Lambda を指定しましたが、直接 SNS を指定することも可能です。
今まで気づかなかったのが悔やまれるくらい、すごく便利ですね!

WindowsのWorkSpacesクライアントでデバイス認証

$
0
0

こんにちは、技術4課の城です。
WorkSpacesの接続元を制限する方法の一つとして、Windows、Macのクライアントについては、デバイス認証が用意されています。
Windows端末にて作業を実施する際に必要なことについて、記載します。

やること

AWSドキュメントを参考に下記を実施します。

  • ルート証明書、クライアント証明書の用意
  • ルート証明書のインポート(AWSマネジメントコンソール)
  • クライアント証明書のインポート(ローカル端末)

環境

OpenSSLはStoreでインストールしたUbuntu 16.04のOpenSSLを利用します。

事前確認

ubuntuを起動し、opensslがインストール済みであることを確認します。

openssl version

【結果例】

OpenSSL 1.0.2g  1 Mar 2016

※インストールされていない場合はインストールします。

sudo apt-get install openssl

作業用ディレクトリの作成

mkdir -p ~/workspaces/CA/{newcerts,client}

コンフィグの変更

sudo vi /etc/ssl/openssl.cnf

デフォルトのディレクトリを変更しておきます。
[ CA_default ]セクション
dir             = ./demoCA
↓
dir             = /home/【ユーザー名】/workspaces/CA

自己認証局の作成

シリアルとインデックスファイルの作成

cd ~/workspaces/CA
echo 01 > serial
touch index.txt

自己認証局(CA)の秘密鍵(cakey.pem)、証明書(cacert.pem)の作成

sudo openssl req \
  -x509 \
  -days 3650 \
  -newkey rsa:2048 \
  -keyout cakey.pem \
  -out cacert.pem \
  -subj "/C=JP/ST=Tokyo/O=Serverworks/CN=jo-workspaces-ca"

対話式にて入力していきます。任意の秘密鍵のパスフレーズを入力します。
Generating a 2048 bit RSA private key
.........................+++
.+++
writing new private key to 'private/cakey.pem'
Enter PEM pass phrase: 【任意のパスフレーズを入力】
Verifying - Enter PEM pass phrase: 【パスフレーズの再入力】
-----

クライアント証明書の作成

秘密鍵(client.key)の作成

cd client
sudo openssl genrsa -out client.key 2048

署名要求(CSR)の作成

sudo openssl req \
  -new \
  -key client.key \
  -out client.csr \
  -sha256

対話式にて入力していきます。下記は例です。
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:JP
State or Province Name (full name) [Some-State]:Tokyo
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Serverworks
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:jo-workspaces
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

CSRへの署名に利用するコンフィグの作成

cp /etc/ssl/openssl.cnf .
vi openssl.cnf

[ usr_cert ]セクション
下記、追加
keyUsage = critical,nonRepudiation, digitalSignature, keyEncipherment,dataEncipherment
extendedKeyUsage = clientAuth

下記行をコメントアウト
nsComment = "OpenSSL Generated Certificate"

CSRへの署名

sudo openssl ca \
  -config openssl.cnf \
  -keyfile ~/workspaces/CA/cakey.pem \
  -cert ~/workspaces/CA/cacert.pem \
  -in client.csr \
  -out client.crt

対話式にて入力していきます。
Using configuration from openssl.cnf
Enter pass phrase for /home/kotajo/workspaces/CA/cakey.pem: 【秘密鍵のパスフレーズを入力】
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 1 (0x1)
        Validity
            Not Before: Sep  9 13:42:36 2018 GMT
            Not After : Sep  9 13:42:36 2019 GMT
        Subject:
            countryName               = JP
            stateOrProvinceName       = Tokyo
            organizationName          = Serverworks
            commonName                = jo-workspaces
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
            X509v3 Subject Key Identifier:
                4B:F0:A3:F6:B5:FE:E6:EE:03:0E:1B:C8:49:28:C3:50:A5:5F:0B:70
            X509v3 Authority Key Identifier:
                keyid:A7:B6:0F:DF:AC:E9:25:31:10:EE:95:C6:30:62:25:C2:BC:7F:0E:34

            X509v3 Extended Key Usage:
                TLS Web Client Authentication
Certificate is to be certified until Sep  9 13:42:36 2019 GMT (365 days)
Sign the certificate? [y/n]:y


1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

標準だと証明書の期限が1年なので、延長したい場合は -daysオプションや openssl.cnfの設定変更で対応します。

インストール用クライアント証明書(client.p12)の作成

sudo openssl pkcs12 \
  -export \
  -in client.crt \
  -inkey client.key \
  -certfile ~/workspaces/CA/cacert.pem \
  -name 'jo workspaces client cert' \
  -caname jo-workspaces-ca \
  -out client.p12

パスワードなしで作成する場合はそのままEnterでOKです。
Enter Export Password:
Verifying - Enter Export Password:

ルート証明書のインポート(AWSマネジメントコンソール)

WorkSpacesのダッシュボードにて[Directory]をクリックします。
対象のDirectory Serviceを選択し、[アクション] > [詳細の更新]とクリックします。

[アクセス制御のオプション]を展開します。

「信頼された Winodws デバイスのみに WorkSpaces へのアクセスを許可」にチェックし、[インポート]をクリックします。

cacert.pemの内容を貼り付け、[インポート]をクリックします。

[更新と終了]をクリックします。

アクセス確認(拒否されること)

アクセス確認をします。
クライアント証明書をインストールしていないため、アクセスできません。

クライアント証明書のインポート(ローカル端末)

作成したclient.p12をローカル端末にて実行します。

証明書のインポートウィザードが開きますので、そのまま[次へ]をクリックします。

インポートする証明書ファイルについても、そのまま[次へ]をクリックします。

秘密キーの保護についても、そのまま[次へ]をクリックします。

証明書ストアは「信頼されたルート証明機関」を選択し、次へをクリックします。

自己認証局なので、セキュリティ警告が出ます。[はい]をクリックします。

[完了]をクリックします。

アクセス確認

WorkSpacesクライアントを起動し、アクセスします。

アクセスできました!!

終わりに

今さらながらではありますが、デバイス認証の手順についてまとめてみました。
どなたかの助けになれば、幸いです。

WorkSpacesのデバイス認証とWebアクセスの関係について

$
0
0

こんにちは、技術4課の城です。
つい先日、WorkSpacesの日本語OSについてもWebアクセスが可能になりました
Webアクセスとデバイス認証との関係はどうなるのだろう?という疑問を検証してみました。

結論から

検証してみた結果、Webアクセスはデバイス認証を行っていても制限されません。
FAQにも記載がありました。

Q: デジタル証明書を使用して、iOS、Android、Chrome OS、またはゼロクライアントから Amazon WorkSpaces のアクセスを制御できますか?

現時点では、Amazon WorkSpaces は、MacOS と Microsoft Windows のクライアントデバイスでのみデジタル証明書を使用できます。

以下、検証内容になります。

デバイス認証とWebアクセスの設定

デバイス認証の設定をクライアント証明書のインストールを除いて、実施します。
また、Webアクセスについても設定します。

デバイス認証の設定手順については、下記ブログをご参考ください。

WindowsのWorkSpacesクライアントでデバイス認証

WorkSpacesクライアントからのアクセス確認(拒否されること)

WorkSpacesクライアントからアクセス確認をします。
アクセスできないことを確認します。

Webアクセスでのアクセス確認

Webアクセスから確認してみます。
https://clients.amazonworkspaces.com/webclient#/main

アクセス可能でした。

Androidクライアントからも試しにやってみます

こちらもアクセス可能なようです。

さいごに

FAQに記載のとおり、デバイス認証はWindows及びMacOSからのみ制限可能なようです。
その他のアクセスを許可すると、想定外のアクセスとなることも考えられるので適切に設定すべきところかと思います。
どなたかの助けになれば、幸いです。

[New] Systems Manager Session Manager – SSH/RDPが不要になる(かもしれない)新機能の話

$
0
0

こんにちは。マネージドサービス課の橋本です。

本日、New – AWS Systems Manager Session Manager for Shell Access to EC2 Instances というリリース記事の発表がありました。私の課内でもちょっとしたニュースになっており、軽く触ってみましたので簡単にご報告します。

どのような機能なのか

SSMエージェントを介してEC2インスタンスにリモート接続を行えるようにする機能です。この機能を使ってリモート接続を行う前提ならば、煩わしい踏み台サーバーも撤去できる可能性があります。

リモートアクセスの方法は、マネジメントコンソールのSystems Managerの画面から、もしくはお手元のAWS CLIを介してかの2通りがあります。

Linux/Windowsともに対応しています。Linuxであればbash、WindowsであればPowerShell環境が利用できます。

どのようなメリットがあるか

これまでのオペレーションでは、オペレーターがEC2インスタンスの中で作業を行うためには作業拠点からのインバウンドアクセスを許可する必要がありました。

この従来方式に対して、Session ManagerではSSM AgentからSystems Manager エンドポイントへの通信によってセッションを確立します。そのため、セキュリティグループのインバウンドルールを開ける作業は不要になります。「作業を行うため一時的にファイアウォールに穴を開けたが、作業後に閉め忘れた」などという、ありがちなヒューマンエラーはSession Managerを使うことで撲滅できます。

セキュリティグループによる制御から開放される一方、それに不安を覚える方もいらっしゃると思います。Session Managerでは、その役割はIAMポリシーが代替することになります。IAMの設計がしっかりできていれば問題はない、と言えそうです。

また、今までの方法は、前述したようにヒューマンエラーのリスクが伴います。それを潰せる仕組みであることは非常にメリットが大きいのではないかなと考えています。

どのように利用するか

こちらについては、公式アナウンスが既に画面キャプチャを添えて解説していますので、そちらに譲ります。記事の中段以降をご覧ください。

利用開始にあたって

とりあえず試してみたい!という方に向けて、利用前の注意として以下をご案内いたします。

In order to use Session Manager to access my EC2 instances, the instances must be running the latest version (2.3.12 or above)

SSM Agentのバージョンは 2.3.12 以上である必要があります。既存のインスタンスに対して適用する場合は、Run Commandの「AWS-UpdateSSMAgent」を利用するなどして適宜バージョンアップする必要があります。

The SSM Agent running on the EC2 instances must be able to connect to Session Manager’s public endpoint. You can also set up a PrivateLink connection to allow instances running in private VPCs (without Internet access or a public IP address) to connect to Session Manager.

対象となるインスタンスが、SSMのパブリックエンドポイントに到達性を持っていることが必要です。ただし、これに該当しない場合であっても、Private Link(※)を利用することで本機能の利用が可能です。

To use the AWS CLI to run session commands, you must be using version 1.16.12 of the CLI, and you must have installed the Session Manager plugin on your local machine. For information, see (Optional) Install the Session Manager Plugin for the AWS CLI.

上記はAWSドキュメント Learn More About Session Manager の「What Are the Main Features of Session Manager?」節からの引用です。

AWS CLIから本機能を利用する場合は、CLIバージョン、ならびにSession Manager用のプラグインのインストールが必要となります。プラグインインストールは、バンドルをダウンロードし、展開後にインストールスクリプトを実行するだけのごく簡単な手順です。 こちら にインストールガイドがありますので、ご参照ください。

おわりに

非常に魅力的な新機能ですね。ヒューマンエラーをこのような仕組みによって潰していくことが、負荷の低い、理想的な運用の実現に役立つと思います。このような効率化を自社内でも行いながら、お客様に還元していけたらと思います。

実運用に乗せるためには詳細に検証項目を詰めていく必要がありますし、現場の運用手順との兼ね合いも考えていく必要があるかと思いますので、今後とも本機能の検証は続けていきたいと思います。続報があれば、このブログなど、何らかの形でアナウンスできればと思います。

※ … Private Linkについては、以前に弊社の城がブログ記事を書いておりますので、よければそちらも併せてご参照ください。

参考: 【VPC エンドポイントサービス (AWS PrivateLink)】オンプレから既存インスタンスのIPを別クラスのIPとして通信する検証をしてみました。

Amazon Connect を使って Lambda で電話をかけれるんです

$
0
0

こんにちは、技術一課の山中です。

先日社内のメンバーから以下相談を受けました。

「山中さん、 Amazon Connect 詳しいですよね? 何かインスタンスに障害が起きたときに電話で通知するとかできるんですか?」(多分こんなかんじ
「できるんじゃないですか?」

ということで、Amazon Connect はチュートリアル以外触ったことがなかったので、実際に電話をかけれるのか検証してみました。

はじめに

何かインスタンスに障害が発生した際に、 CloudWatch 等で検知する仕組みがあれば、それをトリガーに Lambda ファンクションをキックできるので、 Lambda から Amazon Connect 経由で電話通知ができればよいと考え、 Lambda から Connect で電話することを目標としました。

Amazon Connect とは

Amazon Connect は簡単に使えるクラウド型コンタクトセンターです。
詳しくはこちらをご覧ください。
公式サイト
Amazon Connect 安心して運用ができるか疑って調べてみた
Amazon Connect 導入支援資料を公開しました
Amazon Connectで電話をつなぐ

コールセンターサービスの立ち上げ

Amazon Connect ハンズオン初級編 を見ながら、コールセンターサービスを立ち上げます。

問い合わせフローの作成

今回以下のようなフローを作成しました。
すごくシンプルですよね。

ここでのポイントはユーザへの応答を Lambda から受け取ったメッセージとしたいので、以下のように「プロンプトの再生」で属性を指定する必要があります。

フローを作成したら、 以下のような ARN が発行されますので、 インスタンス IDコンタクトフロー ID を控えておいてください。

arn:aws:connect:ap-southeast-2:000000000000:instance/[インスタンス ID]/contact-flow/[コンタクトフロー ID]

Lambda ファンクションの作成

作成した Lambda ファンクションはこちら
DestinationPhoneNumber には電話をかける電話番号を、 SourcePhoneNumber には Amazon Connect で取得した電話番号を入力します。

import boto3

ec2 = boto3.client('ec2', region_name='ap-northeast-1')
connect = boto3.client('connect')

def lambda_handler(event, context):
    running_instances = get_running_instance()
    message = '現在稼働中のインスタンスは'
    if running_instances:
        for instance_name in running_instances:
            message += instance_name

        message += 'です'
    else:
        message += 'ありません'

    call(message)


# Amazon Connect で電話をかける
def call(message):
    connect.start_outbound_voice_contact(
        DestinationPhoneNumber='+819000000000',
        ContactFlowId=[コンタクトフロー ID],
        InstanceId=[インスタンス ID],
        SourcePhoneNumber='+815000000000',
        Attributes={
            'message': message
        }
    )


# 稼働中のインスタンス一覧を取得
def get_running_instance():
    response = ec2.describe_instances(
        Filters=[
            {
                'Name': 'instance-state-name',
                'Values': [
                    'running',
                ]
            },
        ],
    )
    if not response['Reservations']:
        return []

    running_instances = []
    for reservation in response['Reservations']:
        reservation['Instances'][0]
        running_instances += [tag['Value'] for tag in reservation['Instances'][0]['Tags'] if tag['Key'] == 'Name']

    return running_instances

作成した Lambda をテスト実行すると、 Mizuki さんが東京リージョンで稼働中のインスタンスを電話でつぶやいてくれますよ!
(実際に使うときはもうちょっとしっかりやります

おわりに

Lambda から電話をかけれるってすごいですよね、しかも上記の流れを作るのに本当に 1 時間くらいしかかかりませんでした。
Amazon Connect 、夢があります。

OneLoginにAmazon ConnectのSAMLコネクタが追加されました

$
0
0

宮澤です。
今回はOneLoginに、Amazon ConnectのSAMLコネクタが追加されたのでその設定手順を紹介します。

1.Amazon Connectの作成

Amazon Connectの画面に移動し”今すぐ始める”を押します。

“SAML2.0 ベースの認証”を選択して、アクセスURLを入力して”次のステップ”を押します。

このタイミングで、管理者を作成する場合は”新しい管理者の追加”を選択して、項目を入力します。
作成しない場合は”これをスキップ”を押して”次のステップ”を押します。

次にテレフォニーオプションを設定します。
今回は発着信両方ともConnectを使う想定なので、両方ともチェックして”次のステップ”を押します。

ログの保存先の設定が表示されますが、デフォルト設定を利用するため”次のステップ”を押します。

Connectの構成確認画面が表示されるので、問題がなければ”インスタンスの作成”を押します。

ユーザー作成

Connectの管理画面から、作成したインスタンスを選択します。

”概要 > 管理者としてログイン”を押します。

“ユーザー > ユーザー管理 > 新しいユーザーの追加”を押します。

ユーザー情報を確認し、問題なければ”ユーザーの作成”を押します。

ユーザーを作成する際、OneLogin上に存在するユーザーと姓、名、メールアドレスが一致するように作成してください。

作成するユーザー情報が表示されるので、問題がなければ”ユーザーの作成”を押します。

2.AWSアカウントとOneLoginをSAML設定

OneLogin側でコネクタ作成

OneLoginに管理者アカウントでログインし、”APPS > Add Apps”へ移動し、”Amazon Connect”と検索し、表示されたアプリケーションを選択します。

Display NameにOneLogin上の表示名を設定し”SAVE”を押します。

 

SAVEを押すと以下の画面に遷移するので、”MORE ACTIONS>SAML Metadata”を押してXMLファイルをダウンロードします。
※後ほどAWSマネジメントコンソールの設定で利用します。

AWS側のIDプロバイダ設定

IDプロバイダの作成

マネジメントコンソールにログイン後IAMの画面に移動し、”IDプロバイダー>プロバイダの作成”を押します。

プロバイダタイプは”SAML”を選択し、プロバイダ名を任意で設定します。
メタデータドキュメントは、先程OneLoginからダウンロードしたファイルを指定して”次のステップ”を押します。

最後に確認画面が表示されるので、問題なければ”作成”を押します。

IAM ポリシーの作成

ConnectをSAML経由で利用する場合、以下のIAMポリシーをロールに付与する必要があるので、任意の名前で以下の2つを作成します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Statement1",
            "Effect": "Allow",
            "Action": "connect:GetFederationToken",
            "Resource": [
                "arn:aws:connect:RegionID:AccountNumber:instance/ConnectInstanceID/user/${aws:userid}"
            ]
        }
    ]
}

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Statement2",
            "Effect": "Allow",
            "Action": "connect:GetFederationToken",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "connect:InstanceId": "ConnectInstanceID"
                }
            }
        }
    ]
}

IAM Roleの作成

IAMの画面で”ロール > 新しいロールの作成”を押します。

”SAML2.0 フェデレーション”を選択し、”SAMLプロバイダー”の値を先ほど作成した、IDプロバイダーを指定します。
そして、”プログラムによるアクセスとAWSマネジメントコンソールによるアクセスを許可する”を選択して”次のステップ:アクセス権限”を押します。

該当IAMロールで利用する権限を設定します。
先程作成した2つのIAMポリシーを選択して”次のステップ : 確認”を押します。

最後に、ロール名を入力して”ロールの作成”を押します。

OneLoginのParameter設定

OneLoginのコネクタ設定画面に戻り”Parameters”タブを開きます。
ParametersタブではSAML認証を行うときに利用する以下の3つの用に設定します。

  • Amazon Username UsernameAWS上でのユーザーの表示名) : Email
  • Role : arn:aws:iam::アカウントナンバー:role/作成し/作成しロール名,arn:aws:iam::アカウントナンバー:saml-provider/作成したIDプロバイダ名
  • RoleSessionName(AWS上でのユーザーの表示名) : Email

次に”Configuration”タブを開き、Connectのリージョンと、ConnectのインスタンスIDを入力して”SAVE”を押します。

最後に”Access”タブを押して、Connectを利用するユーザーが指定されているRoleを指定し”SAVE”を押します。

3.ログイン確認

OneLoginからConnectのAWSアカウントにログインします。

SAMLログインが実行され、以下のダッシュボードに移動することができます。

注意事項

SAMLベースでConnectを作成すると、以下のような通常のログインURLは利用できない状態になります。

https://ConnectAlias.awsapps.com/connect/login

また、Amazon Connectセッションは、ユーザーがログインしてから10時間後に失効します。
10時間後、ユーザーは現在通話中であっても自動的にログアウトされてしまいます。
エージェントに10時間以上ログインさせる予定の場合は、セッションが終了する前に、Amazon ConnectおよびOneLoginからログアウトした後、再度ログインする必要があります。
※これにより、トークンに設定されたセッションタイマーがリセットされます。


AWSのIAMユーザーにYubikeyを設定する

$
0
0

宮澤です。
以下の記事で、IAMユーザーの多要素認証として”Yubikey”が利用可能になりましたので、その設定手順を紹介したいと思います。
https://aws.amazon.com/jp/about-aws/whats-new/2018/09/aws_sign_in_support_for_yubikey_security_key_as_mfa/

Yubikeyとは

YubikeyはPCに接続して使用する認証デバイスで、すべてのOSやブラウザで利用可能なデバイスです。
これを利用して、ワンタイムパスワードの生成や、FIDO U2Fの二段階認証などの、より強力な認証を実現できます。

今回の設定手順では、Yubikey4C Nano を利用します。
https://www.yubion.com/shop/html/products/detail.php?product_id=15

設定手順

マネジメントコンソールにログインして、”IAM”の画面に移動します。
その後、”ユーザー”から”Yubikey”を設定したいユーザーを選択します。

“認証情報”タブを開き、MFAデバイスの割当に表示されている”管理”を押します。

“U2F セキュリティキー”を選択して”続行”を押します。

以下の画面が表示されるので、”Yubikey”をPCに挿入して”金色の部分”をタップします。

Chromeを利用した場合、以下のポップアップが表示されるので”許可”を押します。

正常に設定が完了すると以下のポップアップが表示されるので”閉じる”を押します。

ログイン確認

IAMユーザーでログインを行います。

その後、以下のような画面が表示されるので、PCにYubikeyを挿入し”金色の部分”をタップすることでログインが完了します。

まとめ

今回紹介”Yubikey”を利用することで、ログイン時にTOTPを利用しているときのように、ワンタイムパスワードを入力する必要がなくなり、安全性を確保しつつ運用が楽になります。
また、物理MFA等の場合、電池切れを心配する必要がありましたが、Yubikeyは耐久性も高く、電池の心配もする必要が無いので、安心して長く使うことができます。
今回はAWSの手順を紹介していますが、弊社で提供しているシングル。サイン・オン製品の”OneLogin”のユーザー認証にもYubikeyを利用することができます。

また、AWSがサポートするYubikeyデバイスは以下に公開されています。
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_u2f_supported_configurations.html#id_credentials_mfa_u2f_supported_devices

Cloud Automatorに新しく操作ログ機能を追加しました!

$
0
0

今回のブログでは、本日Cloud Automatorに新しく追加した操作ログについてご紹介したいと思います。

操作ログとは?

操作ログとは、Cloud Automator上での操作内容が記録されたログのことで、オーナーまた管理者権限を持っているユーザーがCSVファイルでダウンロードすることができます。
AWSにもCloudTrailがあるようにいつ、誰が、どのような操作を行ったかを記録しておくことはコンプライアンス、運用監査、リスク監査の観点で非常に重要なことです。Cloud Automatorでもご利用のお客様からたくさんのご要望を頂き、本日リリースさせていただきました。

ご利用方法

操作ログのご利用方法、ログの形式、対応している操作はこちらにマニュアルを用意しておりますので、ご参考ください。

終わりに

以上、本日リリースしました「操作ログ」をご紹介致しました。
今後のリリース計画については決まり次第、ロードマップページにて公開しております。これからも Cloud Automator をよろしくお願い致します。

Cloud Automator(クラウドオートメーター)とは、ノンプログラミングでAWS運用を自動化し、AWSの利用を最大限に引き出すサービスです。バックアップや災害対策、AWS費用の削減を実現する「ジョブ」と、AWSがガイドライン通りに運用されていることを継続的に確認する「構成レビュー」という2つの機能をご提供しております。

Cloud Automator

Unipos にOneLoginのSAML設定をする

$
0
0

宮澤です。
今回は、ピアボーナスを簡単に実現できるサービスの”Unipos”のSAML設定手順を紹介します。

設定

OneLoginに管理者でログインして、”APPS > Add Apps”を開きます。

“SAML Test Connector (IdP w/attr)”と入力し、検索を行い、表示されたコネクタを選択します。

OneLogin上の表示名を設定し”SAVE”を押します。

次に、UniposのSSO設定を開きます。
Uniposにログイン後、左下の”管理者設定”を押します。

“セキュリティ > SSO設定”を押して、”エンティティID”と”ACSのURL”を控えておきます。

OneLogin側のコネクタ設定画面に戻り”Configuration”タブを選択します。

以下のように項目値を設定をして、右上のSAVEを押します。

OneLogin Unipos
Audience エンティティID
Recipient ACSのURL
ACS (Consumer) URL Validator .*
ACS (Consumer) URL ACSのURL

SSOタブを開き、”Issuer URL”と”SAML 2.0 Endpoint (HTTP)”の値を控えておき、”View Details”を押します。

“View Details”を押すと、証明書の管理画面にいくので、アイコンをタップして、X.509証明書の内容をコピーして、控えておきます。

UniposのSSO設定画面に戻り”IDプロバイダを設定する”を押します。

以下の画面が表示されるので、以下の項目のように設定を行い”保存する”を押します。

Unipos OneLogin
エンティティID Issuer URL
SSOのURL SAML 2.0 Endpoint (HTTP)
証明書(Base64エンコード) X.509証明書

最後に、OneLoginの設定画面で、”Access”タブを開き、該当するロール(権限)を設定し”SAVE”を押します。

ログイン確認

OneLogin上に表示された、Uniposのアイコンをクリックしてログインを行います。

ログインして、以下のような画面が表示されれば、無事SAML認証でのログインは完了です。

まとめ

今回紹介した手順で、UniposにSAMLログインを行う事ができました。
SAMLログイン時にエラーが起きた場合は、”404″が表示された場合は、OneLogin側の設定が間違っている可能性がありますので、再度見直しをしていただければと思います。

OneLoginの多要素認証にYubikeyを使う

$
0
0

宮澤です。
今回は、OneLoginを利用してるユーザーに、Yubikeyを他要素認証デバイスとして使わせる設定を紹介します。

管理者設定

OneLoginに管理者画面でログインして”SETTING > Authentication Factors”を開き、”NEW AUTH FACTOR”を押します。

Partnersの一覧にある”YUBIKEY”の”CHOSE”を押します。

OneLogin上の表示名を設定し”SAVE”を押します。

次に”SETTINGS > Policies”を押します。

Yubikeyを使わせたいユーザー用のポリシーに設定を行います。
新規ポリシーにYubikeyを設定する場合は、右上の”NEW USER POLICY”を押します。
既存のポリシーにYubikeyを設定する場合は、下の一覧にある既存のポリシー名を選択します。
※新規ポリシーを作成した場合は、既存のユーザーに別途ポリシーを割り当てる必要があります。

新規にポリシーを作成した場合は、上部の欄にポリシー名を設定します。
MFAタブを開き、”OTP Auth Required”にチェックを入れたあとに、”Yubikey”にチェックを入れて”SAVE”を押します。
※OTP Auth Requiredをにチェックを入れることでユーザーに他要素設定を必須にさせることができます。

ユーザー設定

OTP Auth Requiredが有効になっている場合、ユーザーがOneLoginにログインしたタイミングで他要素認証の設定が求められます。
その時は、YubikeyIDの入力欄を選択した状態で、Yubikeyの金色の部分をタップします。

 

 

 

 

 

 

ログイン済みのユーザーや、ユーザーが任意で設定する場合は、ログイン後、右上のユーザー名をクリックし”プロフィール”を押します。

2要素認証部分の”+”を押します。

以下の画面が表示されるので、YubikeyIDの入力欄を選択した状態で、Yubikeyの金色の部分をタップします。

ログイン

OneLoginにメールアドレスとパスワードを使ってログインすると、以下のようにセキュリティコードの入力を求められるので、そのタイミングで、Yubikeyの金色の部分をタップして、ログインを行うことができます。

まとめ

今回紹介した方法で、OneLoginの他要素認証をYubikeyで行うことができました。
他要素認証を行いたいけれど、モバイルデバイスを使いたくないなどの場合は、Yubikeyの利用は適切だと思います。

Googleアカウントの他要素認証としてYubikeyを設定する

$
0
0

宮澤です。
今回は、Googleアカウントの他要素認証としてYubikeyを設定する方法を紹介します。
GoogleアカウントにYubikeyを設定する場合、事前に電話番号の設定が必要になります。
今回紹介するのは、設定後の手順になります。

設定手順

Googleアカウントにログインし、右上のメニューボタンから”Googleアカウント”を押して”ログインとセキュリティ”を押します。

“Googleへのログイン”を押してから”2段階認証プロセス”を押します。

セキュリティキーの項目に表示されている”セキュリティキーを追加”を押します。

“次へ”を押します。

以下の画面が表示されたら、デバイスに”Yubikey”を挿入し、金色の部分をタップします。

登録が完了すると、Yubikeyの名前を設定し”完了”を押します。

設定が完了すると、以下のように設定内容が表示されます。

ログイン時に、メールアドレスとパスワードでログインを実施すると以下のような画面が表示されるので、デバイスにYubikeyを挿入し金色の部分をタップすることでログインができます。

まとめ

今回紹介した方法で、Googleアカウントでの他要素認証をYubikeyで行うことができました。
G Suiteをお使いで、ユーザーのセキュリティを強化したい場合はYubikeyを利用することで簡単にセキュリティレベルを強化できます。

入門!はじめてのServerless Framework(LambdaからSlackへ定期実行編)

$
0
0

こんにちは。新卒1年目、OJT中の小林です。

サーバーワークスの新卒は、1年間はOJTによる実地研修を行なっており、私も現在マネージドサービス課で元気に修行中です。

先日、研修で、巷で有名なServerless Frameworkをはじめて使い、AWSのLambdaのデプロイをしてみちゃいました。

ですので、修行の一環として、また備忘録も兼ねて、僭越ながらご紹介したいと思います。

ちなみに、Serverless Frameworkの使い方は、新卒2年目の先輩に教えていただきました。尊敬します。

 

今回やったこと

 

今回作ったのは、サーバーワークスの社内で定期開催されるLT大会(いわゆる社内勉強会)のリモート配信先のURLを記載したメッセージをSlackに送信するBotです。

LT大会は毎週水曜日と金曜日の18:30に行われるため、その30分前の18:00に特定のチャンネル(#lt-championship)に送信されるようにしました。

 

Serverless Frameworkを作る手順

まずは、Serverless Frameworkの作成。ランタイムはpython3系で行います。slsとしていますが、serverlessでも動作します。

sls create -t aws-python3 -p LT_G2M

 

必要な外部ライブラリもアップロードしちゃいます。私の場合は、requestsのライブラリをアップロードしました。

pip install requests -t .

 

早速handler.pyのファイルにコードを書いちゃいます。今回はできるだけコードを変更しないようにするため、認証情報は環境変数(environment variable)としました。具体的にはtokenとchannelです。

import json
import os
import requests


def lambda_handler(event, context):
    message = '本日のLTのGoToMeetingはこちらです。 ```https://xxxxxxxxxxxxxxxx```'
    token = os.getenv('token')
    channel = os.getenv('channel')
    param = {
        'token': token,
        'channel': channel,
        'text': message
        }

    response = requests.post(
        'https://slack.com/api/chat.postMessage',
        data = param
        )

 

次は、serverless.ymlのファイルを編集します。前述したように、tokenとchannelは環境変数としてこちらのファイルで情報を持たせます。

また、今回は定期的にメッセージを送信させるため、CloudWatchEventsを使用します。

service: LT-G2M 
provider:
  name: aws
  runtime: python3.6

functions:
  hello:
    handler: handler.lambda_handler
    environment:
      token: 'xoxp-xxxxxxxxxxxxxxxxxxxxxxx'
      channel: '#lt_championship'
    events:
      - schedule: cron(0 9 ? * WED,FRI *)

 

ちなみに、CloudWatchEventsの設定の際、私は最初schedule: cron(0 18 ? * WED,FRI *)としてしまったがために、飛んでこないなーこないなーと待ちぼうけを食らいました。CloudWatchEventsはJSTではなく、UTCですね。

 

そしてデプロイ

デプロイは以下のコマンドを実行するだけ。

sls deploy

メチャ簡単。

本当にできているのか。マネコンよりLambdaを確認。

出来た。

ログも確認。

 

出来た。

Slackも確認。

 

出来た。感動ですね。

 

おわりに

はじめてのServerless Framework。

簡単なプログラムながら、AWSのマネコンからではなく、CLIを使ってLambdaがデプロイできるなんて。

しかしながら、

東京リージョンにデプロイするはずがバージニア北部リージョンにデプロイしていたり、

関数を使わずコードを書いていたら、一行がひたすら長いブサイクなコードを記述していたり、

ツメが甘い私は、まだまだ改善の余地ありです。

 

ただ、Serverless Framework楽しいですね。

GitHubの他要素認証にYubikeyを使う

$
0
0

宮澤です。
今回は、GitHubアカウントの他要素認証としてYubikeyを設定する方法を紹介します。

設定手順

GitHubにログインし、プロフィールのアイコンをクリックし、”Settings”を押します。

次に、”セキュリティ”を開き、”Security Keys”の項目にある、”Add”を押します。

以下のような画面に移動するので、”Security Keys”の項目に表示されている”Register new device”を押します。

登録するキーの名前を指定して”Add”を押します。

以下のような画面が表示されるので、Yubikeyをデバイスに挿入して、金色の部分をタップします。

登録が完了すると、以下のような画面になります。

まとめ

今回紹介した方法で、GitHubアカウントでの他要素認証をYubikeyで行うことができました。
GitHubの多要素認証以外にも、LinuxへのSSH接続をより安全にすることもできます。
https://www.yubico.com/why-yubico/for-business/computer-login/linux/


AWS Lambdaのタイムアウトが15分になったので試してみた

$
0
0

最近、暖かくなったり寒くなったりと体調を崩しがちですが、なんとか元気にやってます、技術課の森です。

今回は、AWSのForumにLambdaのタイムアウト値が15分になったとありましたので、ちょっと試してみました。

ちなみに、公式ドキュメントも15分の記載になっています。

試したこと

タイムアウト値を15分にして、15分Lambdaを動かしてみる

やってみた

最初にタイムアウト値を15分にしてみます。15分にしてもエラーなく設定されました。

つぎにコードを書いてみました。
コードは至って単純で、1秒スリープして、1秒ごとに経過秒を出してるだけです。
0スタートなので、899が出ることがゴールです。

import json
from datetime import datetime
import time

def lambda_handler(event, context):
    # TODO implement
    incrementCounter = 0
    while True:
        print(incrementCounter)
        time.sleep(1)
        incrementCounter += 1
        
    return {
        "statusCode": 200,
        "body": json.dumps('Hello from Lambda!')
    }

結果

待ってる時間はなかなか長かったです。が、見事!899を出力。(本当は1スタートの900にしたかったのは内緒です

Lambdaの処理時間が長くなったので、今までコンテナやEC2で動作させてたものがLambdaで処理できる可能性も出てきたのかなと思います。
ただ、API Gateway + Lambdaだと、API Gateway側のタイムアウト 30秒 に引っかかるので、API Gateway側もタイムアウト値が伸びるといいなと思いました。

後、体調にはくれぐれもご注意を。

WorkSpacesを東京リージョンで利用するのに必要なWorkSpacesクライアント側の通信要件

$
0
0

こんにちは、技術4課の城です。
WorkSpacesを利用する際にWorkSpacesクライアントからの通信経路にファイアウォール、プロキシ等があり、通信制御されていることは多々あるかと思います。
その場合、WorkSpacesの通信に必要な設定を各機器に設定する必要があります。
そこで東京リージョンでWorkSpacesクライアントから利用するのに必要な通信要件をAWSドキュメントを参考にまとめてみました。
※2018/10/12時点の情報です。

ポート443(TCP)

WorkSpacesクライアントの更新、登録、認証に使用されるポートとなります。
次の宛先について許可されている必要があります。

  • GLOBAL リージョンの AMAZON サブセット
  • WorkSpace が存在するリージョンの AMAZON サブセット
  • us-east-1 リージョンの AMAZON サブセット
  • us-west-2 リージョンの AMAZON サブセット
  • us-west-2 リージョンの S3 サブセット

上記は公開されているAWSのIPアドレスレンジとなります。
https://docs.aws.amazon.com/ja_jp/general/latest/gr/aws-ip-ranges.html

jsonのフィルタ

IPアドレスレンジはjson形式で公開されている、かつ膨大な量が記載されているので目的のレンジを見つけるためにフィルタしましょう。
今回は私的におすすめのAWS Tools for PowerShellで実行するコマンドを記載しておきます。
AWS Tools for PowerShellのセットアップについてはこちらのドキュメントをご参照ください。

GLOBAL リージョンの AMAZON サブセット

Get-AWSPublicIpAddressRange -Region GLOBAL -Servicekey AMAZON

WorkSpace が存在するリージョンの AMAZON サブセット

Get-AWSPublicIpAddressRange -Region ap-northeast-1 -Servicekey AMAZON

us-east-1 リージョンの AMAZON サブセット

Get-AWSPublicIpAddressRange -Region us-east-1 -Servicekey AMAZON

us-west-2 リージョンの AMAZON サブセット

Get-AWSPublicIpAddressRange -Region us-west-2 -Servicekey AMAZON

us-west-2 リージョンの S3 サブセット

Get-AWSPublicIpAddressRange -Region us-west-2 -Servicekey S3

※ただしAWSのIPアドレスレンジは変更がある為、制限することを推奨しません。

ポート4172(UDP と TCP)

WorkSpace デスクトップの画面転送とヘルスチェックのストリーミングに使用されるポートとなります。
次の宛先への通信が許可されている必要があります。

  • 54.250.251.0/24
  • drp-nrt.amazonworkspaces.com

ホワイトリストに登録するドメイン

アクセス経路でドメインによるフィルタリングを行っている場合は下記について、許可する必要があります。

カテゴリ ホワイトリストに登録するドメイン
セッションブローカー(PCM) https://skylight-cm.ap-northeast-1.amazonaws.com
デバイスメトリクス https://device-metrics-us-2.amazon.com/
Forrester Log Service https://fls-na.amazon.com/
ディレクトリ設定 https://d21ui22avrxoh6.cloudfront.net/prod/ap-northeast-1/【directory name】
https://d1cbg795sa4g1u.cloudfront.net/prod/ap-northeast-1/【directory name】
https://d3s98kk2h6f4oh.cloudfront.net/
https://d1whcm49570jjw.cloudfront.net/
キャプチャ https://opfcaptcha-prod.s3.amazonaws.com/
クライアントの自動更新 https://d2td7dqidlhjx7.cloudfront.net/
登録の依存関係 https://s3.amazonaws.com
接続の確認 https://connectivity.amazonworkspaces.com/

※【directory name】についてはWorkSpacesに登録しているディレクトリサービスのものとなります。

最後に

意外につまづくことが多いポイントなので、どなたかの助けになれば幸いです。

固定IPでApplication Load Balancerを使ってみる

$
0
0

どうも、こんにちはエンジニアの横倉です。最近、ひとり暮らしなのにソロキャンプにも興味が出てしまい、いよいよ孤高の存在として仕上がるのも近そうです。

さて、今回は固定IPでApplication Load Balancer を使ったAWS ブログを検証してみました。
固定IPをNetwork Load Balancerで提供し、ターゲットがApplication Load Balancer のローカルIPアドレスとなります。その動的IPアドレスの紐づけ処理をLambdaファンクションで行うことでApplication Load Balancerでも固定IPでサービス提供が出来ます。
元のブログ はこちらです。基本的に同じような内容ですがHTTPSでも動作するかを本記事では確認しています。

利用者へのサービス提供構成図

前提条件

  • NLB(Internal or External)で配置
  •  ALB (Internal) で配置
  • ACMで取得したSSL証明書をALBに付与
  • ALBとNLBを同じAvailability Zone環境に配置
  • NLBにはIPターゲットグループを用意(プロトコルはTCP)※LambdaがNLBとALBを紐付け
  • S3バケットを用意し、ALBのIPアドレス情報を保持
  • Lambdaに必要なIAMロール

Lmabda ファンクションの動き

  • ALBのIPアドレスを名前解決で取得、S3バケットに新IPリストを作成 or 更新
  • describe-target-health API を実行しNLBに登録されているターゲットリストのIPアドレス取得
  • S3から旧 IPアドレスリストを取得
  • CloudWatch ログストリームにIPアドレスリストを送る
  • 内部ALB IPアドレスの数をカウントしCloudWatchのメトリクスに反映
  • 新IPリストのアドレスが旧IPリストに無い場合はNLBに登録
  • 旧IPリストのアドレスが新IPリストにない場合はNLBから解除

Lambdaの連携図

 

セットアップ

IPポリシーの作成

サンプルポリシーは元のブログ一番下に記載されております。

 

IAMロールの作成

Lambda用のIAMロールを作成し、先程のポリシーを紐づけます。

Lambdaファンクションの作成

Pythonランタイム環境  Python2.7で用意し、
ハンドラー名 “populate_NLB_TG_with_ALB.lambda_handler” で登録します。
 Lambdaのzipファイル.で取得したZipファイルをアップロードしてください。

環境変数の設定

  • ALB_DNS_NAME : ALBのエンドポイント名
  • ALB_LISTENER : ALBのリスナーポート
  • S3_BUCKET : ALBのIPアドレスリストを保管するS3バケット
  • NLB_TG_ARN : NLBのターゲットグループのARN
  • MAX_LOOKUP_PER_INVOCATION : 名前解決の実行回数
  • INVOCATIONS_BEFORE_DEREGISTRATION : IPアドレスの登録解除間隔
  • CW_METRIC_FLAG_IP_COUNT : IPアドレスカウントのCloudWatchメトリクスの有効化

CloudWatchイベントの設定

CloudWatch イベントを作成します。スケジュールで1分間隔でLambdaファンクションを呼び出して設定完了です。

動作確認

CloudWatch LogsでLambdaの実行処理が確認できます。こちらにErrorが表示されていたら、設定の誤りなどが考えられます。

固定IPでアクセスも可能ですが、今回はSSLサーバー証明書を適応しているのでRoute53で名前解決しています。
PHPでサーバー変数を出力するようにしてアクセスしてみました。
REMOTE_ADDR はALBのIPアドレス、HTTP_X_FORWARDED_FORはNLBのIPアドレスでした。
察しの良い方はお気づきかもしれませんが接続元IPアドレスはNLBまでしかわかりませんでした。これはIPベースのNLBだとALBに渡される接続元IPアドレスはNLBのものになるためです。

ここで、ダメ元でNLBのターゲットグループの設定でProxy Protocol v2 を有効化してみました。しかし、ERR_SSL_PROTOCOL_ERRORが表示されてパケットが壊れてしまった模様です。

まとめ

固定IPを利用してALBでのサービス提供は可能でした。1分間隔でDNSをチェックするのでALBのIPアドレスが変わっても対応可能です。そしてLambdaのサンプルが用意されているので簡単にセットアップが可能です。※CloudFormationも用意されています

ただ、接続元IPアドレスをサーバー側で確認できないのでサービスを運用する上ではネックになりそうです。また、セッション維持などはNLB、ALBに依存してしまうのも懸念かもしれないですね。
ただ、仕組みとしては非常に面白いので、Lambdaを使って出来なかったことを出来るようにしていくチャレンジをもっとしてみたいですね。

AWS認定 Advanced Networking -Speciality 合格レポート

$
0
0

こんにちは、技術4課の城です。
サーバーワークスでは上期(3月~8月)、下期(9月~10月)にてそれぞれの目標を設定することになっています。
私は今期の目標の一つに資格取得によるスキルアップを掲げました。

というわけで、さっそくAWS認定 Advanced Networking -Specialityを受験してきましたのでレポートをしたいと思います。

AWS認定 Advanced Networking -Specialityとは

AWSのネットワークについての専門知識試験となります。
下記、公式サイトより抜粋です。

AWS 認定高度なネットワーキング – 専門知識は、大規模な AWS およびハイブリッド IT ネットワークアーキテクチャの設計と実装における高度な技術スキルと経験を認定します。

詳細内容は公式サイトをご覧ください。

受験料:32,400円(税込み)
時間:170分

受験時のスペック

簡単に受験時の自身のスペックを紹介します。
ネットワーク関連の業務経験ですが、オンプレネットワーク運用の現場でサーバー管理チームの一員として、9か月ほど働いた経験があります。

AWS歴 業務利用はサーバーワークスに入社してからの10カ月
認定 アソシエイト3種、プロフェッショナル2種取得済み
その他ネットワーク系の資格 ネットワークスペシャリスト、CCNPは失効しました。
エンジニア歴 もうすぐ4年になります。

事前にやったこと

ありきたりですが、下記、実施しました。

いつもは模擬試験を受けているのですが、この試験については模擬試験が用意されていません。(2018年10月19日現在)
そこで、LinuxAcademyのテストで確認してみて、私は特にDirectConnectが弱かったので、次のblackbeltを熟読しました。
AWS Direct Connect 概要
AWSのネットワーク接続とAWS上のネットワーク内部設計

また、JPNIC様のBGPについての資料がとても理解しやすかったです。
https://www.nic.ad.jp/ja/newsletter/No35/0800.html

勉強法について

人それぞれ合ったやり方があると思いますが、私のメインの勉強時間はやはり「移動時間」です。
スマホでいかに学習できるように用意できるか、これが肝ですね。
PCに向かって勉強できる時間は、上記準備の他は、主に実環境を触ってみることをするように意識しています。

結果

総合成績80%にて合格しました!!

まとめ

資格取得へのプロセスの中で、よりAWSのネットワークやアーキテクチャへの理解を深められたと感じています。
是非、みなさまも挑戦されてみてはいかがでしょうか?

どなたかの助けになれば幸いです。

Alexaだけじゃない!SiriからでもAWSを操作できるiOS12「ショートカット」の使い方

$
0
0

こんにちは、AWSエンジニアの大石です。

みなさん、新しいiPhoneは買いましたでしょうか?

良く訓練されたApple信者である私は迷うこと無くiPhone XS Maxにしてみましたが、さすがにデカすぎ感が否めません。しかもiPhone Xからの買い換えだったので「何がかわったんだ」という問いに未だにこたえられずにいます。信者です。

そんな新しいiPhoneですが、どちらがというとハードよりもiOS12というソフトの満足度が高そうです。比較的古いiPhoneでも「OSのアップデートでサクサク動くようになったので、もう少し今の機種で使えそうだ」という話もきいたりしました。

くだんのiOS12、わたしのイチオシ機能が「ショートカット」です。

もともとはWorkflowという名前の有料アプリだったのですが、Appleに買収され、iOS12から標準機能になったというアプリです。

Workflowの時代から、iPhoneで行ういろいろな操作を自動化することた神アプリだったのですが、iOSに統合されたことでSiriからも呼び出せるようになりました。
この「ショートカット」、HTTPリクエストを送信したりすることもできますので、Webhookを受け付けられる様々なクラウドサービス(例えばIFTTTなど)と連携することも可能です。Cloud AutomatorにもWebhookを受け付ける「HTTPトリガー」という機能がありますので、これを使えばSiriからAWSのインスタンスを立ち上げるなんてことも可能です。
早速やってみましょう。

Cloud AutomatorとSiriを連携させる方法

  1. まずCloud Automatorにログインします(アカウントがない方は無料トライアルも可能です)
  2. 「ジョブの追加」をクリックします
    1. トリガーとしてHTTPトリガーを選びます
    2. アクションは何でもよいのですが、今回はわかりやすく「インスタンスの起動」を選びます
    3. 必要な情報を入れたら「作成する」ボタンをクリックします
    4. すると、完了画面がでてきて「URL」と「アクセストークン」が表示されます。ショートカットのレシピ作成時に必要になりますので、記録しておきます
  3. 次にiPhoneから「ショートカット」アプリを開きます
    1. ギャラリーから「+」をクリックして、レシピの作成画面に入ります
    2. 検索ボックスに「URL」と入力して、
    3. URLを画面上までドラッグ&ドロップして
    4. 先ほどのCloud Automatorジョブ作成後に表示された「URL」を入力します
    5. 同様に検索ボックスに「URL」と入力して、「URLの内容を取得」をドラッグ&ドロップします
    6. 「方法」(多分「メソッド」をよく知らない人が和訳したものと思われますw)は「POST」に、ヘッダに「Authorization」と自分で入力して、その右に値としてアクセストークンの値を入力します(アクセストークンには”CAAuth “という7文字が含まれます)。同様に「Content-Length」「0」を追加します
    7. レシピが作成できたら、こちらのボタンをクリックして
    8. このレシピに名前をつけて「Siriに追加」をクリックします
    9. このような録音画面がでてきますので、録音ボタンを押して自分でこのレシピを起動するフレーズを吹き込みます(ここでは「CAでインスタンスを起動して」と入れてみました
    10. このようになれば完成です!

ためしてみる

実際に動かしてみましょう。「ヘイ!シリ!」でSiriを起動して「CAでインスタンスを起動して」と呼びかけてみると・・・

おお!Siriさんが「わかりました」といってCloud Automatorを呼び出してくれたようです。

CAでジョブの一覧から「ログ」をクリックしてみると

おお、確かに起動していますね!

今回はSiriから起動してみましたが、Launch Center ProというiPhoneアプリと組み合わせると「ロケーション情報で起動する」なんてことも可能です。Launch Center Proでは「特定の場所を離れた時に、ショートカットのレシピを起動する」ということができますので、例えば「会社を離れたら、開発環境のEC2インスタンスを停止する」などというレシピを起動させて、EC2インスタンスのコストを削減したりすることも可能です。

いかがでしたでしょうか?当社ではKokexaという謎テクノロジーに投資を継続しており、会議室から夜な夜な「コケクサ・・・コケクサ・・・」というつぶやき声が聞こえるために「夜会社にいてはいけない」という都市伝説が生まれつつありますが、SiriとCloud Automatorの組み合わせによってKokexaに一矢報いることができそうです。
敬虔なApple信者の方はぜひお試し下さい!

Viewing all 1210 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>