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.

Sources

Related topics