SnowPro Advanced: MLOps Engineer 無料問題 8 / 10 ・ 分野4: Pipeline Orchestration and Automation (CI/CD)
GitHub Actions のパイプラインが、ML のパイプラインのコードを Snowflake へデプロイしている。セキュリティの担当は、長く使える Snowflake の資格情報を GitHub のどこにも置きたくない。Snowflake の CI/CD のページは、何を設定するよう勧めているか。
- サービスの利用者のパスワードを、GitHub のシークレットに置いて頻繁に変える
- サービスの利用者のキーペアで、秘密鍵は GitHub のシークレットに置く
- 主任エンジニア自身の MFA 付きの利用者で、実行の始めごとに承認する
- CI の発行元に対し、WORKLOAD_IDENTITY の TYPE = OIDC を持つサービスの利用者
正解と解説を見る
正解: D
正解の理由
「Authenticate with workload identity federation (OIDC)」の節には、OIDC では CI のランナーが短い間だけ使えるアイデンティティのトークンを得て、Snowflake がそれを直接確かめると書かれている。よくある設定は、パイプラインがその者として認証するサービスの利用者から始まり、その認証には、CI の仕組みに長く使えるシークレットを置かずに済むよう、Snowflake は OIDC によるワークロードアイデンティティフェデレーションを勧めている。最小の定義は、TYPE = SERVICE と WORKLOAD_IDENTITY = (TYPE = OIDC, ISSUER = ..., SUBJECT = ...) を付けた CREATE USER で、発行元と主体には CI の基盤が示す値を使う。
違う選択肢
「サービスの利用者のキーペアで、秘密鍵は GitHub のシークレットに置く」… GitHub のシークレットに置いた秘密鍵は、CI の仕組みに置いた長く使える資格情報で、セキュリティの担当が避けたいものである。ページの勧める設定は、そうしたシークレットを置かずに済むよう選ばれている。
「サービスの利用者のパスワードを、GitHub のシークレットに置いて頻繁に変える」… ページには、パスワードの認証は旧来のワークフローのために対応しているが、本番の CI/CD には勧めないとある。定期的に変えるのは OIDC を取り入れられないチームへの助言で、パスワードはやはり GitHub に置かれる。
「主任エンジニア自身の MFA 付きの利用者で、実行の始めごとに承認する」… Snowflake 側のよくある設定は、パイプラインがその者として認証するサービスの利用者を作ることから始まる。人のアカウントと対話の承認は、無人のパイプラインが頼れるものではない。
置いたシークレットではなく、ランナーを信頼する
発行元と主体が Snowflake の利用者を、リポジトリや環境のような特定の CI のアイデンティティに結び付けるので、ほかで発行したトークンは合わない。GitHub Actions・GitLab・Azure DevOps の公式の連携は、どれもワークロードアイデンティティフェデレーションを勧める認証として挙げている。