Descripción general de la seguridad

Kf tiene como objetivo proporcionar una experiencia para el desarrollador similar a Cloud Foundry, por lo que busca replicar el ciclo de vida de la compilación, el envío y la implementación. Para ello, compila una capa de UX del desarrollador sobre tecnologías populares, ampliamente usadas y adoptadas, como Kubernetes, Istio y registros de contenedores, en lugar de implementar todas las piezas desde cero.

En la toma de decisiones de seguridad, Kf tiene como objetivo proporcionar soluciones completas que sean nativas para sus respectivos componentes y que pueda aumentarse con otros mecanismos. Explicación:

  • Soluciones completas significa que Kf intenta no proporcionar soluciones parciales que puedan llevar a una falsa sensación de seguridad.
  • Nativas significa que las soluciones deben ser parte del componente en lugar de una construcción de Kf para evitar cambios rotundos.
  • Que pueda aumentarse significa que el enfoque que adopta Kf debería funcionar a la perfección con otras herramientas de Kubernetes y Google Cloud para la seguridad en profundidad.

Consideraciones importantes

Además de las limitaciones actuales que se describen a continuación, es importante que leas y comprendas los elementos descritos en esta sección.

Workload Identity

De forma predeterminada, Kf usa Workload Identity para proporcionar entrega y rotación segura de las credenciales de la cuenta de servicio que usa Kf a fin de interactuar con el proyecto de Google Cloud. Para hacerlo, mapea una cuenta de servicio de Kubernetes (KSA) a una cuenta de servicio de Google (GSA). El controlador Kf se ejecuta en el espacio de nombres kf y usa una KSA llamada controller mapeada a la GSA para realizar las siguientes acciones:

  1. Escribe métricas en Stackdriver.
  2. Cuando se crea un espacio de Kf nuevo (kf create-space), el controlador de Kf crea una nueva KSA llamada kf-builder en el espacio nuevo y la mapea a la misma GSA.
  3. Tekton usa la KSA kf-builder para enviar y extraer imágenes de contenedor a Google Container Registry (gcr.io).

En este diagrama, se ilustran esas interacciones:

Limitaciones actuales

  • Kf no proporciona funciones de RBAC compiladas con anterioridad. Hasta que Kf lo haga, usa RBAC.

  • Un desarrollador que envía una app con Kf también puede crear pods (con kubectl) que pueden usar la KSA kf-builder con los permisos de la GSA asociada.

  • La implementación en Kf requiere acceso de escritura a un registro de contenedor. Implementa Kf en un proyecto dedicado sin acceso a recursos de producción. Otorga a los desarrolladores acceso a código de envío a Artifact Repository mediante la concesión de roles/storage.admin en el proyecto o buckets que usa Artifact Repository.

  • Kf usa el mismo Pod para recuperar, compilar y almacenar imágenes. Supongamos que los autores y publicadores de los paquetes de compilación que usas pueden conocer las credenciales que proporciones.

  • Kf no admite cuotas para protegerse contra vecinos ruidosos. Usa cuotas de recursos de Kubernetes.

Otros recursos

General

Protecciones avanzadas