Ograniczanie wdrożeń za pomocą uwierzytelniania plików binarnych

1. Wprowadzenie

Autoryzacja plików binarnych to funkcja zabezpieczeń podczas wdrażania, która zapewnia, że w Google Kubernetes Engine (GKE) lub Cloud Run wdrażane są tylko zaufane obrazy kontenerów. Dzięki usłudze Binary Authorization możesz wymagać, aby obrazy były podpisywane przez zaufane urzędy w trakcie procesu programowania, a następnie egzekwować weryfikację podpisu podczas ich wdrażania. Wymuszanie weryfikacji pozwala uzyskać ściślejszą kontrolę nad środowiskiem kontenera, ponieważ na integrację w procesie kompilacji i udostępniania pozwala tylko zweryfikowanym obrazom.

Poniższy diagram przedstawia komponenty w konfiguracji usługi Binary Authorization/Cloud Build:

**Rys. 1.**Potok Cloud Build, który tworzy atest usługi Binary Authorization.

W tym potoku:

1. Kod do tworzenia obrazu kontenera jest przekazywany do repozytorium źródłowego, takiego jak Cloud Source Repositories.
2. Cloud Build kompiluje i testuje kontener za pomocą narzędzia do ciągłej integracji.
3. Kompilacja przenosi obraz kontenera do Container Registry lub innego rejestru, w którym przechowywane są skompilowane obrazy.
4. Obraz kontenera podpisuje usługa zarządzania kluczami w chmurze, która umożliwia zarządzanie kluczami w parze kluczy kryptograficznych. Powstały podpis jest przechowywany w nowo utworzonym atestie.
5. W czasie wdrażania atestator weryfikuje atest za pomocą klucza publicznego z pary kluczy. Binary Authorization egzekwuje zasadę, wymagając podpisanych atestów do wdrożenia obrazu kontenera.

W tym module skupisz się na narzędziach i technikach zabezpieczania wdrożonych artefaktów. W tym module skupiamy się na artefaktach (kontenerach), które zostały utworzone, ale nie zostały wdrożone w żadnym konkretnym środowisku.

Czego się nauczysz

• Podpisywanie obrazów
• Zasady kontroli wstępu
• Podpisywanie zeskanowanych zdjęć
• Autoryzacja podpisanych obrazów
• Zablokowane niepodpisane obrazy

2. Konfiguracja i wymagania

Samodzielne konfigurowanie środowiska

1. Zaloguj się w konsoli Google Cloud i utwórz nowy projekt lub wykorzystaj już istniejący. Jeśli nie masz jeszcze konta Gmail ani Google Workspace, musisz je utworzyć.

• Nazwa projektu jest wyświetlaną nazwą uczestników tego projektu. To ciąg znaków, który nie jest używany przez interfejsy API Google. W każdej chwili możesz ją zmienić.
• Identyfikator projektu jest unikalny we wszystkich projektach Google Cloud i nie można go zmienić (po jego ustawieniu nie można go zmienić). Cloud Console automatycznie wygeneruje unikalny ciąg znaków. zwykle nieważne, co ona jest. W większości ćwiczeń z programowania konieczne jest odwołanie się do identyfikatora projektu (zwykle nazywa się on PROJECT_ID). Jeśli nie podoba Ci się wygenerowany identyfikator, możesz wygenerować kolejny losowy. Możesz też spróbować własnych sił i sprawdzić, czy jest dostępna. Potem nie będzie można go zmienić. Pozostanie ono przez czas trwania projektu.
• Dostępna jest trzecia wartość, numer projektu, z którego korzystają niektóre interfejsy API. Więcej informacji o wszystkich 3 wartościach znajdziesz w dokumentacji.

Uwaga: identyfikator projektu jest globalnie unikalny i po wybraniu nie może go użyć żaden inny użytkownik. Jesteś jedynym użytkownikiem tego identyfikatora. Nawet po usunięciu projektu identyfikatora nie można użyć ponownie

Uwaga: jeśli używasz konta Gmail, jako domyślną lokalizację możesz pozostawić ustawienie Brak organizacji. Jeśli używasz konta Google Workspace, wybierz lokalizację, która będzie odpowiednia dla Twojej organizacji.

2. Następnie musisz włączyć płatności w Cloud Console, aby korzystać z zasobów Cloud/interfejsów API. Ukończenie tego ćwiczenia z programowania nie powinno kosztować zbyt wiele. Aby wyłączyć zasoby, aby nie naliczać opłat po zakończeniu tego samouczka, możesz usunąć utworzone zasoby lub cały projekt. Nowi użytkownicy Google Cloud mogą skorzystać z programu bezpłatnego okresu próbnego o wartości 300 USD.

Konfiguracja środowiska

W Cloud Shell ustaw identyfikator i numer projektu. Zapisz je jako zmienne PROJECT_ID i PROJECT_ID.

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

Włączanie usług

Włącz wszystkie niezbędne usługi:

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 

Tworzenie repozytorium Artifact Registry

W tym module będziesz używać Artifact Registry do przechowywania i skanowania obrazów. Utwórz repozytorium za pomocą tego polecenia.

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

Skonfiguruj Dockera tak, aby wykorzystywał dane logowania gcloud podczas uzyskiwania dostępu do Artifact Registry.

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

Tworzenie katalogu roboczego i przekształcanie go w katalog roboczy

mkdir vuln-scan && cd vuln-scan

Definiowanie przykładowego obrazu

Utwórz plik o nazwie Dockerfile z poniższą zawartością.

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

Utwórz plik o nazwie main.py z następującą zawartością

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

Kompilowanie i przekazywanie obrazu do AR

Użyj Cloud Build, aby skompilować i automatycznie wypchnąć kontener do Artifact Registry.

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

3. Podpisywanie obrazów

Czym jest atestator

Atestator

• Ta osoba lub proces odpowiada za 1 ogniwo w łańcuchu zaufania systemu.
• Przechowują klucz kryptograficzny i podpisują obraz, jeśli przejdzie przez proces zatwierdzenia.
• Twórca zasad określa zasady w sposób ogólny, abstrakcyjny, natomiast atestator jest odpowiedzialny za konkretne egzekwowanie pewnych zasad.
• Może to być prawdziwa osoba, np. tester jakości lub menedżer, albo bot w systemie CI.
• Bezpieczeństwo systemu zależy od wiarygodności systemu, dlatego ważne jest, aby klucze prywatne były bezpieczne.

Każda z tych ról może reprezentować konkretną osobę lub zespół osób w organizacji. W środowisku produkcyjnym role te byłyby prawdopodobnie zarządzane przez osobne projekty Google Cloud Platform (GCP), a dostęp do zasobów byłby między nimi w ograniczony sposób rozdzielany za pomocą Cloud IAM.

Atestatory w usłudze Binary Authorization są zaimplementowane razem z Cloud Container Analysis API, dlatego ważne jest, aby najpierw opisać, jak to działa. Interfejs Container Analysis API umożliwia powiązanie metadanych z konkretnymi obrazami kontenerów.

Możesz na przykład utworzyć notatkę, aby śledzić lukę w zabezpieczeniach Heartbleed. Następnie dostawcy zabezpieczeń tworzą skanery, aby testować obrazy kontenerów pod kątem luk w zabezpieczeniach i tworzyć wystąpienia powiązane z każdym zaatakowanym kontenerem.

Container Analysis, oprócz luk w zabezpieczeniach, został zaprojektowany jako ogólny interfejs API metadanych. Autoryzacja plików binarnych wykorzystuje Container Analysis do powiązania podpisów z obrazami kontenerów, które weryfikuje**.** Notatka do analizy kontenera służy do reprezentowania pojedynczego atestatora, a wystąpienia są tworzone i powiązane z każdym kontenerem zatwierdzonym przez atestator.

Interfejs Binary Authorization API wykorzystuje koncepcje „atestatorów” i „atesty”, ale są one zaimplementowane za pomocą odpowiednich notatek i wystąpień w interfejsie Container Analysis API.

Tworzenie notatki atestatora

Notatka atestatora to po prostu niewielka ilość danych służąca jako etykieta stosowanego typu podpisu. Jedna notatka może na przykład wskazywać na skanowanie pod kątem luk w zabezpieczeniach, a druga – do zatwierdzenia przez kontrolę jakości. Zostanie ona przywołana podczas procesu podpisywania.

Tworzenie notatki

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

Zapisywanie notatki

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}"

Sprawdzanie notatki

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

Twoja notatka została zapisana w interfejsie Container Analysis API.

Tworzenie atestatora

Atestatory służą do przeprowadzania rzeczywistego procesu podpisywania obrazu i dołączają wystąpienie notatki do obrazu na potrzeby późniejszej weryfikacji. Aby skorzystać z atestatora, musisz też zarejestrować notatkę w usłudze Binary Authorization:

Utwórz atestator

ATTESTOR_ID=vulnz-attestor

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

Zweryfikuj atestator

gcloud container binauthz attestors list

Uwaga: ostatni wiersz wskazuje NUM_PUBLIC_KEYS: 0, które przekażesz w następnym kroku.

Pamiętaj też, że Cloud Build automatycznie tworzy w projekcie atestator built-by-cloud-build po uruchomieniu kompilacji generującej obrazy. Polecenie powyżej zwraca 2 atestatory: vulnz-attestor i built-by-cloud-build. Po skompilowaniu obrazów Cloud Build automatycznie podpisuje i tworzy dla nich atesty.

Dodawanie roli uprawnień

Konto usługi Binary Authorization musi mieć uprawnienia do wyświetlania informacji o atestach. Przyznaj dostęp za pomocą następującego wywołania interfejsu 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

Utwórz zasadę uprawnień przy użyciu pliku

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"

Dodawanie klucza KMS

Zanim użyjesz tego atestatora, Twój urząd musi utworzyć parę kluczy kryptograficznych, której można używać do podpisywania obrazów kontenerów. Możesz to zrobić za pomocą usługi Google Cloud Key Management Service (KMS).

Najpierw dodaj zmienne środowiskowe do opisania nowego klucza

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

Tworzenie pęku kluczy do przechowywania zestawu kluczy

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

Utwórz nową asymetryczną parę kluczy podpisywania dla atestatora

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

Klucz powinien pojawić się na stronie KMS w konsoli Google Cloud.

Powiąż klucz z atestatorem za pomocą polecenia 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}"

Po ponownym wydrukowaniu listy urzędów powinien pojawić się zarejestrowany klucz:

gcloud container binauthz attestors list

Tworzenie podpisanego atestu

W tej chwili masz skonfigurowane funkcje, które umożliwiają podpisywanie obrazów. Użyj utworzonego wcześniej atestatora do podpisania obrazu kontenera, z którym pracujesz.

Atest musi zawierać podpis kryptograficzny, który informuje, że atestator zweryfikował dany obraz kontenera i można go bezpiecznie uruchomić w Twoim klastrze. Aby określić, który obraz kontenera ma być poświadczony, musisz określić jego skrót.

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)')

Teraz możesz utworzyć atest za pomocą gcloud. Polecenie pobiera po prostu szczegóły klucza, którego chcesz użyć do podpisywania, oraz konkretny obraz kontenera, który chcesz zatwierdzić.

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}"

W warunkach analizy kontenera spowoduje to utworzenie nowego wystąpienia i dołączenie go do notatki atestatora. Aby mieć pewność, że wszystko działa zgodnie z oczekiwaniami, możesz dodać listę atestów

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

4. Zasady kontroli wstępu

Binary Authorization to funkcja w GKE i Cloud Run, która umożliwia sprawdzanie reguł przed uruchomieniem obrazu kontenera. Weryfikacja jest wykonywana przy każdym żądaniu uruchomienia obrazu, niezależnie od tego, czy jest to zaufany potok CI/CD, czy też użytkownik próbujący ręcznie wdrożyć obraz. Ta funkcja pozwala skuteczniej zabezpieczać środowiska wykonawcze niż same testy potoku CI/CD.

Aby zrozumieć tę funkcję, zmodyfikuj domyślną zasadę GKE tak, aby wymuszała rygorystyczną regułę autoryzacji.

Tworzenie klastra GKE

Utwórz klaster GKE z włączoną autoryzacją plików binarnych:

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

Zezwól Cloud Build na wdrażanie w tym klastrze:

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

Zezwalaj na wszystkie zasady

Najpierw sprawdź domyślny stan zasady i możliwość wdrożenia dowolnego obrazu

1. Sprawdź obecną zasadę

gcloud container binauthz policy export

2. Zauważ, że zasada egzekwowania jest ustawiona na ALWAYS_ALLOW

evaluationMode: ALWAYS_ALLOW

3. Wdróż przykład, aby sprawdzić, czy możesz wdrożyć wszystko

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

4. Sprawdź, czy wdrożenie zadziałało

kubectl get pods

Zobaczysz następujące dane wyjściowe

5. Usuń wdrożenie

kubectl delete pod hello-server

Odrzuć wszystkie zasady

Teraz zaktualizuj zasadę, żeby nie zezwalać na wyświetlanie wszystkich obrazów.

1. Eksportuj bieżącą zasadę do pliku z możliwością edycji

gcloud container binauthz policy export  > policy.yaml

2. Zmień zasadę

W edytorze tekstu zmień ustawienie evaluationMode z ALWAYS_ALLOW na ALWAYS_DENY.

edit policy.yaml

Plik YAML zasad powinien wyglądać tak:

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

Te zasady są stosunkowo proste. Wiersz globalPolicyEvaluationMode deklaruje, że ta zasada rozszerza zasadę globalną zdefiniowaną przez Google. Dzięki temu wszystkie oficjalne kontenery GKE będą domyślnie uruchamiane. Dodatkowo zasada deklaruje regułę defaultAdmissionRule, która mówi, że wszystkie inne pody będą odrzucane. Reguła dostępu zawiera wiersz enforcementMode, który wskazuje, że wszystkie pody, które nie są zgodne z tą regułą, powinny zostać zablokowane w klastrze.

Instrukcje tworzenia bardziej złożonych zasad znajdziesz w dokumentacji usługi Binary Authorization.

3. Otwórz Terminal i zastosuj nową zasadę, a następnie poczekaj kilka sekund na rozpowszechnienie zmiany

gcloud container binauthz policy import policy.yaml

4. Próba wdrożenia przykładowego zbioru zadań

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

5. Nie udało się wdrożyć i wyświetla się następujący komunikat

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

Przywróć zasadę, by zezwolić na wszystkie

Zanim przejdziesz do następnej sekcji, cofnij zmiany zasad.

1. Zmień zasadę

W edytorze tekstu zmień ustawienie evaluationMode z ALWAYS_DENY na ALWAYS_ALLOW.

edit policy.yaml

Plik YAML zasad powinien wyglądać tak:

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

2. Zastosuj cofniętą zasadę

gcloud container binauthz policy import policy.yaml

5. Podpisywanie zeskanowanych zdjęć

Masz włączone podpisywanie obrazów i ręcznie używasz atestatora do podpisania przykładowego obrazu. W praktyce warto stosować atesty podczas zautomatyzowanych procesów, takich jak potoki CI/CD.

W tej sekcji skonfigurujesz Cloud Build tak, aby automatycznie atestował obrazy

Role

Dodaj rolę wyświetlającego atestator autoryzacji plików binarnych do konta usługi Cloud Build:

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

Dodaj rolę podpisującego lub weryfikatora klucza CryptoKey Cloud KMS do konta usługi Cloud Build (podpisywanie przy użyciu KMS):

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

Dodaj rolę dołączającego notatki analizy kontenera do konta usługi Cloud Build:

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

Przyznaj dostęp kontu usługi Cloud Build

Cloud Build wymaga uprawnień dostępu do interfejsu API skanowania na żądanie. Przyznaj dostęp przy użyciu tych poleceń.

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"

Przygotuj krok kompilacji niestandardowej Cloud Build

Aby uprościć proces poświadczania, będziesz używać kroku kompilacji niestandardowej w Cloud Build. Google udostępnia ten etap kompilacji niestandardowej, który zawiera funkcje pomocnicze, które upraszczają ten proces. Przed użyciem kodu wykonania niestandardowego kroku kompilacji należy go umieścić w kontenerze i przekazać do Cloud Build. Aby to zrobić, uruchom następujące polecenia:

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

Dodaj krok podpisywania do pliku cloudbuild.yaml

W tym kroku dodasz krok poświadczania do potoku Cloud Build.

1. Zapoznaj się z poniższym krokiem do podpisania.

Tylko recenzja. Nie kopiuj

#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'

2. Zapisz plik cloudbuild.yaml z pełnym potokiem poniżej.

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

Uruchamianie kompilacji

gcloud builds submit

Sprawdzanie kompilacji w historii Cloud Build

W konsoli Cloud otwórz stronę Historia Cloud Build i sprawdź tę najnowszą kompilację oraz udane jej wykonanie.

6. Autoryzacja podpisanych obrazów

W tej sekcji zaktualizujesz GKE, aby używała usługi Binary Authorization do sprawdzania, czy obraz ma podpis ze skanowania pod kątem luk w zabezpieczeniach, zanim zezwolisz na uruchomienie obrazu.

Zaktualizuj zasadę GKE, aby wymagać atestu

Wymagaj, aby obrazy były podpisane przez atestator przez dodanie clusterAdmissionRules do zasady GKE BinAuth

Obecnie w klastrze działają zasady z 1 regułą: zezwalanie na kontenery z oficjalnych repozytoriów i odrzucanie wszystkich innych.

Zastąp zasadę zaktualizowaną konfiguracją za pomocą poniższego polecenia.

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

Na dysku powinien znajdować się nowy plik o nazwie updated_policy.yaml. Teraz zamiast domyślnej reguły odrzucającej wszystkie obrazy, sprawdza ona najpierw atestator pod kątem weryfikacji.

Prześlij nową zasadę do usługi Binary Authorization:

gcloud beta container binauthz policy import binauth_policy.yaml

Wdrażanie podpisanego obrazu

Pobierz skrót obrazu dobrego

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)')

Używanie skrótu w konfiguracji 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

Wdrażanie aplikacji w GKE

kubectl apply -f deploy.yaml

Sprawdź zbiór zadań w konsoli i zanotuj udane wdrożenie obrazu.

7. Zablokowane niepodpisane obrazy

Utwórz obraz

W tym kroku użyjesz lokalnego Dockera, aby utworzyć obraz w lokalnej pamięci podręcznej.

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

Przekaż niepodpisany obraz do repozytorium

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

Pobierz podsumowanie obrazu niewłaściwego

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)')

Używanie skrótu w konfiguracji 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

Spróbuj wdrożyć aplikację w GKE.

kubectl apply -f deploy.yaml

Przejrzyj zbiór zadań w konsoli i zanotuj błąd z informacją o odrzuceniu wdrożenia:

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

8. Gratulacje!

Gratulacje. Udało Ci się ukończyć ćwiczenia z programowania.

Omówione zagadnienia:

• Podpisywanie obrazów
• Zasady kontroli wstępu
• Podpisywanie zeskanowanych zdjęć
• Autoryzacja podpisanych obrazów
• Zablokowane niepodpisane obrazy

Co dalej:

• Zabezpieczanie wdrożeń obrazów w Cloud Run i Google Kubernetes Engine | Dokumentacja Cloud Build
• Krótkie wprowadzenie: konfigurowanie zasady autoryzacji plików binarnych w GKE | Google Cloud,

Czyszczenie danych

Aby uniknąć obciążenia konta Google Cloud opłatami za zasoby zużyte w tym samouczku, możesz usunąć projekt zawierający te zasoby lub zachować projekt i usunąć poszczególne zasoby.

Usuwam projekt

Najprostszym sposobem na uniknięcie płatności jest usunięcie projektu utworzonego na potrzeby samouczka.

–

Ostatnia aktualizacja: 21.03.2023 r.