目次
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 /app /app
COPY /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 /app /app
COPY /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 /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
COPY /etc/passwd /etc/passwd
COPY /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 /app/dist ./dist
COPY /app/node_modules ./node_modules
COPY /app/package.json ./
# セキュリティ:非rootで実行
USER appuser
ENV NODE_ENV=production
EXPOSE 3000
CMD ["node", "dist/index.js"]
3. イメージスキャニング:脆弱性検出(けんしゅつ)
3.1 スキャニングツール比較
| ツール | ライセンス | 特徴 | CI/CD統合 | SBOM生成 |
|---|---|---|---|---|
| Trivy | Apache 2.0 | 総合スキャナー(イメージ/IaC/シークレット) | 優秀 | 対応 |
| Grype | Apache 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つ挙げてください。
正解:
- 非rootユーザーで実行(runAsNonRoot: true)
- すべてのLinux capabilityを削除(capabilities.drop: ALL)
- 権限昇格をブロック(allowPrivilegeEscalation: false)
追加として、seccompプロファイルの適用(RuntimeDefaultまたはLocalhost)、読み取り専用ルートファイルシステム(readOnlyRootFilesystem: true)もRestrictedレベルの推奨事項です。
Q4. ランタイムセキュリティ
質問:FalcoとTetragonのアーキテクチャの違いを説明してください。
正解:
- Falco:カーネルモジュールまたはeBPFドライバーでシステムコールをキャプチャし、ユーザースペースのルールエンジンでイベントを分析します。検知(detection)中心で、ルールにマッチするとアラートを生成します。
- Tetragon:純粋なeBPFベースで、カーネルレベルで直接ポリシーを実行します。検知だけでなくブロック(enforcement)も可能で、プロセス実行、ネットワーク接続、ファイルアクセスをカーネルで直接制御できます。
Q5. SLSAフレームワーク
質問:SLSA Level 3で要求される核心的なセキュリティ属性を2つ挙げてください。
正解:
- 隔離されたビルド環境:ビルドが他のビルドから隔離された環境で実行され、ビルド間の汚染を防止します。
- 改ざん防止(tamper-resistant)provenance:ビルドシステムが生成したprovenanceをビルド自体が変更できません。provenanceはビルドサービスによって署名され、ソースとビルドプロセスの完全性を保証します。
13. 参考資料(さんこうしりょう)
- Trivy - https://aquasecurity.github.io/trivy/
- Sigstore (cosign, Rekor, Fulcio) - https://www.sigstore.dev/
- SLSA Framework - https://slsa.dev/
- Falco - https://falco.org/docs/
- Tetragon - https://tetragon.io/docs/
- Grype - https://github.com/anchore/grype
- syft - https://github.com/anchore/syft
- CycloneDX - https://cyclonedx.org/
- SPDX - https://spdx.dev/
- Kyverno - https://kyverno.io/docs/
- External Secrets Operator - https://external-secrets.io/
- Kubescape - https://kubescape.io/
- Chainguard Images - https://www.chainguard.dev/chainguard-images
- CIS Benchmarks - https://www.cisecurity.org/benchmark/kubernetes
この記事では、コンテナセキュリティのライフサイクル全体(ぜんたい)を取り上げました。イメージセキュリティ(最小ベースイメージ、スキャニング)、署名と検証(Sigstore/cosign)、SBOM、Pod Security Standards、ネットワークポリシー、ランタイムセキュリティ(Falco/Tetragon)、シークレット管理、SLSAフレームワーク、CI/CDセキュリティパイプラインまで包括的(ほうかつてき)に説明しました。多層防御(たそうぼうぎょ)(Defense in Depth)戦略を採用し、開発初期からCI/CDパイプラインにセキュリティを統合(とうごう)することが鍵(かぎ)です。
현재 단락 (1/627)
コンテナ環境(かんきょう)は、従来のVM基盤インフラとは異なる固有(こゆう)の脅威表面を持ちます。イメージ脆弱性(ぜいじゃくせい)、設定ミス、ランタイム攻撃(こうげき)、サプライチェーン脅威まで、多層...