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:
- Kod do tworzenia obrazu kontenera jest przekazywany do repozytorium źródłowego, takiego jak Cloud Source Repositories.
- Cloud Build kompiluje i testuje kontener za pomocą narzędzia do ciągłej integracji.
- Kompilacja przenosi obraz kontenera do Container Registry lub innego rejestru, w którym przechowywane są skompilowane obrazy.
- 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.
- 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
- 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.
- 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/proces jest odpowiedzialny 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 będą prawdopodobnie zarządzane przez oddzielne projekty Google Cloud Platform (GCP), a dostęp do zasobów byłby między nimi w ograniczony sposób udostępniany 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 wią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
- Sprawdź obecną zasadę
gcloud container binauthz policy export
- Zauważ, że zasada egzekwowania jest ustawiona na
ALWAYS_ALLOW
evaluationMode: ALWAYS_ALLOW
- 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
- Sprawdź, czy wdrożenie zadziałało
kubectl get pods
Zobaczysz następujące dane wyjściowe
- Usuń wdrożenie
kubectl delete pod hello-server
Odrzuć wszystkie zasady
Teraz zaktualizuj zasadę, żeby nie zezwalać na wyświetlanie wszystkich obrazów.
- Eksportuj bieżącą zasadę do pliku z możliwością edycji
gcloud container binauthz policy export > policy.yaml
- 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.
- Otwórz Terminal i zastosuj nową zasadę, a następnie poczekaj kilka sekund na rozpowszechnienie zmiany
gcloud container binauthz policy import policy.yaml
- Próba wdrożenia przykładowego zbioru zadań
kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080
- 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.
- Zmień zasadę
W edytorze tekstu zmień wartość 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
- 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.
- 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'
- 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 być teraz dostępny 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
Przejrzyj 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.