いわさです。
最近、検証のために Verified Access を作ったり壊したりを繰り返しています。
利用料金が気になるので検証が終わったらすぐにリソースを削除しておきたいところです。
ただ、検証用途で繰り返し作成する場合は、毎回マネジメントコンソール上で操作するのではなく出来ればコード化しておきたいところです。
しかし、本日時点で Verified Access は CloudFormation にまだ対応していません。
ただし、リソース操作の API 自体は用意されており、本日時点では AWS CLI v1 で操作可能です。(v2 は使用出来ない)
今回は AWS CLI で構築してみました。なお v1 を使う関係で以下を参考にしています。
EC2 コマンドのサブコマンドとしてverified-access
を含む 24 個の API が追加されています。
CloudFormation でサポートされれば、出番は少なくなるかもしれませんけども。
AWS CLI で構築するにあたっての前提
Verified Access はそれ単独では動作出来なくて、Verified Access エンドポイントへの名前解決・SSL証明書・プライベートネットワークと Web アプリケーションが必要です。
これらについては今回はコード化の対象にしていません。
Route 53 と ACM については事前に準備済みとします。
プライベートアプリケーションと外部 IdP (Azure AD) についても事前に準備済みです。詳しくは以下の記事を参照してください。
Azure AD アプリケーションは前回使ったものをそのまま使うことにしました。
プライベートアプリケーションは上記記事内に CloudFormation テンプレートを用意しています。
デプロイすると以下の情報がスタックから取得出来て、Verified Access エンドポイント構築時に使用します。
% rain deploy template.yaml hoge0502app -r us-east-1
Enter a value for parameter 'BaseAMI' (default value: /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2):
CloudFormation will make the following changes:
:
Stack hoge0502app: CREATE_COMPLETE
Outputs:
LoadBalancerArn: arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/hoge0502app-internal-alb/64521aef57defdd3
HogeSecurityGroup: sg-089c11d8aa7a732ad
SubnetId2: subnet-0c17f52f13b198be1
SubnetId1: subnet-0c3c71276f27eec8f
Successfully deployed hoge0502app
Verified Access 作成
事前準備が終わっていればそれぞれのリソースを作成するのですが、リソースに依存関係があるので作成順序に気をつける必要があります。
依存リソースの情報を直接パラメータで指定するものもあれば、指定しないものもあります。
作成時は次のようにグループ作成前に、インスタンスへ信頼プロバイダーをアタッチしておくくらいでしょうか。
Must attach a TrustProvider to Instance vai-05b3bfffca49b391c before you can create a Group
Verified Access インスタンス作成
% cat create-verified-access-instance.json
{
"Description": "hoge0501service"
}
% aws-v1 ec2 create-verified-access-instance --cli-input-json file://create-verified-access-instance.json --region us-east-1
{
"VerifiedAccessInstance": {
"VerifiedAccessInstanceId": "vai-05b3bfffca49b391c",
"Description": "hoge0501service",
"VerifiedAccessTrustProviders": [],
"CreationTime": "2023-05-01T20:24:18",
"Tags": []
}
}
上記ハイライトのインスタンス ID は後ほど使用します。
Verified Access 信頼プロバイダー作成(OpenID Connect)
今回は Azure AD と統合するので OpenID Connect 用のパラメータになっています。
別の形式の場合は次のパラメータファイルの内容が変わります。
% cat create-verified-access-trust-provider.json
{
"TrustProviderType": "user",
"UserTrustProviderType": "oidc",
"OidcOptions": {
"Issuer": "https://login.microsoftonline.com/11111111-2222-3333-4444-555555555555/v2.0",
"AuthorizationEndpoint": "https://login.microsoftonline.com/11111111-2222-3333-4444-555555555555/oauth2/v2.0/authorize",
"TokenEndpoint": "https://login.microsoftonline.com/11111111-2222-3333-4444-555555555555/oauth2/v2.0/token",
"UserInfoEndpoint": "https://graph.microsoft.com/oidc/userinfo",
"ClientId": "55555555-4444-3333-2222-111111111111",
"ClientSecret": "hogehoge",
"Scope": "openid"
},
"PolicyReferenceName": "hoge0502policy"
}
% aws-v1 ec2 create-verified-access-trust-provider --cli-input-json file://create-verified-access-trust-provider.json --region us-east-1
{
"VerifiedAccessTrustProvider": {
"VerifiedAccessTrustProviderId": "vatp-07cb626b19ac88efa",
"Description": "",
"TrustProviderType": "user",
"UserTrustProviderType": "oidc",
"OidcOptions": {
"Issuer": "https://login.microsoftonline.com/11111111-2222-3333-4444-555555555555/v2.0",
"AuthorizationEndpoint": "https://login.microsoftonline.com/11111111-2222-3333-4444-555555555555/oauth2/v2.0/authorize",
"TokenEndpoint": "https://login.microsoftonline.com/11111111-2222-3333-4444-555555555555/oauth2/v2.0/token",
"UserInfoEndpoint": "https://graph.microsoft.com/oidc/userinfo",
"ClientId": "55555555-4444-3333-2222-111111111111",
"ClientSecret": "REDACTED",
"Scope": "openid"
},
"PolicyReferenceName": "hoge0502policy",
"CreationTime": "2023-05-01T20:32:44",
"Tags": []
}
}
上記ハイライトの信頼プロバイダー ID は後ほど使用します。
Verified Access インスタンスへ信頼プロバイダーをアタッチする
信頼プロバイダーは独立していて、Verified Access の各リソースと紐付かない状態で存在することが出来ます。
インスタンスで実際に使用する際にはアタッチを行う必要があります。
% cat attach-verified-access-trust-provider.json
{
"VerifiedAccessInstanceId": "vai-05b3bfffca49b391c",
"VerifiedAccessTrustProviderId": "vatp-07cb626b19ac88efa"
}
% aws-v1 ec2 attach-verified-access-trust-provider --cli-input-json file://attach-verified-access-trust-provider.json --region us-east-1
{
"VerifiedAccessTrustProvider": {
:
},
"VerifiedAccessInstance": {
:
}
}
Verified Access グループ作成
グループ作成時には先程使用したインスタンス ID を入力パラメータとして指定します。
また、今回はポリシーをこの時点で指定しています。ここでは省略して後ほど Update しても良いです。
% cat create-verified-access-group.json
{
"VerifiedAccessInstanceId": "vai-05b3bfffca49b391c",
"PolicyDocument": "permit(principal,action,resource) when { true };"
}
% aws-v1 ec2 create-verified-access-group --cli-input-json file://create-verified-access-group.json --region us-east-1
{
"VerifiedAccessGroup": {
"VerifiedAccessGroupId": "vagr-041da360dd968e65d",
"VerifiedAccessInstanceId": "vai-05b3bfffca49b391c",
"Description": "",
"Owner": "123456789012",
"VerifiedAccessGroupArn": "arn:aws:ec2:us-east-1:123456789012:verified-access-group/vagr-041da360dd968e65d",
"CreationTime": "2023-05-01T20:40:40",
"Tags": []
}
}
また、出力のグループ ID は、次のエンドポイント作成で使用します。
Verified Access エンドポイント作成
今回はテンプレートのプライベートアプリケーションを対象にしているので、Application Load Balancer (internal) をターゲットに指定しています。
前提条件で取得した、ACM の ARN、Verified Access 用のアプリケーションドメイン、Verified Access 用のセキュリティグループ、ターゲットのロードバランサー ARN とセキュリティグループを指定します。
% cat create-verified-access-endpoint.json
{
"VerifiedAccessGroupId": "vagr-041da360dd968e65d",
"EndpointType": "load-balancer",
"AttachmentType": "vpc",
"DomainCertificateArn": "arn:aws:acm:us-east-1:123456789012:certificate/47b9e1c1-6c21-431f-ba7c-84c89500f0d6",
"ApplicationDomain": "hoge0502.tak1wa.com",
"EndpointDomainPrefix": "hoge0502",
"SecurityGroupIds": [
"sg-089c11d8aa7a732ad"
],
"LoadBalancerOptions": {
"Protocol": "http",
"Port": 80,
"LoadBalancerArn": "arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/hoge0502app-internal-alb/64521aef57defdd3",
"SubnetIds": [
"subnet-0c17f52f13b198be1",
"subnet-0c3c71276f27eec8f"
]
}
}
% aws-v1 ec2 create-verified-access-endpoint --cli-input-json file://create-verified-access-endpoint.json --region us-east-1
{
"VerifiedAccessEndpoint": {
"VerifiedAccessInstanceId": "vai-05b3bfffca49b391c",
"VerifiedAccessGroupId": "vagr-041da360dd968e65d",
"VerifiedAccessEndpointId": "vae-0e45659caa8bd4710",
"ApplicationDomain": "hoge0502.tak1wa.com",
"EndpointType": "load-balancer",
"AttachmentType": "vpc",
"DomainCertificateArn": "arn:aws:acm:us-east-1:123456789012:certificate/47b9e1c1-6c21-431f-ba7c-84c89500f0d6",
"EndpointDomain": "hoge0502.edge-0c6233b9192080f3b.vai-05b3bfffca49b391c.prod.verified-access.us-east-1.amazonaws.com",
:
}
}
CNAME レコード登録とリダイレクト URI の登録(手動)
上記ハイライト部分のエンドポイントドメインの CNAME レコードを DNS へ登録し、アプリケーションドメインのリダイレクト URI を IdP 側(Azure AD)に登録します。
ここは手動です。
アクセス確認
ここまでで基本的な構築は完了しました。
アプリケーションドメインへアクセスしてみましょう。
Azure AD の認証が要求されました。
サインインしてみましょう。
内部アプリケーションにアクセス出来ましたね。やったー。
ログ記録も設定する
Verified Access ではログ機能が備わっているのですが、デフォルトは OFF となっています。
そして、作成時のパラメータではどうやらログ機能の有効化は出来ない模様です。
なのでmodify-verified-access-instance-logging-configuration
を使ってログ構成を変更してやります。
まずはデフォルト OFF の状態を確認してみます。
% aws-v1 ec2 describe-verified-access-instance-logging-configurations --region us-east-1
{
"LoggingConfigurations": [
{
"VerifiedAccessInstanceId": "vai-05b3bfffca49b391c",
"AccessLogs": {
"S3": {
"Enabled": false
},
"CloudWatchLogs": {
"Enabled": false
},
"KinesisDataFirehose": {
"Enabled": false
}
}
}
]
}
オフになっていますね。
次のコマンドで有効化します。
今夏いは CloudWatch Logs を対象にしてみますので、事前にロググループを作成しておきます。
ロググループに特にプレフィックス制限などはないようです。
# ロググループ作成
% aws-v1 logs create-log-group --log-group-name hoge0502verified --region us-east-1
# ログ有効化
% cat modify-verified-access-instance-logging-configuration.json
{
"VerifiedAccessInstanceId": "vai-05b3bfffca49b391c",
"AccessLogs": {
"CloudWatchLogs": {
"Enabled": true,
"LogGroup": "hoge0502verified"
}
}
}
% aws-v1 ec2 modify-verified-access-instance-logging-configuration --cli-input-json file://modify-verified-access-instance-logging-configuration.json --region us-east-1
{
"LoggingConfiguration": {
"VerifiedAccessInstanceId": "vai-05b3bfffca49b391c",
"AccessLogs": {
"S3": {
"Enabled": false
},
"CloudWatchLogs": {
"Enabled": true,
"DeliveryStatus": {
"Code": "success"
},
"LogGroup": "hoge0502verified"
},
"KinesisDataFirehose": {
"Enabled": false
}
}
}
}
マネジメントコンソールからログが出力されていることも確認出来ました。
Verified Access 削除
冒頭お伝えしたとおり、用途として作ったり消したりを繰り返すことを想定しています。
そのため削除もしっかりやっておきます。
ただし、削除はリソースが依存しあっているので順序が大事です。
削除順序としては以下である必要があります。
- エンドポイント削除(delete-verified-access-endpoint)
- グループ削除(delete-verified-access-group)
- 信頼プロバイダーをインスタンスからデタッチ(detach-verified-access-trust-provider)
- インスタンスを削除(delete-verified-access-instance)
信頼プロバイダーの削除(delete-verified-access-trust-provider)はデタッチ後であればいつでも良いですし、しなくても良いです。
以下のエラーメッセージが出力された方は上記順序を気にしてみてください。
- An error occurred (InvalidParameterValue) when calling the DeleteVerifiedAccessInstance operation: Verified Access Instance vai-05b3bfffca49b391c has trust providers attached and cannot be deleted.
- An error occurred (VerifiedAccessGroupAttachmentExists) when calling the DetachVerifiedAccessTrustProvider operation: VerifiedAccessInstance vai-05b3bfffca49b391c is not empty. Please remove all VerifiedAccessGroups before attaching or detaching a VerifiedAccessTrustProvider with TrustProviderType user
- An error occurred (InvalidParameterValue) when calling the DeleteVerifiedAccessGroup operation: VerifiedAccessGroup vagr-041da360dd968e65d is not empty. Please remove all VerifiedAccessEndpoints before deleting.
エンドポイント削除
% cat delete-verified-access-endpoint.json
{
"VerifiedAccessEndpointId": "vae-0e45659caa8bd4710"
}%
% aws-v1 ec2 delete-verified-access-endpoint --cli-input-json file://delete-verified-access-endpoint.json --region us-east-1
{
"VerifiedAccessEndpoint": {
:
}
}
グループ削除
% cat delete-verified-access-group.json
{
"VerifiedAccessGroupId": "vagr-041da360dd968e65d"
}
% aws-v1 ec2 delete-verified-access-group --cli-input-json file://delete-verified-access-group.json --region us-east-1
{
"VerifiedAccessGroup": {
:
}
}
信頼プロバイダーをインスタンスからデタッチ
% cat detach-verified-access-trust-provider.json
{
"VerifiedAccessInstanceId": "vai-05b3bfffca49b391c",
"VerifiedAccessTrustProviderId": "vatp-07cb626b19ac88efa"
}
% aws-v1 ec2 detach-verified-access-trust-provider --cli-input-json file://detach-verified-access-trust-provider.json --region us-east-1
{
"VerifiedAccessTrustProvider": {
:
}
}
インスタンス削除
% cat delete-verified-access-instance.json
{
"VerifiedAccessInstanceId": "vai-05b3bfffca49b391c"
}
% aws-v1 ec2 delete-verified-access-instance --cli-input-json file://delete-verified-access-instance.json --region us-east-1
{
"VerifiedAccessInstance": {
:
}
}
信頼プロバイダーの削除
% cat delete-verified-access-trust-provider.json
{
"VerifiedAccessTrustProviderId": "vatp-07cb626b19ac88efa"
}
% aws-v1 ec2 delete-verified-access-trust-provider --cli-input-json file://delete-verified-access-trust-provider.json --region us-east-1
{
"VerifiedAccessTrustProvider": {
:
}
}
さいごに
本日は AWS Verified Access のリソース一式を AWS CLI で作成・削除してみました。
よく聞く話ですが CLI で一通り実施してみるとリソースの依存関係などが理解出来ておもしろかったです。
Verified Access は登場コンポーネント多くて混乱するので CLI 通して理解するのは良いです。