管理の認証情報と CI

tegata v0.3.1 の文書

プロバイダーがほかの認証情報を作るための認証情報を、どこに置くか。長く使う鍵なしで、CI で tegata を動かすにはどうするか。

プロバイダーは、あなたが使うものを作るために管理の認証情報を必要とします。アカウントの API トークンを作れる Cloudflare のトークンや、参加の鍵を作れる Tailscale の OAuth クライアントです。tegata を使う中で、これがいちばん強いシークレットです。次のように置いてください。

tegata が管理する保存先の外に。 tegata apply を流す人はそのプロジェクトを管理していて、中のどれでも自分に読む権限を付けられます。
環境ごとではなく 1 か所に。 読めるのは、運用する人と CI の runner だけにします。
プロバイダーが許すなら、長く使う鍵を持たずに。

ここで使うキーは、どれも設定のリファレンスに説明があります。

1. 要らないところに鍵を置かない

プロバイダー	管理の認証情報	鍵を置かずに済むか
`gcp` と保存先	Google の認証情報	済む：手元では `gcloud`、CI では Workload Identity Federation、VM ではそのサービスアカウント
`aws`	AWS の認証情報	済む：AWS SDK の既定の順番で探すので、手元では `aws sso login`、CI では GitHub の OIDC のトークンで引き受ける role
`cloudflare`	トークンを作れる API トークン	済まない。なければ、手元では `cf` のログインを使える（`optional: true`）。CI にはトークンが要る
`tailscale`	OAuth クライアント	済まない

置くのは下の 2 つだけにし、プロバイダーが許す限り狭く絞ってください。Cloudflare なら、「API Tokens Write」だけを持つトークンにし、できれば決まった IP アドレスからだけ使えるようにします。本番には別のものを用意します。

2. 管理用のプロジェクトに置く

管理の認証情報だけを置く Google Cloud のプロジェクトを作ります（ここでは myorg-admin）。そこでは何も動かさず、シークレットを読めるのは 2 種類のアカウントだけにします。運用する人と、CI の runner（tegata-runner@myorg-admin.iam.gserviceaccount.com）です。そのプロジェクトで Secret Manager のデータアクセスの監査ログを有効にして、読み出しをすべて記録します。

それから、プロバイダーがそこを読むようにします。

credential_sources:
  admin:
    gcp: { project: myorg-admin }
providers:
  cloudflare:
    source: github.com/k-kawa/tegata
    version: "^0.3"
    config: { account_id: 0123456789abcdef }
    credentials:
      api_token:
        from: { source: admin, secret: cloudflare-admin-token }
        env: TEGATA_CLOUDFLARE_TOKEN    # a one-off override still works

環境を使えば、本番は自分のトークンを読めます。

providers:
  cloudflare:
    credentials:
      api_token: { from: { source: admin, secret: cloudflare-admin-token-prod } }

パスワードの管理ツールも、command の読み元で同じように使えます。たとえば 1Password なら：

credential_sources:
  op:
    command: [op, read]
providers:
  cloudflare:
    credentials:
      api_token: { from: { source: op, ref: "op://infra/cloudflare-admin/token" } }

3. 管理の認証情報を tegata で管理する

管理の認証情報もシークレットです。版と読み手を持たせ、どれくらい古いかが分かるようにしておきます。管理用のプロジェクトを保存先にし、manual のリソースだけを持つ小さな設定を別に作ればできます。この設定自体には管理の認証情報が要りません。

stores:
  main:
    gcp: { project: myorg-admin, location: asia-northeast1 }
identities:
  runner: [serviceAccount:tegata-runner@myorg-admin.iam.gserviceaccount.com]
  operators: [group:operators@example.com]
resources:
  cloudflare_admin:
    provider: manual
    stores:
      main:
        - { name: cloudflare-admin-token, readers: [runner, operators] }
  cloudflare_admin_prod:
    provider: manual
    stores:
      main:
        - { name: cloudflare-admin-token-prod, readers: [runner, operators] }

tegata -f admin.yaml apply                  # the secrets and their readers
op read op://infra/cloudflare-admin/token | tegata -f admin.yaml set cloudflare_admin
tegata -f admin.yaml status                 # versions, and who reads them

管理のトークンを替えるには：プロバイダーで新しいものを作り、tegata -f admin.yaml set で入れ、もとの設定が動き続けることを確かめ（害のないものを tegata -e staging rotate するか、apply --dry-run）、それからプロバイダーで古いものを無効にして、tegata -f admin.yaml prune を流します。

4. 鍵なしで CI で tegata を動かす

GitHub Actions では、ワークフローが Workload Identity Federation で runner のサービスアカウントになります。管理用のプロジェクトから管理の認証情報を読み、環境のプロジェクトを管理します。GitHub には鍵を置きません。

on: workflow_dispatch
jobs:
  rotate:
    runs-on: ubuntu-latest
    environment: production                 # a GitHub environment with required reviewers
    permissions: { id-token: write, contents: read }
    steps:
      - uses: actions/checkout@v5
      - uses: google-github-actions/auth@v3
        with:
          workload_identity_provider: projects/123456/locations/global/workloadIdentityPools/github/providers/github
          service_account: tegata-runner@myorg-admin.iam.gserviceaccount.com
      - uses: google-github-actions/setup-gcloud@v3
      - run: |
          # install tegata (checked as in the README), then:
          tegata -e production init
          tegata -e production rotate --yes session_key

runner に要るもの：

場所	role
管理用のプロジェクト	使う管理のシークレットへの `roles/secretmanager.secretAccessor`
各環境のプロジェクト	`apply`、`rotate`、`prune` に要るもの。たとえば `roles/secretmanager.admin`
AWS（`aws` プロバイダーのため）	GitHub の OIDC のトークンで引き受ける role。SES のユーザーのアクセスキーを管理できるもの

confirm: true の環境の問いには --yes で答えます。代わりに GitHub の環境のレビュアーが確かめます。

このページの問題を報告する（GitHub。英語でも日本語でも）