先日7/18に開催された関西Ruby会議09でLTをしてきました。Aurora MySQL v8.4で変わったTLSと認証プラグインのデフォルト設定について、Rails側で何が必要になるかを話しました。
登壇スライド
スライド「Aurora MySQL 8.4リリース！ Rubyistが備えること」はこちらです。 speakerdeck.com
登壇のキッカケと登壇内容を決めた背景
6月の頭頃にコミュニティから、LT企画してるけど大阪枠でどう？と声を掛けてもらったことがキッカケです。内容に縛りはないけどRailsのDB周りの話を聴きたいなっていうリクエストをもらって話を考えました。LTなのでエンタメ寄りも考えましたが、自分のスタイルでは難しそうだったので、参加者のお土産になる実用的な話にしました。題材にはちょうど5月にリリースされたばかりのAurora MySQL v8.4を選び、Ruby / Rails 関連で必要になる対応を調査することにしました。
登壇内容について
タイトルの通り、5月にリリースされた Aurora MySQL v8.4 の変更点の内、Ruby / Rails を使うアプリケーションエンジニアが対応に迫られそうなものを Aurora MySQL 8.4.7, May 21, 2026 - Amazon Aurora からピックアップしてセキュリティ関連で接続できなくなる類の「TLS」「認証プラグイン」のデフォルト設定変更について紹介しました。
本題に入る前に、まずAurora MySQL v8.4のバージョニング上の位置づけについて触れておきます。
Aurora MySQL v8.4のLTS版はまだ公開されていない
スライドでも触れてたようにこのAurora MySQL v8.4 は現状LTS版ではないので急いでバージョンアップする必要はありません。しばらくは現最新LTSの Aurora MySQL v3.10(MySQL v8.0互換)を使うほうがサポート期間も長いので安全だと思います。実際、v8.4.7 の標準サポート終了が2027年11月30日、v3.10 は2028年4月30日で新しいはずの v8.4.7 のほうが先に切れます。
Vanilla MySQL v8.0がこの4月にEOLを迎えていたこともあり本当に待望だったんですよね。
TLS のデフォルト設定のハマりポイント
require_secure_transport のデフォルト値がローカルのVanilla MySQL v8.4 と本番環境のAurora MySQL v8.4で異なるのが1つハマりそうなポイントです。ローカルでは接続できていたのに本番でだけ次のエラーが出る、という形で踏むことになります。
Connections using insecure transport are prohibited while --require_secure_transport=ON. (ActiveRecord::ConnectionNotEstablished)
※利用アダプタによってメッセージに追記があります
本番と同様にTLS必須にするため、ローカル環境ではrequire_secure_transportを明示的にONにしておく必要があります。
データベースアダプターに trilogy を使うかmysql2を使うかによってssl_modeのデフォルト値が異なりますが、TLS必須化に合わせる場合は、ssl_modeをrequired以上に設定しておけば良いと思います。verify_ca、verify_identity にするかは要件次第ですね。
ちなみに mysql2 のデフォルト値は Oracle libmysqlclient 8.0.46 で preferred、MariaDB Connector/C 3.4.9 で disabled 相当となっていました。MariaDB Connector/C の場合は verify_ca を指定しても CA検証されない不具合もあったので、mysql2 を使っている方は別途検証した記事も読んでみてください。
また CA検証のパス設定がtrilogyでssl_ca、mysql2でsslcaと異なるのでそこも注意が必要です。
database.ymlの設定例はこんな形になります。
default: &default adapter: trilogy # mysql2利用時は mysql2 に修正 # 本番 production: <<: *default ssl_mode: verify_identity ssl_ca: /path/to/global-bundle.pem # mysql2 では sslca # ローカル開発 development: <<: *default ssl_mode: required
デフォルト認証プラグインの変更
MySQLはアカウント毎に認証プラグインの設定を持ち、その認証プラグインによって認証のフローが異なります。 アカウント作成時にデフォルトで設定される認証プラグインがmysql_native_passwordからcaching_sha2_passwordに変わりました。
認証プラグイン毎のフローは登壇に収まりきらなかったため、別記事にまとめているので興味を持った人は読んでみてください。 fkmy.hatenablog.com
認証プラグインの選択はDB側の責務なので、クライアント側ではtrilogy・mysql2がcaching_sha2_passwordに対応していれば十分です。gemを最新に追随させていれば特に対応は不要です。trilogyで非TLS接続でcaching_sha2_passwordを扱えるようになったのは今年に入ってからで、わりと最近です。TLS接続なら v2.8.0 以降、非TLS接続なら v2.11.0 以降が必要になります。
とはいえ、Vanilla MySQL v8.0では既に認証プラグインのデフォルトはcaching_sha2_passwordに変わっています。Aurora MySQL v3 をお使いの方はローカルもv8.0系のはずなのでローカル環境のユーザーが既に caching_sha2_password になっていて、gem のバージョンアップ対応は不要というケースが多いと思います。
これはDB管理者側の領分なので触れなかったけど、既存のmysql_native_password設定済みユーザーは現状のままで使えます。ただしVanilla MySQL v9.xで mysql_native_password は廃止済みなので、そのうちAurora MySQL でも削除されると思うんですよね。Admin相当のユーザーなど過去作成されたユーザーは意図的に変更していない限り、mysql_native_passwordが設定されていると思うので廃止されるまでにはcaching_sha2_passwordへの移行を済ませておく必要がありそうです。
まとめ
オプティマイザの挙動変更によるクエリ性能の変化などは検証したほうが良いですが、Aurora MySQL v8.4に備えて必要な対応は思っていたよりも多くはなさそうです。
Kaigi Effect
登壇のために trilogyリポジトリを調査していたときに、4月にMySQL 9.7がリリースされているのにCIの9系のテストが9.6のままなことに気付きました。何か意図があって9.7にしてないのかなとモヤモヤしながら、PRを送るのはやめていました。
懇親会でtrilogyやmysql2にもコントリビュートされている@yahondaさんにこの疑問を話したところ「他意はなくやってないだけだと思う、PRを送ってみるといいよ」と言われ、翌日にPRを送ったところ無事にその日中にマージされました 🎉
その対応中にmacOSのCIが古いopenssl@1.1を参照したままコケていることに気付いたので、そちらも併せてPRを出してマージされました。
ということで、懇親会での何気ない会話がOSS貢献につながる、いわゆる Kaigi Effect を私も体験できました！
登壇した感想
緊張しすぎて思ってた通りに話が全然できなかったのが一番の後悔でしたね。登壇の度に緊張してうまく喋れないことが続いているので何とかできないものか…と思うばかりです。タイマーを設定するつもりだったのを忘れたのが余計にテンパった要因かもしれません。とはいえ、最後のスライドまで走り切ることはできたのでいちおうは成功でしょうか。
登壇キッカケで良いこともありました。Aurora MySQL v8.4へのアップグレードまでに何をする必要があるかを理解できたのはよかったですし、特にTLS有効化によってハマりかねないポイントとMySQLの認証プラグインについての理解を深められたのは収穫でした。 また登壇後に@yahondaさんに声を掛けてもらって「良い登壇内容だった」と言ってもらえたので一番嬉しい思い出にもなりました。mysql2やtrilogyについても会話できそれキッカケで trilogy にもコントリビュートできたので登壇してよかったです。
これから先 Aurora MySQL v8.4のLTS版が公開され、いよいよバージョンアップするとなったタイミングで誰かの調査が楽になれば幸いです。
