Политики проверки подписи образов

Типы политик

Container Security поддерживает создание политик проверки подписей образов следующих типов:

• Image Validation (весь кластер) — политика применяется ко всем объектам кластера.

• Namespaced Image Validation (пространство имен) — политика применятся к объектам кластера из выбранного пространства имен.

Фильтрация образов для проверки

В политике проверки подписи образов раздел matchImageReferences определяет, какие образы из ресурса попадают под действие политики. Без него политика проверяла бы все образы, извлеченные из ресурсов.

Отбор позволяет сузить область верификации до определенных реестров, репозиториев или тегов, оставив остальные образы без проверки.

Поддерживаются два взаимодополняющих формата записи — glob и expression:

• glob — шаблон с подстановочными знаками, удобный для простых и предсказуемых случаев. Символ * заменяет любую последовательность символов, ? — один символ.

  Паттерны glob применяются к полному имени образа, включая реестр, репозиторий и тег или дайджест. Это позволяет, например, проверять только образы с тегом latest или только те, что не закреплены по дайджесту.

  Пример

  matchImageReferences:
    - glob: registry.example.com/prod/*
    - glob: ghcr.io/kyverno/test-verify-image*
  
  

• expression — CEL-выражение, дающее гибкость там, где glob-паттернов недостаточно. Выражение получает на вход образ и возвращает булево значение:

  • true — образ включается в проверку;

  • false — пропускается.

  Пример

  matchImageReferences:
    - expression: "!image.contains('@sha256:')"
  
  

  В примере проверяются только те образы, у которых не указан дайджест.

Несколько записей в matchImageReferences объединяются по логике ИЛИ: образ проходит отбор, если совпал хотя бы с одним паттерном или выражением. Если блок пуст или отсутствует, под проверку попадают все образы ресурса.

Отбор срабатывает до обращения к аттесторам и валидациям: образы, не прошедшие matchImageReferences, не участвуют в проверке подписей и аттестаций и, соответственно, не могут ее провалить. Это важно учитывать при построении политик: слишком широкий отбор увеличивает нагрузку на верификацию, слишком узкий — оставляет часть образов непроверенными.

Доверенные подписи

В политике проверки подписи образов раздел attestors определяет доверенные стороны, подписи которых политика считает валидными.

Каждый источник подписи получает название, на которое затем ссылаются в validations через CEL-выражения.

Типы источников подписи:

• Cosign — публичные ключи, keyless-подписи (через Fulcio/OIDC), сертификаты, прозрачные логи (Rekor), TUF-метаданные.

  Cosign-аттестор поддерживает модели доверия:

  ---

  Публичный ключ

  Keyless-подпись

  Подписывающая сторона владеет парой ключей, проверяющая — публичным ключом. Ключ можно встроить прямо в политику:

  attestors:
    - name: corporate-key
      cosign:
        key:
          value: |
            -----BEGIN PUBLIC KEY-----
            ...
            -----END PUBLIC KEY-----
  
  

  Либо хранить в Kubernetes Secret и ссылаться через secretRef — так публичный ключ не попадает в YAML-политику.

• Notary — сертификаты и, опционально, сертификаты TSA.

  Notary-аттестор проверяет подпись образа через цепочку сертификатов и, опционально, через сертификат TSA, подтверждающий время подписи.

  Конфигурация сводится к передаче цепочки сертификатов в PEM-формате:

  attestors:
    - name: internal-notary
      notary:
        certs:
          value: |
            -----BEGIN CERTIFICATE-----
            ...
            -----END CERTIFICATE-----
  
  

  Сертификаты также можно читать из Kubernetes Secret, а через поле expression — динамически разрешать их с помощью CEL-выражений.

  В модели доверия Notary заранее известен доверенный корневой или конечный сертификат, а при проверке устанавливается, что сертификат подписи выпущен этой цепочкой.