En este instructivo, se muestra cómo ajustar, configurar y usar la autorización binaria para Google Kubernetes Engine (GKE). La autorización binaria es un proceso que consiste en crear certificaciones en imágenes de contenedor con el fin de verificar que se cumplan ciertos criterios antes de implementar las imágenes en GKE
Por ejemplo, la autorización binaria puede verificar que una app superó las pruebas de unidades o que se compiló mediante un conjunto específico de sistemas. Para obtener más información, consulta Descripción general de Software Delivery Shield.
Este instructivo está dirigido a profesionales que desean comprender mejor el análisis de vulnerabilidades de contenedores y la autorización binaria, además de su implementación y aplicación en una canalización de IC/IC.
En este instructivo, se da por sentado que tienes un conocimiento básico sobre los siguientes temas y tecnologías:
- La integración y la implementación continuas
- El análisis de vulnerabilidades y riesgos comunes (CVE)
- GKE
- Artifact Registry
- Cloud Build
- Cloud Key Management Service (Cloud KMS)
Objetivos
- Implementar clústeres de GKE para la etapa de pruebas y la producción
- Crear varios certificadores y certificaciones
- Implementar una canalización de IC/EC con Cloud Build
- Probar la canalización de la implementación
- Desarrollar un proceso de emergencia
Costos
En este documento, usarás los siguientes componentes facturables de Google Cloud:
Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios.
Cuando finalices las tareas que se describen en este documento, puedes borrar los recursos que creaste para evitar que continúe la facturación. Para obtener más información, consulta Cómo realizar una limpieza.
Antes de comenzar
- Accede a tu cuenta de Google Cloud. Si eres nuevo en Google Cloud, crea una cuenta para evaluar el rendimiento de nuestros productos en situaciones reales. Los clientes nuevos también obtienen $300 en créditos gratuitos para ejecutar, probar y, además, implementar cargas de trabajo.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.
-
Habilita las API de Binary Authorization, Cloud Build, Cloud KMS, GKE, Artifact Registry, Artifact Analysis, Resource Manager, and Cloud Source Repositories.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.
-
Habilita las API de Binary Authorization, Cloud Build, Cloud KMS, GKE, Artifact Registry, Artifact Analysis, Resource Manager, and Cloud Source Repositories.
-
En la consola de Google Cloud, activa Cloud Shell.
En la parte inferior de la consola de Google Cloud, se inicia una sesión de Cloud Shell en la que se muestra una ventana de línea de comandos. Cloud Shell es un entorno de shell con Google Cloud CLI ya instalada y con valores ya establecidos para el proyecto actual. La sesión puede tardar unos segundos en inicializarse.
Todos los comandos de este instructivo se ejecutan en Cloud Shell.
Arquitectura de la canalización de IC/EC
Un aspecto importante del ciclo de vida del desarrollo de software (SDLC) es garantizar y exigir que las implementaciones de apps sigan los procesos aprobados de la organización. Un método para establecer estas verificaciones y equilibrios es usar la autorización binaria en GKE. En primer lugar, la autorización binaria adjunta notas a las imágenes de contenedor. Luego, GKE verifica que las notas obligatorias estén presentes para que puedas implementar la app.
Estas notas, o certificaciones, realizan declaraciones sobre la imagen. Las certificaciones se pueden configurar por completo; los siguientes son algunos ejemplos comunes:
- La app aprobó las pruebas de unidades.
- El equipo de control de calidad (QA) verificó la app.
- La app se analizó en busca de vulnerabilidades y no se encontró ninguna.
En el siguiente diagrama, se muestra un SDLC en el que se aplica una sola certificación una vez que finaliza el análisis de vulnerabilidades, sin vulnerabilidades conocidas.
En este instructivo, crearás una canalización de CI/CD mediante Cloud Source Repositories, Cloud Build, Artifact Registry y GKE. En el siguiente diagrama, se ilustra la canalización de CI/CD.
Esta canalización de IC/EC consta de los siguientes pasos:
Compila una imagen de contenedor con el código fuente de la app.
Envía la imagen de contenedor a Artifact Registry.
Artifact Analysis analiza la imagen de contenedor en busca de vulnerabilidades de seguridad conocidas o CVE.
Si la imagen no contiene CVE con una puntuación de gravedad mayor que cinco, se certifica que no tiene CVE críticas y se implementa de forma automática en etapa de pruebas. Una puntuación superior a cinco indica una vulnerabilidad de rango medio a crítico y, por lo tanto, no se certifica ni se implementa.
Un equipo de control de calidad inspecciona la app en el clúster de etapa de pruebas. Si cumple con los requisitos, se aplica una certificación manual que indica que la imagen del contenedor es de calidad suficiente para la implementación en producción. Los manifiestos de producción se actualizan, y la app se implementa en el clúster de GKE de producción.
Los clústeres de GKE están configurados para examinar las imágenes de contenedor en busca de certificaciones y rechazar las implementaciones que no cuenten con las certificaciones necesarias. El clúster de GKE de etapa de pruebas solo requiere la certificación de análisis de vulnerabilidades, pero el clúster de GKE de producción requiere un análisis de vulnerabilidades y una certificación de control de calidad.
En este instructivo, debes ingresar fallas en la canalización de CI/CD para probar y verificar esta aplicación. Por último, debes implementar un procedimiento de emergencia para omitir estas verificaciones de implementación en GKE en caso de emergencia.
Configura tu entorno
En este instructivo, se usan las siguientes variables de entorno. Puedes cambiar estos valores para que coincidan con tus requisitos, pero en todos los pasos del instructivo, se supone que estas variables de entorno existen y contienen valores válidos.
En Cloud Shell, configura el proyecto de Google Cloud en el que implementarás y administrarás todos los recursos que se usan en este instructivo:
export PROJECT_ID="${DEVSHELL_PROJECT_ID}" gcloud config set project ${PROJECT_ID}
Configura la región en la que implementarás estos recursos:
export REGION="us-central1"
El clúster de GKE y las claves de Cloud KMS residen en esta región. En este instructivo, la región es
us-central1
. Para obtener más información acerca de las regiones, consulta Geografía y regiones.Configura el número del proyecto de Cloud Build:
export PROJECT_NUMBER="$(gcloud projects describe "${PROJECT_ID}" \ --format='value(projectNumber)')"
Configura el correo electrónico de la cuenta de servicio de Cloud Build:
export CLOUD_BUILD_SA_EMAIL="${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com"
Crea clústeres de GKE
Crea dos clústeres de GKE y otorga permisos de administración de identidades y accesos (IAM) para que Cloud Build implemente apps en GKE. Crear clústeres de GKE puede llevar unos minutos.
En Cloud Shell, crea un clúster de GKE para la etapa de pruebas:
gcloud container clusters create "staging-cluster" \ --project "${PROJECT_ID}" \ --machine-type "n1-standard-1" \ --region "${REGION}" \ --num-nodes "1" \ --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE
Crea un clúster de GKE para la producción:
gcloud container clusters create "prod-cluster" \ --project "${PROJECT_ID}" \ --machine-type "n1-standard-1" \ --region "${REGION}" \ --num-nodes "1" \ --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE
Otorga a la cuenta de servicio de Cloud Build permiso para implementar en GKE:
gcloud projects add-iam-policy-binding "${PROJECT_ID}" \ --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \ --role "roles/container.developer"
Crea claves de firma
Crea dos claves asimétricas de Cloud KMS para firmar certificaciones.
En Cloud Shell, crea un llavero de claves de Cloud KMS con el nombre
binauthz
:gcloud kms keyrings create "binauthz" \ --project "${PROJECT_ID}" \ --location "${REGION}"
Crea una clave asimétrica de Cloud KMS con el nombre
vulnz-signer
, que se usará para firmar y verificar certificaciones de análisis de vulnerabilidades:gcloud kms keys create "vulnz-signer" \ --project "${PROJECT_ID}" \ --location "${REGION}" \ --keyring "binauthz" \ --purpose "asymmetric-signing" \ --default-algorithm "rsa-sign-pkcs1-4096-sha512"
Crea una clave asimétrica de Cloud KMS con el nombre
qa-signer
para firmar y verificar las certificaciones del control de calidad:gcloud kms keys create "qa-signer" \ --project "${PROJECT_ID}" \ --location "${REGION}" \ --keyring "binauthz" \ --purpose "asymmetric-signing" \ --default-algorithm "rsa-sign-pkcs1-4096-sha512"
Configura certificaciones
Crea las notas que se adjuntan a las imágenes de contenedor y otorga permisos a la cuenta de servicio de Cloud Build para ver y adjuntar notas y crear los certificadores mediante las claves mencionadas en los pasos anteriores.
Crea la certificación del análisis de vulnerabilidades
En Cloud Shell, crea una nota de Artifact Analysis llamada
vulnz-note
:curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=vulnz-note" \ --request "POST" \ --header "Content-Type: application/json" \ --header "Authorization: Bearer $(gcloud auth print-access-token)" \ --header "X-Goog-User-Project: ${PROJECT_ID}" \ --data-binary @- <<EOF { "name": "projects/${PROJECT_ID}/notes/vulnz-note", "attestation": { "hint": { "human_readable_name": "Vulnerability scan note" } } } EOF
Otorga permiso a la cuenta de servicio de Cloud Build para que pueda ver y adjuntar la nota
vulnz-note
a las imágenes de contenedor:curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/vulnz-note:setIamPolicy" \ --request POST \ --header "Content-Type: application/json" \ --header "Authorization: Bearer $(gcloud auth print-access-token)" \ --header "X-Goog-User-Project: ${PROJECT_ID}" \ --data-binary @- <<EOF { "resource": "projects/${PROJECT_ID}/notes/vulnz-note", "policy": { "bindings": [ { "role": "roles/containeranalysis.notes.occurrences.viewer", "members": [ "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" ] }, { "role": "roles/containeranalysis.notes.attacher", "members": [ "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" ] } ] } } EOF
Crea el certificador de análisis de vulnerabilidades:
gcloud container binauthz attestors create "vulnz-attestor" \ --project "${PROJECT_ID}" \ --attestation-authority-note-project "${PROJECT_ID}" \ --attestation-authority-note "vulnz-note" \ --description "Vulnerability scan attestor"
Agrega la clave pública de la clave de firma del certificador:
gcloud beta container binauthz attestors public-keys add \ --project "${PROJECT_ID}" \ --attestor "vulnz-attestor" \ --keyversion "1" \ --keyversion-key "vulnz-signer" \ --keyversion-keyring "binauthz" \ --keyversion-location "${REGION}" \ --keyversion-project "${PROJECT_ID}"
Otorga permiso a la cuenta de servicio de Cloud Build para que pueda ver las certificaciones que realizó
vulnz-attestor
:gcloud container binauthz attestors add-iam-policy-binding "vulnz-attestor" \ --project "${PROJECT_ID}" \ --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \ --role "roles/binaryauthorization.attestorsViewer"
Otorga permiso a la cuenta de servicio de Cloud Build para que pueda firmar objetos mediante la clave
vulnz-signer
:gcloud kms keys add-iam-policy-binding "vulnz-signer" \ --project "${PROJECT_ID}" \ --location "${REGION}" \ --keyring "binauthz" \ --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \ --role 'roles/cloudkms.signerVerifier'
Crea la certificación de QA
En Cloud Shell, crea una nota de Artifact Analysis llamada
qa-note
:curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=qa-note" \ --request "POST" \ --header "Content-Type: application/json" \ --header "Authorization: Bearer $(gcloud auth print-access-token)" \ --header "X-Goog-User-Project: ${PROJECT_ID}" \ --data-binary @- <<EOF { "name": "projects/${PROJECT_ID}/notes/qa-note", "attestation": { "hint": { "human_readable_name": "QA note" } } } EOF
Otorga permiso a la cuenta de servicio de Cloud Build para que pueda ver y adjuntar la nota
qa-note
a las imágenes de contenedor:curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/qa-note:setIamPolicy" \ --request POST \ --header "Content-Type: application/json" \ --header "Authorization: Bearer $(gcloud auth print-access-token)" \ --header "X-Goog-User-Project: ${PROJECT_ID}" \ --data-binary @- <<EOF { "resource": "projects/${PROJECT_ID}/notes/qa-note", "policy": { "bindings": [ { "role": "roles/containeranalysis.notes.occurrences.viewer", "members": [ "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" ] }, { "role": "roles/containeranalysis.notes.attacher", "members": [ "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" ] } ] } } EOF
Crea el certificador de QA:
gcloud container binauthz attestors create "qa-attestor" \ --project "${PROJECT_ID}" \ --attestation-authority-note-project "${PROJECT_ID}" \ --attestation-authority-note "qa-note" \ --description "QA attestor"
Agrega la clave pública de la clave de firma del certificador:
gcloud beta container binauthz attestors public-keys add \ --project "${PROJECT_ID}" \ --attestor "qa-attestor" \ --keyversion "1" \ --keyversion-key "qa-signer" \ --keyversion-keyring "binauthz" \ --keyversion-location "${REGION}" \ --keyversion-project "${PROJECT_ID}"
Otorga permiso a la cuenta de servicio de Cloud Build para que pueda ver las certificaciones que realizó
qa-attestor
:gcloud container binauthz attestors add-iam-policy-binding "qa-attestor" \ --project "${PROJECT_ID}" \ --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \ --role "roles/binaryauthorization.attestorsViewer"
Otorga al equipo de control de calidad permiso para firmar certificaciones:
gcloud kms keys add-iam-policy-binding "qa-signer" \ --project "${PROJECT_ID}" \ --location "${REGION}" \ --keyring "binauthz" \ --member "group:qa-team@example.com" \ --role 'roles/cloudkms.signerVerifier'
Configura la política de autorización binaria
Aunque creaste los clústeres de GKE con --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE
, debes autorizar una política que indique a GKE qué certificaciones deben ejecutar los objetos binarios en el clúster. Las políticas de autorización binaria existen a nivel de proyecto, pero tienen la configuración del nivel de clúster.
La política que se muestra a continuación modifica la política predeterminada de las siguientes maneras:
Cambia el
evaluationMode
predeterminado aALWAYS_DENY
. Solo las imágenes exentas o las que cuentan con las certificaciones requeridas pueden ejecutarse en el clúster.Habilita
globalPolicyEvaluationMode
, que cambia la lista de anunciantes permitidos predeterminada para que solo incluya las imágenes del sistema que proporciona Google.Define las siguientes reglas de admisión de clústeres:
staging-cluster
requiere certificaciones devulnz-attestor
.prod-cluster
requiere certificaciones devulnz-attestor
yqa-attestor
.
Para obtener más información sobre las políticas de autorización binaria, consulta Referencia de la política de YAML.
En Cloud Shell, crea un archivo YAML que describa la política de autorización binaria del proyecto de Google Cloud:
cat > ./binauthz-policy.yaml <<EOF admissionWhitelistPatterns: - namePattern: docker.io/istio/* defaultAdmissionRule: enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG evaluationMode: ALWAYS_DENY globalPolicyEvaluationMode: ENABLE clusterAdmissionRules: # Staging cluster ${REGION}.staging-cluster: evaluationMode: REQUIRE_ATTESTATION enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG requireAttestationsBy: - projects/${PROJECT_ID}/attestors/vulnz-attestor # Production cluster ${REGION}.prod-cluster: evaluationMode: REQUIRE_ATTESTATION enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG requireAttestationsBy: - projects/${PROJECT_ID}/attestors/vulnz-attestor - projects/${PROJECT_ID}/attestors/qa-attestor EOF
Sube la política nueva al proyecto de Google Cloud:
gcloud container binauthz policy import ./binauthz-policy.yaml \ --project "${PROJECT_ID}"
Crea el verificador del análisis de vulnerabilidades y habilita la API
Crea una imagen de contenedor que se use como paso de compilación en Cloud Build. Este contenedor compara las puntuaciones de gravedad de las vulnerabilidades detectadas en función del límite configurado. Si la puntuación está dentro del límite, Cloud Build crea una certificación en el contenedor. Si la puntuación se encuentra fuera del límite, la compilación falla, y no se crea ninguna certificación.
En Cloud Shell, crea un repositorio nuevo de Artifact Registry para almacenar la imagen del certificador:
gcloud artifacts repositories create cloudbuild-helpers \ --repository-format=DOCKER --location=${REGION}
Clona las herramientas de autorización binaria y la fuente de la aplicación de muestra:
git clone https://github.com/GoogleCloudPlatform/gke-binary-auth-tools ~/binauthz-tools
Compila y envía el contenedor del certificador del análisis de vulnerabilidades llamado
attestor
acloudbuild-helpers
Artifact Registry:gcloud builds submit \ --project "${PROJECT_ID}" \ --tag "us-central1-docker.pkg.dev/${PROJECT_ID}/cloudbuild-helpers/attestor" \ ~/binauthz-tools
Configura la canalización de Cloud Build
Crea un repositorio de Cloud Source Repositories y un activador de Cloud Build para la app de muestra y los manifiestos de Kubernetes.
Crea los repositorios de Cloud Source Repositories y Artifact Registry de hello-app
En Cloud Shell, crea un repositorio de Cloud Source Repositories para la app de muestra:
gcloud source repos create hello-app \ --project "${PROJECT_ID}"
Clona el repositorio en el entorno local:
gcloud source repos clone hello-app ~/hello-app \ --project "${PROJECT_ID}"
Copia el código de muestra en el repositorio:
cp -R ~/binauthz-tools/examples/hello-app/* ~/hello-app
Crea un repositorio nuevo de Artifact Registry para almacenar imágenes de aplicaciones:
gcloud artifacts repositories create applications \ --repository-format=DOCKER --location=${REGION}
Crea el activador de Cloud Build para hello-app
En la consola de Google Cloud, ve a la página Activadores.
Haz clic en Administrar repositorios.
Para el repositorio
hello-app
, haz clic en ... y selecciona Agregar activador.En la ventana Configuración del activador, ingresa los siguientes detalles:
- En el campo Nombre, ingresa
build-vulnz-deploy
. - En Evento, elige Enviar a una rama.
- En el campo Repositorio, elige
hello-app
en el menú. - En el campo Rama, ingresa
master
. - En Configuración, selecciona Archivo de configuración de Cloud Build (yaml or json).
- En Ubicación, selecciona Repositorio y, luego, ingresa el valor predeterminado
/cloudbuild.yaml
.
- En el campo Nombre, ingresa
Agrega los siguientes pares de Variables de sustitución:
_COMPUTE_REGION
con el valorus-central1
(o la región que elegiste al principio)_KMS_KEYRING
con el valorbinauthz
_KMS_LOCATION
con el valorus-central1
(o la región que elegiste al principio)_PROD_CLUSTER
con el valorprod-cluster
_QA_ATTESTOR
con el valorqa-attestor
_QA_KMS_KEY
con el valorqa-signer
_QA_KMS_KEY_VERSION
con el valor1
_STAGING_CLUSTER
con el valorstaging-cluster
_VULNZ_ATTESTOR
con el valorvulnz-attestor
_VULNZ_KMS_KEY
con el valorvulnz-signer
_VULNZ_KMS_KEY_VERSION
con el valor1
Haga clic en Crear.
Prueba la canalización de Cloud Build
Para probar la canalización de CI/CD, confirma y envía la app de muestra al repositorio de Cloud Source Repositories. Cloud Build detecta el cambio, compila la app y la implementa en staging-cluster
. La canalización espera hasta 10 minutos para la verificación del control de calidad. Después de que el equipo de control de calidad verifica la implementación, el proceso continúa, los manifiestos de producción de Kubernetes se actualizan, y Cloud Build implementa la app en prod-cluster
.
En Cloud Shell, confirma y envía los archivos
hello-app
al repositorio de Cloud Source Repositories para activar una compilación:cd ~/hello-app git add . git commit -m "Initial commit" git push origin master
En la consola de Google Cloud, ve a la página Historial (History).
Para ver el progreso de la compilación, haz clic en la ejecución más reciente de Cloud Build.
Cuando finalice la implementación en
staging-cluster
, ve a la página Servicios.A fin de verificar que la aplicación esté funcionando, haz clic en el vínculo Extremos para la aplicación.
Ve a la página Repositorios.
Haz clic en
applications
.Haz clic en
hello-app
.Haz clic en la imagen que validaste en la implementación de la etapa de pruebas.
Copia el valor Resumen de los detalles de la imagen. Esta información se necesita en el siguiente paso.
Para aplicar la certificación manual del control de calidad, reemplaza
...
por el valor que copiaste de los detalles de la imagen. La variableDIGEST
debe tener el formatosha256:hash-value
.El paso de compilación
Await QA attestation
también generará un comando que se puede copiar y pegar, que se muestra a continuación.DIGEST="sha256:..." # Replace with your value gcloud beta container binauthz attestations sign-and-create \ --project "${PROJECT_ID}" \ --artifact-url "${REGION}-docker.pkg.dev/${PROJECT_ID}/applications/hello-app@${DIGEST}" \ --attestor "qa-attestor" \ --attestor-project "${PROJECT_ID}" \ --keyversion "1" \ --keyversion-key "qa-signer" \ --keyversion-location "${REGION}" \ --keyversion-keyring "binauthz" \ --keyversion-project "${PROJECT_ID}"
Para verificar que la app se haya implementado, ve a la página Servicios.
Para ver la aplicación, haz clic en el vínculo del extremo.
Implementa una imagen no certificada
Hasta ahora, la app de muestra no tenía ninguna vulnerabilidad. Actualiza la app para generar un mensaje diferente y cambiar la imagen base.
En Cloud Shell, cambia la salida de
Hello World
aBinary Authorization
y la imagen base dedistroless
adebian
:cd ~/hello-app sed -i "s/Hello World/Binary Authorization/g" main.go sed -i "s/FROM gcr\.io\/distroless\/static-debian11/FROM debian/g" Dockerfile
Confirma y envía los cambios:
git add . git commit -m "Change message and base image" git push origin master
Para supervisar el estado de la canalización de IC/EC, ve a la página Historial (History) en la consola de Google Cloud.
Esta compilación falla debido a que se detectan CVE en la imagen.
Para examinar las CVE identificadas, ve a la página Images (Imágenes).
Haz clic en
hello-app
.Para revisar las CVE identificadas, haz clic en el resumen de vulnerabilidades de la imagen más reciente.
En Cloud Shell, intenta implementar la imagen nueva en producción sin la certificación del análisis de vulnerabilidades:
export SHA_DIGEST="[SHA_DIGEST_VALUE]" cd ~/hello-app sed "s/REGION/${REGION}/g" kubernetes/deployment.yaml.tpl | \ sed "s/GOOGLE_CLOUD_PROJECT/${PROJECT_ID}/g" | \ sed -e "s/DIGEST/${SHA_DIGEST}/g" > kubernetes/deployment.yaml gcloud container clusters get-credentials \ --project=${PROJECT_ID} \ --region="${REGION}" prod-cluster kubectl apply -f kubernetes
En la consola de Google Cloud, ve a la página Cargas de trabajo (Workloads).
Ir a la página Cargas de trabajo
La imagen no se pudo implementar porque no estaba firmada por
vulnz-attestor
niqa-attestor
.
Procedimiento de emergencia
A veces, debes permitir cambios que estén fuera del flujo de trabajo normal. Para permitir implementaciones de imágenes sin las certificaciones necesarias, la definición del pod se anota con una marca de política de emergencia. Habilitar esta marca hace que GKE verifique las certificaciones necesarias, pero permitirá que se implemente la imagen de contenedor y que se registren las infracciones.
Para obtener más información sobre cómo omitir las verificaciones de certificación, consulta Anula una política.
En Cloud Shell, quita el comentario de la anotación de emergencia en el manifiesto de Kubernetes:
sed -i "31s/^#//" kubernetes/deployment.yaml
Usa
kubectl
para aplicar los cambios:kubectl apply -f kubernetes
Para verificar que el cambio se haya implementado en
prod-cluster
, ve a la página Cargas de trabajo (Workloads) en la consola de Google Cloud.Ir a la página Cargas de trabajo
Ahora no aparece el mensaje de error de implementación.
Para verificar que la aplicación se implementó, ve a la página Servicios.
Para ver la aplicación, haz clic en el vínculo del extremo.
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
- En la consola de Google Cloud, ve a la página Administrar recursos.
- En la lista de proyectos, elige el proyecto que quieres borrar y haz clic en Borrar.
- En el diálogo, escribe el ID del proyecto y, luego, haz clic en Cerrar para borrar el proyecto.
¿Qué sigue?
- Recomendaciones para compilar contenedores
- Implementa una aplicación web en contenedor
- Entrega continua tipo GitOps con Cloud Build
- Imágenes base administradas
- Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.