ガードレールの実装 - L0 カリキュラム

ストーリー

田

田中VPoE

Golden Pathは「推奨」、ガードレールは「境界」だ。ガードレールの実装方法を学ぼう。開発者の自由を最大限に保ちながら、安全とコンプライアンスを自動的に担保する仕組みだ

あなた

ガードレールはどうやって実装するんですか？手動でレビューするのは現実的ではないですよね

あ

田

田中VPoE

自動化が前提だ。Policy as Code。OPA（Open Policy Agent）、Kyverno、コンテナセキュリティスキャン。CI/CDパイプラインとKubernetesのAdmission Controlに組み込んで、ポリシー違反を自動的にブロックする

あなた

開発者が「なぜブロックされたか」を理解できることも重要ですよね

あ

田

田中VPoE

その通り。ガードレールは「ブロックする」だけでなく「なぜブロックしたか」「どう修正すべきか」を明確に伝える必要がある。エラーメッセージの質がガードレールの使いやすさを決める

ガードレールの実装レイヤー

多層ガードレール

レイヤー	タイミング	ツール	チェック内容
IDE	コーディング中	ESLint, Semgrep LSP	コーディング規約、セキュリティパターン
Pre-commit	コミット前	Gitleaks, lint-staged	シークレット漏洩、フォーマット
PR	PR作成時	Semgrep, Trivy, OPA	SAST、依存脆弱性、ポリシーチェック
CI/CD	ビルド時	Trivy(Image), Checkov	コンテナ脆弱性、IaCポリシー
Admission	デプロイ時	Kyverno, OPA Gatekeeper	Kubernetesリソースポリシー
Runtime	稼働中	Falco, NetworkPolicy	異常検出、ネットワーク制御

Kubernetes Admission Controlによるガードレール

Kyvernoポリシーの例

# ポリシー1: rootユーザーでの実行を禁止
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-root-user
  annotations:
    policies.kyverno.io/title: "rootユーザーの禁止"
    policies.kyverno.io/description: |
      コンテナをrootユーザーで実行することは
      セキュリティリスクです。非rootユーザーを使用してください。
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-runAsNonRoot
      match:
        any:
          - resources:
              kinds: ["Pod"]
      validate:
        message: |
          コンテナはrootユーザーで実行できません。
          Dockerfileで USER を設定するか、
          securityContext.runAsNonRoot: true を設定してください。
          参照: https://wiki.cloudops.io/security/non-root
        pattern:
          spec:
            containers:
              - securityContext:
                  runAsNonRoot: true

# ポリシー2: リソースリクエスト/リミットの必須化
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-resource-limits
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-resource-limits
      match:
        any:
          - resources:
              kinds: ["Pod"]
      validate:
        message: |
          CPUとメモリのrequests/limitsが必要です。
          Application CRDのsizeパラメータを使用すれば
          自動設定されます。
          参照: https://wiki.cloudops.io/platform/sizing
        pattern:
          spec:
            containers:
              - resources:
                  requests:
                    memory: "?*"
                    cpu: "?*"
                  limits:
                    memory: "?*"

# ポリシー3: 承認されたコンテナレジストリのみ許可
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-image-registries
spec:
  validationFailureAction: Enforce
  rules:
    - name: validate-registries
      match:
        any:
          - resources:
              kinds: ["Pod"]
      validate:
        message: |
          承認されたコンテナレジストリのイメージのみ使用できます。
          許可レジストリ: registry.cloudops.io
          参照: https://wiki.cloudops.io/security/approved-registries
        pattern:
          spec:
            containers:
              - image: "registry.cloudops.io/*"

OPAによるポリシーチェック

CIパイプラインでのOPA

# policy/platform.rego
# Application CRD のバリデーション

package platform.application

# productionは最低2レプリカ
deny[msg] {
    input.spec.replicas.min < 2
    input.metadata.labels.environment == "production"
    msg := sprintf(
        "production環境では最低2レプリカが必要です。現在: %d",
        [input.spec.replicas.min]
    )
}

# ヘルスチェック必須
deny[msg] {
    not input.spec.health
    msg := "ヘルスチェック（spec.health）の設定が必要です"
}

# 承認されたサイズのみ
deny[msg] {
    allowed_sizes := {"small", "medium", "large"}
    not allowed_sizes[input.spec.size]
    msg := sprintf(
        "サイズ '%s' は許可されていません。small/medium/large を使用してください",
        [input.spec.size]
    )
}

# コスト上限（xlargeは承認必要）
warn[msg] {
    input.spec.size == "xlarge"
    msg := "xlargeサイズにはPlatform Adminの承認が必要です"
}

ガードレールのUX設計

エラーメッセージの品質

品質	悪い例	良い例
何がダメか	`Policy violation`	`rootユーザーでの実行は禁止されています`
なぜダメか	（理由なし）	`rootユーザーはコンテナ脱出時のリスクがあります`
どう直すか	（修正方法なし）	`Dockerfileで USER 1001 を追加してください`
参照先	（リンクなし）	`詳細: https://wiki.cloudops.io/security/non-root`

「ガードレールが開発者に『なぜ止められたかわからない』と感じさせたら、それはガードレールの設計不良だ。すべてのブロックメッセージに『理由』と『修正方法』を含めろ」 — 田中VPoE

まとめ

ポイント	内容
多層ガードレール	IDE → Pre-commit → PR → CI/CD → Admission → Runtime
Kyverno	Kubernetes Admission Controlでポリシーを強制
OPA	CI/CDパイプラインでポリシーチェック
エラーメッセージ	何がダメか + なぜダメか + どう直すか + 参照先

チェックリスト

多層ガードレールの各レイヤーを説明できる
Kyvernoポリシーの記述方法を理解した
OPAによるCIパイプラインでのチェックを設計できる
エラーメッセージのUX設計を理解した

次のステップへ

次は「Compliance as Code」を学びます。コンプライアンス要件をコードとして定義し、自動チェックする方法を身につけましょう。

推定読了時間: 30分