Skip to content
Published on

コンテナセキュリティ&サプライチェーンセキュリティ完全ガイド2025:イメージスキャニング、Sigstore、SBOM、ランタイムセキュリティ

Authors

目次

1. コンテナ脅威(きょうい)モデル:攻撃表面(こうげきひょうめん)の理解

コンテナ環境(かんきょう)は、従来のVM基盤インフラとは異なる固有(こゆう)の脅威表面を持ちます。イメージ脆弱性(ぜいじゃくせい)、設定ミス、ランタイム攻撃(こうげき)、サプライチェーン脅威まで、多層的(たそうてき)なセキュリティ戦略(せんりゃく)が必要です。

1.1 コンテナ攻撃表面

コンテナセキュリティレイヤー:
┌─────────────────────────────────────────────────┐
│ Layer 6: サプライチェーン                         │
│  - ベースイメージ汚染、依存関係の改ざん            │
├─────────────────────────────────────────────────┤
│ Layer 5: オーケストレーション(Kubernetes)        │
│  - RBAC未設定、APIサーバー露出、etcd未暗号化      │
├─────────────────────────────────────────────────┤
│ Layer 4: ネットワーク                             │
│  - ネットワークポリシー未設定、サービスメッシュ未適用│
├─────────────────────────────────────────────────┤
│ Layer 3: ランタイム                               │
│  - コンテナ脱出、権限昇格、暗号通貨マイニング      │
├─────────────────────────────────────────────────┤
│ Layer 2: イメージ                                 │
│  - CVE脆弱性、ハードコードされたシークレット        │
├─────────────────────────────────────────────────┤
│ Layer 1: ホストOS / コンテナランタイム             │
│  - カーネル脆弱性、Dockerソケット露出              │
└─────────────────────────────────────────────────┘

1.2 主要な攻撃ベクター

1. イメージ脆弱性の悪用:
   攻撃者 -> 公開イメージの既知CVEを悪用 -> コンテナ侵入

2. サプライチェーン攻撃:
   攻撃者 -> ベースイメージ/ライブラリにマルウェア注入 -> 下流汚染

3. ランタイム攻撃:
   攻撃者 -> 脆弱なアプリを悪用 -> コンテナ脱出 -> ホストアクセス

4. 設定ミスの悪用:
   攻撃者 -> 過剰な権限/未設定ポリシー -> 横方向移動

2. イメージセキュリティ:安全なコンテナイメージの構築(こうちく)

2.1 最小ベースイメージの選択(せんたく)

# BAD: フルイメージ使用(200MB+、数百のCVEの可能性)
FROM ubuntu:22.04
RUN apt-get update && apt-get install -y python3
COPY app.py /app/
CMD ["python3", "/app/app.py"]

# GOOD: Distroless イメージ(最小限のバイナリのみ)
FROM python:3.12-slim AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .

FROM gcr.io/distroless/python3-debian12
COPY --from=builder /app /app
COPY --from=builder /usr/local/lib/python3.12/site-packages /usr/local/lib/python3.12/site-packages
WORKDIR /app
CMD ["app.py"]

2.2 Chainguard イメージ

# Chainguard Images:毎日リビルド、ゼロCVE目標
FROM cgr.dev/chainguard/python:latest-dev AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .

FROM cgr.dev/chainguard/python:latest
COPY --from=builder /app /app
COPY --from=builder /home/nonroot/.local/lib/python3.12/site-packages /home/nonroot/.local/lib/python3.12/site-packages
WORKDIR /app
ENTRYPOINT ["python", "app.py"]

2.3 マルチステージビルドとセキュリティ

# Go アプリのマルチステージビルド
FROM golang:1.22-alpine AS builder

# セキュリティ:ビルド時のみ必要なツールをインストール
RUN apk add --no-cache git ca-certificates

WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download

COPY . .

# セキュリティ:静的バイナリビルド(CGO無効化)
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 \
    go build -ldflags="-w -s" -o /app/server ./cmd/server

# 最終イメージ:scratch(完全に空のイメージ)
FROM scratch

# セキュリティ:非rootユーザー
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
COPY --from=builder /etc/passwd /etc/passwd
COPY --from=builder /app/server /server

USER 65534:65534
ENTRYPOINT ["/server"]

2.4 Dockerfileセキュリティベストプラクティス

# セキュリティ強化されたDockerfile
FROM node:20-slim AS builder

# セキュリティ:非rootユーザー作成
RUN groupadd -r appuser && useradd -r -g appuser -d /app appuser

WORKDIR /app

# セキュリティ:package.jsonを先にコピー(レイヤーキャッシュ活用)
COPY package.json yarn.lock ./
RUN yarn install --frozen-lockfile --production

COPY . .
RUN yarn build

# 本番イメージ
FROM node:20-slim

RUN groupadd -r appuser && useradd -r -g appuser -d /app appuser

WORKDIR /app

# セキュリティ:必要なファイルのみコピー
COPY --from=builder --chown=appuser:appuser /app/dist ./dist
COPY --from=builder --chown=appuser:appuser /app/node_modules ./node_modules
COPY --from=builder --chown=appuser:appuser /app/package.json ./

# セキュリティ:非rootで実行
USER appuser

ENV NODE_ENV=production

EXPOSE 3000
CMD ["node", "dist/index.js"]

3. イメージスキャニング:脆弱性検出(けんしゅつ)

3.1 スキャニングツール比較

ツールライセンス特徴CI/CD統合SBOM生成
TrivyApache 2.0総合スキャナー(イメージ/IaC/シークレット)優秀対応
GrypeApache 2.0高速な脆弱性スキャン優秀syft連携
Docker ScoutプレミアムDocker Desktop統合Docker Hub対応
Snyk Containerプレミアム修正推奨が優秀優秀対応

3.2 Trivyの使い方(つかいかた)

# イメージスキャン
trivy image nginx:1.25

# 重大度フィルタリング
trivy image --severity HIGH,CRITICAL nginx:1.25

# SARIF形式出力(GitHub Security連携)
trivy image --format sarif --output trivy-results.sarif nginx:1.25

# シークレットスキャン
trivy image --scanners secret myapp:latest

# IaCスキャン(Dockerfile, Kubernetes YAML)
trivy config .

# SBOM生成
trivy image --format cyclonedx --output sbom.json nginx:1.25

3.3 Grypeとsyft

# syftでSBOM生成
syft packages nginx:1.25 -o cyclonedx-json > sbom.json

# GrypeでSBOMベーススキャン
grype sbom:./sbom.json

# Grype直接イメージスキャン
grype nginx:1.25

# 重大度閾値設定(CI/CDで使用)
grype nginx:1.25 --fail-on critical

3.4 CI/CD統合スキャニング

# .github/workflows/image-scan.yml
name: Container Image Scan

on:
  push:
    branches: [main]
  pull_request:

jobs:
  build-and-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build image
        run: docker build -t myapp:ci .

      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: 'myapp:ci'
          format: 'sarif'
          output: 'trivy-results.sarif'
          severity: 'CRITICAL,HIGH'
          exit-code: '1'

      - name: Upload Trivy scan results
        uses: github/codeql-action/upload-sarif@v3
        if: always()
        with:
          sarif_file: 'trivy-results.sarif'

      - name: Run Grype scan
        uses: anchore/scan-action@v4
        with:
          image: 'myapp:ci'
          fail-build: true
          severity-cutoff: 'high'

4. イメージ署名(しょめい):Sigstoreとcosign

4.1 Sigstoreエコシステム

Sigstore コンポーネント:
┌──────────────────────────────────────────────────┐
│  cosign                                           │
│  - コンテナイメージ/アーティファクトの署名と検証    │
│  - キーレス(Keyless)署名サポート(OIDCベース)    │
├──────────────────────────────────────────────────┤
│  Rekor                                            │
│  - 不変の透明性ログ(Transparency Log)            │
│  - すべての署名記録を公開的に保存                   │
├──────────────────────────────────────────────────┤
│  Fulcio                                           │
│  - 短期証明書発行(Certificate Authority)         │
│  - OIDCトークンをX.509証明書に変換                 │
└──────────────────────────────────────────────────┘

4.2 cosignでイメージ署名

# キーペア生成
cosign generate-key-pair

# イメージ署名
cosign sign --key cosign.key myregistry.com/myapp:v1.0

# イメージ署名検証
cosign verify --key cosign.pub myregistry.com/myapp:v1.0

# キーレス署名(CI/CDで推奨)
# OIDCトークンで自動認証(GitHub Actions, GitLab CI)
cosign sign myregistry.com/myapp:v1.0

# キーレス検証
cosign verify \
  --certificate-identity "https://github.com/myorg/myapp/.github/workflows/build.yml@refs/heads/main" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  myregistry.com/myapp:v1.0

4.3 GitHub Actionsでのキーレス署名

# .github/workflows/sign-image.yml
name: Build, Sign, and Push

on:
  push:
    tags: ['v*']

permissions:
  contents: read
  packages: write
  id-token: write  # キーレス署名に必要

jobs:
  build-sign-push:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: sigstore/cosign-installer@v3

      - name: Login to GHCR
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: "${{ github.actor }}"
          password: "${{ secrets.GITHUB_TOKEN }}"

      - name: Build and push
        id: build
        uses: docker/build-push-action@v5
        with:
          push: true
          tags: "ghcr.io/${{ github.repository }}:${{ github.ref_name }}"

      - name: Sign the image (keyless)
        run: |
          cosign sign --yes \
            "ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}"

4.4 Kubernetes Admission Controllerによる署名検証

# Kyvernoポリシー:署名済みイメージのみ許可
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signature
spec:
  validationFailureAction: Enforce
  background: false
  rules:
    - name: verify-cosign-signature
      match:
        any:
          - resources:
              kinds:
                - Pod
      verifyImages:
        - imageReferences:
            - "ghcr.io/myorg/*"
          attestors:
            - entries:
                - keyless:
                    subject: "https://github.com/myorg/*/.github/workflows/*@refs/heads/main"
                    issuer: "https://token.actions.githubusercontent.com"
                    rekor:
                      url: "https://rekor.sigstore.dev"

5. SBOM(Software Bill of Materials)

5.1 SBOMフォーマット比較

CycloneDX:
- OWASPプロジェクト
- セキュリティに焦点(脆弱性、ライセンス)
- JSON、XML形式
- VEX(Vulnerability Exploitability eXchange)サポート

SPDX:
- Linux Foundationプロジェクト
- ライセンスコンプライアンスに焦点
- JSON、RDF、Tag-Value形式
- ISO/IEC 5962:2021 国際標準

5.2 syftでSBOM生成

# CycloneDX形式でSBOM生成
syft packages myapp:latest -o cyclonedx-json > sbom-cyclonedx.json

# SPDX形式でSBOM生成
syft packages myapp:latest -o spdx-json > sbom-spdx.json

# ディレクトリスキャン
syft dir:./my-project -o cyclonedx-json > project-sbom.json

# SBOMをイメージに添付(cosign + SBOM)
cosign attach sbom --sbom sbom-cyclonedx.json myregistry.com/myapp:v1.0

# SBOM attestation 生成
cosign attest --predicate sbom-cyclonedx.json \
  --type cyclonedx \
  myregistry.com/myapp:v1.0

6. Pod Security Standards

6.1 セキュリティレベル比較

Privileged(特権):
- 制限なし
- 既知の権限昇格を許可
- システムデーモン、CNIプラグイン用

Baseline(基本):
- 既知の権限昇格を防止
- hostNetwork, hostPID, hostIPC をブロック
- 特権コンテナをブロック
- ほとんどのワークロードに適合

Restricted(制限):
- 最小権限の原則を適用
- 非root強制
- すべてのcapabilityを削除
- seccompプロファイル必須
- セキュリティが重要なワークロード用

6.2 Pod Security Admission設定

# NamespaceにPod Security Standardsを適用
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    # Restricted レベルを強制
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    # Restricted レベルの警告
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: latest
    # Restricted レベルの監査
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/audit-version: latest

6.3 セキュリティ強化(きょうか)されたPod仕様(しよう)

# Restrictedレベルを満たすPod仕様
apiVersion: apps/v1
kind: Deployment
metadata:
  name: secure-app
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: secure-app
  template:
    metadata:
      labels:
        app: secure-app
    spec:
      automountServiceAccountToken: false

      securityContext:
        runAsGroup: 1000
        fsGroup: 1000
        seccompProfile:
          type: RuntimeDefault

      containers:
        - name: app
          image: ghcr.io/myorg/secure-app:v1.0
          ports:
            - containerPort: 8080
              protocol: TCP

          securityContext:
            runAsNonRoot: true
            runAsUser: 1000
            readOnlyRootFilesystem: true
            allowPrivilegeEscalation: false
            capabilities:
              drop:
                - ALL

          volumeMounts:
            - name: tmp
              mountPath: /tmp
            - name: cache
              mountPath: /app/cache

          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 512Mi

      volumes:
        - name: tmp
          emptyDir:
            sizeLimit: 100Mi
        - name: cache
          emptyDir:
            sizeLimit: 200Mi

7. ネットワークポリシー

7.1 デフォルト拒否(きょひ)ポリシー

# すべてのIngress/Egressをブロック(デフォルト拒否)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

7.2 きめ細(こま)かいネットワークポリシー

# APIサービス:特定ソースからのみIngress許可
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-service-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api-service
  policyTypes:
    - Ingress
    - Egress
  ingress:
    # Ingressコントローラーからのみ許可
    - from:
        - namespaceSelector:
            matchLabels:
              name: ingress-nginx
          podSelector:
            matchLabels:
              app: ingress-nginx
      ports:
        - protocol: TCP
          port: 8080
  egress:
    # データベースアクセスを許可
    - to:
        - podSelector:
            matchLabels:
              app: postgres
      ports:
        - protocol: TCP
          port: 5432
    # DNSを許可
    - to:
        - namespaceSelector: {}
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

7.3 Ciliumネットワークポリシー

# Cilium L7ネットワークポリシー(HTTPパスベース)
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-l7-policy
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: api-service
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "/api/v1/products"
              - method: "POST"
                path: "/api/v1/orders"

8. ランタイムセキュリティ:FalcoとTetragon

8.1 Falcoルール

# Falco カスタムルール
- rule: Detect Reverse Shell
  desc: コンテナでのリバースシェル接続試行を検知
  condition: >
    evt.type=connect and
    evt.dir=< and
    container and
    fd.typechar=4 and
    fd.rip != "127.0.0.1" and
    proc.name in (bash, sh, zsh, dash, csh)
  output: >
    リバースシェル検知 (user=%user.name command=%proc.cmdline
    connection=%fd.name container=%container.name
    image=%container.image.repository)
  priority: CRITICAL
  tags: [network, shell, mitre_execution]

- rule: Detect Cryptomining
  desc: コンテナでの暗号通貨マイニングプロセスを検知
  condition: >
    spawned_process and
    container and
    (proc.name in (xmrig, minerd, minergate, cpuminer) or
     proc.cmdline contains "stratum+tcp" or
     proc.cmdline contains "cryptonight")
  output: >
    暗号通貨マイニング検知 (user=%user.name command=%proc.cmdline
    container=%container.name image=%container.image.repository)
  priority: CRITICAL
  tags: [crypto, mining, mitre_resource_hijacking]

- rule: Sensitive File Access
  desc: 機密ファイルへのアクセスを検知
  condition: >
    open_read and
    container and
    (fd.name startswith /etc/shadow or
     fd.name startswith /etc/passwd or
     fd.name startswith /proc/self/environ or
     fd.name startswith /run/secrets)
  output: >
    機密ファイルアクセス (user=%user.name file=%fd.name
    command=%proc.cmdline container=%container.name)
  priority: WARNING
  tags: [filesystem, mitre_credential_access]

8.2 Falco Helmデプロイ

# Falco インストール
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update

helm install falco falcosecurity/falco \
  --namespace falco --create-namespace \
  --set falcosidekick.enabled=true \
  --set falcosidekick.config.slack.webhookurl="https://hooks.slack.com/services/xxx" \
  --set falcosidekick.config.slack.minimumpriority=warning \
  --set driver.kind=ebpf

8.3 Tetragon eBPFポリシー

# Tetragon ポリシー:プロセス実行監視
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: monitor-process-execution
spec:
  kprobes:
    - call: "security_bprm_check"
      syscall: false
      args:
        - index: 0
          type: "linux_binprm"
      selectors:
        - matchBinaries:
            - operator: "In"
              values:
                - "/bin/bash"
                - "/bin/sh"
                - "/usr/bin/curl"
                - "/usr/bin/wget"
          matchNamespaces:
            - namespace: Mnt
              operator: NotIn
              values:
                - "host_mnt_ns"

---
# Tetragon ポリシー:ネットワーク接続監視
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: monitor-network-connections
spec:
  kprobes:
    - call: "tcp_connect"
      syscall: false
      args:
        - index: 0
          type: "sock"
      selectors:
        - matchArgs:
            - index: 0
              operator: "NotDAddr"
              values:
                - "127.0.0.1"
                - "10.0.0.0/8"

9. シークレット管理

9.1 External Secrets Operator

# SecretStore設定(AWS Secrets Manager)
apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: aws-secrets
  namespace: production
spec:
  provider:
    aws:
      service: SecretsManager
      region: ap-northeast-2
      auth:
        jwt:
          serviceAccountRef:
            name: external-secrets-sa

---
# ExternalSecret定義
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: db-credentials
  namespace: production
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets
    kind: SecretStore
  target:
    name: db-credentials
    creationPolicy: Owner
  data:
    - secretKey: username
      remoteRef:
        key: prod/database
        property: username
    - secretKey: password
      remoteRef:
        key: prod/database
        property: password

9.2 Vault CSI Provider

# Vault SecretProviderClass
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: vault-db-creds
  namespace: production
spec:
  provider: vault
  parameters:
    vaultAddress: "https://vault.example.com"
    roleName: "app-role"
    objects: |
      - objectName: "db-username"
        secretPath: "secret/data/prod/database"
        secretKey: "username"
      - objectName: "db-password"
        secretPath: "secret/data/prod/database"
        secretKey: "password"

10. SLSAフレームワーク

10.1 SLSAレベル

SLSA Level 1 - Provenance:
- ビルドプロセスが文書化
- 自動化されたビルド

SLSA Level 2 - Build Service:
- ホスティングされたビルドサービスの使用
- 署名されたprovenance生成
- バージョン管理されたソース

SLSA Level 3 - Build Integrity:
- 隔離されたビルド環境
- 改ざん防止provenance
- ソース完全性の保証

SLSA Level 4 - Dependencies:
- すべての依存関係に対する再帰的保証
- 再現可能なビルド
- (現在は理論的段階)

10.2 SLSA Provenance生成

# GitHub ActionsでのSLSA Provenance生成
name: SLSA Build

on:
  push:
    tags: ['v*']

permissions:
  contents: read
  packages: write
  id-token: write

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      digest: "${{ steps.build.outputs.digest }}"
    steps:
      - uses: actions/checkout@v4

      - name: Build and push
        id: build
        uses: docker/build-push-action@v5
        with:
          push: true
          tags: "ghcr.io/${{ github.repository }}:${{ github.ref_name }}"

  provenance:
    needs: build
    uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@v2.0.0
    with:
      image: "ghcr.io/${{ github.repository }}"
      digest: "${{ needs.build.outputs.digest }}"
    secrets:
      registry-username: "${{ github.actor }}"
      registry-password: "${{ secrets.GITHUB_TOKEN }}"

11. CI/CDセキュリティパイプライン

11.1 パイプライン全体構成(ぜんたいこうせい)

セキュリティCI/CDパイプライン:
┌─────┐   ┌──────┐   ┌──────┐   ┌──────┐   ┌──────┐   ┌──────┐
│Build│ -> │ Scan │ -> │ Sign │ -> │Attest│ -> │Verify│ -> │Deploy│
└─────┘   └──────┘   └──────┘   └──────┘   └──────┘   └──────┘
  |          |          |          |          |          |
 ビルド    脆弱性     cosign     SBOM      Kyverno   署名検証
 イメージ  スキャン   署名      attestation ポリシー  後デプロイ
          Trivy               SLSA        検証
          Grype              provenance

11.2 CISベンチマークとKubescape

# kube-bench: CIS Kubernetes Benchmark 実行
kube-bench run --targets master,node

# Kubescape: NSA, MITRE, CIS フレームワークスキャン
kubescape scan framework cis-v1.23 --exclude-namespaces kube-system

# 特定コントロールのスキャン
kubescape scan control C-0002 --namespace production

# Kubescape YAMLスキャン
kubescape scan .

12. クイズ

この記事で取り上げたコンテナセキュリティについて理解を確認しましょう。

Q1. イメージセキュリティ

質問:DistrolessイメージとAlpineイメージの違いは何ですか?

正解:Distrolessイメージはシェル(bash/sh)やパッケージマネージャーを含まない最小イメージです。AlpineはMusl libcベースの軽量Linuxディストリビューションで、シェルとパッケージマネージャー(apk)を含みます。

Distrolessは攻撃表面がより小さいですが、デバッグが困難です。Alpineはデバッグが可能ですが、musl libcの互換性問題が発生する可能性があります。本番環境ではDistrolessやChainguardイメージを推奨し、デバッグが必要な場合はdebugタグの変種を使用します。

Q2. Sigstoreキーレス署名

質問:cosignキーレス署名がCI/CDでキーベース署名より好まれる理由は何ですか?

正解:キーレス署名はOIDCトークン(例:GitHub Actionsのワークフロー IDトークン)を使用するため、長期秘密鍵の管理と保護が不要です。

Fulcioが OIDCトークンを短期証明書に変換し、Rekor透明性ログに署名が記録されます。鍵のローテーション、鍵の漏洩、鍵の保管の問題がなく、CI/CD環境での運用負担が大幅に軽減されます。

Q3. Pod Security Standards

質問:Pod Security StandardsのRestrictedレベルで必ず満たすべきセキュリティ要件を3つ挙げてください。

正解:

  1. 非rootユーザーで実行(runAsNonRoot: true)
  2. すべてのLinux capabilityを削除(capabilities.drop: ALL)
  3. 権限昇格をブロック(allowPrivilegeEscalation: false)

追加として、seccompプロファイルの適用(RuntimeDefaultまたはLocalhost)、読み取り専用ルートファイルシステム(readOnlyRootFilesystem: true)もRestrictedレベルの推奨事項です。

Q4. ランタイムセキュリティ

質問:FalcoとTetragonのアーキテクチャの違いを説明してください。

正解:

  • Falco:カーネルモジュールまたはeBPFドライバーでシステムコールをキャプチャし、ユーザースペースのルールエンジンでイベントを分析します。検知(detection)中心で、ルールにマッチするとアラートを生成します。
  • Tetragon:純粋なeBPFベースで、カーネルレベルで直接ポリシーを実行します。検知だけでなくブロック(enforcement)も可能で、プロセス実行、ネットワーク接続、ファイルアクセスをカーネルで直接制御できます。

Q5. SLSAフレームワーク

質問:SLSA Level 3で要求される核心的なセキュリティ属性を2つ挙げてください。

正解:

  1. 隔離されたビルド環境:ビルドが他のビルドから隔離された環境で実行され、ビルド間の汚染を防止します。
  2. 改ざん防止(tamper-resistant)provenance:ビルドシステムが生成したprovenanceをビルド自体が変更できません。provenanceはビルドサービスによって署名され、ソースとビルドプロセスの完全性を保証します。

13. 参考資料(さんこうしりょう)

  1. Trivy - https://aquasecurity.github.io/trivy/
  2. Sigstore (cosign, Rekor, Fulcio) - https://www.sigstore.dev/
  3. SLSA Framework - https://slsa.dev/
  4. Falco - https://falco.org/docs/
  5. Tetragon - https://tetragon.io/docs/
  6. Grype - https://github.com/anchore/grype
  7. syft - https://github.com/anchore/syft
  8. CycloneDX - https://cyclonedx.org/
  9. SPDX - https://spdx.dev/
  10. Kyverno - https://kyverno.io/docs/
  11. External Secrets Operator - https://external-secrets.io/
  12. Kubescape - https://kubescape.io/
  13. Chainguard Images - https://www.chainguard.dev/chainguard-images
  14. CIS Benchmarks - https://www.cisecurity.org/benchmark/kubernetes

この記事では、コンテナセキュリティのライフサイクル全体(ぜんたい)を取り上げました。イメージセキュリティ(最小ベースイメージ、スキャニング)、署名と検証(Sigstore/cosign)、SBOM、Pod Security Standards、ネットワークポリシー、ランタイムセキュリティ(Falco/Tetragon)、シークレット管理、SLSAフレームワーク、CI/CDセキュリティパイプラインまで包括的(ほうかつてき)に説明しました。多層防御(たそうぼうぎょ)(Defense in Depth)戦略を採用し、開発初期からCI/CDパイプラインにセキュリティを統合(とうごう)することが鍵(かぎ)です。