Carpe Diem

備忘録

dbt の source, seed, 各modelとの関係性

dbt

背景

dbt を使う上で、

  • source
  • seed
  • staging model
  • snapshot
  • ref

などの色んな用語が出てきますが、それぞれどういったときに使うべきなのか分からなかったので関係性を図でまとめてみました。

環境

  • dbt v1.12

関係性

関係図

一般的な dbt project の依存関係例としては次のようになります。

続きを読む

Pydantic でシークレットの漏洩を防止する方法

Python Pydantic

背景

以前Goで機密情報の漏洩防止について触れました。

christina04.hatenablog.com

今回はPythonでどうするべきかについて説明します。

環境

  • Python 3.11.15
  • Pydantic 2.13.4

Pydantic でシークレットを漏洩させないためのパラメータ

トークン等のシークレットが検証エラー・ログ・repr 経由で漏れないための対策を一覧化します。

各パラメータの守備範囲

漏洩経路 SecretStr
(型) 		hide_input_in_errors
(ConfigDict) 		Field(repr=False) Field(exclude=True)
A. print(settings)/f"{settings}"
（モデルを文字列化） 		✅ ********** ❌ ✅ 項目ごと非表示 ❌ raw 出る
B. settings.token を直接ログ/f-string ✅ 要get_secret_value() ❌ ❌ raw ❌ raw
C. 第三者lib/例外がモデルをrepr
（traceback locals等） 		✅ ❌ ✅ ❌
D. model_dump()/model_dump_json() をログ ✅ json→********** ❌ ❌ raw ✅ 出力から除外
E. 検証エラーの input_value
（モデルレベルは生 dict） 		❌ raw漏れ ✅ ❌ ❌
続きを読む

pull_request と pull_request_target の違いとセキュリティ上の注意点

GitHub Actions GitHub

背景

依存しているライブラリに次のようなコードがありました。
※簡単のためシンプルにしています

on: pull_request_target

jobs:
  coverage:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}

      - run: npm ci && npm run test:coverage

      - uses: actions/github-script@v7
        with:
          script: |
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
              body: 'Coverage report generated'
            });

一見テストを実行してテストカバレッジをPRにコメントしているだけのCIですが、セキュリティ的には大きな問題があります。

大きく2つの問題点があります。

  • pull_request_targetを使っているのにPR元のコードを参照している
  • permissionsで権限を制限していない

これらの詳細について、pull_request, pull_request_target の使い分けを踏まえながら説明していきます。

続きを読む

Release Please をモノリポに導入する際にハマったこと

GitHub Actions GitHub モノリポ

背景

前回の

christina04.hatenablog.com

をチームのモノリポに導入する際にハマったことをまとめていきます。

この記事は

  • release-please を既に導入した
  • monorepo を運用している
  • conventional commits を使っている

人向けです。

環境

  • Release Please Action v4.4.1
続きを読む

Release Please Actions を導入してモノリポでもリリース差分を自動で抽出できるようにする

GitHub Actions GitHub モノリポ

背景

モノリポでは1つのリポジトリで全てのサービス・コンポーネントを管理するため次のメリットがあります。

一方で次のような問題が生まれます。

  • GitHubリリースの自動差分生成で、関係ないコンポーネントの差分も含まれる
  • コンポーネントが多いためtag管理が煩雑化する

それらを自動的に解決できるツールとして、Google自身がモノリポでのリリースに利用しているRelease PleaseというGitHub Actionsがあります。

今回はこちらの導入方法を紹介します。

環境

  • Release Please Action v5.0.0

どんな事ができるのか

次のような挙動になります。

  1. 機能系PRのmasterマージ時に、自動的にRelease PRが作成される
    • バージョンはコミットタイトルのconventional commitに従う
    • 追加でmasterマージされれば、↑のPRにCHANGE LOGが追加される
  2. Release PRをマージすると自動的にtagを作成する
続きを読む

GitHub Apps, GITHUB_TOKEN, OAuth Apps, PATの使い分けフローチャート

GitHub GitHub Actions CI

背景

歴史的経緯もあり、GitHubでは様々な種類のトークンがあります。

  • GitHub Apps によるトークン
  • Github Actions で使える GITHUB_TOKEN
  • OAuth Apps によるトークン
  • PAT (Personal Access Token)

それぞれの特徴、使い分けが分かりにくかったので、フローチャートでまとめました。

フローチャート図

ユースケースに応じたフローチャートはこちらです。

続きを読む

GKE → Snowflake の Workload Identity Federation を構築する

Snowflake Terraform GCP GKE

背景

以前Google Cloud サービスアカウントのimpersonationを使った Workload Identity Federation の例を紹介しました。

christina04.hatenablog.com

ただ最近は従来のWIFから、Direct Workload Identity Federationと呼ばれるサービスアカウントを挟まず直接KSAをプリンシパルにすることができる方法が推奨され始めたので、今回はそちらで実現できるようにします。

環境

  • Terraform v1.13.4
  • snowflakedb/snowflake provider v2.11.0
  • hashicorp/google provider v7.9

コンポーネント図

前回と同じ図です。図を見て分かるように、SnowflakeのWIFはKubernetesからのOIDCにも対応しています。

続きを読む