Blog
Wie Sie den Kritis Signer auf Google Cloud automatisieren

Wie Sie den Kritis Signer auf Google Cloud automatisieren
Mit Google Binary Authorization können Sie die Images kontrollieren, die in Ihrem Kubernetes-Cluster zugelassen sind. Sie können die Images benennen oder nur Images zulassen, die von vertrauenswürdigen Parteien abgezeichnet werden müssen. Google dokumentiert einen manuellen Prozess zur Erstellung von Kritis-Signierbescheinigungen. In diesem Blog zeige ich Ihnen, wie Sie den Kritis-Signierer mit Terraform und Google Cloud Run automatisieren können.
Was ist der Kritis-Unterzeichner
Der Kritis Signer ist ein Befehlszeilen-Dienstprogramm
, mit dem Sie überprüfen können, ob ein Image gegen die Richtlinie für Sicherheitslücken verstößt. Nachdem der Container-Scan-Dienst einen Scan abgeschlossen hat, müssen Sie Folgendes eingeben:
signer
-mode check-and-sign
-policy policy.yaml
-note_name projects/demo/notes/passed-vulnerability-policy
-kms_key_name projects/demo/locations/eur4/keyRings/vulnerability_policy_attestors/cryptoKeys/vulnerability-attestor-XX0/cryptoKeyVersions/1
-kms_digest_alg SHA384
-image $IMAGE_TO_SCAN
Dieser Befehl prüft, ob der Image-Schwachstellen-Scan die folgende Richtlinie erfüllt:
apiVersion: Kritis.grafeas.io/v1beta1
kind: VulnzSigningPolicy
metadata:
name: my-vsp
spec:
imageVulnerabilityRequirements:
maximumFixableSeverity: MEDIUM
maximumUnfixableSeverity: MEDIUM
allowlistCVEs:
- projects/goog-vulnz/notes/CVE-2020-10543
- projects/goog-vulnz/notes/CVE-2020-10878
- projects/goog-vulnz/notes/CVE-2020-14155
Wenn das Abbild erfolgreich ist, wird eine Bescheinigung mit der Notiz passed-vulnerability-policy erstellt, die mit dem KMS-Schlüssel signiert ist.
Da dieser Befehl in eine Build-Pipeline aufgenommen werden muss, besteht die Gefahr, dass die Entwickler die Sicherheitsrichtlinien lockern. Dadurch wird die Kritis-Bescheinigung weniger wertvoll.
Automatisieren Sie den Kritis Signer
Um dem Bescheiniger den Status einer unabhängigen Entität zu geben, habe ich den Kritis Signer-Dienst erstellt. Er hört auf Container-Scan-Ereignisse. Wenn ein Schwachstellen-Scan abgeschlossen ist, führt er den Kritis Prüf- und Signiervorgang durch.
Es gibt zwei Möglichkeiten, den Signierer zu automatisieren. Sie können ein kleines Wrapper-Programm erstellen, das die Kritis-Signierfunktion aufruft. Alternativ können Sie das aktuelle Kritis-Signierprogramm um diese Funktionalität erweitern.
Ich habe mich entschieden, den Signer zu erweitern. Um ihn in die Standardversion aufzunehmen, habe ich einen Pull Request für Kritis erstellt, der am 22. Dezember 2020 zusammengeführt wurde.
Wie setzen Sie den Signer-Dienst ein?
Um den Kritis Signer-Dienst einzusetzen, führen Sie die folgenden Schritte aus:
- die Notiz definieren
- einen kms-Schlüssel erstellen
- den Bescheiniger erstellen
- den Kritis-Unterzeichner einsetzen
- abonnieren Sie die Google Container Analysis-Benachrichtigungen
Dies sind die großen Schritte. Wir lassen ein paar kleine Details wie IAM-Policy-Bindings weg, die in dieser vollständigen Terraform-Vorlage enthalten sind.
Definieren der Notiz
Ein Hinweis (es ist nicht das, was Sie denken) kennzeichnet eine bestimmte Tatsache in Bezug auf ein Bild. In diesem Fall zeigt der Hinweis an, dass ein Bild nicht gegen die Richtlinie für Sicherheitslücken verstößt. Der Hinweis wird mit diesem Terraform-Snippet definiert:
resource "google_container_analysis_note" "passed_vulnerability_policy" {
name = "passed-vulnerability-policy"
short_description = "image passed vulnerability policy"
long_description = <<EOF
attached to an image which passed the vulnerability
scan without violating the security policy.
EOF
attestation_authority {
hint {
human_readable_name = "vulnerability policy attestors"
}
}
}
Definieren des KMS-Schlüssels
Ein Zeuge ist jemand, der eine Tatsache bezeugt hat. Ein Bescheiniger bescheinigt, indem er eine schriftliche Erklärung, die so genannte Bescheinigung, unterschreibt. Diese Signatur verwendet einen KMS-Schlüssel, der mit dem folgenden Terraform-Snippet definiert wird:
resource "google_kms_key_ring" "vulnerability_policy_attestors" {
name = "vulnerability_policy_attestors"
location = "eur4"
depends_on = [google_project_service.cloudkms]
}
resource "google_kms_crypto_key" "vulnerability_policy_attestor" {
name = "vulnerability-attestor"
key_ring = google_kms_key_ring.vulnerability_policy_attestors.id
purpose = "ASYMMETRIC_SIGN"
version_template {
algorithm = "EC_SIGN_P384_SHA384"
}
}
Erstellen des Bescheinigers
Um einen Attestor zu erstellen, verknüpfen Sie den Signierschlüssel mit der Notiz, wie in diesem Terraform-Snippet gezeigt:
## Define the attestor to be and attestor of vulnerability policies
resource "google_binary_authorization_attestor" "vulnerability_policy" {
name = "vulnerability-policy"
attestation_authority_note {
note_reference = google_container_analysis_note.passed_vulnerability_policy.name
public_keys {
id = data.google_kms_crypto_key_version.vulnerability_policy_attestor.id
pkix_public_key {
public_key_pem = data.google_kms_crypto_key_version.vulnerability_policy_attestor.public_key[0].pem
signature_algorithm = local.algorithms[data.google_kms_crypto_key_version.vulnerability_policy_attestor.public_key[0].algorithm]
}
}
}
}
locals {
algorithms = { ## avoid continuous update of google_binary_authorization_attestor
"EC_SIGN_P384_SHA384" = "ECDSA_P384_SHA384"
}
}
Bereitstellung des Kritis Signer-Dienstes
Jetzt können Sie den Kritis-Signierdienst auf Google Cloud Run einsetzen, indem Sie dieses Snippet verwenden:
resource "google_cloud_run_service" "vulnerability_policy_attestor" {
name = "vulnerability-policy-attestor"
location = "europe-west1"
template {
spec {
service_account_name = google_service_account.vulnerability_policy_attestor.email
containers {
image = "gcr.io/${var.project}/gcr-kritis-signer:latest"
env {
name = "ATTESTATION_PROJECT"
value = var.project
}
env {
name = "ATTESTATION_NOTE_NAME"
value = google_container_analysis_note.passed_vulnerability_policy.id
}
env {
name = "ATTESTATION_KMS_KEY"
value = replace(data.google_kms_crypto_key_version.vulnerability_policy_attestor.id, "///cloudkms.googleapis.com/[^/]*//", "")
}
env {
name = "ATTESTATION_DIGEST_ALGORITHM"
value = "SHA384"
}
env {
name = "ATTESTATION_OVERWRITE"
value = "true"
}
env {
name = "ATTESTATION_POLICY"
value = file("policy.yaml")
}
}
}
}
depends_on = [google_project_service.run]
}
Der Dienst bietet die Endpunkte /check /check-and-sign und /event. Letzterer ist der Endpunkt für Benachrichtigungen zur Containeranalyse. Weitere Einzelheiten finden Sie in der offenen API-Spezifikation.
Abonnieren Sie die Benachrichtigungen zur Containeranalyse
Schließlich abonnieren Sie den Dienst für die Benachrichtigungen über das Auftreten von Containeranalysen, wie in diesem Ausschnitt gezeigt:
## subscribe the attestor to the container analysis occurrences events
resource "google_pubsub_subscription" "vulnerability_policy_attestor" {
name = "vulnerability-policy-attestor"
topic = "projects/${var.project}/topics/container-analysis-occurrences-v1"
ack_deadline_seconds = 30
push_config {
push_endpoint = "${google_cloud_run_service.vulnerability_policy_attestor.status[0].url}/event"
oidc_token {
service_account_email = google_service_account.vulnerability_policy_attestor_invoker.email
}
}
depends_on = [google_project_service.pubsub]
}
Jetzt signiert der Kritis Signer automatisch jedes Bild, das in die Registrierung übertragen wird.
Demo
Für die Demo erstellen Sie den kritis signer-Dienst, indem Sie eingeben:
git clone https://github.com/grafeas/kritis
cd kritis
gcloud builds submit --config deploy/gcr-kritis-signer/cloudbuild.yaml .
Dadurch wird der Kritis-Signierdienst erstellt und in der Container-Registrierung Ihres Projekts bereitgestellt.
Stellen Sie die vollständige Demo aus dem Github-Repository bereit, indem Sie Folgendes eingeben:
git clone https://github.com/binxio/gcr-kritis-signer.git
cd gcr-kritis-signer/Terraform
terraform init
terraform apply -auto-approve
Fügen Sie zwei Bilder in die Registrierung ein, indem Sie eingeben:
PROJECT=$(gcloud config get-value project)
docker pull alpine:3.2
docker tag alpine:3.2 gcr.io/$PROJECT/alpine:3.2
docker push !$
docker pull alpine:3.12
docker tag alpine:3.12 gcr.io/$PROJECT/alpine:3.12
docker push !$
Warten Sie, bis die Bilder gescannt sind, indem Sie tippen:
gcloud beta container images list-tags gcr.io/$PROJECT/alpine --show-occurrences
DIGEST TAGS TIMESTAMP VULNERABILITIES VULNERABILITY_SCAN_STATUS
d7342993700f 3.12 2020-10-22T04:19:24 FINISHED_SUCCESS
ddac200f3ebc 3.2 2019-01-30T23:20:12 HIGH=1 FINISHED_SUCCESS
Jetzt können Sie die vom Dienst erstellten Bescheinigungen sehen, indem Sie eingeben:
gcloud beta container binauthz attestations list --attestor=vulnerability-policy
---
attestation:
serializedPayload: eyJjcml0aWNhbCI6eyJpZGVudGl0eSI6eyJkb2NrZXItcmVmZXJlbmNlIjoiZ2NyLmlvL3NwZWVsdHVpbi1tdmFuaG9sc3RlaWpuLTIvYWxwaW5lIn0sImltYWdlIjp7ImRvY2tlci1tYW5pZmVzdC1kaWdlc3QiOiJzaGEyNTY6ZDczNDI5OTM3MDBmOGNkN2FiYTg0OTZjMmQwZTU3YmUwNjY2ZTgwYjRjNDQxOTI1ZmM2ZjkzNjFmYTgxZDEwZSJ9LCJ0eXBlIjoiYXRvbWljIGNvbnRhaW5lciBzaWduYXR1cmUifX0=
signatures:
- publicKeyId: //cloudkms.googleapis.com/v1/projects/binx-io-public/locations/eur4/keyRings/vulnerability_policy_attestors/cryptoKeys/vulnerability-attestor-XX0/cryptoKeyVersions/1
signature: MGYCMQDX-xe0hlYFZjDJNzNhI7Kdd-yMLVjWfT_DNUBP9mjnU6KaezIyxeng436sVYbSpQwCMQDDi5HQWnBfHCShGB1gbSbhOG6HWT6Fn6SAJzSGf_3sV0_2WuV3PwvKhBj7SSl0Xb4=
createTime: '2020-11-29T12:53:19.619920Z'
kind: ATTESTATION
name: projects/binx-io-public/occurrences/3ebccaff-67a6-4221-82ba-7e7515091342
noteName: projects/binx-io-public/notes/passed-vulnerability-policy
resourceUri: https://gcr.io/binx-io-public/alpine@sha256:d7342993700f8cd7aba8496c2d0e57be0666e80b4c441925fc6f9361fa81d10e
updateTime: '2020-11-29T12:53:19.619920Z'
Beachten Sie, dass nur ein alpine:3.12 Image eine Bescheinigung hat. Version 3.2 weist einen hohen Schweregrad der Sicherheitslücke auf und besteht die Richtlinie nicht.
Zusammenfassung
Der Kritis Vulnerability Policy Signer lässt sich mit Terraform und Cloud Run leicht automatisieren. Der Dienst ist unabhängig und wird durch Container-Scan-Ereignisse ausgelöst. Sie können sich darauf verlassen, dass das Image nicht gegen Ihre Richtlinie für Sicherheitslücken verstößt.
Bild von Free-Photos von Pixabay
Verfasst von

Mark van Holsteijn
Mark van Holsteijn is a senior software systems architect at Xebia Cloud-native solutions. He is passionate about removing waste in the software delivery process and keeping things clear and simple.
Unsere Ideen
Weitere Blogs
Contact



