En este documento se explica cómo configurar Autorización binaria para clústeres locales creados como parte de Google Distributed Cloud. A continuación, se explica cómo configurar una política de autorización binaria de ejemplo.
Antes de empezar
Asegúrate de que tus clústeres tengan una versión compatible de Google Distributed Cloud. Autorización binaria admite los siguientes entornos.
Bare metal
Google Distributed Cloud 1.14 o 1.15. En la versión 1.16 o posteriores, la autorización binaria se puede configurar durante la creación o la actualización del clúster.
VMware
Distributed Cloud for VMware (Google Distributed Cloud) 1.4 o versiones posteriores.
El servicio Autorización binaria usa una dirección IP externa a la que se puede acceder mediante una conexión a Internet normal. Configura las reglas de cortafuegos para HTTPS de forma que el clúster de usuarios pueda acceder al endpoint
binaryauthorization.googleapis.com
.Bare metal
Configura las reglas de cortafuegos de Google Distributed Cloud.
VMware
Configura las reglas de cortafuegos de Google Distributed Cloud.
Si quieres usar registros de auditoría de Cloud centralizados para ver las entradas de registro de auditoría, incluidas las de Autorización binaria para clústeres externos Google Cloud, debes configurar los registros de auditoría de Cloud en la configuración de tu clúster.
Bare metal
Configura los registros de auditoría de Cloud en Google Distributed Cloud.
VMware
Configura los registros de auditoría de Cloud en Google Distributed Cloud.
Debes habilitar la API de autorización binaria de la siguiente manera:
Ve a la Google Cloud consola.
En la lista desplegable de proyectos, selecciona el proyecto host de tu flota. Puedes encontrarlo en la sección
gkeConnect
de tu archivo de configuración de clúster de usuario. Este es el Google Cloud proyecto que conecta tu clúster de usuarios con Google Cloud.
Configurar autorización binaria
En esta sección, configurarás la autorización binaria en tu clúster local.
Especificar variables de entorno de instalación
Para especificar las variables de entorno, haga lo siguiente:
Usar Workload Identity
Especifica el proyecto host de tu flota:
export PROJECT_ID=PROJECT_ID
Asigna el ID de pertenencia a la flota al ID de tu clúster:
El ID de la suscripción se muestra en la columna
NAME
cuando ejecutas el comandogcloud container fleet memberships list
.export MEMBERSHIP_ID=CLUSTER_NAME
Usar una clave de cuenta de servicio
Especifica el proyecto host de tu flota:
export PROJECT_ID=PROJECT_ID
Sustituye PROJECT_ID por el Google Cloud proyecto en la sección
gkeConnect
de tu archivo de configuración del clúster de usuarios.Especifica la ruta del archivo kubeconfig del clúster de usuarios:
export KUBECONFIG=PATH
Sustituye PATH por la ruta del archivo kubeconfig de tu clúster de usuario.
Elige un nombre para la cuenta de servicio de acceso a la API de autorización binaria:
export SA_NAME=SERVICE_ACCOUNT_NAME
Sustituye SERVICE_ACCOUNT_NAME por el nombre de la cuenta de servicio que quieras. El módulo de autorización binaria usa esta cuenta de servicio para acceder a la API Binary Authorization.
Especifica la ruta al archivo de clave de cuenta de servicio que descargarás más adelante en esta guía:
export SA_JSON_PATH=SA_KEY_FILE_PATH
Sustituye SA_KEY_FILE_PATH por la ruta del archivo de clave JSON de la cuenta de servicio.
Instalar el módulo de autorización binaria en el clúster de usuario
Para instalar el módulo de autorización binaria, haz lo siguiente:
Usar Workload Identity
La identidad de carga de trabajo de flotas permite que las cargas de trabajo de tu clúster se autentiquen en Google sin que tengas que descargar, rotar manualmente y gestionar en general las claves de las cuentas de servicio. Google Cloud Para obtener más información sobre cómo funciona la identidad de cargas de trabajo de flotas y las ventajas de usarla, consulta el artículo Usar la identidad de cargas de trabajo de flotas.
Asigna el rol
binaryauthorization.policyEvaluator
a la cuenta de servicio de Kubernetes en el proyecto host de tu flota:gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="serviceAccount:${PROJECT_ID}.svc.id.goog[binauthz-system/binauthz-admin]" \ --role="roles/binaryauthorization.policyEvaluator"
Crea un directorio de trabajo:
Crea un directorio llamado
binauthz
.Cambia al directorio.
Descarga el archivo
manifest-wi-0.2.6.yaml.tmpl
, que se usa para instalar el módulo de autorización binaria en tu clúster de usuario:Bare metal
gcloud storage cp gs://anthos-baremetal-release/binauthz/manifest-wi-0.2.6.yaml.tmpl .
VMware
gcloud storage cp gs://gke-on-prem-release/binauthz/manifest-wi-0.2.6.yaml.tmpl .
Sustituye las variables de entorno en la plantilla:
envsubst < manifest-wi-0.2.6.yaml.tmpl > manifest-0.2.6.yaml
Instala el módulo de autorización binaria en tu clúster de usuario:
kubectl apply -f manifest-0.2.6.yaml
Verifica que se haya creado la implementación:
kubectl get pod --namespace binauthz-system
Verá el pod
binauthz-module-deployment-*
en la lista conStatus
deRunning
y 1/1 pods listos, como en este resultado:NAME READY STATUS RESTARTS AGE binauthz-module-deployment-5fddf9594f-qjprz 1/1 Running 0 11s
Usar una clave de cuenta de servicio
Define el proyecto predeterminado de Google Cloud CLI:
gcloud config set project ${PROJECT_ID}
Crea una cuenta de servicio de acceso a la API de autorización binaria:
gcloud iam service-accounts create ${SA_NAME}
Asigna el rol
binaryauthorization.policyEvaluator
a la cuenta de servicio de acceso a la API de Autorización binaria en el proyecto host de tu flota:gcloud projects add-iam-policy-binding ${PROJECT_ID}\ --member="serviceAccount:${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com" \ --role="roles/binaryauthorization.policyEvaluator"
Crea un directorio de trabajo:
Crea un directorio llamado
binauthz
.Cambia al directorio.
Descarga el archivo
manifest-0.2.6.yaml
, que se usa para instalar el módulo de autorización binaria en tu clúster de usuario:Bare metal
gcloud storage cp gs://anthos-baremetal-release/binauthz/manifest-0.2.6.yaml .
VMware
gcloud storage cp gs://gke-on-prem-release/binauthz/manifest-0.2.6.yaml .
Crea un archivo YAML para el espacio de nombres
binauthz-system
.Copia lo siguiente en un archivo llamado
namespace.yaml
:apiVersion: v1 kind: Namespace metadata: labels: control-plane: binauthz-controller name: binauthz-system
Crea el espacio de nombres en tu clúster de usuarios:
kubectl apply -f namespace.yaml
Verá un resultado similar al siguiente:
namespace/binauthz-system created
Descarga un archivo de clave JSON de tu cuenta de servicio:
gcloud iam service-accounts keys create ${SA_JSON_PATH} --iam-account ${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com
Guarda la clave de la cuenta de servicio como un secreto de Kubernetes en tu clúster de usuario:
kubectl --namespace binauthz-system create secret generic binauthz-sa --from-file=key.json=${SA_JSON_PATH}
Instala el módulo de autorización binaria en tu clúster de usuario:
kubectl apply -f manifest-0.2.6.yaml
Verifica que se haya creado la implementación:
kubectl get pod --namespace binauthz-system
Verá el pod
binauthz-module-deployment-*
en la lista conStatus
deRunning
y 1/1 pods listos, como en este resultado:NAME READY STATUS RESTARTS AGE binauthz-module-deployment-5fddf9594f-qjprz 1/1 Running 0 11s
Configurar y usar políticas de autorización binaria
En esta sección se explica cómo configurar y usar políticas de autorización binaria en clústeres locales.
En cada ejemplo, se configura la política y, a continuación, se prueba intentando desplegar una imagen de contenedor en el clúster.
Permitir todas
En esta sección se muestra un caso de éxito. Configura la política de autorización binaria para que una imagen de contenedor cumpla la política y se despliegue.
En Google Cloud, haz lo siguiente:
Consola
En la Google Cloud consola, ve a la página Autorización binaria.
Asegúrate de seleccionar el ID del proyecto host de tu flota.
Haz clic en Editar política.
En Regla predeterminada del proyecto, selecciona Permitir todas las imágenes.
Haz clic en Save Policy.
gcloud
Define el
PROJECT_ID
de tu proyecto de host de flota. Puedes encontrar este ID de proyecto en el campogkeConnect
de tu archivo de configuración del clúster de usuario.export PROJECT_ID=PROJECT_ID
Configura el proyecto Google Cloud predeterminado.
gcloud config set project ${PROJECT_ID}
Exporta el archivo YAML de la política a tu sistema local:
gcloud container binauthz policy export > policy.yaml
El archivo YAML tendrá este aspecto:
defaultAdmissionRule: enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG evaluationMode: ALWAYS_ALLOW globalPolicyEvaluationMode: ENABLE name: projects/<var>PROJECT_ID</var>/policy
Editar
policy.yaml
.Asigna el valor
ALWAYS_ALLOW
aevaluationMode
.Si tienes un bloque
requireAttestationsBy
en el archivo, elimínalo.Guarda el archivo.
Importa
policy.yaml
de la siguiente manera:gcloud container binauthz policy import policy.yaml
Para añadir una imagen exenta a la lista de permitidas, añade lo siguiente al archivo de políticas:
admissionWhitelistPatterns: - namePattern: EXEMPT_IMAGE_PATH
Sustituye EXEMPT_IMAGE_PATH
por la ruta de la imagen que quieras excluir. Para excluir más imágenes, añada más entradas - namePattern
. Consulta más información sobre admissionWhitelistPatterns
.
En tu estación de trabajo de administrador, haz lo siguiente:
Crea un archivo de manifiesto para un pod.
Guarda lo siguiente en un archivo llamado
pod.yaml
:apiVersion: v1 kind: Pod metadata: name: test-pod spec: containers: - name: test-container image: us-docker.pkg.dev/google-samples/containers/gke/hello-app@sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4
Crea el Pod:
kubectl apply -f pod.yaml
Verás que el pod se ha desplegado correctamente.
Elimina el pod:
kubectl delete -f pod.yaml
No permitir ninguno
En esta sección se muestra un caso de fallo. En esta sección, configurará la política predeterminada para impedir que se despliegue su imagen de contenedor.
En Google Cloud , haz lo siguiente:
Consola
En la Google Cloud consola, ve a la página Autorización binaria.
Asegúrate de que esté seleccionado el proyecto host de tu flota.
Haz clic en Editar política.
En Regla predeterminada del proyecto, selecciona No permitir todas las imágenes.
Haz clic en Guardar política.
gcloud
Asigna el valor
PROJECT_ID
al ID del proyecto host de tu flota.export PROJECT_ID=PROJECT_ID
Configura el proyecto Google Cloud predeterminado.
gcloud config set project ${PROJECT_ID}
Exporta el archivo YAML de la política:
gcloud container binauthz policy export > policy.yaml
Editar
policy.yaml
.Asigna el valor
ALWAYS_DENY
aevaluationMode
.Si tienes un bloque
requireAttestationsBy
en el archivo, elimínalo.Guarda el archivo.
Importa
policy.yaml
de la siguiente manera:gcloud container binauthz policy import policy.yaml
En tu estación de trabajo de administrador, haz lo siguiente:
Crea un archivo de manifiesto para un pod.
Guarda lo siguiente en un archivo llamado
pod.yaml
:apiVersion: v1 kind: Pod metadata: name: test-pod spec: containers: - name: test-container image: us-docker.pkg.dev/google-samples/containers/gke/hello-app@sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4
Crea el Pod:
kubectl apply -f pod.yaml
Verás que se ha bloqueado la implementación del pod. La salida tiene el siguiente aspecto:
Error from server (VIOLATES_POLICY): error when creating "pod.yaml": admission webhook "binaryauthorization.googleapis.com" denied the request: Denied by default admission rule. Overridden by evaluation mode
Obtener el ID de recurso del clúster de usuarios
En esta sección se muestra cómo crear el ID de recurso de clúster para tu clúster de usuario. En tu política de autorización binaria, puedes crear reglas específicas de clúster. Estas reglas se asocian a un ID de recurso específico del clúster, que se basa en el ID del clúster.
Para obtener el ID de recurso, sigue estos pasos:
Consola
En la Google Cloud consola, ve a la página Clusters de GKE.
Selecciona el ID del proyecto host de la flota de tus clústeres. Puedes encontrar este ID de proyecto en la sección
gkeConnect
del archivo de configuración de tu clúster de usuario.En la lista de clústeres, busque el ID de su clúster en la columna Nombre.
Para crear el ID de recurso, añade el prefijo
global.
al ID de clúster para que el ID de recurso tenga el siguiente formato:global.CLUSTER_ID
.
gcloud
Usa SSH para conectarte a tu estación de trabajo de administrador.
En la estación de trabajo del administrador, ejecuta el siguiente comando:
kubectl get membership -o yaml
Obtén el ID del clúster del campo
spec.owner.id
de la salida. Ejemplo de salida:apiVersion: v1 items: - apiVersion: hub.gke.io/v1 kind: Membership ... spec: owner: id: //gkehub.googleapis.com/projects/PROJECT_NUMBER/locations/global/memberships/my-cluster-id
En el ejemplo de salida, el ID del clúster es
my-cluster-id
.Para crear el ID de recurso, añade el prefijo
global.
al ID de clúster. En el ejemplo, el ID de recurso esglobal.my-cluster-id
.
Este ID de recurso se usa al definir reglas específicas de un clúster. Consulta cómo definir reglas específicas de un clúster mediante la Google Cloud consola o la CLI de gcloud.
Actualizar la política de errores
El webhook del módulo de autorización binaria se puede configurar para que falle abierto o falle cerrado.
Cierre en caso de fallo
Para actualizar la política de errores a fail close, haz lo siguiente:
Edita el archivo manifest-0.2.6.yaml y asigna el valor
Fail
a failurePolicy.Vuelve a habilitar el webhook:
kubectl apply -f manifest-0.2.6.yaml
Verá un resultado similar al siguiente:
serviceaccount/binauthz-admin unchanged role.rbac.authorization.k8s.io/binauthz-role configured clusterrole.rbac.authorization.k8s.io/binauthz-role configured rolebinding.rbac.authorization.k8s.io/binauthz-rolebinding unchanged clusterrolebinding.rbac.authorization.k8s.io/binauthz-rolebinding unchanged secret/binauthz-tls unchanged service/binauthz unchanged deployment.apps/binauthz-module-deployment unchanged validatingwebhookconfiguration.admissionregistration.k8s.io/binauthz-validating-webhook-configuration configured
Apertura en caso de fallo
Para actualizar la política de errores a la opción de apertura en caso de fallo, haz lo siguiente:
Edita el archivo manifest-0.2.6.yaml y asigna el valor
Ignore
a failurePolicy.Vuelve a habilitar el webhook:
kubectl apply -f manifest-0.2.6.yaml
Verá un resultado similar al siguiente:
serviceaccount/binauthz-admin unchanged role.rbac.authorization.k8s.io/binauthz-role configured clusterrole.rbac.authorization.k8s.io/binauthz-role configured rolebinding.rbac.authorization.k8s.io/binauthz-rolebinding unchanged clusterrolebinding.rbac.authorization.k8s.io/binauthz-rolebinding unchanged secret/binauthz-tls unchanged service/binauthz unchanged deployment.apps/binauthz-module-deployment unchanged validatingwebhookconfiguration.admissionregistration.k8s.io/binauthz-validating-webhook-configuration configured
Para obtener más información, consulta la política de fallos de webhooks.
Limpieza
En el siguiente código de ejemplo se muestra cómo inhabilitar la webhook:
kubectl delete ValidatingWebhookConfiguration/binauthz-validating-webhook-configuration
En el siguiente código de ejemplo se muestra cómo volver a habilitar la webhook:
kubectl apply -f manifest-0.2.6.yaml
En el siguiente ejemplo de código se muestra cómo eliminar todos los recursos relacionados con la autorización binaria:
kubectl delete -f manifest-0.2.6.yaml kubectl delete namespace binauthz-system
Siguientes pasos
- Para comprobar el cumplimiento de las políticas en el momento de la creación de un pod sin bloquearlo, consulta Habilitar la ejecución de prueba.
- Para forzar la creación de un pod que el verificador de autorización binaria bloquearía, consulta Usar Breakglass.
- Usa el
built-by-cloud-build
attestor para desplegar solo imágenes creadas por Cloud Build. - Para implementar una política de autorización binaria basada en un attestor, consulta lo siguiente:
- Configura una política con la Google Cloud consola o la herramienta de línea de comandos. Define la regla predeterminada o específica del clúster para requerir certificaciones.
- Crea un attestor mediante la Google Cloud consola o la herramienta de línea de comandos.
- Crea una certificación.
- Para ver los eventos de registro relacionados con la autorización binaria de Distributed Cloud, consulta Ver eventos de registros de auditoría de Cloud.
- Monitorizar métricas