AWS Verified AccessでGoogle認証を使って、ユーザーごとにEC2へのアクセス制御をしてみた
こんにちは、ゲームソリューション部のsoraです。
今回は、AWS Verified AccessでGoogle認証を使って、ユーザーごとにEC2へのアクセス制御をしてみたことについて書いていきます。
構成
今回構築したのは以下の構成です。
プライベートサブネットに配置した2つのEC2に対して、Verified Access経由でアクセスします。
Google CloudのOAuthクライアントを作成して、Google認証を行い、Verified Accessのポリシーに従ってエンドポイントごとにアクセス制御を行います。
Verified Accessの構成要素は以下です。
グループのポリシーはGoogle認証をしたユーザーのみがアクセスできる形とします。
その先のエンドポイントとして、管理者用とユーザー用の2つを作成して、管理者用のエンドポイントでは特定のメールアドレスのユーザーしか通さないようにします。
事前準備
事前に準備していたものは以下です。
特にエンドポイントに紐付けるドメインとACMは必要になるため、事前に準備しておく必要があります。
- VPC・サブネット
- ドメイン（Route53）
- SSL/TLS証明書（ACM）
構築
EC2
まず接続先のEC2を管理者用とユーザー用の2台をプライベートサブネットに作成しました。
テスト用のため、Nginxをインストールして、管理者用とユーザー用で別の文字が表示されるようにしました。
dnf install -y nginx
echo "<h1>Admin Page</h1>" > /usr/share/nginx/html/index.html
systemctl start nginx
systemctl enable nginx
dnf install -y nginx
echo "<h1>App Page</h1>" > /usr/share/nginx/html/index.html
systemctl start nginx
systemctl enable nginx
セキュリティグループは、Verified AccessエンドポイントからのHTTPを許可しておきます。
Google CloudのOAuth2.0クライアント
Verified Access信頼プロバイダーから認証を行うために、OAuth2.0クライアントを作成します。
IAM Identity Centerでも可能なのですが、アカウントインスタンスは利用できなくて、組織インスタンスが必要であったため、今回はOAuth2.0クライアントにしました。
Google CloudのGoogle Auth Platformのクライアントから作成するのみであるため、手順は割愛します。
設定項目について、承認済みのリダイレクトURIはVerified Access エンドポイント作成後に設定するため、最初は空欄で設定します。
クライアントIDとクライアントシークレットは、Verified Access信頼プロバイダー作成時に必要なため、メモしておきます。
Verified Access信頼プロバイダー
VPCのVerified Access 信頼プロバイダーから作成します。
ポリシー参照名は任意の文字列、信頼プロバイダータイプは今回Google認証のためOIDCを選択します。
クライアントIDとクライアントシークレットは、先ほどOAuth2.0クライアントを作成したときに表示された値を入力します。
Verified Accessインスタンス
VPCのVerified Access インスタンスから作成します。
こちらは先ほど作成したVerified Access信頼プロバイダーを選択して作成します。
Verified Accessグループ
VPCのVerified Access グループから作成します。
Verified Accessインスタンスとして先ほど作成したものを設定して、ポリシーはGoogle認証したユーザーのみとします。
permit(principal, action, resource)
when {
context.google_oidc.email_verified == true
};
Verified Accessエンドポイント
VPCのVerified Access エンドポイントから作成します。
今回はHTTPで設定して、エンドポイントタイプはロードバランサーではなくネットワークインターフェイスを選択します。
エンドポイントのプレフィックスはなんでも良いのですが、それぞれadminとappとします。
ドメインやドメイン証明書の部分には、事前準備してあるドメインを入力、証明書を選択します。
ポリシーは管理者用のエンドポイントでは、特定のアドレスのみ許可するように設定します。
ユーザー用のエンドポイントでは、制限をかけずに許可します。
アクセスが許可されるには、グループのポリシーとエンドポイントのポリシーの両方で許可される必要があります。
permit(principal, action, resource)
when {
context.google_oidc.email == "xxxxx@xxxxxx.com"
};
permit(principal, action, resource)
when {
true
};
エンドポイント作成後、ステータスがActiveになるまで待ちます。（私は10分程度かかりました。）
エンドポイント作成後に表示されるエンドポイントドメインを、Google CloudのOAuth2.0クライアントの承認済みのリダイレクトURIに設定しておきます。
Route 53の設定
各Verified Accessエンドポイントのドメインを、Route53のCNAMEレコードで紐付けます。
動作確認
まず管理者用のドメインにアクセスしてみると、Google認証の画面が出ました。
管理者用のエンドポイントで許可したアドレスでログインしてみると、Admin Pageの文字列が表示されました。
ユーザー用のドメインにもアクセスしてみると、App Pageの文字列が表示されています。
管理者用のエンドポイントで許可していないGoogleアカウントでログインしても同様に表示されました。
管理者用のエンドポイントで許可していないGoogleアカウントで管理者用のドメインにアクセスしてみると、Admin Pageの文字列が表示されずに拒否されていることも確認できました。
最後に
今回は、AWS Verified AccessでGoogle認証を使って、ユーザーごとにEC2へのアクセス制御をしてみたことを記事にしました。
どなたかの参考になると幸いです。
