DockerSeniorSystem design
Зачем нужен image signing (Cosign, Notary)? Что такое supply chain security в контексте контейнеров?
Signing доказывает происхождение и целостность image digest (Cosign + Sigstore). Supply chain security включает build provenance, SBOM, vulnerability scanning, secrets hygiene и admission control — только проверенные подписанные образы попадают в production.
Зачем нужен image signing
Image signing решает проблему происхождения и целостности: deployment система может проверить, что конкретный image digest был создан доверенным CI pipeline и не подменён в registry или при передаче. Без signing невозможно отличить легитимный образ от скомпрометированного, даже если registry настроен правильно.
Cosign и Sigstore
Cosign (проект Sigstore) — стандарт для подписи container images:
- Keyless signing: использует OIDC identity (GitHub Actions, GitLab CI, Google SA) вместо долгосрочных ключей. Подпись привязана к identity, а не к файлу ключа.
- Transparency log (Rekor): все подписи записываются в публичный append-only лог — аудит невозможно скрыть.
- Attestations: помимо подписи образа можно приложить SBOM, vulnerability scan report, provenance (откуда и как собран).
# Подписать образ (keyless, в GitHub Actions):
cosign sign --yes registry.example.com/api@sha256:abc123...
# Проверить подпись:
cosign verify \
--certificate-identity-regexp 'https://github.com/myorg/myrepo' \
--certificate-oidc-issuer 'https://token.actions.githubusercontent.com' \
registry.example.com/api@sha256:abc123...
# Приложить SBOM как attestation:
cosign attest --predicate sbom.json \
--type cyclonedx \
registry.example.com/api@sha256:abc123...
Supply chain security — шире чем signing
Signing — один слой защиты. Полный supply chain security pipeline включает:
- Build провенанс: зафиксировать, что образ собран из конкретного commit в конкретном CI pipeline (
slsa-framework/slsa-github-generator). - SBOM: Software Bill of Materials — список всех компонентов в образе (CycloneDX или SPDX формат).
- Vulnerability scanning: Trivy по digest перед деплоем.
- Secrets hygiene: никаких секретов в слоях образа или build logs.
- Admission control: Kubernetes OPA/Gatekeeper или Kyverno проверяет подпись перед запуском Pod. Только signed images из trusted identity проходят в production namespace.
# Kyverno ClusterPolicy: разрешить только signed images
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-signed-images
spec:
validationFailureAction: Enforce
rules:
- name: check-image-signature
match:
resources:
kinds: [Pod]
verifyImages:
- imageReferences: ["registry.example.com/*"]
attestors:
- entries:
- keyless:
issuer: "https://token.actions.githubusercontent.com"
subject: "https://github.com/myorg/myrepo/.github/workflows/build.yml@refs/heads/main"
Подводные камни
- Signing говорит кто подписал, а не что внутри безопасно: подписанный образ может содержать CVE. Signing + scanning — два разных инструмента.
- Тег vs digest: подписывать нужно digest (
sha256:...), а не тег. Тег mutable — его можно перенаправить на другой образ. - Break-glass сценарии: жёсткая admission policy должна иметь emergency bypass с аудитом и alert.
- Rollback по signed digest: при инциденте нужно откатиться на предыдущий signed digest, а не на floating tag типа
:stable. - Private key management для key-based signing: KMS (AWS KMS, HashiCorp Vault) вместо файла на диске. Keyless через Sigstore проще в CI и безопаснее по умолчанию.
Common mistakes
- Считать signed image автоматически безопасным.
- Подписывать tag instead of verifying the deployed digest.
- Не защищать CI runner and signing identity.
What the interviewer is testing
- Объясняет integrity/provenance purpose of signing.
- Связывает signing with SBOM, scanning and admission.
- Понимает digest-based verification and trusted identity.