Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
O objetivo do Kf é proporcionar aos desenvolvedores uma experiência semelhante à do Cloud Foundry, replicando o ciclo de compilação, push e implantação. Ele faz isso criando uma camada de UX de desenvolvedor com base em tecnologias amplamente conhecidas e amplamente adotadas, como Kubernetes, Istio e Container Registry, em vez de implementar todas as partes do zero.
Informações gerais da segurança
Ao tomar decisões de segurança, o Kf tem como objetivo fornecer soluções completas que são nativas dos respectivos componentes e podem ser aumentadas com outros mecanismos. Explicando melhor isso:
Soluções completas significa que o Kf tenta não fornecer soluções parciais que podem levar a uma falsa sensação de segurança.
Nativo significa que as soluções precisam fazer parte do componente em vez de uma construção Kf para evitar alterações interruptivas.
Pode ser aumentado significa que a abordagem do Kf precisa funcionar perfeitamente com outras ferramentas do Kubernetes e do Google Cloud para defesa em profundidade.
Considerações importantes
Além das limitações atuais descritas abaixo, é importante ler e entender os itens descritos nesta seção.
Identidade da carga de trabalho
Por padrão, o Kf usa a identidade da carga de trabalho para a entrega e a rotação seguras das credenciais da conta de serviço usada pelo Kf para interagir com o projeto do Google Cloud . Para isso, a Identidade da carga de trabalho associa uma conta de serviço do Kubernetes (KSA, na sigla em inglês) a uma conta de serviço do Google (GSA, na sigla em inglês). O controlador Kf é executado no namespace kf e usa a KSA controller, associada a uma GSA, para fazer o seguinte:
Gravar métricas no Stackdriver
Quando um espaço do Kf é criado (kf create-space), o controlador do Kf cria uma KSA chamada kf-builder no novo espaço e a associa à mesma GSA.
A KSA kf-builder é usada pela Tekton para enviar e extrair imagens de contêiner para o Google Container Registry (gcr.io)
Um desenvolvedor que envia um aplicativo com o Kf também pode criar pods (com kubectl) que podem usar o KSA kf-builder com as permissões da GSA associada.
A implantação no Kf requer acesso de gravação a um registro de contêiner.
Implante o Kf em um projeto dedicado sem acesso a recursos de produção.
Para que os desenvolvedores possam enviar código por push ao repositório de artefatos, conceda a eles roles/storage.admin no projeto ou nos buckets usados pelo repositório.
O Kf usa o mesmo pod para buscar, criar e armazenar imagens.
Suponha que todas as credenciais fornecidas por você sejam conhecidas pelos autores e editores das versões usadas.
O Kf não é compatível com cotas para proteger contra vizinhos barulhentos.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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)"]]
