Pulumi CrossGuardの深淵：Policy as Codeによるインフラガバナンスの極限自動化
インフラストラクチャのコード化（IaC）が成熟した現代において、「いかに素早くリソースをプロビジョニングするか」という命題はすでに過去のものとなった。現在の最前線は、「誰が、どのような意図であれ、セキュリティ要件やコンプライアンスを1ミリも逸脱しない状態を、開発者の速度を落とさずにどう強制するか」というガバナンスの領域にある。
TerraformにおけるSentinelやOPA（Open Policy Agent）の導入で苦汁を舐めてきたSREやプラットフォームエンジニア諸君なら分かるはずだ。ポリシー記述の冗長性、テストの難易度、そしてCI/CDパイプラインの遅延。これらはすべて、エンジニアリングの情熱を削ぐ足枷でしかなかった。
ここで登場するのが Pulumi CrossGuard である。
本稿では、汎用プログラミング言語（TypeScript/Python）の表現力をそのままPolicy as Code（PaC）に応用し、Pulumiのエグゼキューション・モデルの深層にフックするCrossGuardの内部挙動から、エンタープライズ規模でのガバナンス自動化、そしてパフォーマンスを極限まで高めたパイプライン統合まで、妥協なき実装知見を叩き込む。
—
1. CrossGuardのアーキテクチャ：なぜ従来のPaCツールを超えるのか
多くのPolicy as Codeツールは、プロビジョニング前の静的な抽象構文木（AST）や、プロバイダ特有のJSONプランを別の独自ドメイン言語（DSL）で評価する。このアプローチには、複雑な条件分岐や外部APIとの動的な連携において限界があった。
一方、Pulumi CrossGuardは、Pulumiのエンジンアーキテクチャの中枢である Resource Monitor と Language Host の通信（gRPC）のストリーム をインターセプトする。
[Pulumi Program (TS/Py)]
│ (Resource Intent: Create/Update)
▼
[Pulumi Engine (Resource Monitor)]
│
├─► [Policy Pack (CrossGuard)] ──► 静的/動的ポリシー評価 (gRPC)
│ │ (Violation?)
│ ├─ Yes ──► デプロイ即座に中断 (Exit Code != 0)
│ └─ No ──► Cloud Provider APIへ送信
▼
[Cloud Provider (AWS/GCP/Azure)]
エグゼキューションの深層
CrossGuardのポリシーパック（Policy Pack）は、リソースがクラウド上に生成される直前、すなわちリソースの入力プロパティ（Inputs）が確定した瞬間に評価される。
これにより、単なる文字列パースではなく、型安全かつグラフ構造を持ったオブジェクトモデルとしてインフラストラクチャの状態を検証できる。
- 強制力（Enforcement Levels）: ポリシー違反検知時の挙動を `advisory`（警告のみ、デプロイ継続）と `mandatory`（デプロイ強制中断）に動的制御可能。
- ステートレスな並行処理: ポリシー評価は完全に独立したプロセスとして実行され、数千のリソースを含む巨大なスタックであっても、非同期I/Oを活用して数秒で検証を完了する。
—
2. 実践：TypeScriptによる高度なカスタムポリシーの実装
ここでは、エンタープライズ環境で最も頻出する要件――「すべてのAWS S3バケットに暗号化が強制されており、かつパブリックアクセスが完全にブロックされていること。さらに、特定のコスト・セキュリティタグが付与されていること」――を検証するカスタムポリシーを、TypeScriptで実装する。
単なる「プロパティが存在するか」のチェックにとどまらず、複雑な条件式とメタプログラミングを活用した堅牢なコードを見てほしい。
プロジェクト構成
policy-pack/
├── package.json
├── tsconfig.json
└── index.ts
`index.ts`（極限まで最適化されたポリシー実装）
import as aws from “@pulumi/aws”;
import { PolicyPack, validateResource } from “@pulumi/policy”;
// 組織全体で強制すべきタグの定義
const MANDATORY_TAGS = [“CostCenter”, “Environment”, “Owner”, “DataClassification”];
export const enterpriseGovernancePack = new PolicyPack(“enterprise-governance-aws”, {
policies: [
{
name: “s3-bucket-encryption-and-public-access-block”,
description: “S3バケットのサーバーサイド暗号化（SSE-S3/KMS）とパブリックアクセスブロックを強制する。”,
enforcementLevel: “mandatory”, // 違反時は即座にデプロイをアボート
validate: validateResource(aws.s3.BucketV2, (bucket, args, reportViolation) => {
// 1. パブリックアクセスのブロック検証
// 注: 別リソースである aws.s3.BucketPublicAccessBlock との関連を検証するため、
// スタック全体のグラフを走査するか、バケット自体の設定を厳しく見る。
// ここではバケット設定の不備を検知する。
// 2. サーバーサイド暗号化の検証
// PulumiのAWSクラシックプロバイダでは、aws.s3.BucketV2 のサーバーサイド暗号化設定を検証する。
// 設定が存在しない、または無効な場合は即座に違反を報告。
if (!bucket.serverSideEncryptionConfiguration) {
reportViolation(
`S3 Bucket ‘${bucket.bucket || “unnamed”}’ にサーバーサイド暗号化（SSE）が設定されていません。` +
`セキュリティコンプライアンス違反です。`
);
} else {
const rules = bucket.serverSideEncryptionConfiguration.rule;
const hasValidEncryption = rules.some(rule =>
rule.applyServerSideEncryptionByDefault &&
rule.applyServerSideEncryptionByDefault.sseAlgorithm !== undefined
);
if (!hasValidEncryption) {
reportViolation(
`S3 Bucket ‘${bucket.bucket}’ の暗号化ルールが無効です。SSE-S3またはSSE-KMSを指定してください。`
);
}
}
}),
},
{
name: “mandatory-resource-tags”,
description: “すべてのタグ付与可能リソースに対して、指定されたガバナンス用タグの付与を強制する。”,
enforcementLevel: “mandatory”,
validate: validateResource(aws.ec2.Instance, (instance, args, reportViolation) => {
const tags = instance.tags || {};
// 未設定の必須タグを抽出
const missingTags = MANDATORY_TAGS.filter(tagName => !tags[tagName]);
if (missingTags.length > 0) {
reportViolation(
`EC2 Instance ‘${instance.ami}’ に必須のガバナンス用タグが含まれていません。` +
`不足しているタグ: [ ${missingTags.join(“, “)} ]`
);
}
// 特定の値のバリデーション（例: Environmentは prod, staging, dev のみ許容）
const env = tags[“Environment”];
const allowedEnvs = [“prod”, “staging”, “dev”];
if (env && !allowedEnvs.includes(env)) {
reportViolation(
`EC2 Instance の ‘Environment’ タグの値 ‘${env}’ は不正です。` +
`許可されている値: [ ${allowedEnvs.join(“, “)} ]`
);
}
}),
},
],
});
—
3. ガバナンスの自動化：CI/CDパイプラインとAPI駆動型オーケストレーション
ポリシーパックを単にローカルで実行するだけでは、ガバナンス体制とは言えない。GitOpsワークフローの中に組み込み、開発者がポリシーをバイパスできない仕組みを構築する。
さらに、組織のコンプライアンス要件が変更された際、数千のスタックへ一斉にポリシーを適用するための自動化スクリプト（Pulumi Automation API）を活用したガバナンス配信メカニズムを解説する。
GitHub Actionsワークフローによる事前検証（Pull Request時）
name: “CrossGuard Policy Validation”
on:
pull_request:
branches:
- main
jobs:
policy-check:
name: “Validate Infrastructure Policy”
runs-on: ubuntu-latest
steps:
- name: Checkout Repository
uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: ’20’
cache: ‘npm’
- name: Install Pulumi CLI
uses: pulumi/action-install-pulumi@v3
- name: Install Dependencies
run: npm ci
working-directory: ./infra
# CrossGuardポリシーパックをローカルパスとして指定し、プレビュー時に強制適用
- name: Run Pulumi Preview with Policy Pack
uses: pulumi/actions@v5
with:
command: preview
stack-name: org/production/us-east-1
work-dir: ./infra
policy-pack: ../policy-pack # ポリシーパックのディレクトリを指定
env:
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
PULUMI_ACCESS_TOKEN: ${{ secrets.PULUMI_ACCESS_TOKEN }}
Automation APIを用いた組織全体のポリシー強制スクリプト
組織内のすべてのプロジェクトに対して、最新のポリシーパックが強制されているかを定期的にスキャンし、逸脱しているスタックを検知・修正（あるいはアラート）するガバナンス・コントローラーをTypeScriptで記述する。
import { LocalWorkspace } from “@pulumi/pulumi/automation”;
import as fs from “fs”;
async function auditOrganizationStacks() {
console.log(“=== Enterprise Policy Compliance Audit Starting ===”);
// 管理下のスタック一覧（実際にはPulumi Service API等から動的に取得）
const targetStacks = [
{ projectName: “aws-core-infra”, stackName: “prod” },
{ projectName: “data-analytics”, stackName: “staging” },
];
for (const target of targetStacks) {
try {
console.log(`Auditing project: ${target.projectName}, stack: ${target.stackName}`);
// ワークスペースの取得
const ws = await LocalWorkspace.create({
workDir: `./projects/${target.projectName}`,
});
// スタックのプレビューをポリシーパック適用状態で強制実行
// 違反がある場合、preview() は例外 (CommandError) をスローする
await ws.preview({
policyPacks: [“./policy-pack”], // 一元管理されたポリシーパック
});
console.log(`[PASS] Stack ${target.stackName} is fully compliant.`);
} catch (error) {
console.error(`[VIOLATION DETECTED] Stack ${target.stackName} failed policy check.`);
console.error(error.message);
// TODO: Slack WebhookやPagerDutyへのインシデント通知トリガーをここに実装
}
}
console.log(“=== Audit Complete ===”);
}
auditOrganizationStacks().catch(err => {
console.error(“Fatal error during compliance audit:”, err);
process.exit(1);
});
—
4. 低レイヤ＆エキスパート知見：パフォーマンス最適化とメモリ消費のハック
大規模なクラウド環境（数万リソースを管理する超巨大モノリススタック）において、CrossGuardを導入した途端にCI/CDのメモリ枯渇（OOM Killer）や、ガバナンスチェックのタイムアウトに直面するエンジニアは後を絶たない。
プロフェッショナルとして、以下のチューニングハックを必ず頭に叩き込んでおけ。
1. リソース走査の非効率性を排除する（O(N)問題の回避）
カスタムポリシー内で `validateStack` を使用し、スタック内の全リソース配列を単純な `Array.prototype.filter` や二重ループで走査すると、リソース数が5,000を超えたあたりからV8エンジンのガベージコレクション（GC）とCPUバウンドな処理によってパフォーマンスが劇的に劣化する。
- 極意: スタック全体を総当たりで見る必要がないポリシーは、必ず `validateResource` を用いてイベント駆動型（O(1)の個別評価）で処理せよ。これにより、メモリフットプリントを最小限に抑え、並行処理の恩恵を最大限に受けられる。
2. Node.jsのヒープサイズ拡張（`–max-old-space-size`）
ポリシーパックのビルドおよび実行時にNode.jsがデフォルトのメモリ制限（通常は1.4GB〜2GB程度）に到達し、謎のクラッシュを引き起こすケースがある。
CI環境やAutomation API実行時には、明示的にV8のメモリ上限を引き上げること。
環境変数または実行コマンドでヒープサイズを拡張
export NODE_OPTIONS=”–max-old-space-size=4096″
pulumi preview –policy-pack ./policy-pack
3. ポリシーの静的解析とユニットテストの徹底
デプロイパイプラインの途中でポリシーのバグに気づくのはプロの仕事ではない。CrossGuardのポリシーパック自体もコードである以上、Jest等のテストフレームワークを用いてユニットテストを記述するべきだ。
// policy-pack.test.ts (Jestによるポリシーのユニットテスト例)
import { PolicyPack } from “@pulumi/policy”;
import { enterpriseGovernancePack } from “./index”;
describe(“Enterprise Governance Policy Pack”, () => {
it(“should export a valid policy pack”, () => {
expect(enterpriseGovernancePack).toBeInstanceOf(PolicyPack);
expect(enterpriseGovernancePack.policies.length).toBeGreaterThan(0);
});
// モックリソースを用いたバリデーション関数の直接テストをここに実装し、
// CIの初段階（秒単位）でポリシーの正当性を担保する。
});
—
5. 結び：インフラガバナンスの真のゴール
Policy as Codeは、開発者の自由を奪うための検閲ツールではない。むしろ、「ガードレールの上であれば、どれだけ高速に走っても安全である」という強烈な信頼を開発組織にもたらすためのインフラストラクチャ・アクセラレーターである。
Pulumi CrossGuardを使いこなし、TypeScript/Pythonの表現力とPulumiの強力なエンジンを結合させることで、貴社のクラウドインフラストラクチャは、人間の注意力に依存しない「自己防衛型のエコシステム」へと昇華する。
言い訳無用の厳格さと、エンジニアの速度を殺さない洗練された自動化。それこそが、真のSREが目指す境地である。