Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
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.
Descripción general de la seguridad
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 para interactuar con tu Google Cloud proyecto. 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:
Escribe métricas en Stackdriver.
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.
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.
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 depósitos 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.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-04 (UTC)"],[],[],null,["# Security Overview\n\nKf aims to provide a similar developer experience to Cloud Foundry, replicating the build, push, and deploy lifecycle. It does this by building a developer UX layer on top of widely-known, broadly used and adopted technologies like Kubernetes, Istio, and container registries rather than by implementing all the pieces from the ground up.\n| **Note:** Kf should be used in a Google Cloud project dedicated to your evaluation. See [Important considerations](#important_considerations) for more information.\n\nSecurity overview\n-----------------\n\nWhen making security decisions, Kf aims to provide complete solutions that are native to their respective components and can be augmented with other mechanisms. Breaking that down:\n\n- **Complete solutions** means that Kf tries not to provide partial solutions that can lead to a false sense of security.\n- **Native** means that the solutions should be a part of the component rather than a Kf construct to prevent breaking changes.\n- **Can be augmented** means the approach Kf takes should work seamlessly with other Kubernetes and Google Cloud tooling for defense in depth.\n\nImportant considerations\n------------------------\n\nIn addition to the [Current limitations](#current_limitations) described below, it is important that you read through and understand the items outlined in this section.\n\n### Workload Identity\n\nBy default, Kf uses [Workload Identity](/kubernetes-engine/docs/how-to/workload-identity) to provide secure delivery and rotation of the Service Account credentials used by Kf to interact with your Google Cloud project. Workload Identity achieves this by mapping a Kubernetes Service Account (KSA) to a Google Service Account (GSA). The Kf controller runs in the `kf` namespace and uses a KSA named `controller` mapped to your GSA to do the following things:\n\n1. Write metrics to Stackdriver\n2. When a new Kf space is created (`kf create-space`), the Kf controller creates a new KSA named `kf-builder` in the new space and maps it to the same GSA.\n3. The `kf-builder` KSA is used by Tekton to push and pull container images to Google Container Registry (gcr.io)\n\nThis diagram illustrates those interactions:\n\n### Current limitations\n\n- Kf doesn't provide pre-built RBAC roles.\n - Until Kf provides this, use [RBAC](/kubernetes-engine/docs/how-to/role-based-access-control).\n- A developer pushing an app with Kf may also create pods (with `kubectl`) that can use the `kf-builder` KSA with the permissions of its associated GSA.\n- Deploying to Kf requires write access to a container registry.\n - Deploy Kf in a dedicated project without access to production resources.\n - Grant developers access to push code to the Artifact Repository by [granting them `roles/storage.admin`](/container-registry/docs/access-control) on the project, or buckets that Artifact Repository uses.\n- Kf uses the same Pod to fetch, build, and store images.\n - Assume any credentials you provide can be known by the authors and publishers of the buildpacks you use.\n- Kf doesn't support quotas to protect against noisy neighbors.\n - Use Kubernetes [resource quotas](https://kubernetes.io/docs/concepts/policy/resource-quotas/).\n\nOther resources\n---------------\n\n### General\n\n- [GKE security overview](/kubernetes-engine/docs/concepts/security-overview)\n- [GKE cluster multi-tenancy](/kubernetes-engine/docs/concepts/multitenancy-overview)\n- [Workload Identity](/kubernetes-engine/docs/how-to/workload-identity)\n- [GKE and IAM policies](/kubernetes-engine/docs/how-to/iam)\n\n### Recommended protections\n\n- [Protecting cluster metadata](/kubernetes-engine/docs/how-to/protecting-cluster-metadata)\n- [Role-based access control](/kubernetes-engine/docs/how-to/role-based-access-control)\n\n### Advanced protections\n\n- [GKE Sandbox](/kubernetes-engine/docs/how-to/sandbox-pods)\n- [Network policies](/kubernetes-engine/docs/how-to/network-policy)"]]
