🔐

dbt Cloud環境の認証方式をユーザー名&パスワードからキーペア認証に変更する

に公開
Snowflake
dbt
tech

こちらの対応、そろそろ対応しないといけない頃合いになって来たかと思います。皆様いかがお過ごしでしょうか。

  • [Snowflake、2025年11月までに単一要素パスワード認証をブロック]

https://www.snowflake.com/ja/blog/blocking-single-factor-password-authentification/

https://zenn.dev/dataheroes/articles/fa0b8c9b0017bb

かくいう私も「"多要素認証によるユーザーログイン対応"を済ませたSnowflake環境」に対し、「そのSnowflake環境を利用しているdbt Cloud環境の多要素認証対応」についても対処せざるを得なくなりました。以前投稿した時に作っていた(使っていた)環境を従来のユーザー名&パスワード認証から多要素認証に変更しないといけなくなった感じです。

https://zenn.dev/truestar/articles/85539155d9d7c6

そんな訳で当エントリでは従来パスワード認証方式で連携していたSnowflake＋dbt Cloud環境の接続内容をキーペア認証方式に切り替えた際の手順について、備忘録として残しておこうと思います。

時系列と状況を整理

上記状況をもう少し時系列的に整理するとこんな感じです。

  • 従来Snowflake環境を利用していた(パスワード認証でアクセス)
    • この環境を参照する形でdbt Cloud環境も利用していた
  • Snowflake環境について、先行してログインして操作を行うユーザー(人間)に対して多要素認証対応を行った
  • 上記の状況でdbt Cloud環境の操作を行う。当然ながら認証部分でコケてしまっている
  • Snowflakeの対応に合わせる形で、dbt Cloud側も多要素認証に対応しないとね！【←今ココ】

実践内容：概要

この状況に対し、今回実践したのは以下内容です。

  • dbt Cloud利用部分に関する認証方式は「キーペア認証」を採用
  • ローカル環境下で今回の設定に利用する秘密鍵と公開鍵を作成
  • ケース1: 既存ユーザー(TYPE = PERSON)に対する認証設定でdbt Cloud側の連携に対応
    • 開発環境の連携設定を切替
    • 本番環境の連携設定を切替
  • ケース2: 新規ユーザー(TYPE = SERVICE)に対する認証設定でdbt Cloud側の連携に対応
    • 本番環境の連携設定を切替

実践手順

キーペア認証に用いる「秘密鍵」と「公開鍵」を作成

手順に倣い秘密鍵と公開鍵を作成。まずは秘密鍵から。

% openssl genrsa 2048 | openssl pkcs8 -topk8 -v2 des3 -inform PEM -out rsa_key.p8
Enter Encryption Password: (任意のパスワードを入力)
Verifying - Enter Encryption Password: (任意のパスワードを入力)
% ls
rsa_key.p8
% cat rsa_key.p8
-----BEGIN ENCRYPTED PRIVATE KEY-----
XXxxxxx....
-----END ENCRYPTED PRIVATE KEY-----

次いで公開鍵も作成。

openssl rsa -in rsa_key.p8 -pubout -out rsa_key.pub
Enter pass phrase for rsa_key.p8: (秘密鍵作成時に設定したパスワードを入力)
writing RSA key
% cat rsa_key.pub
-----BEGIN PUBLIC KEY-----
YYYYyyyy......
-----END PUBLIC KEY-----

ケース1: 既存ユーザー(TYPE = PERSON)に対する認証設定

Snowflakeでは作成するユーザーのタイプを指定することが可能となっています。

当エントリではこれらのユーザーのタイプにおいて、以下2つのケースを確認、対応してみます。まずは従来の形式、人間が実操作を行うTYPE = PERSONの場合から。

Snowflake設定

dbt Cloud接続に用いているSnowflakeユーザーに対し、RSA_PUBLIC_KEYの値を更新。ユーザーと公開鍵の情報を紐付けます。

--// 更新する内容は公開鍵の実文字列テキスト部分を設定.
ALTER USER <dbtclouduser>
SET RSA_PUBLIC_KEY='YYYYyyyy......';

--// 内容が更新されていることを念の為確認.
DESC USER <dbtclouduser>;

dbt Cloud(開発環境)環境設定

dbt Cloud側の設定切り替えを続けて行います。dbt Cloudに関しては一連の設定作業が済んだ状態であれば、メニューの[Orchestration]→[Environments]から接続認証情報を辿ることが出来ます。

まずは開発環境(Development)から変更していきます。

接続設定の[Connection]配下にある[Development Credentials]の[profile page]を選択。

変更前の状況。ユーザー名とパスワードによる認証で設定されています。[Edit]押下。

以下の内容で変更を行います。

  • Auth method: Key pairに変更
  • Username: 接続ユーザー名
  • Private Key: 前述手順で作成した秘密鍵の情報(コメント部分も含めてすべて)
  • Private key passphrase: 秘密鍵作成の時に指定したパスワード

接続確認を行い無事完了出来たら内容を保存。

IDEで諸々の操作を行えるところまで確認出来ました。

dbt Cloud(本番環境)環境設定

本番環境についても実施内容は同じ流れです。環境一覧から紐付けを行っている認証情報に対し、上述開発環境で行った内容と同じ変更を行います。

変更内容を保存後、ジョブ実行が変更前と変わらず実施出来ていることを確認。

ケース2: 新規ユーザー(TYPE = SERVICE)に対する環境設定

開発環境に関しては実ユーザーがアクセス利用する事になるのでTYPE = PERSONでないといけませんでしたが、本番環境に関しては人間を介する必要は無いのでTYPE = SERVICEでも良さそうです。という事で設定に用いるユーザーをTYPE = SERVICEのものに置き換えてみます。

Snowflake設定

検証用に別途Snowflakeユーザーを作成。この際、TYPE = SERVICEの指定でサービスユーザーであることを明示し、多要素認証を行わずにアクセス出来るようにするためにケース1でも行ったキーペアに関する情報を同様に活用します。

CREATE USER xxxxxxxxxxxxxxx_keypair
  COMMENT = 'KeyPairアクセス用ユーザー'
  TYPE = SERVICE
  RSA_PUBLIC_KEY='YYYYyyyy......';

dbt Cloud(本番環境)環境設定

ケース1で実践した本番環境の設定に対し、上述サービスユーザーとして作成した情報を上書き更新。接続も問題なく通りました。

ジョブ実行も再度実践、問題無く稼動していることを確認出来ました。

まとめ

という訳でSnowflakeの多要素認証対応におけるdbt(dbt Cloud)の認証方式変更対応の実践、備忘録の紹介でした。同様の手順実践を検討されている方の何らかの参考になりましたら幸いです。

Discussion