継続は力なり

タイトル通り定期的な更新を心掛けるブログです。

AWS Clinet VPN のユーザー認証を SAML 認証で行う

タダです.

前回の AWS Client VPN のユーザー認証を Active Directory で行いました.今回はもう1つのユーザー認証の方式の SAML 認証を検証した内容をまとめます.別記事でも触れてますが,AWS SSO を業務上投入してて,AWS SSO で認証できるのかを確認したかったので今回検証したみた次第です.

sadayoshi-tada.hatenablog.com

検証シナリオ

シナリオとしては,前回 Simple AD を使って認証したのを AWS SSO 認証に変える以外,それ以外の設定は変わりません.認証のフローは公式ドキュメントにて解説されておりました.

  1. AWS Client VPN と連携するには、選択した IdP で SAML ベースのアプリを作成するか、既存のアプリを使用します。

  2. AWS との信頼関係を確立するために IdP を設定します。リソースについては、「SAML ベースの IdP 設定リソース」を参照してください。

  3. IdP で、組織を IdP として定義するフェデレーションメタデータドキュメントを生成し、ダウンロードします。この署名付き XML ドキュメントは、AWS と IdP の間の信頼関係を確立するために使用されます。

  4. クライアント VPN エンドポイントと同じ AWS アカウントに IAM SAML ID プロバイダーを作成します。IAM SAML ID プロバイダーは、IdP によって生成されたメタデータドキュメントを使用して、組織の IdP と AWS の信頼関係を定義します。詳細については、IAM ユーザーガイドの「SAML ID プロバイダーの作成」を参照してください。後で IdP のアプリ設定を更新する場合は、新しいメタデータドキュメントを生成し、IAM SAML ID プロバイダーを更新します。

  5. クライアント VPN エンドポイントを作成します。認証タイプとしてフェデレーション認証を指定し、作成した IAM SAML ID プロバイダーを指定します。詳細については、「クライアント VPN エンドポイントを作成する」を参照してください。

  6. クライアント設定ファイルをエクスポートし、ユーザーに配布します。AWS が提供するクライアントの最新バージョンをダウンロードし、これを使用して設定ファイルをロードして、クライアント VPN エンドポイントに接続するようにユーザーに指示します。または、クライアント VPN エンドポイントのセルフサービスポータルを有効にした場合は、セルフサービスポータルにアクセスして設定ファイルと AWS が提供するクライアントを取得するようにユーザーに指示します。詳細については、「セルフサービスポータルにアクセスする」を参照してください。

f:id:sadayoshi_tada:20201230190102p:plain 引用元:AWS クライアント VPN 認証ワークフロー図より引用

設定内容

SAML 認証設定としてやるのは①AWS SSO のカスタム SAML アプリケーションの登録,属性値の登録,ユーザーの追加,②IAM にカスタム SAML メタデータの登録,③SAML 認証でエンドポイントの再作成および Client VPN 各種再設定です.

AWS SSO のカスタム SAML アプリケーションの登録,属性値の登録,ユーザーの追加

SSO のアプリケーションのページに移動し,新規アプリケーションの追加 > カスタム SAML 2.0 アプリケーションの追加 を押します.表示名や説明は任意の値を入力し,AWS SSO メタデータ セクションのメタデータファイルをダウンロードしておきます.

f:id:sadayoshi_tada:20201230192350p:plain

アプリケーションメタデータセクションで手動でメタデータ値を入力します.ドキュメントに記載の下記2つの設定値を転記し,保存します.

Assertion Consumer Service (ACS) URL: http://127.0.0.1:35001

Audience URI: urn:amazon:webservices:clientvpn

f:id:sadayoshi_tada:20201230192313p:plain

次に,属性値の登録で Subject と NameID を登録してます.他にも,FirstName,LastName,memberOf という属性も追加できますが,今回は最小の検証を目的にしているので使っていません.

f:id:sadayoshi_tada:20201230192716p:plain

属性:説明

NameID:ユーザーの E メールアドレス。

FirstName:ユーザーの名。

LastName:ユーザーの姓。

memberOf:ユーザーが属するグループ (複数も可)。

最後に,VPN の認証に割り当てたいユーザーを追加して AWS SSO の設定は完了です.

f:id:sadayoshi_tada:20201230193040p:plain

②IAM にカスタム SAML メタデータの登録

前項でダウンロードしたメタデータのファイルを IAM に登録します.IAM のサービス画面からID プロバイダ > プロバイダを追加 を押します.プロバイダ名を任意のものにして,ダウンロードしたメタデータファイルをアップロードしてプロバイダを追加ボタンを押します.

f:id:sadayoshi_tada:20201230200032p:plain

SAML 認証でエンドポイントの再作成および Client VPN 各種再設定

Client VPN のエンドポイントを再作成します.これまでと変わるのは認証情報のセクションで,ユーザー ベースの認証を使用 > 統合認証 を選択し,前項で登録した IAM の ID プロバイダー名を指定すること以外は他の設定は特に変更しないこととします.また,エンドポイント作成後の受信の認証ルールやルートテーブルもこれまでの記事と同一の設定にしています.

f:id:sadayoshi_tada:20201230200300p:plain

動作確認

エンドポイントの設定が完了後クライアント設定ファイルをダウンロードして VPN クライアントアプリのプロファイルを追加しました.接続を試みると AWS SSO の認証画面が表示されます.ユーザー認証情報を入力し,認証が成功すると画面遷移して http://127.0.0.1:35001 と認証が終わったので画面閉じてもいいと表示されます.

f:id:sadayoshi_tada:20201230200721p:plain f:id:sadayoshi_tada:20201230200809p:plain

VPN 接続確立を確認したところ,接続がうまく行っていることを確認できました.

f:id:sadayoshi_tada:20201230201504p:plain

まとめ

Client VPN のユーザー認証方式として SAML の認証パターンを試したので検証内容をまとめました.ACS のURLに指定するのが http://127.0.0.1:35001で画面遷移の結果をみていてなんとももどかしい感想を持ちました...公式では Okta と Microsoft Azure Active Directory など別の IdP と連携したパターンを紹介もあり,ちょっと違ったパターンも試したいなと思ったのでその結果もまたブログにしてみたいなと思います.

docs.aws.amazon.com

関連記事

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

CloudWatch Logs の大量のログに対して『check-aws-cloudwatch-logs-insights』プラグインによる監視を入れる

タダです.

システムの中で CloudWatch Logs に Apache のログを保存しているのですが,大量のログとなっています.このログの中から HTTP ステータスコードが4XX 系を抽出してエラー発生数をモニタリングしたい時に,「check-aws-cloudwatch-logs-insights」の Mackerel プラグインを使って検証してみたのでその内容をこの記事でまとめます.

check-aws-cloudwatch-logs-insights とは

Mackerel の「check-aws-cloudwatch-logs-insightsプラグインは現在(2020年12月29日時点)β版公開されているもので,CloudWatch Logs Insights 経由で大量のログ監視に有用な機能とされてます.この機能を使って監視を入れてみました.

mackerel.io

プラグインの導入

プラグインの実行環境は CentOS 7 の EC2 です.導入コマンドは下記のコマンドを実行して完了です.mkr コマンドがない場合は導入してから実行します.

sudo mkr plugin install mackerelio-labs/check-aws-cloudwatch-logs-insights@v0.0.2

監視の設定の実施

IAM ロールの設定

EC2 の IAM ロールにlogs:GetQueryResults/logs:StartQuery/logs:StopQuery の権限をつけた IAM ポリシーをアタッチします.検証なのでリソースは絞ってないですが,権限制御する場合はリソースで特定のロググループを指定します(ex. arn:aws:logs:ap-northeast-1:XXXXXXXXXXXX:log-group:/XXXX/access_log:* 等).

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "check-aws-cloudwatch-logs-insights-test",
            "Effect": "Allow",
            "Action": [
                "logs:StartQuery",
                "logs:GetQueryResults",
                "logs:StopQuery"
            ],
            "Resource": "*"
        }
    ]
}

mackerel-agent のコンフィグ定義

監視の設定例はプラグインの紹介記事にも記載がありますが,他のプラグイン同様に/etc/mackerel-agent/mackerel-agent.confで次のような定義を行います.

[plugin.checks.aws-cloudwatch-logs-insights-test]
command = ["/opt/mackerel-agent/plugins/bin/check-aws-cloudwatch-logs-insights", "--log-group-name", "/XXX/access_log", "--filter", "parse '* - * [*] \"* * *\" * * * *' as host, identity, date, method, path, protocol, statuscode, bytes,referer,useragent | sort date desc | filter statuscode like /(4\\d\\d)/" "--critical-over", "10", "--warning-over", "1"]
env = { AWS_REGION = "ap-northeast-1" }
  • --log-group-name で CloudWatch Logs Insights を実行するロググループ名を指定してます.
  • --filter で CloudWatch Logs Insights のクエリ文を書いています.Apache のログフォーマットをパースしてフィルタリングしています.parse 以降の ""ステータスコード4\d\d にはエスケープ文字を追加しないと認識しないため定義しています.後述しますがここが一番苦労した部分です.
  • --critical-over で CloudWatch Logs Insights のクエリの結果の Critical になる件数を定義しています.10件超えたら Critical と言う定義です.
  • --warning-over で CloudWatch Logs Insights のクエリの結果の Warning になる件数を定義しています.1件超えたら Warning と言う定義です.

アラートの設定確認

ステータスコードが4XX 系エラーであれば1件出れば Warning,10件出れば Criticalとしているのですが,mackerel-agent を起動した後アラート一覧の画面をみてみると意図通りアラートが出ているのを確認できました.

f:id:sadayoshi_tada:20201229123644p:plain

設定のよもやま話

上述したように --filter の箇所の定義が一番苦労し,Mackerel User Group の Slack で開発者の id:astj さんに調査サポートいただきました...ここで改めて感謝いたします.ありがとうございました🙇‍♂️

mackerel-ug-slackin.herokuapp.com

一番ハマったのがエスケープ文字の認識のところです.当初は parse 内の [*] の箇所を \\[*\\]のようにしていました.コマンドでの実行(AWS_REGION=ap-northeast-1 /opt/mackerel-agent/plugins/bin/check-aws-cloudwatch-logs-insights --log-group-name=/xxx/access_log --filter="parse '* - * \[\*\]\ \"\* * *\"\ * * * *' as host, identity, date, method, path, protocol, statuscode, bytes,referer,useragent | sort date desc | filter statuscode like /(4\d\d)/")やMackerel のコンフィグ的には通るのですが,ログを見ると CloudWatch Logs Insights OK: 0 messages とでており,ログ検索ができていませんでした.調査をサポートいただき,最終的にエスケープ文字は不要で [*] に戻しています.Mackerel を通した時に CloudWatch Log Insights 側まで \[*\] のフィルターの形で検索してしまっていたため元に戻すことにして意図通りの設定を実現できました.

まとめ

check-aws-cloudwatch-logs-insights」のプラグインを検証した内容をまとめました.意図した監視ができるようになったので本番の方にも組み込んでいきたいと思いますし,改めて Slack のユーザー グループで開発者の方とやりとりできるありがたさを実感しました.もし入ってない方がいれば入って困っていることや悩み事を利用者の皆さんや開発者の皆さんと会話してみると良いかも知れません!

関連記事

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

AWS SSO と GSuite を連携した認証のフローを作ってみよう!

タダです.

自分の会社では AWS アカウントのログイン形式がこれまでは IAM ユーザーによるアカウントに直ログインになっていたのですが,それを AWS SSO を入れてログイン方式を変更しました.ユーザー管理はデフォルトだと ID 管理が SSO で発行されるユーザーになりますが,業務で GSuite を使っているし,GSuite が IdP として使えるため,AWS SSO の IdP を GSuite で設定する場合の検証をしてみました.次の AWS ブログに手順が載っていたのでその内容に沿って検証したことをまとめます.

aws.amazon.com

aws.amazon.com

設定内容

SSO 側からサービスプロバイダー情報をコピーする

SSO 側の IdP を変更するために ID ソースを選択セクションで外部 ID プロバイダーの項目を選択します.次に,サービスプロバイダー情報のうちAWS SSO サインイン URL,AWS SSO ACS URL,AWS SSO 発行者 URLを控えておきます.

f:id:sadayoshi_tada:20201228060510p:plain f:id:sadayoshi_tada:20201228060818p:plain

GSuite でカスタム SAML アプリケーションを設定する

次に,GSuite 側の設定を行います.GSuite の管理画面に移動し,アプリ>SAMLアプリ>アプリを追加>カスタム SAML アプリの追加を選択します.カスタム SAML アプリの設定ウィザードに則って進みます.まずは,アプリ名ですがこれは任意の名前を入力して次に進みます.

f:id:sadayoshi_tada:20201228150432p:plain

次に,SSO の設定で使うため IdP メタデータをダウンロードして次に進みます. f:id:sadayoshi_tada:20201228150529p:plain

次に,サービスプロパイダの詳細設定を行います.SSO の URL を画像の箇所にコピーして転記していきます.署名付き応答にもチェックを入れて次に進み保存します

f:id:sadayoshi_tada:20201228153618p:plain

最後の属性マッピングは何もせず,完了ボタンを押します.これで GSuite の設定完了です.

f:id:sadayoshi_tada:20201228153909p:plain

SSO 側の連携設定

最後に,SSO と GSuite の連携設定を詰めていきます.はじめに GSuite のカスタム SAML アプリケーション追加設定時にダウンロードしていたメタデータをアップロードします.

f:id:sadayoshi_tada:20201228154223p:plain

アップロードが終わったら最後に確認画面です.ID ソースの変更を承認するのでACCEPTと欄に入力して ID ソースを変更します.問題なければ変更が反映されます.

f:id:sadayoshi_tada:20201228154304p:plain f:id:sadayoshi_tada:20201228154637p:plain

動作確認

最後に動作確認をします.SSO のエンドポイント URL https://XXX.awsapps.com/start にアクセスすると GSuite のユーザー認証に飛びます.

f:id:sadayoshi_tada:20201228154456p:plain f:id:sadayoshi_tada:20201228154738p:plain

ユーザー認証後,設定が問題なければ SSO のログイン後ページに遷移することを確認できました.

f:id:sadayoshi_tada:20201228154920p:plain

まとめ

AWS SSO の IdP として GSuite を設定する検証を行ったのでその内容をまとめました.自分が働く会社では GSuite が業務の中心にありその ID も使うので IdP として投入できれば,入社・退社の手続きでアカウントを消すだけで業務アプリケーションのログイン情報も消せてよく,IAM ユーザーによるログイン管理からも開放されるので効果を感じられました.同様の設定を考えられている方の何か参考になれば幸いです.

関連記事

sadayoshi-tada.hatenablog.com

AWS Client VPN のユーザー認証を Active Directory 認証で行う

タダです.

AWS Client VPN の相互認証を検証した時の課題が VPN 接続ログに誰が VPN を使っているかが記録されてなかったことです.ユーザー認証の仕組みは Active Directory 認証と SAML 認証が用意されているのですが,この記事では Active Directory 認証を試した内容をまとめていきます.

docs.aws.amazon.com

検証シナリオ

シナリオとしては,これまで ACM のサーバー及びクライアント証明書による相互認証だったところを Active Directory 認証の基盤として Simple AD を使って認証するように変更しています.Simple AD を新規に作り,その中で認証するユーザーを作成・管理するような形に変更します.それ以外の設定は変わりません.

f:id:sadayoshi_tada:20201228002910p:plain

設定内容

ユーザー認証設定としてやるのは①Simple AD をプライベートサブネットに作成およびユーザーの作成,②ユーザー認証でエンドポイントの再作成および Client VPN 各種再設定です.

①Simple AD をプライベートサブネットに作成およびユーザーの作成

まず,ユーザー認証基盤である Simple AD の作成とユーザーの作成を行います.ただ,この記事では Client VPN の設定部分にフォーカスするようにしたいため,Simple AD の作成やユーザー作成部分は公式ドキュメントの説明に譲り,割愛します.

docs.aws.amazon.com

②ユーザー認証でエンドポイントの再作成および Client VPN 各種再設定

Client VPN エンドポイントを再作成していきます.変わるのは大きく2カ所です.1つは認証オプションをユーザー認証に設定し,①で作成した Simple AD を指定することと,DNS サーバーの箇所に Simple AD の DNS サーバーの IP アドレス2つを記載することが変わりますが,それ以外は初回の記事と同じ設定で定義しました.また,受信の認証ルールおよびルートテーブルも初回と二回目の記事と同様の設定に行いました.

f:id:sadayoshi_tada:20201228001612p:plain f:id:sadayoshi_tada:20201228001739p:plain

動作確認

エンドポイントの設定が完了後クライアント設定ファイルをダウンロードして VPN クライアントアプリのプロファイルを追加しました.接続を試みるとユーザー認証画面が表示されます.Simple AD の Administrator で認証してみます.

f:id:sadayoshi_tada:20201228002119p:plain

認証が成功し,VPN 接続のログを確認してみたところユーザー名の欄に Administrator が表示されているので意図した通りの設定ができました.

f:id:sadayoshi_tada:20201228002330p:plain

まとめ

Client VPN のユーザー認証方式として Active Directory の認証パターンを試したので検証内容をまとめました.Active Directory 認証パターンも試したのですが,もう1つの SAML 認証パターンも試したいと思っており,AWS SSO との連携をしてみたいと考えているのでその内容は次回以降の記事に書いていきます!

関連記事

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

AWS Client VPN の IP アドレスを固定化してインターネットと通信する

タダです.

AWS Client VPN 検証の続きです.前回の記事でプライベートサブネットの EC2 への VPN 接続が可能になりました.次に,VPN を繋いだ IP アドレスで業務システムへのアクセス制限をしたいといった要件で検証した内容です.

sadayoshi-tada.hatenablog.com

検証シナリオ

Client VPN が接続できるネットワークと分離した社内のシステム用のネットワークがあると仮定します.要件として ELB + EC2 の業務システムにアクセスできる IP を絞りたいというものがあります.そこで,Client VPN に繋いでインターネットと通信する際は NAT Gateway を経由させることで IP アドレスを固定化します.

f:id:sadayoshi_tada:20201227185255p:plain

パブリックサブネットに Client VPN を関連づけることでインターネットに通信を出すことができますが,接続時にネットワークインターフェースが変わってグローバル IP アドレスも変わってしまうため固定化するために NAT Gateway を使っています.

f:id:sadayoshi_tada:20201227200427p:plainf:id:sadayoshi_tada:20201227200437p:plain

設定内容

前回記事内容に追加する形で設定を行う場合を想定します.やるのは①NAT Gateway をパブリックサブネットに作ってプライベートサブネットのルートテーブルに関連づける,②ルートテーブルと受信の承認ルールの変更する

①NAT Gateway をパブリックサブネットに作ってプライベートサブネットのルートテーブルに関連づける

NAT Gateway を作成し,パブリックサブネットに作ります.作成後,パブリックサブネットが使っているルートテーブルに関連づけます.設定の詳細は下記の解説ページに譲り割愛します.

aws.amazon.com

②ルートテーブルと受信の承認ルールの変更する

受信の承認ルールに0.0.0.0/0 の許可を追加します.ルートテーブルにも同様に0.0.0.0/0 の経路を追加します.

f:id:sadayoshi_tada:20201227203227p:plain

f:id:sadayoshi_tada:20201227203454p:plain

動作確認

NAT Gateway を経由できているのであれば,インターネットに接続できて EIP のアドレスで通信するはずです.検証用に NAT Gateway には 3.113.152.210 を EIP を設定しているので, 使用中の IP アドレス確認をしてみます.

意図通りの設定ができていることを確認できました.

f:id:sadayoshi_tada:20201227203856p:plain

まとめ

今回は,Client VPN を使いつつ IP アドレスの固定化を行ってみました.相互認証での検証は以上になるのですが,相互認証方式だと1つ課題があります.それは接続のログにユーザー名が表示されないことです.この課題を次の記事でユーザー認証方式に切り替えた内容でまとめます.

f:id:sadayoshi_tada:20201227204212p:plain