Información general sobre seguridad

El objetivo de Kf es ofrecer una experiencia de desarrollo similar a la de Cloud Foundry, replicando el ciclo de vida de compilación, envío e implementación. Para ello, crea una capa de experiencia de usuario para desarrolladores sobre tecnologías ampliamente conocidas, usadas y adoptadas, como Kubernetes, Istio y los registros de contenedores, en lugar de implementar todas las piezas desde cero.

A la hora de tomar decisiones sobre seguridad, Kf ofrece soluciones completas que son nativas de sus respectivos componentes y que se pueden complementar con otros mecanismos. Vamos a analizar estos elementos por separado:

  • Soluciones completas: Kf intenta no proporcionar soluciones parciales que puedan generar una falsa sensación de seguridad.
  • Nativo significa que las soluciones deben formar parte del componente en lugar de ser una estructura de Kf para evitar cambios que provoquen errores.
  • Se puede aumentar: el enfoque de Kf debería funcionar a la perfección con otras herramientas de Kubernetes y Google Cloud para ofrecer una defensa en profundidad.

Cuestiones importantes

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

Workload Identity

De forma predeterminada, Kf usa Workload Identity para proporcionar una entrega y una rotación seguras de las credenciales de la cuenta de servicio que usa Kf para interactuar con tu proyecto de Google Cloud . Workload Identity lo consigue asociando 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 un KSA llamado controller asignado a tu GSA para hacer lo siguiente:

  1. Escribir métricas en Stackdriver
  2. Cuando se crea un nuevo espacio de Kf (kf create-space), el controlador de Kf crea un nuevo KSA llamado kf-builder en el nuevo espacio y lo asigna al mismo GSA.
  3. Tekton usa la kf-builder KSA para insertar y extraer imágenes de contenedor en Google Container Registry (gcr.io).

En este diagrama se ilustran esas interacciones:

Limitaciones actuales

  • Kf no proporciona roles de control de acceso basado en roles predefinidos. Hasta que Kf proporcione esta función, usa el control de acceso basado en roles.

  • Un desarrollador que suba una aplicación con Kf también puede crear pods (con kubectl) que puedan usar el KSA kf-builder con los permisos de su GSA asociada.

  • Para implementar en Kf, se necesita acceso de escritura a un registro de contenedores. Despliega Kf en un proyecto dedicado sin acceso a los recursos de producción. Concede a los desarrolladores acceso para enviar código al repositorio de artefactos otorgándoles el rol roles/storage.admin en el proyecto o en los buckets que utiliza el repositorio de artefactos.

  • Kf usa el mismo pod para obtener, compilar y almacenar imágenes. Ten en cuenta que los autores y editores de los paquetes de compilación que utilices pueden conocer las credenciales que proporciones.

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

Otros recursos

General

Protección avanzada