Esta página se ha traducido con Cloud Translation API.

Configuración de clústeres on-premise

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:
1. Ve a la Google Cloud consola.
  
  Habilitar APIs
2. 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 comando gcloud 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:
1. Crea un directorio llamado binauthz.
2. 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 con Status de Running 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:
1. Crea un directorio llamado binauthz.
2. 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 con Status de Running 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.

Ir a 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 campo gkeConnect 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 a evaluationMode.
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.

Ir a 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 a evaluationMode.
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.

Ir a Clústeres
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 es global.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