Carpe Diem

備忘録

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にも対応しています。

続きを読む

Google Cloud IAM と GKE 権限の関係

Kubernetes GKE IAM GCP

概要

GKEの権限管理は、Google Cloud IAM（プロジェクトレベルの操作）と Kubernetes RBAC（クラスター内部のリソース操作）の組み合わせで決まります。

IAMの権限が多く、それぞれの違いがぱっと見分かりづらかったので、一覧化したり知っておくべき差分を洗い出しました。

前提：認可（Authorization）の仕組み

GKEでは以下の順序で権限がチェックされます。

  1. Kubernetes RBAC のポリシーを確認
  2. RBAC で許可されていない場合、Google Cloud IAM の権限を確認

Kubernetes RBAC と IAM のいずれかで十分な権限が付与されていれば、操作は許可されます。

続きを読む