Верификация provenance и политики-гейты

Подпись — это утверждение; защита — это верификация

L01 дал тебе половину «производства»: cosign sign прикрепил подпись к digest образа, а билд-платформа выдала SLSA provenance attestation, описывающий, что его собрало. Это настоящая криптография. И сама по себе она полностью инертна. Подпись — это всего лишь утверждение, привинченное к артефакту, — она ничего не меняет в том, что запускается. Защита возникает только в тот момент, когда что-то отказывается запускать артефакт, не подписанный и не attestation-нутый доверенным билдером. Если ничто не отказывается, подписи — настенное украшение.

Так что вопрос, на который отвечает этот урок, — не «как мне подписывать» (ты это сделал), а «что именно я верифицирую и где живёт отказ».

Что ты верифицируешь: подпись, provenance и identity — по digest

Верификация — это три проверки, и пропуск любой из них оставляет дыру:

# 1. ПОДПИСЬ — этот конкретный digest образа подписан identity, которому я доверяю?
#    Keyless: OIDC identity подписавшего записан в Rekor (transparency log),
#    а сертификат цепляется к Fulcio. Ты пинишь КОГО, а не долгоживущий ключ.
cosign verify \
  --certificate-identity "https://github.com/acme/app/.github/workflows/release.yml@refs/heads/main" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  ghcr.io/acme/app@sha256:abc123...

# 2. PROVENANCE — говорит ли SLSA attestation, что МОЙ билдер собрал это из МОЕГО коммита?
cosign verify-attestation \
  --type slsaprovenance \
  --certificate-identity "https://github.com/acme/app/.github/workflows/release.yml@refs/heads/main" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  ghcr.io/acme/app@sha256:abc123...

Первая проверка отвечает на «это подписано кем-то, кому я доверяю?» Вторая отвечает на более сильный вопрос: «был ли этот образ собран моим CI, из моего репозитория, на коммите, который я могу назвать?» — вот почему provenance важен даже для «подписанного» образа. Атакующий, укравший ключ подписи, может подписать вредоносный образ; но ему нелегко подделать provenance attestation, утверждающий, что твоя билд-платформа собрала его из твоего источника. И каждая проверка прибита к digest образа (@sha256:...), никогда не к меняемому тегу — тег можно перенаправить на другой образ после того, как ты его проверил; digest — это содержимое.

Третья проверка: политика на attestation

Проверить, что подпись валидна, недостаточно — ты должен утвердить, что содержимое совпадает с твоими ожиданиями. Policy-as-code (политика как код — правила безопасности, версионируемые в репозитории и применяемые автоматически) выражает это так, что оно под контролем версий, тестируемо и применяется единообразно:

# Набросок OPA/Rego: впускаем, только если builder == наш CI И source repo == наш
package supplychain

default allow = false

allow {
  input.provenance.builder.id == "https://github.com/acme/app/.github/workflows/release.yml@refs/heads/main"
  input.provenance.invocation.configSource.uri == "git+https://github.com/acme/app@refs/heads/main"
  input.image.digest == input.requested.digest
}

Это разница между «существует валидная подпись» и «валидная подпись от моего билдера для моего источника на этом конкретном digest». Утёкший ключ, форк, пересборка из подделанной ветки — все они дают подписи, которые криптографически валидны и отвергнуты политикой.

Где живёт отказ: admission control

Ты мог бы запускать cosign verify в своём CD-джобе деплоя. Это лучше, чем ничего, и это слабый гейт: любой, кто деплоит в обход CI — оператор с kubectl, скомпрометированный CD-шаг, break-glass-скрипт — обходит его полностью. Это ровно инцидент с пятничным хотфиксом. CI-проверка защищает путь, проходящий через CI, а это не тот путь, которым ходят атакующие и паникующие инженеры.

Принуждение, которое ничто не обходит, живёт на рантайм-границе: Kubernetes admission controller (контроллер допуска — плагин API-сервера, перехватывающий каждый запрос на создание ресурса и способный его отклонить). На каждом создании Pod контроллер (Sigstore policy-controller, Kyverno или OPA Gatekeeper) перехватывает запрос, резолвит образ в его digest, верифицирует подпись + provenance против твоей политики и отказывает в admission, если проверка не прошла. Нет «задеплоить в обход» — единственный способ запустить Pod проходит через API-сервер, а API-сервер вызывает webhook.

# Sigstore policy-controller: запускаться могут только подписанные + provenance-нутые
# образы из нашего CI
apiVersion: policy.sigstore.dev/v1beta1
kind: ClusterImagePolicy
metadata:
  name: require-acme-provenance
spec:
  images:
    - glob: "ghcr.io/acme/**"
  authorities:
    - keyless:
        identities:
          - issuer: "https://token.actions.githubusercontent.com"
            subject: "https://github.com/acme/app/.github/workflows/release.yml@refs/heads/main"
      attestations:
        - name: must-have-slsa-provenance
          predicateType: "https://slsa.dev/provenance/v1"
  # КРИТИЧНО: отказывай, когда верификация не может завершиться, не впускай по ошибке
  policy:
    fetchConfigFile: true

Уровни SLSA: планка, против которой ты верифицируешь

SLSA — это фреймворк, определяющий, насколько сильна гарантия provenance. Более высокие уровни означают, что provenance сгенерирован самой билд-платформой (а не билд-скриптом), сборки изолированы и неподделываемы, а путь от источника к артефакту устойчив к подмене. Ты выбираешь целевой уровень — скажем, «все прод-образы должны соответствовать SLSA Build L3» — и твоя политика верифицирует, что входящие артефакты несут provenance, отвечающий этой планке, прежде чем они деплоятся. Уровень — это контракт; admission control — это то, что его принуждает.

Fail-closed против fail-open: компромисс, решающий всё

Вот тонкость, которая повернула вторую половину этой истории. Проверка верификации может не завершиться: реестр недоступен, transparency log на миг недостижим, attestation отсутствует. Политика должна решить, что делать тогда, и ответов всего два:

• Fail closed — если верификация не может завершиться, отказывай. Артефакт не запускается.
• Fail open — если верификация не может завершиться, впускай всё равно. Артефакт запускается непроверенным.

Fail-open-политика — это молчаливое отсутствие защиты: каждый временный сбой инфраструктуры подписи или лога становится окном, в которое проезжает что угодно. Команда из истории сначала выкатила fail-open-политику; когда Rekor стал на миг недоступен, непроверенные образы проехали прямиком, и никто не заметил, потому что не было отказа, на который сработал бы алерт. Fail closed — единственный корректный дефолт.

Цена реальна, и ты проектируешь под неё, а не вокруг неё: fail-closed означает, что сбой реестра или лога может блокировать деплои. Доступность ты выкупаешь обратно, кешируя trust roots, мониторя путь верификации как зависимость первого класса и относясь к инфраструктуре подписи как к production-критичной, — а не ослабляя политику до fail-open, что меняет проблему доступности деплоя на отсутствие защиты как фичи.