[アップデート]Amazon Redshiftへのカスタムドメイン(CNAME)接続が可能に!SSL通信もサポート!
Amazon Redshiftは、ユーザーが独自のドメインを使用してクラスターのエンドポイントに接続する機能に対応しました。この機能はCNAMEレコードを通じて設定され、TLS(SSL)での安全な接続も可能です。
- Redshiftクラスター変更時もエンドポイントを一貫して管理したい
- サービス用のドメインでアクセスさせたい
- Redshift独自のエンドポイントを隠蔽したい
といったケースで有用です。
ポイント
本機能のポイントを列挙します。
- Redshift側での追加料金は発生しない
- プロビジョンド型とサーバーレス型の両方のクラスターで使用可能
- カスタムドメインでSSL(TLS)接続を行うため証明書が必要
- DNSサーバーに加え、Redshiftクラスターでの設定変更が必要
- プロビジョンドクラスターではリロケーションの有効化が必要
- つまり、リロケーションをサポートするRA3ノードタイプでのみ利用可能であり、サポートしないDC2ノードタイプなどでは使用できない
sslmode=verify-full
モードでデフォルトエンドポイントにSSL接続すると、証明書と接続先のドメインが異なるためエラーが発生する
Redshiftにカスタムドメインを設定して接続する
Route 53でDNS管理し、ACMでSSL証明書管理する前提で、本機能を有効化してみます。
1. Redshiftの起動
まずはRedshiftを起動します。
クラスターの種類は、provisionedとserverlessのどちらでも構いません。
provosionedの場合、リロケーションに対応したノードタイプ、具体的には、RA3を選択ください。DC2はリロケーションに未対応です。
クラスター起動完了後、Redshiftのエンドポイントを控えます。
この時点では、クラスターのCustom domain nameはブランク(-)です。
2. RedshiftのエンドポイントをCNAME登録
Redshiftのエンドポイントを CNAME レコードとしてDNS登録します。
Route 53を利用している場合でも、ALIASレコードではなくCNAMEで登録します。
3. SSL 証明書を取得
カスタムドメインを所持していることの確認、及び、カスタムドメインへの通信をセキュアにするために、カスタムドメインに対応するSSL証明書が必要です。
Amazon Redshift or Amazon Redshift Serverless require a validated Secure Sockets Layer (SSL) certificate for a custom endpoint to keep communication secure and to verify ownership of the domain name.
https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-connection-CNAME-security.html
AWS環境では、ACM で簡単に取得出来ます。
redshift.example.com
のようなカスタムドメインに対して、既存のワイルドカード証明書(*.example.com
)を適用して問題有りません。
4. Redshiftにカスタムドメインを設定
最後に、Redshiftにカスタムドメインを割り当てます。
サーバーレス型を例にすると、ワークグループのメニューから"Create custom domain name"を選択し、カスタムドメインと対応するSSL証明書を指定します。
有効化後は、RedshiftのGeneral Informationにカスタムドメインを確認出来ます。
リロケーションが無効なプロビジョンド・クラスターに対してカスタムドメインを追加すると、以下のエラー・メッセージが表示されます。
Relocation is not enabled on cluster redshift-test, please enable it first before using came.
クラスターのノードタイプがリロケーションに対応していない場合、リロケーション有効時に以下のエラー・メッセージが表示されます。
If the cluster node type isn't RA3, avallability zone relocation isn't supported.
5. Redshiftにカスタムドメインで接続
Redshift にカスタムドメイン経由で接続してみましょう。
$ CUSTOM=redshift.example.com $ psql -h $CUSTOM -d dev -U admin -p 5439 -W ... dev=#
無事成功です。
デフォルト・エンドポイントに sslmode=verify-full でSSL接続できない
PostgreSQLでは、サーバー接続時にサーバー証明書を検証してよりセキュアにSSL接続するsslmode
オプションが存在します。
代表的なモードは次の2つです
verify-ca
: 証明書が信頼される認証局から発行されているか検証verify-full
:verify-ca
にプラスして、接続先ホスト名が証明書と一致するか検証
カスタムドメインを有効にしてデフォルトのエンドポイントに接続すると、証明書のホスト名(*.example.com
)と通信するホスト名(XXX.REGION.redshift.amazonaws.com
)が一致しないため、verify-full
モードではエラーが発生することにご注意ください。
デフォルトエンドポイント | カスタムドメイン | |
---|---|---|
verify-ca | 成功 | 成功 |
verify-full | エラー | 成功 |
$ # https://www.amazontrust.com/repository/ $ wget https://www.amazontrust.com/repository/SFSRootCAG2.pem $ DEFAULT=test-cluster.xxx.ap-northeast-1.redshift.amazonaws.com $ psql -h $DEFAULT \ "dbname=dev user=awsuser sslrootcert=SFSRootCAG2.pem sslmode=verify-full port=5439" psql: error: connection to server at "test-cluster.xxx.ap-northeast-1.redshift.amazonaws.com" (172.31.32.137), port 5439 failed: server certificate for "*.example.co" does not match host name "test-cluster.xxx.ap-northeast-1.redshift.amazonaws.com"
カスタムドメインを別クラスターに付け替える
カスタム・ドメインに紐づくクラスター(ワークグループ)をBlue/Greenデプロイメントのように切り替えたい場合、以下の手順で行います。
- 古いクラスターからカスタムドメインを削除
- CNAMEレコードを新しいクラスターのエンドポイントに変更
- 新しいクラスターでカスタムドメイン設定
アトミックな切り替えには対応していないものの、軽微なメンテナンス時間で対応できるでしょう。
最後に
Amazon Redshiftのエンドポイントにユーザー独自のカスタムドメインで接続できるようになりました。
Redshiftインスタンスを透過に一貫したカスタムドメインでSSL接続できるため、運用負荷の軽減が期待出来ます。 プロビジョンド・クラスターの場合、リロケーションに対応していない DC2 ノードタイプなどでは利用できない点にはご注意ください。
それでは。