Эта страница переведена с помощью Cloud Translation API.

Запрет развертывания с помощью двоичной аутентификации

1. Введение

Двоичная авторизация — это элемент управления безопасностью во время развертывания, который гарантирует, что в Google Kubernetes Engine (GKE) или Cloud Run развертываются только доверенные образы контейнеров. С помощью двоичной авторизации вы можете потребовать, чтобы образы были подписаны доверенными лицами в процессе разработки, а затем обеспечить проверку подписи при развертывании. Принудительно выполняя проверку, вы можете получить более жесткий контроль над своей контейнерной средой, гарантируя, что в процесс сборки и выпуска будут интегрированы только проверенные образы.

На следующей диаграмме показаны компоненты в настройке двоичной авторизации/сборки облака:

Конвейер аттестации двоичной авторизации Cloud Build. **Рис. 1.**Конвейер Cloud Build, создающий аттестацию двоичной авторизации.

В этом конвейере:

Код для создания образа контейнера передается в исходный репозиторий, например Cloud Source Repositories .
Инструмент непрерывной интеграции (CI) Cloud Build создает и тестирует контейнер.
При сборке образ контейнера помещается в реестр контейнеров или другой реестр, в котором хранятся построенные вами образы.
Cloud Key Management Service , обеспечивающий управление ключами для пары криптографических ключей , подписывает образ контейнера. Полученная подпись затем сохраняется во вновь созданном свидетельстве.
Во время развертывания аттестатор проверяет аттестацию, используя открытый ключ из пары ключей. Двоичная авторизация обеспечивает соблюдение политики , требуя подписанных аттестаций для развертывания образа контейнера.

В этой лабораторной работе вы сосредоточитесь на инструментах и методах защиты развернутых артефактов. В этой лабораторной работе основное внимание уделяется артефактам (контейнерам) после того, как они были созданы, но не развернуты в какой-либо конкретной среде.

Что вы узнаете

Подписание изображения
Политика контроля допуска
Подписание отсканированных изображений
Авторизация подписанных изображений
Заблокированные неподписанные изображения

2. Настройка и требования

Самостоятельная настройка среды

Войдите в Google Cloud Console и создайте новый проект или повторно используйте существующий. Если у вас еще нет учетной записи Gmail или Google Workspace, вам необходимо ее создать .

Имя проекта — это отображаемое имя для участников этого проекта. Это строка символов, не используемая API Google. Вы можете обновить его в любое время.
Идентификатор проекта уникален для всех проектов Google Cloud и является неизменяемым (нельзя изменить после его установки). Cloud Console автоматически генерирует уникальную строку; обычно тебя не волнует, что это такое. В большинстве лабораторий кода вам потребуется указать идентификатор проекта (обычно он обозначается как PROJECT_ID ). Если вам не нравится сгенерированный идентификатор, вы можете создать другой случайный идентификатор. Кроме того, вы можете попробовать свой собственный и посмотреть, доступен ли он. Его нельзя изменить после этого шага, и он останется в силе на протяжении всего проекта.
К вашему сведению, есть третье значение — номер проекта , который используют некоторые API. Подробнее обо всех трех этих значениях читайте в документации .

Затем вам необходимо включить выставление счетов в Cloud Console, чтобы использовать облачные ресурсы/API. Прохождение этой лаборатории кода не должно стоить много, если вообще стоит. Чтобы отключить ресурсы и избежать выставления счетов за пределами этого руководства, вы можете удалить созданные вами ресурсы или удалить весь проект. Новые пользователи Google Cloud имеют право на участие в программе бесплатной пробной версии стоимостью 300 долларов США .

Настройка среды

В Cloud Shell укажите идентификатор и номер вашего проекта. Сохраните их как переменные PROJECT_ID и PROJECT_ID .

export PROJECT_ID=$(gcloud config get-value project)
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID \
    --format='value(projectNumber)')

Включить службы

Включите все необходимые службы:

gcloud services enable \
  cloudkms.googleapis.com \
  cloudbuild.googleapis.com \
  container.googleapis.com \
  containerregistry.googleapis.com \
  artifactregistry.googleapis.com \
  containerscanning.googleapis.com \
  ondemandscanning.googleapis.com \
  binaryauthorization.googleapis.com

Создать репозиторий реестра артефактов

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

gcloud artifacts repositories create artifact-scanning-repo \
  --repository-format=docker \
  --location=us-central1 \
  --description="Docker repository"

Настройте docker для использования ваших учетных данных gcloud при доступе к реестру артефактов.

gcloud auth configure-docker us-central1-docker.pkg.dev

Создать и перейти в рабочий каталог

mkdir vuln-scan && cd vuln-scan

Определите образец изображения

Создайте файл Dockerfile со следующим содержимым.

cat > ./Dockerfile << EOF
from python:3.8-slim  

# App
WORKDIR /app
COPY . ./

RUN pip3 install Flask==2.1.0
RUN pip3 install gunicorn==20.1.0

CMD exec gunicorn --bind :\$PORT --workers 1 --threads 8 main:app

EOF

Создайте файл main.py со следующим содержимым.

cat > ./main.py << EOF
import os
from flask import Flask

app = Flask(__name__)

@app.route("/")
def hello_world():
    name = os.environ.get("NAME", "Worlds")
    return "Hello {}!".format(name)

if __name__ == "__main__":
    app.run(debug=True, host="0.0.0.0", port=int(os.environ.get("PORT", 8080)))
EOF

Создайте и отправьте изображение в AR

Используйте Cloud Build, чтобы создать и автоматически отправить контейнер в реестр артефактов.

gcloud builds submit . -t us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image

3. Подписание изображения

Что такое аттестатор

Свидетель

Этот человек/процесс отвечает за одно звено в цепочке доверия системы.
У них есть криптографический ключ, и они подписывают изображение, если оно проходит процесс утверждения.
В то время как создатель политики определяет политику на высоком уровне, абстрактно, аттестатор отвечает за конкретное соблюдение некоторых аспектов политики.
Это может быть реальный человек, например тестировщик или менеджер по обеспечению качества, или бот в системе CI.
Безопасность системы зависит от их надежности, поэтому важно, чтобы их личные ключи хранились в безопасности.

Каждая из этих ролей может представлять отдельного человека или группу людей в вашей организации. В производственной среде этими ролями, скорее всего, будут управлять отдельные проекты Google Cloud Platform (GCP), а доступ к ресурсам будет распределяться между ними ограниченным образом с использованием Cloud IAM .

Подтверждающие в двоичной авторизации реализуются поверх API Cloud Container Analysis , поэтому важно описать, как это работает, прежде чем двигаться дальше. API Container Analysis был разработан, чтобы позволить вам связывать метаданные с конкретными образами контейнеров.

Например, можно создать заметку для отслеживания уязвимости Heartbleed . Затем поставщики средств безопасности создают сканеры для проверки образов контейнеров на наличие уязвимости и создают событие, связанное с каждым скомпрометированным контейнером.

Помимо отслеживания уязвимостей, Container Analysis был разработан как универсальный API метаданных. Двоичная авторизация использует Container Analysis для связывания подписей с образами контейнеров, которые они проверяют**.** Примечания Container Analysis используются для представления одного подтверждающего лица, а экземпляры создаются и связываются с каждым контейнером, одобренным подтверждающим лицом.

API двоичной авторизации использует концепции «подтверждающих» и «аттестатов», но они реализуются с использованием соответствующих примечаний и вхождений в API Container Analysis.

Создайте заметку проверяющего

Примечание аттестатора — это просто небольшой фрагмент данных, который действует как метка для типа применяемой подписи. Например, одно примечание может обозначать сканирование уязвимостей, а другое может использоваться для завершения контроля качества. На это примечание будет сделана ссылка в процессе подписания.

Создать заметку

cat > ./vulnz_note.json << EOM
{
  "attestation": {
    "hint": {
      "human_readable_name": "Container Vulnerabilities attestation authority"
    }
  }
}
EOM

Сохранить заметку

NOTE_ID=vulnz_note

curl -vvv -X POST \
    -H "Content-Type: application/json"  \
    -H "Authorization: Bearer $(gcloud auth print-access-token)"  \
    --data-binary @./vulnz_note.json  \
    "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=${NOTE_ID}"

Подтвердите примечание

curl -vvv  \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/${NOTE_ID}"

Ваша заметка теперь сохраняется в API Container Analysis.

Создание аттестатора

Подтверждающие используются для выполнения фактического процесса подписания изображения и прикрепляют вхождение примечания к изображению для последующей проверки. Чтобы использовать своего аттестатора, вы также должны зарегистрировать заметку с помощью двоичной авторизации:

Создать аттестатора

ATTESTOR_ID=vulnz-attestor

gcloud container binauthz attestors create $ATTESTOR_ID \
    --attestation-authority-note=$NOTE_ID \
    --attestation-authority-note-project=${PROJECT_ID}

Проверить аттестатора

gcloud container binauthz attestors list

Обратите внимание, что в последней строке указано NUM_PUBLIC_KEYS: 0 ключи вы предоставите на более позднем этапе.

Также обратите внимание, что Cloud Build автоматически создает в вашем проекте built-by-cloud-build когда вы запускаете сборку, генерирующую образы. Таким образом, приведенная выше команда возвращает двух аттестаторов: vulnz-attestor built-by-cloud-build . После успешной сборки образов Cloud Build автоматически подписывает и создает для них аттестации.

Добавление роли IAM

Учетной записи службы двоичной авторизации потребуются права на просмотр примечаний к аттестации. Предоставьте доступ с помощью следующего вызова API

PROJECT_NUMBER=$(gcloud projects describe "${PROJECT_ID}"  --format="value(projectNumber)")

BINAUTHZ_SA_EMAIL="service-${PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"


cat > ./iam_request.json << EOM
{
  'resource': 'projects/${PROJECT_ID}/notes/${NOTE_ID}',
  'policy': {
    'bindings': [
      {
        'role': 'roles/containeranalysis.notes.occurrences.viewer',
        'members': [
          'serviceAccount:${BINAUTHZ_SA_EMAIL}'
        ]
      }
    ]
  }
}
EOM

Используйте файл для создания политики IAM.

curl -X POST  \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    --data-binary @./iam_request.json \
    "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/${NOTE_ID}:setIamPolicy"

Добавление ключа KMS

Прежде чем вы сможете использовать этот аттестатор, вашему органу власти необходимо создать пару криптографических ключей, которую можно будет использовать для подписи образов контейнеров. Это можно сделать через службу управления ключами Google Cloud (KMS) .

Сначала добавьте несколько переменных среды для описания нового ключа.

KEY_LOCATION=global
KEYRING=binauthz-keys
KEY_NAME=codelab-key
KEY_VERSION=1

Создайте брелок для хранения набора ключей.

gcloud kms keyrings create "${KEYRING}" --location="${KEY_LOCATION}"

Создайте новую пару ключей асимметричной подписи для подтверждающего.

gcloud kms keys create "${KEY_NAME}" \
    --keyring="${KEYRING}" --location="${KEY_LOCATION}" \
    --purpose asymmetric-signing   \
    --default-algorithm="ec-sign-p256-sha256"

Вы должны увидеть свой ключ на странице KMS Google Cloud Console.

Теперь свяжите ключ со своим аттестатором с помощью команды gcloud binauthz:

gcloud beta container binauthz attestors public-keys add  \
    --attestor="${ATTESTOR_ID}"  \
    --keyversion-project="${PROJECT_ID}"  \
    --keyversion-location="${KEY_LOCATION}" \
    --keyversion-keyring="${KEYRING}" \
    --keyversion-key="${KEY_NAME}" \
    --keyversion="${KEY_VERSION}"

Если вы еще раз распечатаете список полномочий, вы увидите зарегистрированный ключ:

gcloud container binauthz attestors list

Создание подписанного свидетельства

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

Аттестация должна включать криптографическую подпись, подтверждающую, что аттестатор проверил конкретный образ контейнера и его можно безопасно запускать в вашем кластере. Чтобы указать, какой образ контейнера необходимо подтвердить, необходимо определить его дайджест.

CONTAINER_PATH=us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image

DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:latest \
    --format='get(image_summary.digest)')

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

gcloud beta container binauthz attestations sign-and-create  \
    --artifact-url="${CONTAINER_PATH}@${DIGEST}" \
    --attestor="${ATTESTOR_ID}" \
    --attestor-project="${PROJECT_ID}" \
    --keyversion-project="${PROJECT_ID}" \
    --keyversion-location="${KEY_LOCATION}" \
    --keyversion-keyring="${KEYRING}" \
    --keyversion-key="${KEY_NAME}" \
    --keyversion="${KEY_VERSION}"

С точки зрения Container Analysis, это создаст новое вхождение и прикрепит его к заметке вашего проверяющего. Чтобы убедиться, что все работает как положено, вы можете перечислить свои аттестации.

gcloud container binauthz attestations list \
   --attestor=$ATTESTOR_ID --attestor-project=${PROJECT_ID}

4. Политика контроля допуска

Двоичная авторизация — это функция GKE и Cloud Run, которая предоставляет возможность проверять правила перед запуском образа контейнера. Проверка выполняется при любом запросе на запуск образа, будь то из доверенного конвейера CI/CD или от пользователя, пытающегося развернуть образ вручную. Эта возможность позволяет защитить среду выполнения более эффективно, чем только проверки конвейера CI/CD.

Чтобы понять эту возможность, вы измените политику GKE по умолчанию, чтобы обеспечить соблюдение строгих правил авторизации.

Создайте кластер GKE

Создайте кластер GKE с включенной двоичной авторизацией:

gcloud beta container clusters create binauthz \
    --zone us-central1-a  \
    --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE

Разрешите Cloud Build развертывание в этом кластере:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
        --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
        --role="roles/container.developer"

Разрешить все политики

Сначала проверьте состояние политики по умолчанию и возможность развертывания любого образа.

Обзор существующей политики

gcloud container binauthz policy export

Обратите внимание, что для политики применения установлено значение ALWAYS_ALLOW

evaluationMode: ALWAYS_ALLOW

Разверните образец, чтобы убедиться, что вы можете развернуть что угодно.

kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080

Убедитесь, что развертывание сработало

kubectl get pods

Вы увидите следующий вывод

Удалить развертывание

kubectl delete pod hello-server

Запретить все политики

Теперь обновите политику, чтобы запретить все изображения.

Экспортируйте текущую политику в редактируемый файл.

gcloud container binauthz policy export  > policy.yaml

Изменить политику

В текстовом редакторе измените AssessmentMode с ALWAYS_ALLOW на ALWAYS_DENY .

edit policy.yaml

YAML-файл политики должен выглядеть следующим образом:

globalPolicyEvaluationMode: ENABLE
defaultAdmissionRule:
  evaluationMode: ALWAYS_DENY
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
name: projects/PROJECT_ID/policy

Эта политика относительно проста. Строка globalPolicyEvaluationMode заявляет, что эта политика расширяет глобальную политику, определенную Google. Это позволяет запускать все официальные контейнеры GKE по умолчанию. Кроме того, в политике объявляется defaultAdmissionRule , который гласит, что все остальные модули будут отклонены . Правило допуска включает строку EnforceMode , в которой говорится, что все модули, не соответствующие этому правилу, должны быть заблокированы от запуска в кластере.

Инструкции по созданию более сложных политик можно найти в документации по двоичной авторизации .

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

gcloud container binauthz policy import policy.yaml

Попытка развертывания образца рабочей нагрузки

kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080

Развертывание завершается неудачей со следующим сообщением

Error from server (VIOLATES_POLICY): admission webhook "imagepolicywebhook.image-policy.k8s.io" denied the request: Image gcr.io/google-samples/hello-app:1.0 denied by Binary Authorization default admission rule. Denied by always_deny admission rule

Отмените политику, чтобы разрешить все

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

Изменить политику

В текстовом редакторе измените AssessmentMode с ALWAYS_DENY на ALWAYS_ALLOW .

edit policy.yaml

YAML-файл политики должен выглядеть следующим образом:

globalPolicyEvaluationMode: ENABLE
defaultAdmissionRule:
  evaluationMode: ALWAYS_ALLOW
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
name: projects/PROJECT_ID/policy

Применить отмененную политику

gcloud container binauthz policy import policy.yaml

5. Подписание отсканированных изображений

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

В этом разделе вы настроите Cloud Build для автоматической проверки изображений.

Роли

Добавьте роль наблюдателя аттестатора авторизации двоичных данных в учетную запись службы сборки Cloud:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
  --role roles/binaryauthorization.attestorsViewer

Добавьте роль подписывающего/проверяющего криптоключа Cloud KMS в учетную запись службы Cloud Build (подпись на основе KMS):

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
  --role roles/cloudkms.signerVerifier

Добавьте роль прикрепителя заметок Container Analysis к учетной записи службы Cloud Build:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
  --role roles/containeranalysis.notes.attacher

Предоставить доступ к учетной записи Cloud Build Service.

Cloud Build потребуются права для доступа к API сканирования по требованию. Обеспечьте доступ с помощью следующих команд.

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
        --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
        --role="roles/iam.serviceAccountUser"
        
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
        --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
        --role="roles/ondemandscanning.admin"

Подготовьте этап пользовательской сборки облачной сборки

Вы будете использовать этап «Пользовательская сборка» в Cloud Build, чтобы упростить процесс аттестации. Google предоставляет этот шаг пользовательской сборки, который содержит вспомогательные функции для оптимизации процесса. Перед использованием код для этапа пользовательской сборки необходимо встроить в контейнер и отправить в Cloud Build. Для этого выполните следующие команды:

git clone https://github.com/GoogleCloudPlatform/cloud-builders-community.git
cd cloud-builders-community/binauthz-attestation
gcloud builds submit . --config cloudbuild.yaml
cd ../..
rm -rf cloud-builders-community

Добавьте этап подписания в свой cloudbuild.yaml.

На этом этапе вы добавите этап аттестации в свой конвейер Cloud Build.

Ознакомьтесь с этапом подписания ниже.

Только обзор. Не копировать

#Sign the image only if the previous severity check passes
- id: 'create-attestation'
  name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest'
  args:
    - '--artifact-url'
    - 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image'
    - '--attestor'
    - 'projects/${PROJECT_ID}/attestors/$ATTESTOR_ID'
    - '--keyversion'
    - 'projects/${PROJECT_ID}/locations/$KEY_LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY_NAME/cryptoKeyVersions/$KEY_VERSION'

Напишите файл cloudbuild.yaml с полным описанием конвейера ниже.

cat > ./cloudbuild.yaml << EOF
steps:

# build
- id: "build"
  name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', '.']
  waitFor: ['-']

#Run a vulnerability scan at _SECURITY level
- id: scan
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
    (gcloud artifacts docker images scan \
    us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image \
    --location us \
    --format="value(response.scan)") > /workspace/scan_id.txt

#Analyze the result of the scan
- id: severity check
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
      gcloud artifacts docker images list-vulnerabilities \$(cat /workspace/scan_id.txt) \
      --format="value(vulnerability.effectiveSeverity)" | if grep -Fxq CRITICAL; \
      then echo "Failed vulnerability check for CRITICAL level" && exit 1; else echo "No CRITICAL vulnerability found, congrats !" && exit 0; fi

#Retag
- id: "retag"
  name: 'gcr.io/cloud-builders/docker'
  args: ['tag',  'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good']


#pushing to artifact registry
- id: "push"
  name: 'gcr.io/cloud-builders/docker'
  args: ['push',  'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good']


#Sign the image only if the previous severity check passes
- id: 'create-attestation'
  name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest'
  args:
    - '--artifact-url'
    - 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good'
    - '--attestor'
    - 'projects/${PROJECT_ID}/attestors/$ATTESTOR_ID'
    - '--keyversion'
    - 'projects/${PROJECT_ID}/locations/$KEY_LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY_NAME/cryptoKeyVersions/$KEY_VERSION'



images:
  - us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good
EOF

Запустите сборку

gcloud builds submit

Просмотрите сборку в истории сборок Cloud.

Откройте Cloud Console на странице «История сборок облака» и просмотрите последнюю сборку и успешное выполнение этапов сборки.

6. Авторизация подписанных изображений

В этом разделе вы обновите GKE, чтобы использовать двоичную авторизацию для проверки того, что образ имеет подпись, полученную в результате сканирования уязвимостей, прежде чем разрешить запуск образа.

Обновите политику GKE, чтобы требовать аттестации

Требовать, чтобы изображения были подписаны вашим аттестатором путем добавления кластераAdmissionRules в вашу политику GKE BinAuth.

В настоящее время в вашем кластере действует политика с одним правилом: разрешать контейнеры из официальных репозиториев и отклонять все остальные.

Замените политику обновленной конфигурацией, используя команду ниже.

COMPUTE_ZONE=us-central1-a

cat > binauth_policy.yaml << EOM
defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  evaluationMode: ALWAYS_DENY
globalPolicyEvaluationMode: ENABLE
clusterAdmissionRules:
  ${COMPUTE_ZONE}.binauthz:
    evaluationMode: REQUIRE_ATTESTATION
    enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
    requireAttestationsBy:
    - projects/${PROJECT_ID}/attestors/vulnz-attestor
EOM

Теперь у вас на диске должен появиться новый файл с именем update_policy.yaml. Теперь вместо правила по умолчанию, отклоняющего все изображения, оно сначала проверяет вашего подтверждающего лица на наличие подтверждений.

Загрузите новую политику в Binary Authorization:

gcloud beta container binauthz policy import binauth_policy.yaml

Развертывание подписанного образа

Получите дайджест изображения для хорошего изображения

CONTAINER_PATH=us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image


DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:good \
    --format='get(image_summary.digest)')

Используйте дайджест в конфигурации Kubernetes

cat > deploy.yaml << EOM
apiVersion: v1
kind: Service
metadata:
  name: deb-httpd
spec:
  selector:
    app: deb-httpd
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deb-httpd
spec:
  replicas: 1
  selector:
    matchLabels:
      app: deb-httpd
  template:
    metadata:
      labels:
        app: deb-httpd
    spec:
      containers:
      - name: deb-httpd
        image: ${CONTAINER_PATH}@${DIGEST}
        ports:
        - containerPort: 8080
        env:
          - name: PORT
            value: "8080"

EOM

Разверните приложение в GKE

kubectl apply -f deploy.yaml

Просмотрите рабочую нагрузку в консоли и обратите внимание на успешное развертывание образа.

7. Заблокированные неподписанные изображения

Создайте изображение

На этом этапе вы будете использовать локальный докер для создания образа в локальном кеше.

docker build -t us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad .

Загрузите неподписанное изображение в репозиторий.

docker push us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad

Получите дайджест изображения для плохого изображения

CONTAINER_PATH=us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image


DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:bad \
    --format='get(image_summary.digest)')

Используйте дайджест в конфигурации Kubernetes

cat > deploy.yaml << EOM
apiVersion: v1
kind: Service
metadata:
  name: deb-httpd
spec:
  selector:
    app: deb-httpd
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deb-httpd
spec:
  replicas: 1
  selector:
    matchLabels:
      app: deb-httpd
  template:
    metadata:
      labels:
        app: deb-httpd
    spec:
      containers:
      - name: deb-httpd
        image: ${CONTAINER_PATH}@${DIGEST}
        ports:
        - containerPort: 8080
        env:
          - name: PORT
            value: "8080"

EOM

Попытайтесь развернуть приложение в GKE.

kubectl apply -f deploy.yaml

Просмотрите рабочую нагрузку в консоли и обратите внимание на ошибку, сообщающую, что развертывание отклонено:

No attestations found that were valid and signed by a key trusted by the attestor

8. Поздравляем!

Поздравляем, вы завершили работу над кодом!

Что мы рассмотрели:

Подписание изображения
Политика контроля допуска
Подписание отсканированных изображений
Авторизация подписанных изображений
Заблокированные неподписанные изображения

Что дальше:

Очистить

Чтобы избежать списания средств с вашей учетной записи Google Cloud за ресурсы, используемые в этом руководстве, либо удалите проект, содержащий ресурсы, либо сохраните проект и удалите отдельные ресурсы.

Удаление проекта

Самый простой способ избавиться от выставления счетов — удалить проект, созданный вами для этого руководства.

—

Последнее обновление: 21.03.23.