Cómo limitar las implementaciones con autenticación binaria

1. Introducción

La autorización binaria es un control de seguridad de tiempo de implementación que garantiza que solo se implementen imágenes de contenedor confiables en Google Kubernetes Engine (GKE) o Cloud Run. Con la autorización binaria, puedes solicitar que autoridades confiables firmen las imágenes durante el proceso de desarrollo y, luego, aplicar la validación de firma en el momento de la implementación. Si aplicas la validación obligatoria, puedes ejercer más control sobre el entorno de contenedores y asegurarte de que solo se integren las imágenes verificadas al proceso de compilación y lanzamiento de actualizaciones.

En el siguiente diagrama, se muestran los componentes de una configuración de autorización binaria o Cloud Build:

**Figura 1.**Canalización de Cloud Build que crea una certificación de autorización binaria.

En esta canalización, sucede lo siguiente:

1. El código para compilar la imagen del contenedor se envía a un repositorio de código fuente, como Cloud Source Repositories.
2. Cloud Build, una herramienta de integración continua (CI), compila y prueba el contenedor.
3. Con la compilación, se envía la imagen de contenedor a Container Registry o a otro registro que almacene tus imágenes compiladas.
4. Cloud Key Management Service, que proporciona administración de claves para el par de claves criptográficas, firma la imagen de contenedor. La firma resultante se almacena en una certificación recién creada.
5. En el momento de la implementación, el certificador verifica la certificación con la clave pública del par de claves. La Autorización Binaria aplica la política, ya que exige certificaciones firmadas para implementar la imagen de contenedor.

En este lab, te enfocarás en las herramientas y técnicas para proteger los artefactos implementados. En este lab, nos enfocaremos en los artefactos (contenedores) después de que se crearon, pero no se implementaron en ningún entorno en particular.

Qué aprenderás

• Firma de imágenes
• Políticas de control de admisión
• Firma de las imágenes escaneadas
• Autoriza imágenes firmadas
• Imágenes sin firmar bloqueadas

2. Configuración y requisitos

Cómo configurar el entorno a tu propio ritmo

1. Accede a Google Cloud Console y crea un proyecto nuevo o reutiliza uno existente. Si aún no tienes una cuenta de Gmail o de Google Workspace, debes crear una.

• El Nombre del proyecto es el nombre visible de los participantes de este proyecto. Es una cadena de caracteres que no se utiliza en las APIs de Google. Puedes actualizarla en cualquier momento.
• El ID del proyecto es único en todos los proyectos de Google Cloud y es inmutable (no se puede cambiar después de configurarlo). La consola de Cloud genera automáticamente una cadena única. por lo general, no te importa qué es. En la mayoría de los codelabs, deberás hacer referencia al ID del proyecto (por lo general, se identifica como PROJECT_ID). Si no te gusta el ID generado, puedes generar otro aleatorio. También puedes probar el tuyo propio y ver si está disponible. No se puede cambiar después de este paso y se mantendrá mientras dure el proyecto.
• Para tu información, hay un tercer valor, un número de proyecto, que usan algunas APIs. Obtén más información sobre estos tres valores en la documentación.

Precaución: El ID de un proyecto es único a nivel global y ninguna otra persona puede usarlo después de seleccionarlo. Eres el único usuario de ese ID. Incluso si se borra un proyecto, el ID no se puede volver a usar.

Nota: Si usas una cuenta de Gmail, puedes configurar la ubicación predeterminada como Sin organización. Si usas una cuenta de Google Workspace, elige una ubicación adecuada para tu organización.

2. A continuación, deberás habilitar la facturación en la consola de Cloud para usar las APIs o los recursos de Cloud. Ejecutar este codelab no debería costar mucho, tal vez nada. Para cerrar recursos y evitar que se te facture más allá de este instructivo, puedes borrar los recursos que creaste o borrar todo el proyecto. Los usuarios nuevos de Google Cloud son aptos para participar en el programa Prueba gratuita de USD 300.

Configuración del entorno

Configura tu ID y número de proyecto en Cloud Shell. Guárdalas como variables PROJECT_ID y PROJECT_ID.

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

Habilita los servicios

Habilita todos los servicios necesarios con el siguiente comando:

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 

Crear repositorio de Artifact Registry

En este lab, usarás Artifact Registry para almacenar y analizar tus imágenes. Crea el repositorio con el siguiente comando.

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

Configura Docker para que use tus credenciales de gcloud cuando accedas a Artifact Registry.

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

Crea y cambia a un directorio de trabajo

mkdir vuln-scan && cd vuln-scan

Define una imagen de muestra

Crea un archivo llamado Dockerfile con los siguientes contenidos.

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

Crea un archivo llamado main.py con el siguiente contenido:

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

Compila y envía la imagen a RA

Usa Cloud Build para compilar y enviar automáticamente tu contenedor a Artifact Registry.

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

3. Firma de imágenes

Qué es un certificador

Certificador

• Esta persona o este proceso es responsable de un eslabón en la cadena de confianza del sistema.
• Posee una clave criptográfica y firma una imagen si esta pasa su proceso de aprobación.
• Si bien el Creador de políticas determina la política de manera abstracta y de alto nivel, el certificador es responsable de aplicar de manera concreta algún aspecto de la política.
• Puede ser una persona real, como un verificador de QA o un administrador, o un bot en un sistema de CI.
• La seguridad del sistema depende de su confiabilidad, por lo que es importante que sus claves privadas se mantengan seguras.

Cada uno de estos roles puede representar a una persona individual o a un equipo de personas en tu organización. En un entorno de producción, es probable que estos roles se administren a través de proyectos independientes de Google Cloud Platform (GCP) y que el acceso a los recursos se comparta entre ellos de forma limitada con Cloud IAM.

Los certificadores de Autorización Binaria se implementan sobre la API de Cloud Container Analysis, por lo que es importante describir cómo funciona esto antes de continuar. La API de Container Analysis se diseñó para permitirte asociar metadatos con imágenes de contenedor específicas.

Por ejemplo, es posible que se cree una nota para hacer un seguimiento de la vulnerabilidad Heartbleed. Luego, los proveedores de seguridad crearían escáneres para probar imágenes de contenedores en busca de la vulnerabilidad y crear un caso asociado con cada contenedor comprometido.

Además de realizar un seguimiento de las vulnerabilidades, Container Analysis se diseñó para ser una API de metadatos genéricos. La autorización binaria usa Container Analysis para asociar firmas con las imágenes de contenedor que verifica**.** Las notas de Container Analysis se usan para representar a un solo certificador, y los casos se crean y asocian con cada contenedor aprobado por el certificador.

La API de Autorización Binaria usa los conceptos de “certificadores” y “certificaciones”, pero estas se implementan mediante las Notas y los casos correspondientes en la API de Container Analysis.

Crea una nota de certificador

Una nota del certificador es solo una pequeña porción de datos que actúa como una etiqueta para el tipo de firma que se aplica. Por ejemplo, una nota puede indicar un análisis de vulnerabilidades, mientras que otra podría usarse para la aprobación del control de calidad. Se hará referencia a la nota durante el proceso de firma.

Cómo crear una nota

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

Almacena la nota

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

Verifica la nota

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

Tu nota ahora se guarda en la API de Container Analysis.

Crea un certificador

Los certificadores se usan para realizar el proceso real de firma de imágenes y adjuntarán un caso de la nota a la imagen para su posterior verificación. Para usar el certificador, también debes registrar la nota en la autorización binaria:

Crear certificador

ATTESTOR_ID=vulnz-attestor

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

Verificar certificador

gcloud container binauthz attestors list

Ten en cuenta que la última línea indica NUM_PUBLIC_KEYS: 0, ya que proporcionarás claves en un paso posterior.

Además, ten en cuenta que Cloud Build crea automáticamente el certificador built-by-cloud-build en tu proyecto cuando ejecutas una compilación que genera imágenes. Por lo tanto, el comando anterior muestra dos certificadores, vulnz-attestor y built-by-cloud-build. Una vez que las imágenes se compilan correctamente, Cloud Build las firma y crea automáticamente certificaciones.

Agrega un rol de IAM

La cuenta de servicio de Autorización Binaria necesitará derechos para ver las notas de la certificación. Proporciona el acceso con la siguiente llamada a la 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

Usa el archivo para crear la política de 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"

Agrega una clave de KMS

Antes de que puedas usar este certificador, tu autoridad debe crear un par de claves criptográficas que se pueda usar para firmar imágenes de contenedor. Esto se puede hacer a través de Google Cloud Key Management Service (KMS).

Primero, agrega algunas variables de entorno para describir la clave nueva

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

Crea un llavero de claves para almacenar un conjunto de claves

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

Crea un nuevo par de claves de firma asimétrica para el certificador

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

Deberías ver tu clave en la página de KMS de la consola de Google Cloud.

Ahora, asocia la clave con el certificador a través del comando 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}"

Si vuelves a imprimir la lista de autoridades, ahora deberías ver una clave registrada:

gcloud container binauthz attestors list

Crea una certificación firmada

En este punto, tienes las funciones configuradas que te permiten firmar imágenes. Usa el certificador que creaste anteriormente para firmar la imagen de contenedor con la que trabajaste.

Una certificación debe incluir una firma criptográfica para indicar que el certificador verificó una imagen de contenedor en particular y que es seguro para que se ejecute en tu clúster. Para especificar qué imagen de contenedor certificarás, debes determinar su resumen.

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

Ahora, puedes usar gcloud para crear la certificación. El comando simplemente toma los detalles de la clave que deseas usar para firmar y la imagen del contenedor específica que deseas aprobar

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

En términos de Container Analysis, se creará un caso nuevo y se adjuntará a la nota de tu certificador. Para asegurarte de que todo funcione según lo esperado, puedes enumerar tus certificaciones.

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

4. Políticas de control de admisión

La Autorización Binaria es una función de GKE y Cloud Run que proporciona la capacidad de validar reglas antes de que se permita la ejecución de una imagen de contenedor. La validación se ejecuta en cualquier solicitud para ejecutar una imagen, ya sea desde una canalización de CI/CD confiable o cuando un usuario intenta implementar una imagen de forma manual. Esta capacidad te permite proteger los entornos de ejecución de forma más eficaz que las verificaciones de canalización de CI/CD solas.

Para comprender esta capacidad, modificarás la política de GKE predeterminada para aplicar una regla de autorización estricta.

Crea el clúster de GKE

Crea el clúster de GKE con la autorización binaria habilitada:

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

Permite que Cloud Build se implemente en este clúster:

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

Permitir todas las políticas

Primero, verifica el estado de la política predeterminada y tu capacidad para implementar cualquier imagen

1. Revisar la política existente

gcloud container binauthz policy export

2. Ten en cuenta que la política de aplicación está establecida en ALWAYS_ALLOW

evaluationMode: ALWAYS_ALLOW

3. Implementa la muestra para verificar que puedes implementar lo que quieras

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

4. Verifica que la implementación funcionó

kubectl get pods

Verás el siguiente resultado:

5. Borrar implementación

kubectl delete pod hello-server

Rechazar todas las políticas

Ahora, actualiza la política para inhabilitar todas las imágenes.

1. Exporta la política actual a un archivo editable

gcloud container binauthz policy export  > policy.yaml

2. Cambiar la política.

En un editor de texto, cambia el modo de evaluación de ALWAYS_ALLOW a ALWAYS_DENY.

edit policy.yaml

El archivo de políticas en formato YAML debe aparecer de la siguiente manera:

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

Esta política es relativamente simple. La línea globalPolicyEvaluationMode declara que esta política extiende la política global definida por Google. Esto permite que todos los contenedores oficiales de GKE se ejecuten de forma predeterminada. Además, la política declara una defaultAdmissionRule que establece que se rechazarán todos los demás Pods. La regla de admisión incluye una línea enforcementMode, que establece que todos los Pods que no cumplan con esta regla deben bloquearse y evitar que se ejecuten en el clúster.

Si quieres obtener instrucciones para compilar políticas más complejas, consulta la documentación de Autorización Binaria.

3. Abre la Terminal, aplica la política nueva y espera unos segundos para que se propague el cambio.

gcloud container binauthz policy import policy.yaml

4. Intento de implementación de carga de trabajo de muestra

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

5. La implementación falla con el siguiente mensaje

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

Revertir la política para permitir todo

Antes de pasar a la siguiente sección, asegúrate de revertir los cambios en la política.

1. Cambiar la política.

En un editor de texto, cambia el modo de evaluación de ALWAYS_DENY a ALWAYS_ALLOW.

edit policy.yaml

El archivo de políticas en formato YAML debe aparecer de la siguiente manera:

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

2. Aplicar la política revertida

gcloud container binauthz policy import policy.yaml

5. Firma de las imágenes escaneadas

Habilitaste la firma de imágenes y usaste el certificador de forma manual para firmar tu imagen de muestra. En la práctica, se recomienda aplicar certificaciones durante los procesos automatizados, como las canalizaciones de CI/CD.

En esta sección, configurarás Cloud Build para certificar imágenes automáticamente.

Funciones

Agrega la función de visualizador de certificadores de autorización binaria a la cuenta de servicio de Cloud Build:

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

Agrega la función de verificador y firmante de CryptoKey de Cloud KMS a la cuenta de servicio de Cloud Build (firma basada en KMS):

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

Agrega la función de vinculador de notas de Container Analysis a la cuenta de servicio de Cloud Build:

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

Proporciona acceso a la cuenta de servicio de Cloud Build

Cloud Build necesitará derechos para acceder a la API de análisis a pedido. Proporciona acceso con los siguientes comandos.

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"

Prepara el paso de compilación personalizada de Cloud Build

Usarás un paso de compilación personalizada en Cloud Build para simplificar el proceso de certificación. Google proporciona este paso de Compilación personalizada que contiene funciones auxiliares para optimizar el proceso. Antes de usarlo, el código para el paso de compilación personalizado debe compilarse en un contenedor y enviarse a Cloud Build. Para ello, ejecuta los siguientes comandos:

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

Agrega un paso de firma a tu archivo cloudbuild.yaml

En este paso, agregarás el paso de certificación a tu canalización de Cloud Build.

1. Revisa el paso de firma que se muestra a continuación.

Solo revisión. No copiar

#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. Escribe un archivo cloudbuild.yaml con la canalización completa a continuación.

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

Ejecuta la compilación

gcloud builds submit

Revisa la compilación en el historial de Cloud Build

Abre la consola de Cloud, ve a la página Historial de Cloud Build y revisa la compilación más reciente y la ejecución correcta de los pasos de compilación.

6. Autoriza imágenes firmadas

En esta sección, actualizarás GKE para usar la autorización binaria y así validar que la imagen tenga una firma del análisis de vulnerabilidades antes de permitir que se ejecute.

Actualizar la política de GKE para requerir certificación

Agrega clusterAdmissionRules a tu política de BinAuth de GKE para exigir que las imágenes estén firmadas por tu certificador

Actualmente, tu clúster ejecuta una política con una regla: permitir contenedores de repositorios oficiales y rechazar todas las demás.

Usa el siguiente comando para reemplazar la política por la configuración actualizada.

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

Ahora deberías tener un nuevo archivo en el disco, llamado updated_policy.yaml. Ahora, en lugar de que la regla predeterminada rechace todas las imágenes, primero comprueba las verificaciones del certificador.

Sube la política nueva a Autorización Binaria:

gcloud beta container binauthz policy import binauth_policy.yaml

Implementa una imagen firmada

Obtén el resumen de la imagen de calidad

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

Usa el resumen en la configuración de 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

Implementar la app en GKE.

kubectl apply -f deploy.yaml

Revisa la carga de trabajo en la consola y observa que la imagen se implementó correctamente.

7. Imágenes sin firmar bloqueadas

Cómo crear una imagen

En este paso, usarás Docker local para compilar la imagen en tu caché local.

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

Envía la imagen sin firmar al repositorio

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

Obtén el resumen de la imagen defectuosa

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

Usa el resumen en la configuración de 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

Intenta implementar la app en GKE

kubectl apply -f deploy.yaml

Revisa la carga de trabajo en la consola y observa el error que indica que se rechazó la implementación:

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

8. ¡Felicitaciones!

¡Felicitaciones! Completaste el codelab.

Temas abordados:

• Firma de imágenes
• Políticas de control de admisión
• Firma de las imágenes escaneadas
• Autoriza imágenes firmadas
• Imágenes sin firmar bloqueadas

¿Qué sigue?

• Protege las implementaciones de imágenes en Cloud Run y Google Kubernetes Engine | Documentación de Cloud Build
• Guía de inicio rápido: Configura una política de Autorización Binaria con GKE | Google Cloud

Limpia

Para evitar que se apliquen cargos a tu cuenta de Google Cloud por los recursos usados en este instructivo, borra el proyecto que contiene los recursos o conserva el proyecto y borra los recursos individuales.

Borra el proyecto

La manera más fácil de eliminar la facturación es borrar el proyecto que creaste para el instructivo.

—

Última actualización: 21 de marzo de 2023